PostgreSQL feature highlight: быстрое превращение старого мастера в stand-by с pg_rewind

Всем кому приходилось сталкиваться с процедурой failover при работе с потоковой репликацией в PostgreSQL, наверняка озадачивались вопросом: «А как бы мне ничего заново не копировать, а по-быстрому завести старый мастер в качестве stand-by». Так вот к сожалению, встроенной такой функциональности в PostgreSQL, увы нет. Да, нельзя так просто взять и подключить старый мастер к новому и чтобы все заработало. Для этого нужно повторить процесс настройки потоковой репликации заново, т.е. скопировать весь кластер и запустить postgres в режиме hot-standby.
К счастью работы в этом направлении ведутся, причем результаты довольно не плохие. Называется же проект pg_rewind.
Сразу предупреждаю это еще не production-ready и пост носит характер how-to + technology preview.

Известные ограничения:

• На данный момент pg_rewind поддерживает работу только с версиями 9.4 и частично 9.3. Почему частично, потому что кластер должен быть обязательно проинициализирован с поддержкой контрольных сумм (initdb -k). С версией 9.4 попроще, там нужна либо поддержка контрольных сумм, либо наличие параметра wal_log_hints выставленный в on.
• Еще одно существенное ограничение, мастер должен быть выключен штатно. То есть, если мастер был выключен аварийно, то перемотка не выполнится. Но, разработчики ведут работы в этом направлении.
• Пока не поддерживаются tablespace’ы и не реализована работа с WAL архивами (недостающие архивы следует скопировать вручную).

Еще немного теории и перейдем к практике… что из себя представляет процесс перемотки:

• Сканирование каталога старого узла с момента ветвления WAL и запись блоков которые были изменены после ветвления.
• Копирование изменившихся блоков с нового мастера на старый;
• Копирование оставшихся файлов (clog, конфигурационные файлы и пр.);
• Редактирование recovery.conf и запуск старого мастера с новыми настройками;
• Воспроизведение WAL с момент контрольной точки после failover.

Итак теперь практика, ниже я опишу процесс как выполнить «перемотку» старого мастера и подключение к новому мастеру без полной переинициализации.
План простой:

• собрать и установить PostgreSQL 9.4 (на данный момент только devel);
• собрать pg_rewind;
• настроить потоковую репликацию;
• выполнить failover;
• выполнить перемотку старого мастера и подключиться к новому мастеру.

Все операции выполняются в CentOS 6.5. Вообще процесс довольно простой, больше всего сложностей у меня возникло на этапе сборки pg_rewind, поэтому опишу процесс полностью.
Итак, поехали! Для начала нужно установить несколько пакетов которые потребуются в качестве зависимостей при сборке postgresql. После установки клонируем репозитории и выполняем установку PostgreSQL.

# yum install git gcc zlib-devel flex bison readline-devel pam-devel openssl-devel libxslt-devel # git clone --branch master http://git.postgresql.org/git/postgresql.git # git clone https://github.com/vmware/pg_rewind # cd postgresql # ./configure && make && make install 

Тут стоит заметить что по-умолчанию PostgreSQL установился в /usr/local и все утилиты находятся в /usr/local/pgsql/bin, поэтому этот путь нужно добавить в переменную окружения PATH. Сделать это можно разными способами, я поступил следующим, более менее приличным (а может и не очень) для CentOS образом:

# vi /etc/profile.d/pgsql-9.4.sh  PGSQL94_BINDIR=/usr/local/pgsql/bin pathmunge $PGSQL94_BINDIR export PGSQL94_BINDIR # source /etc/profile 

Теперь переходим в каталог с кодом pg_rewind и выполняем сборку утилиты. Полученную утилиту просто копируем к утилитам postgres’a.

# cd ../pg_rewind # make USE_PGXS=1 top_srcdir=../postgresql/ # cp pg_rewind /usr/local/pgsql/bin/ 

Теперь настраиваем потоковую репликацию. Как я уже писал вначале, для успешной работы pg_rewind нужно соблюсти одно из двух условий:
1) кластера должны быть проинициализированы с поддержкой контрольных сумм (initdb -k).
или
2) postgres сервисы должны быть запущены с опцией wal_log_hints = on в postgresql.conf
Я выбрал второй вариант.
Процесс настройки уже описан много раз, поэтому останавливаться здесь на этом не буду.
Итак когда репликация настроена и работает выполняем failover. Эта операция выполняется с помощью создания файла-триггера указанного в recovery.conf в опции trigger_file. После создания файла-триггера, stand-by переключится в режим мастера и начнет жить своей жизнью. Поэтому старый мастер теперь нужно выключить.
И теперь в дело вступает pg_rewind. В качестве параметров выступает каталог где размещен кластер старого мастера (-D) и опции подключения к stand-by серверу (—source-server). Внимание, операцию нужны выполнять под пользователем которому принадлежит кластер БД (по-умолчанию postgres).

$ pg_rewind -D /var/lib/pgsql/9.4/data/ --source-server="host=192.168.122.12 port=5432 user=postgres" The servers diverged at WAL position 0/48D9580 on timeline 1. Rewinding from Last common checkpoint at 0/3000860 on timeline 1 error reading xlog record: record with zero length at 0/48D9620 Done! 

Итак перемотка выполнена (не пугайтесь слова error, это штатная проверка). Теперь нужно уделить внимание файлам postrgesql.conf и recovery.done, помните что они скопированы с нового мастера и могут содержать специфичные для сервера настройки (например ip-адреса или номера портов в listen_addresses, port и т.п.) Второй файл, recovery. done следует переименовать в recovery.conf и настроить на подключение к новому мастеру.

$ mv /var/lib/pgsql/9.4/data/recovery.done /var/lib/pgsql/9.4/data/recovery.conf $ vi /var/lib/pgsql/9.4/data/recovery.conf standby_mode = 'on' primary_conninfo = 'user=postgres host=192.168.122.12 port=5432' trigger_file = '/var/lib/pgsql/9.4/data/failover' 

После того как конфигурация исправлена запускаем postgres и смотрим журнал сервера

$ cat /var/lib/pgsql/9.4/data/pg_log/postgresql-Mon.log LOG:  entering standby mode LOG:  redo starts at 0/48D95B0 LOG:  record with zero length at 0/61D9EE8 LOG:  consistent recovery state reached at 0/61D9EE8 LOG:  database system is ready to accept read only connections LOG:  started streaming WAL from primary at 0/6000000 on timeline 2 

Обратите внимание на database system is ready to accept read only connections, это самая важная здесь строка свидетельствующая о том что все прошло гладко и postgres запустился как и положено и готов принимать подключения. Можно проверить потоковую репликацию штатными средствами через pg_stat_replication или создать тестовые таблицы на мастере и проверить их наличие на stand-by.

Вот и все. В завершении добавлю… Первое, в процессе между провозглашением нового мастера и перемоткой, новый мастер доступен для записи, поэтому при перемотке не нужно изолировать мастер от подключений со стороны приложений. Второе, проект еще молодой, находится в активной разработке, и на мой взгляд не готов для production. Так что пробуйте, тестируйте…

Тем кто не готов проделать это все или попросту лень, но посмотреть хочется, есть небольшое видео на 8 минут, экшен по переключению начинается с 4:20 (кто незнаком с постгресом тот ничего не поймет).

Всем спасибо за внимание.