Что такое репликация в PostgreSQL?
Репликация — это синхронизация копий баз данных, которые дублируются с главного сервера (master) на резервный или резервные (slave или replica). Это актуальная для высоконагруженных баз данных технология, благодаря которой инфраструктура:
- Приобретает отказоустойчивость. Восстановление из бэкапа может занимать до нескольких часов, да и он может оказаться неактуальным/неисправным. А репликация БД позволит быть уверенным в непрерывности рабочего процесса.
- Наращивает производительность.Своего рода горизонтальное масштабирование, при котором нагрузка на базы данных распределяется между серверами. Построение отчётов, снятие бэкапа можно делать с резервной версии БД, что разгрузит основную.
В этой статье мы расскажем, как настроить репликацию в СУБД PostgreSQL, начиная с версии 10.0.
Виды репликации в PostgreSQL
В PostgreSQL репликацию данных можно осуществлять двумя способами: физическим (потоковым) и логическим.
Потоковая репликация
Все данные об изменениях на мастер-сервере передаются через журнал операций (WAL) в поточном режиме на дополнительный. Этот просто и экономно, но при этом высоки требования к совместимости серверов: вплоть до одной ОС и одинаковых версий PostgreSQL, и даже архитектуры процессора.
Существуют синхронная и асинхронная репликация PostgreSQL. Это типы потоковой репликации в PostgreSQL, отличающиеся порядком выполнения запросов:
Существуют синхронная и асинхронная репликация PostgreSQL. Это типы потоковой репликации в PostgreSQL, отличающиеся порядком выполнения запросов:
- Асинхронная репликация. При асинхронной репликации запросы сначала попадают на главный сервер, потом — в WAL и лишь в конце — на дополнительный сервер. Плюсы такой репликации в быстром подтверждении транзакции, а недостаток — в опасности потерять часть данных на репликах из-за того, что они не успеют полностью продублироваться, если с мастером что-то случится.
- Синхронная репликация. При синхронной — запросы поступают вначале в WAL, а уже оттуда — на master- и slave-серверы. Плюсы — большая защищенность данных, минусы — низкая скорость выполнения операций из-за того, что транзакция подтверждается только после полного дублирования на slave-сервере.
Логическая репликация
Логическая репликация PostgreSQL позволяет синхронизировать копии БД, опираясь на идентификатор репликации (записи в таблицах базы, а не чистые биты и байты), что делает неважной разницу в конфигурации серверов, версиях СУБД и используемых платформах.
Логическая репликация появилась в PostgreSQL версии 10.0 и позволяет выборочно синхронизировать нужные части БД на разных slave-серверах, что недоступно при физической репликации. Работает это по принципу подписки: мастер-сервер выступает издателем, публикующим изменения, а резервные сервера подписываются на те или иные из них.
Логическая репликация появилась в PostgreSQL версии 10.0 и позволяет выборочно синхронизировать нужные части БД на разных slave-серверах, что недоступно при физической репликации. Работает это по принципу подписки: мастер-сервер выступает издателем, публикующим изменения, а резервные сервера подписываются на те или иные из них.
Настройка физической репликации PostgreSQL
- Если используются разные физические серверы, нужно убедиться, что процессоры серверов имеют одинаковую архитектуру, работают под одними операционками, а установленные на них версии PostgreSQL — идентичны (для логической репликации это не принципиально).
Однако чаще речь идет о виртуальных серверах. Если вы используете облачную платформу, в панели управления создайте два сервера и, во избежании путаницы, назовите их Master и Slave. Затем идентично настройте для обоих серверов ОС, конфигурацию, объем оперативной памяти и место на диске, например — Ubuntu 22.04, 2 vCPU, 8 ГБ RAM и 10 ГБ диска.
Обратите внимание на следующие моменты:
Обратите внимание на следующие моменты:
- Важно не забыть настроить доступ к VM из интернета, сделав адрес используемой подсети публичной. Убедитесь, что для подключения к машине вы либо настроили root-доступ по паролю, либо сгенерировали SSH-ключ.
- Т.к. в нашем примере VM находятся в одной сети, используются приватные адреса. В противном случае потребовалось бы использование публичной сети, настройка файрвола и открытие портов. Серверы Postgre используют TCP-порт 5432. При использовании брандмауэра, для открытия порта нужно выполнить одну из команд, отличающихся в зависимости от того, какую утилиту для командной строки Linux вы используете: Firewalld, Iptables или UFW.
- По дефолту в дистрибутивах Linux, таких как Red Hat, CentOS и Fedora включена система безопасности SELinux: ее потребуется отключить.
Настройка и подготовка master-сервера
На этом этапе нужно выдать slave-серверу доступ к подключениям на master-сервере. Делается это посредством редактуры конфига /etc/postgresql/12/main/pg_hba.conf. (цифра «12» в пути означает номер версии PostgreSQL).
После строки «If you want to allow non-local connections, you need to add more» в файл необходимо дописать «host replication postgres REPLICA_ВНУТРЕННИЙ_IP/32 md5».
Затем потребуется настроить саму репликацию. Для этого откройте конфиг nano/etc/postgresql/10/main/postgresql.conf и проставьте в нам необходимые значения параметров.
После строки «If you want to allow non-local connections, you need to add more» в файл необходимо дописать «host replication postgres REPLICA_ВНУТРЕННИЙ_IP/32 md5».
Затем потребуется настроить саму репликацию. Для этого откройте конфиг nano/etc/postgresql/10/main/postgresql.conf и проставьте в нам необходимые значения параметров.
listen_addresses = 'localhost, MASTER_ВНУТРЕННИЙ_IP'
wal_level = hot_standby
archive_mode = on
archive_command = 'cd .'
max_wal_senders = 8
hot_standby = onПосле этого перезагрузите сервер командой «service postgresql restart», чтобы они применились и переходите к терминалу slave-сервера.
Настройка и подготовка master-сервера
Перед настройкой остановите PostgreSQL-сервер командой «service postgresql stop».
Затем на дополнительном сервере PostgreSQL-сервера отредактируйте pg_hba.conf. так же, как и на master-сервере, заменив лишь IP-адрес на мастерский.
Также нужно отредактировать файл postgresql.conf, указав те же самые настройки, что на мастере, за исключением IP-адреса.
Для того, чтобы slave-сервер смог начать репликацию, перенесите на него бэкап базы данных с master-сервера с помощью утилиты pg_basebackup, после чего снова запустите PostgreSQL-сервер. Чтобы сделать это, нужно залогиниться, воспользовавшись командой «su — postgres».
Теперь перейдите в раздел с БД: cd /var/lib/postgresql/12/ и пересоздайте каталог: дефолтный удалите и создайте одноименный новый, но пустой: rm -rf main; mkdir main; chmod go-rwx main .
Далее выгрузите БД с мастер-сервера командой «pg_basebackup -P -R -X stream -c fast -h MASTER_ВНУТРЕННИЙ_IP -U postgres -D ./main». Параметр «-R» в ней означает, что также создается пустой файл, указывающий на то, что этот сервер — replica. Начиная с 12 версии PostgreSQL, рассматриваемой в этой статье, этот файл называется standby.signal, а в ранних версиях — recovery.conf.
Осталось запустить обратно PostgreSQL-сервер командой «service postgresql start». Все, репликация настроена.
Затем на дополнительном сервере PostgreSQL-сервера отредактируйте pg_hba.conf. так же, как и на master-сервере, заменив лишь IP-адрес на мастерский.
Также нужно отредактировать файл postgresql.conf, указав те же самые настройки, что на мастере, за исключением IP-адреса.
Для того, чтобы slave-сервер смог начать репликацию, перенесите на него бэкап базы данных с master-сервера с помощью утилиты pg_basebackup, после чего снова запустите PostgreSQL-сервер. Чтобы сделать это, нужно залогиниться, воспользовавшись командой «su — postgres».
Теперь перейдите в раздел с БД: cd /var/lib/postgresql/12/ и пересоздайте каталог: дефолтный удалите и создайте одноименный новый, но пустой: rm -rf main; mkdir main; chmod go-rwx main .
Далее выгрузите БД с мастер-сервера командой «pg_basebackup -P -R -X stream -c fast -h MASTER_ВНУТРЕННИЙ_IP -U postgres -D ./main». Параметр «-R» в ней означает, что также создается пустой файл, указывающий на то, что этот сервер — replica. Начиная с 12 версии PostgreSQL, рассматриваемой в этой статье, этот файл называется standby.signal, а в ранних версиях — recovery.conf.
Осталось запустить обратно PostgreSQL-сервер командой «service postgresql start». Все, репликация настроена.
Проверка репликации
Проверка репликации PostgreSQL осуществляется в несколько этапов.
- Чтобы проверить, работает ли репликация, создайте на master-сервере новую таблицу и посмотрите, отображается ли она в терминале резервного сервера.
- Затем создайте таблицу на slave-сервере. Если все настроено правильно, то она не появится на master-сервере.
- Наконец, проверьте, защитит ли вас репликация в обстановке, приближенной к боевой. Для имитации падения master-сервера отключите его из KVM-консоли. Если все настроено правильно, теперь вы сможете перевести slave-сервер в режим записи и создавать и редактировать БД непосредственно на нём.
Обратите внимание, что если сервисы и приложения подключались к отключенному мастер-серверу напрямую, то при смене ролей, запросы от них не будут автоматически направляться на новый сервер. Для решения этой проблемы используются балансировщии нагрузок, которые принимают запросы от приложений вместо PostgreSQL и мониторят состояние серверов для автоматического перераспределяют нагрузки между разными инстансами БД.
Частые ошибки репликации
Если после выполнения всех этих пунктов репликация не работает, нужно открыть журнал с логами на slave-сервере и просмотреть его на наличие ошибок. Есть несколько распространённых вариантов сбоев:
- Входящие подключения отсекались брандмауэром.
- На master- и slave-сервере не совпадали идентификаторы репликаций.
- Нужная таблица не была добавлена в публикацию на главном сервере.
- В СУБД репликация не была маркирована как «logical».
Устранение этих проблем должно привести к автоматическому запуску репликации. Если этого не происходит, нужно попробовать удалить неработающую подписку на часть БД командой DROP SUBSCRIPTION my_subscription и пересоздать ее.
Однако репликация PostgreSQL — серьёзная задача, которую лучше всего передать опытному специалисту. Мы в «ДБ-сервис» готовы взять администрирование и поддержку БД на PostgreSQL на себя. Мы обеспечим вашей системе управления базами данных доступность и бесперебойную работу.
Эксперт ДБ-сервис
Список литературы:
- Потоковая репликация PostgreSQL. – Текст: электронный // Убежище инженера: интернет-портал. – URL: Потоковая репликация PostgreSQL - Убежище инженера – Дата публикации: 25.03.2022.
- Репликация в PostgreSQL. – Текст: электронный // Sysadminium: интернет-портал. – URL: Репликация в PostgreSQL – Дата публикации: 21.06.2021
- Настройка потоковой репликации PostgreSQL. – Текст: электронный // Дмитрий Моск. – URL: Настройка репликации PostgreSQL. Отказоустойчивый кластер баз данных Postgre – Дата публикации: 08.08.2023.
- Luzanov Pavel, Rogov Egor, Levshin Igor. Postgres. The First Experience: 9th edition, revised and updated // Postgres Professional, 2016–2023. – ISBN 978-5-6045970-3-3. – URL: introbook_v9_en.pdf
- The PostgreSQL Global Development Group: сайт. The University of California, 1996-2023. URL: https://www.postgresql.org/