Всем кому приходилось сталкиваться с процедурой 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) и опции подключения к новому master серверу (--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 (кто незнаком с постгресом тот ничего не поймет).
Всем спасибо за внимание.
Автор: lesovsky
