Очистка логов postgresql windows
Обновлено: 07.07.2024
У меня следующая проблема: «Вертикальный» дистрибутив Linux (Sophos UMT) поставляется с PostgreSQL 9.2 для хранения его конфигурации. К сожалению, со времени последнего обновления создается впечатление, что журналы транзакций (WAL) некоторых экземпляров растут без каких-либо сбросов. Это приводит к тому, что папка pg_xlog растет на несколько порядков больше, чем базовая папка.
Сейчас я нахожусь в деликатной ситуации: из-за чрезмерного роста файлов WAL диск одной из этих машин (ВМ) будет заполнен до понедельника. Я уже открыл службу поддержки у поставщика, но пока они не очень полезны (они предлагают перестроить виртуальную машину с большими дисками).
Резервное копирование этой базы данных никогда не происходит, потому что программное обеспечение выполняет резервное копирование другим способом (оно имеет свою собственную процедуру резервного копирования и отправляет файлы резервных копий по электронной почте), и я полагаю, что именно по этой причине WAF так сильно растут.
Я боюсь, что я далеко не эксперт PostgreSQL, поэтому очень вероятно, что я задаю глупый или очевидный вопрос, но какова процедура запроса файлов WAL для сброса?
В идеале я ищу процедуру, которая позволит мне сбросить эти файлы WAL в проблемной системе, чтобы у меня было достаточно времени, чтобы поставщик смог выпустить лучшее исправление.
Редактировать : По запросу, вот результат SELECT version(); запроса:
И SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override'); запрос
Edit2
Наконец, мы переустановили весь сервер (в соответствии с запросом поддержки Sophos), но с использованием предыдущей версии и диска большего размера. По-видимому, более старая версия использует гораздо меньше места для WAL, чем новая.
Из любопытства я запустил проверку параметров версии и 7non-default pgsql и получил совершенно разные результаты:
Мне кажется, что между этими двумя версиями произошло довольно много изменений.
Скорее всего, то, что вы видите, имеет огромное checkpoint_segments значение и долго checkpoint_timeout ; альтернативно, они могли бы установить wal_keep_segments очень большое значение, если предполагается, что он поддерживает потоковую репликацию.
Вы можете заставить контрольную точку с помощью CHECKPOINT команды. Это может задержать базу данных на некоторое время, если она накопила огромное количество WAL и не занималась ее написанием. Если checkpoint_completion_target оно низкое (менее 0,8 или 0,9), то, вероятно, будет большое отставание в работе во время контрольной точки. Будьте готовы к тому, что база данных станет медленной и не отвечает на контрольной точке. Вы не можете отменить контрольную точку, если она начинается обычным способом; Вы можете разбить базу данных и перезапустить ее, но это просто вернет вас туда, где вы были.
Я не уверен, но я чувствую, что контрольная точка может также привести к росту основной базы данных - и сделать это до освобождения любого пространства в WAL, если оно вообще есть. Таким образом, контрольная точка может привести к тому, что у вас не хватит места, что очень трудно восстановить, не добавляя больше памяти хотя бы временно.
Сейчас самое подходящее время, чтобы получить правильную резервную копию базы данных - использовать pg_dump -Fc dbname для выгрузки каждой базы данных, а также pg_dumpall --globals-only для выгрузки пользовательских определений и т. Д.
Если вы можете позволить себе простоя, остановить базу данных и принять на уровне файловой системы , копию всего каталога данных (папку , содержащую pg_xlog , pg_clog , global , base , и т.д.). Не делайте этого, пока сервер работает, и не пропускайте никакие файлы или папки, они все важны (ну, за исключением pg_log , но в любом случае рекомендуется хранить текстовые журналы).
Если вам нужен более конкретный комментарий о вероятной причине (и поэтому я могу быть более уверенным в моей гипотезе), вы можете выполнить следующие запросы и вставить их вывод в свой ответ (в блоке с отступом кода), а затем прокомментировать, чтобы я я уведомлен:
Возможно, что установка, а checkpoint_completion_target = 1 затем остановка и перезапуск БД могут привести к тому, что он начнет агрессивно записывать в очередь WAL. Он не освободит ничего, пока не выполнит контрольную точку, но вы можете заставить один раз замедлить запись (как измерено с помощью sar, iostat и т. Д.). Я не проверял, checkpoint_completion_target влияет ли уже написанное WAL при изменении при перезапуске; попробуйте проверить это на одноразовом тесте PostgreSQL initdb сначала на другой машине.
Резервные копии не имеют ничего общего с сохранением и ростом WAL; это не связано с резервным копированием.
pg_resetxlog [ -f ] [ -n ] [ параметр . ] <[ -D ] каталог_данных >
Описание
pg_resetxlog очищает журнал предзаписи (WAL) и может сбросить некоторую другую управляющую информацию, хранящуюся в файле pg_control . Данная функция может быть востребована при повреждении этих файлов. Использовать её нужно только как крайнюю меру, когда запуск сервера оказывается невозможен из-за этого повреждения.
После выполнения этой команды запуск сервера, скорее всего, будет возможен, однако стоит учитывать, что база данных может содержать несогласованные данные из-за транзакций, зафиксированных частично. Вы должны немедленно выгрузить данные, выполнить initdb , а затем восстановить данные. После этого проверьте целостность базы и внесите необходимые коррективы.
Эту утилиту может запускать только пользователь, установивший сервер, так как ей нужны права записи/чтения в каталоге хранения данных кластера. В целях безопасности каталог необходимо указывать в командной строке. pg_resetxlog не поддерживает переменную окружения PGDATA .
Если pg_resetxlog сообщает о невозможности определить данные из pg_control , то команду можно запустить принудительно, указав -f . В этом случае будут использованы наиболее вероятные значения. Они должны подходить для большинства полей, но для некоторых может потребоваться задать нужные значения явно: следующее значение OID, ID и эпоха следующей транзакции, ID мультитранзакции и смещение, начальный адрес WAL. Эти значения можно указать с помощью описанных далее параметров. Если их невозможно определить, то флаг f позволяет это обойти. Однако достоверность данных восстановленной базы не гарантируется: крайне необходимо незамедлительно выгрузить и затем восстановить данные. Не выполняйте никаких операций модификации до создания дампа данных, так как это может привести к ещё более печальным последствиям.
Параметры
Принудительно выполнять pg_resetxlog , даже если не удаётся получить приемлемые данные из pg_control , как описано выше. -n
С флагом -n (нет операции) команда pg_resetxlog отображает извлечённые из pg_control данные, а также значения, которые можно изменить. Режим полезен для отладки и тестирования предстоящей операции без реального применения изменений. -V
--version
Показать версию, а затем завершиться. -?
--help
Показать справку, а затем завершиться.
Следующие параметры необходимы, только когда pg_resetxlog не может определить подходящие значения, прочитав pg_control . Безопасные значения можно определить, как описано ниже. Для значений, принимающих числовые аргументы, можно задать шестнадцатеричные значения, добавив префикс 0x .
Вручную задать идентификаторы старейшей и новейшей транзакций, для которых можно получить время фиксации.
Безопасное значение идентификатора старейшей транзакции, для которой можно получить время фиксации (первый компонент), можно определить, найдя наименьшее в числовом виде имя файла в каталоге pg_commit_ts внутри каталога данных. Безопасное значение идентификатора новейшей транзакции, для которой можно получить время фиксации (второй компонент), можно определить, найдя, напротив, наибольшее в числовом виде имя файла в том же каталоге. Числа в именах этих файлов представлены в шестнадцатеричном формате. -e xid_epoch
Вручную задать эпоху в ID следующей транзакции.
Эпоха идентификаторов транзакции не хранится в базе данных нигде, кроме поля, устанавливаемого командой pg_resetxlog , поэтому пока рассматривается сама база, допустимым будет любое значение. Это значение, возможно, понадобится скорректировать для обеспечения правильной работы системы репликации, например, Slony-I и Skytools . В этом случае подходящее значение следует получить из состояния нижележащей реплицированной базы данных. -l xlogfile
Вручную задать начальный адрес WAL.
Начальный адрес журнала WAL должен превышать наибольшее значение сегмента в имени файла, расположенного в каталоге pg_xlog . Эти имена тоже представлены в шестнадцатеричном формате и состоят из трёх частей. Первая из них — « ID линии времени » и её обычно не следует менять. Например, если 00000001000000320000004A — наибольшее значение в pg_xlog , нужно указать -l 00000001000000320000004B или большее число.
Примечание
pg_resetxlog ищет среди файлов каталога pg_xlog , и по умолчанию выбирает значение для флага -l , идущее следующим после найденного. Корректировка значения параметра -l требуется лишь в ситуации, когда известно о существовании других сегментов WAL, отсутствующих на момент в каталоге pg_xlog , например, из архивного файла, или при полной потере данных в pg_xlog .
Вручную задать ID следующей и старейшей мультитранзакции.
Безопасное значение следующего идентификатора мультитранзакции (первый компонент) можно вычислить, найдя наибольшее числовое значение среди имён файлов, расположенных в каталоге pg_multixact/offsets . К найденному значению необходимо прибавить один, затем умножить на 65536 (0x10000). Для вычисления безопасного значения ID старейшей мультитранзакции (второй компонент -m ) необходимо найти наименьшее числовое значение среди тех же файлов, и умножить его на 65536. Имена файлов представляются в шестнадцатеричном формате, так что значения проще указывать в нём же, добавив в конце четыре нуля. -o oid
Вручную задать следующий OID.
Не существует относительно простого способа вычисления следующего за наибольшим из существующих значением OID, однако это некритично. -O mxoff
Вручную задать смещение следующей мультитранзакции.
Безопасное значение можно определить, найдя наибольшее числовое значение в имени файла в каталоге pg_multixact/members , прибавив один и умножив результат на 52352 (0xCC80). Имена файлов представлены в шестнадцатеричном формате. Простого рецепта с прибавлением нулей в конце, как для других параметров, в данном случае нет. -u xid
Вручную задать ID старейшей незамороженной транзакции.
Безопасное значение можно определить, найдя наименьшее числовое значение в имени файла в подкаталоге pg_xact каталога данных, а затем умножив результат на 1048576 (0x100000). Заметьте, что имена файлов представлены в шестнадцатеричном формате. Значение этого параметра обычно также проще задавать в шестнадцатеричном виде. Например, если 0007 — наименьшее значение в pg_xact , подходящим значением будет -u 0x700000 (нужный множитель дают пять последних нулей). -x xid
Вручную задать ID следующей транзакции.
Безопасное значение можно определить, найдя наибольшее числовое значение в имени файла в подкаталоге pg_clog каталога данных, прибавив один и умножив результат на 1048576 (0x100000). Заметьте, что имена файлов представлены в шестнадцатеричном формате. Значение этого параметра обычно также проще задавать в шестнадцатеричном виде. Например, если 0011 — наибольшее значение в pg_clog , подходящим значением будет -x 0x1200000 (нужный множитель дают пять последних нулей).
Замечания
Команду нельзя выполнять на работающем сервере. pg_resetxlog отклонит выполнение при обнаруженном блокирующем файле в каталоге хранения данных. Иногда при аварии сервера блокирующий файл может остаться в системе. В этом случае необходимо самостоятельно удалить его, чтобы дать возможность pg_resetxlog отработать. Перед выполнением операции дважды убедитесь, что сервер остановлен.
это значит, что 1С не убрала за собой временную таблицу. PostgreSQL автоматически чистит такие таблицы автовакумом, но пока он доберется до проблемы может пройти много времени. Были случаи, когда лог-файлы забивали диск, вызывая падение СУБД.
Перед запуском сделайте бэкап и остановите 1C сервер!
Специальные предложения
Просмотры 16991
Загрузки 9
Рейтинг 3
Создание 18.05.14 03:09
Обновление 21.08.14 21:01
№ Публикации 280074
Тип файла Приложение (exe)
Конфигурация Конфигурации 1cv8
Операционная система Linux
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
Код открыт Не указано
См. также
Универсальный редактор данных (УРД) Промо
Универсальный редактор данных (УРД) - это лучший инструмент в своем классе, который позволяет редактировать реквизиты и движения объектов
1 стартмани
27.08.2021 5919 124 Adeptus 51
Изыскания на тему записи в регистр сведений
1 стартмани
21.09.2021 4554 0 METAL 57
Доп. панель Alt+Z
Панель, вызываемая для объекта комбинацией клавиш Alt+Z (для документа, справочника, плана вида характеристик, плана счетов и т.д.). Возможности: Редактор всех реквизитов, таблиц и движений, Анализ прав к объекту, Поиск ссылок на объект с фильтрами, Сторно движений документа, Выгрузка/загрузка текущего объекта между базами. Подключается как Расширение.
2 стартмани
24.06.2021 8068 100 sapervodichka 57
Мастер создания копии информационной базы для отчетности
Прототип инструмента для подготовки реплики в режиме только для чтения к использованию. Позволяет использовать "read-only" реплики как обычные информационные базы 1С.
10 стартмани
28.08.2020 9511 7 YPermitin 13
Удаление и/или копирование сохраненных в 1С настроек (например настроек печати табличных форм) Промо
Иногда нужно удалить сохраненную в 1С "покореженную" настройку или скопировать "удачную" другому пользователю.
1 стартмани
01.09.2012 66824 1378 AnryMc 46
Оптимизация размера изображений из присоединенных файлов УТ 11.4
5 стартмани
10.07.2020 8773 5 Neti 4
Создание *.dt файла из рабочей базы на сервере 1С без завершения работы пользователей
Предлагаемая обработка создает *.dt файл (выгрузку ИБ) из рабочей базы на сервере 1С:Предприятие 8.3 без завершения работы пользователей.
1 стартмани
19.01.2020 19510 98 Sedaiko 20
Транслятор запросов 1С в SQL
Инструмент для трансляции запросов платформы 1С в SQL, а также их диагностики.
10 стартмани
07.01.2020 28043 220 YPermitin 89
Очистка кэша 1С 8 (8.0, 8.1, 8.2, 8.3). Грамотная чистка кэша 1С с сохранением настроек. Промо
Эффективное средство для устранения ошибок, возникающих в локальном кэше 1С на клиенте, которым легко сможет воспользоваться пользователь с любым уровнем знаний. Wsf-скрипт, созданный на стандартном языке автоматизации Windows - "WSH JScript", очищает кэш 1С просто, быстро и безопасно. Кроме варианта, очищающего кэш текущего пользователя, имеется также вариант для чистки кэша 1С всех пользователей терминального-сервера.
1 стартмани
04.11.2018 54121 529 Eugen-S 35
Работа с базами данных 1С в SQL Server Management Studio (Расширение для SSMS)
Расширение позволяет просматривать связи объектов метаданных и таблиц БД, сгруппированные данные (по группам метаданных) об используемом дисковом пространстве и выполнять трансляцию SQL текста запроса в термины 1С. И бонусом - при наведении курсора мыши на таблицу или поле показывает назначение объекта в терминах 1С.
10 стартмани
27.11.2019 17280 46 akpaevj 46
Командный интерпретатор для 1С
Инструмент для выполнения команд CMD / PowerShell из 1С.
2 стартмани
15.11.2019 18570 35 YPermitin 41
Быстрая реструктуризация базы данных
Внешняя обработка для быстрой реструктуризации клиент-серверной базы данных. Способ ускорения реструктуризации - замена таблиц большого объема пустыми копиями перед проведением обновления БД и возврат к исходным таблицам после обновления с предварительной корректировкой их структуры. Полностью автоматизировано создание и выполнение всех требуемых скриптов SQL. Представлены версии обработки для обычных форм (1С:Предприятие 8.2 (8.2.19.130)) и управляемого приложения (1С:Предприятие 8.3 (8.3.9.1818)).
1 стартмани
05.11.2019 23237 103 dmitrydemenew 39
Легкое и гибкое управление списком доступных баз 1С у пользователей Промо
Когда в локальной сети много пользователей, а еще большое количество различных баз и при этом каждому нужны свои, то администрирование этого зоопарка превращается в АД! Этот комплекс позволяет централизованно управлять списком доступных баз в разрезе пользователей. За пару кликов можно добавить или убрать базу у всех пользователей.
7 стартмани
05.12.2018 21977 22 RomikR 9
Закрытие незавершенных сеансов
Как удалять потерянные сеансы пользователей, чтобы они не мешали работе. Обработка протестирована на платформе версии 8.3.13.1644.
1 стартмани
20.09.2019 28236 103 AnatolPopov 12
Блин, мы забыли включить регламентные задания…
Привет, Инфостарт! Сегодня расскажу, как я решил проблему с выключенными регламентными заданиями в рабочих базах. Желая исключить человеческий фактор и минимизировать количество ошибок, я написал небольшую конфигурацию. В конфигурации два регламентных задания. Первое периодически подключается к кластеру и сохраняет текущие параметры: имя, Сервер БД, базу СУДБ, блокировки входа и регламентных заданий и т.д. Второе задание периодически проверяет эти параметры на ошибки.
1 стартмани
08.04.2019 25130 19 slozhenikin_com 37
Методика оптимизации программного кода 1С: проведение документов
Описание простого метода анализа производительности программного кода 1С, способов его оптимизации и оценки результатов в виде числовых показателей прироста производительности. Не требует сторонних программных продуктов, используются только типовые возможности платформ 1С. Методика проверена на линейке платформ начиная с 1С:Предприятие 8.2 (обычные формы, управляемые формы). Позволяет ускорить проведение проблемных документов в 3 и более раз, провести проверку корректности формирования проводок оптимизированным кодом и подтвердить результаты оптимизации реальными замерами производительности в режиме предприятия. К публикации приложены демонстрационные базы для режимов обычного и управляемого приложения на платформе 1С:Предприятие 8.3 (8.3.9.2033).
P ostgreSQL претендует на звание самой передовой базы данных с открытым исходным кодом в мире, и вполне заслуженно. Основные технические возможности, производительность и рабочие характеристики позволяют относить ее к числу ведущих баз данных для коммерческого использования, делая ее очень подходящей, экономически эффективной альтернативой как для стартапов, так и для крупных компаний, которым необходимо хранить данные и осуществлять управление ими.
Постараемся здесь дать исчерпывающее, разв е рнутое представление об этой замечательной системе управления базами данных — от установки, настройки, резервного копирования и восстановления с помощью barman 2.11 и до репликации и переключения с использованием repmgr 5.0.0 на Ubuntu 20.10. Акцент, впрочем, сделаем на достижении конкретных результатов, целей и задач. Поэтому особое внимание уделим соответствующим этапам и командам, оставив в стороне фоновые сведения и подробные объяснения.
Задействуем три физических компьютера или три виртуальные машины ( database-1 , database-2 и backup ). Каждый компьютер или машину запускаем на ubuntu 20.10 и подключаем к подсоединенному хранилищу, смонтированному в /backup :
Начальная настройка инфраструктуры
Убедитесь, что DNS правильно сконфигурирован на каждой из машин — наше руководство будет ссылаться не на IP-адреса, а только на имена хостов.
Установка Postgres
Конфигурация Postgres
- конфигурируем /etc/postgresql/12/main/postgresql.conf следующим образом:
- редактируем /etc/postgres/12/main/pg_hba.conf и добавляем следующие строки (здесь уже содержится конфигурация репликации, которая потом понадобится для repmgr ):
- создаем начальную структуру базы данных (на этом этапе она может быть любой).
- Запускаемся с нового сервера резервного копирования на ubuntu 20.10.
- В backup устанавливаем barman: apt-get install barman barman-cli .
- Создаем закрытый ключ для пользователя postgres и пользователя barman в
database-1 и backup соответственно. - В database-1 меняем на пользователя postgres su - postgres и генерируем пару ключей: ssh-keygen -b 2048 -t rsa -N "" -C "postgres@database-1" .
- В database-2 меняем на пользователя postgres su - postgres и генерируем пару ключей: ssh-keygen -b 2048 -t rsa -N "" -C "postgres@database-2" .
- В backup меняем на пользователя barman su - barman и создаем пару ключей: ssh-keygen -b 2048 -t rsa -N "" -C "barman@backup" .
- Добавляем открытый ключ postgres и barman соответственно к
- С каждой из машин подключаем одну к другой, используя соответствующее имя пользователя и полное имя хоста:
- В backup перемещаем файл /etc/barman.conf в /etc/barman.conf.orig и воссоздаем его со следующим содержимым:
- Настраиваем входящие в WAL — в backup получаем этот каталог с barman show-server database-1 | grep incoming_wals_directory : should be incoming_wals_directory: /backup/barman/database-1/incoming .
- Убеждаемся, что этот путь такой же, как и на postgresql.conf в archive_command .
- Выводим список всех доступных серверов резервного копирования: barman list-server .
- Проверяем архивацию WAL-журнала и все остальные части нашего сервера: barman check database-1 .
- Тестируем архивацию WAL-журнала с
barman switch-wal --force --archive database-1 . - Если видите строку WAL archive: FAILED (please make sure WAL shipping is setup) , это означает одно из трех: 1) возможно, база данных еще не создала никаких файлов в WAL; 2) они уже были удалены; 3) rsync не работает. Загляните в логи PostgreSQL: там все ответы.
Но если rsync работает правильно и никаких данных в базу данных фактически не записывается, то сервер не будет выдавать никаких WAL-файлов. Стало быть, резервную копию создавать не из чего. WAL-файлы создаются после получения определенного объема данных. Рекомендую создать таблицу и добавить в нее данные. Для принудительного закрытия текущего WAL-файла используйте: barman switch-wal --force --archive database-1 .
- Создаем базовую резервную копию: barman backup database-1 .
- Выводим список всех имеющихся резервных копий для одного сервера barman list-backup database-1 :
- Более подробная информация из конкретной резервной копии получается с помощью: barman show-backup server-a 20210209T115342 .
- Планируем резервное копирование с помощью cron:
- barman cron выполняется каждую минуту (операции архивирования WAL-журнала проходят параллельно на серверной основе, при этом обеспечивается соблюдение политик хранения на этих серверах).
- Выполняем резервное копирование базы данных каждый день в полночь.
- Удаляем /etc/cron.d в backup .
barman check database-1 — проверка конфигурации barman для конкретного сервера.
barman status database-1 — показ состояния конкретного сервера.
barman backup database-1 — создание резервной копии для конкретного сервера.
barman backup --reuse=link main — принудительное добавочное резервное копирование.
barman list-backup database-1 — вывод списка всех доступных резервных копий на конкретном сервере.
barman show-backup database-1 <timestamp> п — показ содержимого резервной копии.
barman show-backup database-1 latest — показ последней доступной резервной копии.
- Подключаемся к схеме баз данных database-1 и удаляем часть данных, некоторые таблицы или базы данных, имитируя аварийную ситуацию.
- Выключаем целевой сервер postgres на database-1 :
systemctl stop postgresql.service . - В backup от имени пользователя barman просматриваем последнюю резервную копию barman barman show-backup database-1 latest :
- Перезагружаем блок со 2-й базой данных database-2 .
- Теперь сервер баз данных восстановлен из резервной копии.
В случае если резервная копия базы данных не подлежит восстановлению и повреждена, практически ничего другого не остается, кроме как прибегнуть к жесткой перезагрузке кластера pg без переустановки контейнера базы данных. Для этого используют следующую процедуру. ВНИМАНИЕ. Это приведет к удалению всех данных.
- А теперь выполните описанную выше процедуру настройки кластера PostgreSQL в /etc/postgres/. , ведь вся последняя конфигурация была удалена.
- Если сервер Postgres не появляется после восстановления, посмотрите подробные логи запуска с помощью следующей команды:
Для настройки репликации между узлами postgres database-1 и database-2 будем использовать repmgr:
- Запускаем с правами администратора root repmgrd в database-1 : /etc/init.d/repmgrd start .
- Настраиваем 2-й узел, переключаемся на database-2 и останавливаем postgresql /etc/init.d/postgresql stop .
- Выполняем от имени пользователя postgres : /usr/bin/repmgr -h database-1 -U repmgr -d repmgr -p 5432 -F -f /etc/repmgr.conf standby clone --dry-run .
- По завершении выполняем операцию клонирования /usr/bin/repmgr -h database-1 -U repmgr -d repmgr -p 5432 -F -f /etc/repmgr.conf standby clone :
- На этом этапе PostgreSQL не работает в резервных узлах. Хотя у резервного узла есть скопированный из основного узла каталог данных Postgres, в том числе любые имеющиеся там конфигурационные файлы PostgreSQL.
- Теперь запускаем службу postgresql на вторичном узле /etc/init.d/postgresql start .
- Регистрируем от имени пользователя postgres вторичный узел с repmgr /usr/bin/repmgr -f /etc/repmgr.conf standby register :
- Теперь проверим настройку кластера repmgr:
/usr/bin/repmgr -f /etc/repmgr.conf cluster show --compact
- Самое время протестировать репликацию: на основном сервере database-1 создаем базы данных, таблицы, записи и видим мгновенные изменения на database-2 → поддерживает идеальную синхронизацию со вспомогательным сервером. Отличная работа!
- Наша цель — с помощью repmgr переключиться с первичного узла/сервера на вторичный и обратно.
- Перед переключением обратимся к настройке кластера sudo -u postgres /usr/bin/repmgr -f /etc/repmgr.conf cluster show --compact :
- Сейчас кластер repmgr работает с database-2 в качестве основного узла.
- Выполняем обратное переключение в database-1 от имени пользователя postgres : /usr/bin/repmgr standby switchover -f /etc/repmgr.conf .
- Опять же, в этом сценарии на ubuntu у postgres возможны проблемы с правильным возвращением на database-2 . Здесь тоже запускаем postgres с правами администратора root с помощью /etc/init.d/postgres start .
- Проверим настройку кластера repmgr: sudo -u postgres /usr/bin/repmgr -f /etc/repmgr.conf cluster show --compact :
- Возможны ситуации, когда проще удалить текущую и, быть может, поломанную конфигурацию repmgr и начать все сначала. В этом случае в основном узле от имени пользователя postgres выполняем:
Поздравляю, мы настроили PostgreSQL с резервным копированием, полной репликацией и научились переключаться с основного узла базы данных на вторичный и обратно без риска для данных.
В добавок ко всему этому неплохо было бы выполнять полное текстовое резервное копирование с применением статической диспетчеризации (например, каждое воскресенье) с помощью pg_dumpall | gzip > backup.gz . Ведь когда-нибудь может понадобиться полный дамп всего содержимого кластера баз данных в текстовом формате для использования на разных ОС, версиях PostgreSQL или даже в разных системах управления базами данных.
А кроме того, мы еще не рассматривали то, как с переключением справляется прикладной уровень. Здесь возможны варианты: использовать средство балансировки нагрузки для принятия фактического решения о том, к какому серверу базы данных подключиться клиенту, или создать и настроить эту возможность на прикладном уровне.
Читайте также: