1c + PostgreSQL + streaming replication на Debian ч.4

Рубрика: Памятка, Софт

Продолжение статей 1c + PostgreSQL + streaming replication на Debian ч.1 , 1c + PostgreSQL + streaming replication на Debian ч.2 и 1c + PostgreSQL + streaming replication на Debian ч.3

Настроим между экземплярами СУБД PostgreSQL на srv-bd-1 и srv-bd-2 streaming replication для обеспечения горячего резерва:

 1. Настраиваем postgresql.conf и pg_hba.conf:
Если ip-адрес мастер-сервера у нас 192.168.0.1, а у слейв-сервера — 192.168.0.2, то строка listen в postgresql.conf должна выглядеть так:

listen_addresses = '192.168.0.1'

 А  в файле pg_hba.conf на мастер-сервере должна быть запись:

host replication postgres 192.168.0.2/32 trust

2. Включаем на мастер-сервере параметры необходимые для репликации:

#Устанавливаем параметр ведения журнала таким образом, чтобы слейв-сервер мог использоваться для чтения. Можно вместо hot_standby поставить archive и тогда он будет просто хранилищем журанала(нечитаемым).

wal_level = hot_standby

#Максимальное количество слейв-серверов

max_wal_senders = 2

#Сколько частей лога будем хранить? Если вдруг у вас большая нагрузка на запись в базу — возможно это значение нужно будет увеличить, чтобы всё успевало доходить до реплики.

wal_keep_segments = 32

#На всякий случай  дублируем журнал в отдельное место(лучше чистить по крону эту локацию, удаляя всё, чему больше суток).

archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/9.0/main/archive/%f'

Перезапускаем мастер-сервер.

3. Передаем базы с мастер-сервера на слейв-сервер.

Нужен инструмент, который может пересылать данные по сети. Можно использовать rsync или любое другое средство. Останавливаем на слейв-сервере postgresql, после этого на мастер-сервере выполняем:

$ psql -c "SELECT pg_start_backup('label', true)"
$ rsync -a /var/lib/postgresql/9.0/main/ slave:/var/lib/postgresql/9.0/main/ --exclude postmaster.pid
$ psql -c "SELECT pg_stop_backup()"

4. Включим hot_standby на слейв-сервере.

Добавим в postgresql.conf:

hot_standby = on

5. Создадим конфигурацию репликации на слейв-сервере.

В файле recovery.conf (его нужно создать), который должен находиться в /var/lib/postgresql/9.0/main запишем следующее:

standby_mode = 'on'
primary_conninfo = 'host=192.168.0.1 port=5432 user=postgres'
trigger_file = '/var/lib/postgresql/9.0/main/trigger'
restore_command = 'cp /var/lib/postgresql/9.0/main/archive/%f "%p"'

Зачем нужен trigger_file? По умолчанию его быть не должно. Он нужен для того, чтобы в случае падения мастер-сервера вы могли (создав этот файл) остановить процесс репликации и сделать слейв-сервер доступным на запись.

6. Вот и все.

Стартуем слейв-сервер. Если на нем команда

ps aux | grep receiver

Показывает что-то вида

postgres 1953 0.0 0.0 101980 4156 ? Ss 19:19 0:00 postgres: wal receiver process streaming 2/B40001D0

То можете считать, что всё работает.

8. Если вдруг мастер-сервер перестал работать.

Обычно, репликация нужна для распределение нагрузки и на случай, если с мастер-сервером что-то случится. Если у вас вдруг перестал работать мастер-сервер, то нужно сделать примерно следующее:

а) Создать на слейв-сервере trigger_file. Слейв-сервер остановит репликацию и станет доступен для записи, после этого можно перевести на него пользователей.
б) Когда железка, на которой крутиться мастер-сервер, вернётся в строй — выполняете обратные действия — настраиваем изначальный мастер-сервер, как реплику — выполняем на мастер-сервере 5 пункт. Когда он восстановится,  удаляем на слейв-сервере trigger_file  и всё должно вернуться как было.

{lang: 'ru'}


Затвитить пост!

Рейтинг:
1 Star (Еще не оценили)
Загрузка...
Популярность: Просмотров: 1 060
Метки: , ,

Оставить комментарий или два

--> Яндекс.Метрика Рейтинг@Mail.ru