В этой статье я хочу поделиться опытом развертывания кластера Master-slave на СУБД PostgreSQL. Отказоустойчивость достигается с помощью возможностей pgpool-II (failover, online recovery).
pgpool — это прекрасное средство для масштабирования и распределения нагрузки между серверами и, думаю, немногие знают о возможностях автоматического создания failover на ведомом сервере при отказе ведущего и как добавить новые мощности в уже работающий кластер без отключения всего кластера.
Схема кластера и требования к машинам
На рисунке представлена типичная схема кластера Master-slave.
Кластер должен содержать 1 ведущий сервер (Master), хотя бы 1 ведомый (Slave), 1 узел масштабирования (Balancer).
При на каждый из серверов должен быть установлен Linux-дистрибутив (у меня поставлен Red Hat 6.1), на узле масштабирования должен установлен компилятор gcc.
Версия PostgreSQL — 9.0.1, pgpool-II 3.0.5. Можно использовать и другие версии СУБД и pgpool. При этом обратитесь к документации.
Настройка удаленного соединения между серверами кластера
Online recovery и failover требуют настройки удаленного соединения по протоколу SSH без пароля. Для этого нужно создать SSH-ключи пользователя postgres и разослать их пользователям postgres каждому из серверов.
Важный момент! Для online recovery необходимо, чтобы при открытии удаленной сессии можно было перейти в еще одну удаленную сессию (т.е. можно было реализовать следующий механизм перехода по SSH без пароля: узел масштабирования — ведущий сервер — ведомый сервер и узел масштабирования — ведомый сервер — ведущий сервер).
Для failover необходимо создать SSH-ключ пользователя root на узле масштабирования и переслать пользователям postgres ведущего и ведомого сервера.
Этот шаг является важным при настройке, поэтому убедитесь, что возможно подключение из удаленной сессии одного из серверов к другому.
Настройка потоковой репликации
Предварительно нужно открыть прием/передачу данных по порту 5432 (стандартный порт PostgreSQL) в iptables.
Отредактируйте конфигурационный файл $PGDATA/postgresql.conf ведущего сервера следующим образом:
listen_addresses = '*' wal_level = hot_standby max_wal_senders = 2 wal_keep_segments = 32 #hot_standby = on Отмечу важность последней строки. Дело в том, что она будет использована в скрипте восстановления ведомого узла, поэтому ее нужно обязательно изменить так, как написано выше.
Далее добавляем строчки для репликации в $PGDATA/pg_hba.conf:
host replication postgres 192.168.100.2/32 trust host replication postgres 192.168.100.3/32 trust postgres — это администратор базы, который будет проводить репликацию и прочие админские хитрости. С помощью этих строк мы разрешили производить репликацию как ведомого, так и ведущего сервера.
После чего перегружаем ведущий сервер:
# service postgresql restart Останавливаем ведомый сервер (если был запущен ранее):
# service postgresql stop Теперь можно приступать к репликации.
На ведущем сервере пользователем postgres создаем backup базы пересылаем ведомому серверу:
$ psql -c "SELECT pg_start_backup('stream');" $ rsync -a /var/lib/pgsql/data/ 192.168.100.3:/var/lib/pgsql/data/ --exclude postmaster.pid $ psql -c "SELECT pg_stop_backup();" После чего на ведомом создаем конфиг репликации $PGDATA/recovery.conf:
recovery_mode = 'on' primary_conninfo = 'host=192.168.100.2 port=5432 user=postgres' trigger_file = 'failover' Параметр trigger_file отвечает за путь, по которому PostgreSQL ищет файл, чтобы переключиться в режим ведущего. В данном случае PostgreSQL ищет файл по пути $PGDATA/failover.
Далее нужно включить режим «горячего резерва» на ведомом сервере:
$ sed -i 's/#hot_stadnby = on/hot_standby = on/' /var/lib/pgsql/data/postgresql.conf После чего нужно запустить ведомый сервер:
# service postgresql start Активность репликации можно проверить следующим образом:
На ведущем сервере выполнить команду
$ ps aux | grep sender Она должна вывести приблизительно следующее:
2561 ? Ss 0:00 postgres: wal sender process postgres 192.168.100.3(33341) streaming 0/2031D28 Аналогично на ведомом сервере:
$ ps aux | grep receiver Она выдаст следующее:
1524 ? Ss 0:00 postgres: wal reciever process streaming 0/2031D28 Общая настройка узла масштабирования
Меняем конфигурационный файл /etc/pgpool-II/pgpool.conf:
# Устанавливаем весь диапазон прослушиваемых адресов listen_addresses = '*' # Параметры подключения к базе на ведомом сервере backend_hostname0 = '192.168.100.3' backend_port0 = 5432 backend_weight0 = 1 backend_data_directory0 = '/var/lib/pgsql/data' # Параметры подключения к базе на ведущем сервере backend_hostname1 = '192.168.100.2' backend_port1 = 5432 backend_weight1 = 1 backend_data_directory1 = '/var/lib/pgsql/data' # Используем pool_hba.conf для авторизации клиентов enable_pool_hba = true Далее в /etc/pgpool-II/pool_hba.conf добавляем информацию об авторизации клиентов:
host all all 127.0.0.1/32 trust host all all 192.168.100.2/32 trust host all all 192.168.100.3/32 trust Перезагружаем pgpool:
# service pgpool restart Настройка автоматического failover
Механизм создания автоматического failover следующий:
- На рабочих (ведущем и ведомом) серверах выполняется процедура
pgpool-walrecrunning(), определяющая, какой из серверов является ведущим, какой ведомый. - pgpool удаленно подключается к рабочим серверам и проверяет активность процессов СУБД. Если нет, то pgpool вызывает скрипт, который создает failover на ведомом узле в случае отказа ведущего сервера.
- После чего pgpool отключается от упавшего узла и перезапускает все клиентские приложения, подключенные к нему.
А теперь настройка:
На узле масштабирования меняем конфиг pgpool /etc/pgpool-II/pgpool.conf:
# Скрипт, вызываемый при падении сервера failover_command = '/etc/pgpool-II/failover.sh %d %H /var/lib/pgsql/data/failover' # Пользователь, проверяющий статус сервера health_check_user = 'postgres' # Ставим активность режима "Ведущий-ведомый" master_slave_mode = true # У нас настроена потоковая репликация, ставим режим работы 'потоковая' master_slave_sub_mode = 'stream' # Не разрешаем pgpool отправлять копию запроса на узлы кластера, у нас это произойдет автоматически благодаря репликации replication_mode = false # Включаем балансировку серверов, чтобы запросы могли равномерно распределяться между серверами load_balance_mode = true Расскажу немного подробнее про параметр failover_command. Скрипту, указанному в этой строке, передаются параметры %d — идентификатор упавшего узла (согласно backend_hostname в pgpool.conf), %H — IP нового ведущего сервера.
Собственно сам скрипт failover.sh:
#! /bin/bash # ID упавшего узла FAILED_NODE=$1 # IP нового мастера NEW_MASTER=$2 # Путь к триггерному файлу TRIGGER_FILE=$3 if [ $FAILED_NODE = 1 ]; then echo "Ведомый сервер вышел из строя" exit 1 fi echo "Ведущий сервер вышел из строя" echo "Новый ведущий сервер: $NEW_MASTER" ssh -T postgres$NEW_MASTER touch $TRIGGER_FILE exit 0 Этот скрипт нужно создать в каталоге pgpool /etc/pgpool-II/ и выдать права 755.
Теперь нужно скомпилировать процедуры pgpool. В src пакета pgpool в каталоге sql/pgpool-walrecrunning содержится исходный код нужной нам процедуры. Для ее компилирования нужны заголовочные файлы PostgreSQL, после чего можно воспользоваться командой make и получить pgpool-walrecrunning.so и SQL-запрос загрузки этой процедуры pgpool-walrecrunning.sql.
Процедуру нужно скопировать в каталог на каждом рабочем сервере /usr/lib64/pgsql/, который именуется $libdir, sql-файл в /usr/share/pgsql/.
Загружаем в базу на ведущем сервере:
psql -f /usr/share/pgsql/pgpool-walrecrunning.sql -d postgres Загрузку в базу этой процедуры на ведомом сервере нет необходимости: она будет доступна благодаря настроенной ранее репликации.
Вот и все.
Статус серверов можно определить с помощью запроса
SHOW pool_nodes; предварительно зайдя в клиент psql на узле масштабирования.
Пример вывода запроса:
hostname | port | status | lb_weight ----------------------------------------------------- 192.168.100.3 | 5432 | 2 | 0.500000 192.168.100.2 | 5432 | 2 | 0.500000 (2 rows) Статус сервера 2 означает, что сервер активен и доступен для запросов. В случае отказа одного из серверов статус изменится на 3.
Протестировать механизм автоматического failover можно следующим образом:
- Отключить ведущий сервер
- Выполнить запрос SHOW pool_nodes; на узле масштабирования
- Смотреть логи pgpool на предмет выполнения скрипта
- Убедиться в том, что ведомый сервер после выполнения скрипта может принимать запросы на запись
Online recovery
Наверное, этот механизм является наиболее сложным в плане дебага, но при этом является мощным инструментом при администрировании базы. Работа этого механизма заключается в следующем: есть рабочий кластер, мы хотим включить упавший ранее ведомый сервер, но данные, хранящиеся на нем, не соответствуют данным в кластере. Этот механизм позволяет нам добавить в реальном времени еще один ведомый сервер без остановки кластера и проведении каких-либо дополнительных действий при его настройке.
Online recovery работает следующим образом:
- На узле масштабирования запускается процедура восстановления ведомого сервера
- Эта процедура на ведущем сервере запускает скрипт, выполняющий автоматическую репликацию между ведущим и ведомым сервером
- После успешного выполнения репликации, база на ведущем сервере удаленно запускается с помощью стандартной утилиты PostgreSQL
PGCTL - pgpool перезапускается, обнаруживает ведомый сервер и включает его в кластер
Переходим к настройке.
Добавить следующие строчки в /etc/pgpool-II/pgpool.conf:
# Пользователь, проводящий восстановление recovery_user = 'postgres' # Пароль этого пользователя recovery_password = '123456' # Скрипт, запускающийся на ведущем скрипте из каталога $PGDATA recovery_1st_stage_command = 'basebackup.sh' Добавить хэш пароля postgres:
# pg_md5 123456 >> /etc/pgpool-II/pcp.conf 123456 — это пароль postgres в открытом виде. При этом дополнительно перед хэшем пароля нужно указать имя пользователя, кому этот хэш принадлежит, т.е. в файле должно быть строка postgres:enrypted_password.
На ведущем узле создать скрипт basebackup.sh следующего содержания:
#!/bin/bash # Путь к каталогу $PGDATA на ведущем сервере PRIMARY_DATA=$1 # IP-адрес ведомого сервера, который включается в кластер SLAVE_IP=$2 # Путь к каталогу $PGDATA на ведомом сервере SLAVE_DATA=$3 # Определяем IP ведущего сервера для включения в конфиг recovery.conf PRIMARY_IP=$(ifconfig eth0| sed -n '2 {s/^.*inet addr:\([0-9.]*\) .*/\1/;p}') # Директория для хранения конфигов для ведомого сервера TMP_DIR=/var/lib/pgsql/tmp # На ведущем сервере удаляем старые конфиги от репликации (если ведущий сервер был когда-то ведомым) cd $PRIMARY_DATA rm -f recovery.* failover # Проверяем, активен ли режим горячего резерва на ведущем сервере cat postgresql.conf | grep '#hot_standby = on' # Если активен, то выключаем его if [ $? = 1 ] then sed -i 's/hot_standby = on/#hot_standby = on/' postgresql.conf # Перезапускаем ведущий сервер /usr/bin/pg_ctl restart -D $PGDIR fi #Удаленно останавливаем ведомый сервер ssh -T postgres@$SLAVE_IP "/usr/bin/pg_ctl stop -D $SLAVE_DATA" # Создаем backup базы на ведущем сервере psql -c "SELECT pg_start_backup('Streaming Replication', true)" postgres # Пересылаем его ведомому rsync -a $PRIMARY_DATA/ $SLAVE_IP:$SLAVE_DATA/ --exclude postmaster.pid --exclude postmaster.opts # Создаем временную папку конфигов для ведомого сервера mkdir $TMP_DIR cd $TMP_DIR # Копируем конфиг postgresql.conf и включаем hot_standby cp $PRIMARY_DATA/postgresql.conf $TMP_DIR/ sed -i 's/#hot_standby = on/hot_standby = on/' postgresql.conf # Создаем конфиг recovery.conf echo "standby_mode = 'on'" > recovery.conf echo "primary_conninfo = 'host=$PRIMARY_IP port=5432 user=postgres'" >> recovery.conf echo "trigger_file = 'failover'" >> recovery.conf # Удаляем с ведомого сервера старые конфиги репликации ssh -T postgres@$SLAVE_IP rm -f $SLAVE_DATA/recovery.* # Копируем новые конфиги scp postgresql.conf postgres@$SLAVE_IP:$SLAVE_DATA/postgresql.conf scp recovery.conf postgres@$SLAVE_IP:$SLAVE_DATA/recovery.conf #Завершаем процесс backup psql -c "SELECT pg_stop_backup()" postgres # Удаляем временную папку с конифгами cd .. rm -fr $TMP_DIR Подчеркиваю, этот скрипт должен быть в каталоге $PGDATA. Скрипту назначить права 755.
На ведомом и ведущем сервере в каталоге $PGDATA создать скрипт pgpool_remote_start (Именно под таким именем!) со следующим содержанием:
#! /bin/bash if [ $# -ne 2 ] then echo "Мало аргументов, переданных скрипту" exit 1 fi SLAVE_IP=$1 SLAVE_DIR=$2 PGCTL=/usr/bin/pg_ctl ssh -T $SLAVE_IP $PGCTL -w -D $SLAVE_DIR start 2>/dev/null 1>/dev/null < /dev/null & Он позволит удаленно запускать процессы СУБД.
Далее на узле масштабирования нужно скомпилировать хранимую процедуру pgpool-recovery.so, расположенную по пути sql/pgpool-recovery src пакета pgpool. Аналогичным образом переслать ее рабочим серверам и выполнить загрузку процедуру в базу:
$ psql -f /usr/share/pgsql/pgpool-recovery.sql -d template1 На этом настройка online recovery закончена.
Для включения нового ведомого сервера в кластер необходимо выполнить следующие действия:
- Запустить базу на новом ведущем узле
- На узле масштабирования выполнить команду по восстановлению сервера:
pcp_recovery_node 20 192.168.100.4 9898 postgres 123456 1
Подробнее о pcp_recovery_node. Эта команда реализует восстановление сервера в кластер. 20 — это число попыток подключения к ведомому серверу, 192.168.100.4 — IP узла масштабирования, 9898 — порт pcp команд узла масштабирования, postgres — имя пользователя, производящего восстановления, 123456 — его пароль, 1 — ID восстанавливаемого узла.
На этом закончена настройка online recovery.
Можно произвести тестирование этих двух механизмов по следующему плану:
- Создать тестовую базу данных на ведущем сервере. Убедиться, что она реплицировалась на ведомый
- Имитировать отказ ведущего сервера, отключив его
- Убедиться, что сработал failover и ведомый сервер стал новым ведущим
- Внести изменения в базу данных на ведомом сервере
- Запустить упавший ведущий сервер и сделать его ведомым, проведя online recovery
Таким образом, описанные выше механизмы позволяют обезопасить кластер «Ведущий-ведомый» и упростить работу администратора базы данных при ее восстановлении.
P.S. Надеюсь, данный пост помог кому-нибудь. Комментарии и дополнения приветствуются! Благодарю за внимание.
ссылка на оригинал статьи http://habrahabr.ru/post/188096/
Добавить комментарий