PostgreSQL база данных поддерживает несколько решений репликации для создания высокодоступных, масштабируемых, отказоустойчивых приложений, одним из которых является Журнал упреждающей записи (WAL) Перевозки. Это решение позволяет реализовать резервный сервер с использованием файловой доставки журналов или потоковой репликации или, где это возможно, комбинации обоих подходов.
При потоковой репликации резервный (подчиненный репликации) сервер базы данных настроен для подключения к главному / первичному серверу, который передает потоки. WAL записи в резерв по мере их создания, не дожидаясь WAL файл для заполнения.
По умолчанию потоковая репликация является асинхронной, когда данные записываются на резервные серверы после того, как транзакция была зафиксирована на основном сервере. Это означает, что существует небольшая задержка между фиксацией транзакции на главном сервере и видимыми изменениями на резервном сервере. Одним из недостатков этого подхода является то, что в случае сбоя главного сервера любые незафиксированные транзакции не могут быть реплицированы, и это может вызвать потерю данных.
В этом руководстве показано, как настроить Postgresql 12 мастер-резервная потоковая репликация на CentOS 8. Мы будем использовать "слоты репликации”Для резервного в качестве решения, позволяющего избежать повторного использования главным сервером старых WAL сегменты до того, как резервная система их получит.
Обратите внимание, что по сравнению с другими методами слоты репликации сохраняют только то количество сегментов, которое, как известно, необходимо.
В этом руководстве предполагается, что вы подключились к главному и резервному серверам баз данных в качестве корневого через SSH (использовать Судо при необходимости, если вы подключены как обычный пользователь с правами администратора):
Главный сервер базы данных Postgresql: 10.20.20.9. Резервный сервер базы данных Postgresql: 10.20.20.8.
Оба сервера баз данных должны иметь Postgresql 12 установлен, в противном случае см.: Как установить PostgreSQL и pgAdmin в CentOS 8.
Примечание: PostgreSQL 12 содержит значительные изменения в реализации и конфигурации репликации, такие как замена recovery.conf и преобразование recovery.conf в обычные параметры конфигурации PostgreSQL, что значительно упрощает настройку репликации кластера.
1. На главном сервере переключитесь на системную учетную запись postgres и настройте IP-адрес (а), на котором главный сервер будет прослушивать соединения от клиентов.
В этом случае мы будем использовать *
имеется в виду все.
# su - postgres. $ psql -c "ИЗМЕНИТЬ НАБОР СИСТЕМЫ listen_addresses TO '*';"
В ИЗМЕНИТЬ НАБОР СИСТЕМЫ Команда SQL - это мощная функция для изменения параметров конфигурации сервера напрямую с помощью SQL-запроса. Конфигурации сохраняются в postgresql.conf.auto файл, расположенный в корне папки данных (например, /var/lib/pgsql/12/data/) и прочтите дополнение к тем, что хранятся в postgresql.conf. Но конфигурации в первом имеют приоритет над конфигурациями в более поздних и других связанных файлах.
2. Затем создайте роль репликации, которая будет использоваться для подключений от резервного сервера к главному серверу, используя Создать пользователя программа. В следующей команде -П
flag запрашивает пароль для новой роли и -e
повторяет команды, которые createuser генерирует и отправляет на сервер базы данных.
# su - postgres. $ createuser --replication -P -e репликатор. $ exit.
3. Затем введите следующую запись в конце /var/lib/pgsql/12/data/pg_hba.conf файл конфигурации аутентификации клиента с полем базы данных, настроенным на репликацию, как показано на снимке экрана.
репликатор репликации хоста 10.20.20.8/24 md5.
4. Теперь перезапустите Postgres12 service, используя следующую команду systemctl, чтобы применить изменения.
# systemctl перезапуск службы postgresql-12.
5. Далее, если у вас есть Firewalld Если служба запущена, вам необходимо добавить службу Postgresql в конфигурацию firewalld, чтобы разрешить запросы от резервного сервера к главному.
# firewall-cmd --add-service = postgresql --permanent. # firewall-cmd --reload.
6. Затем вам нужно сделать базовую резервную копию главного сервера с резервного сервера; это помогает запустить резервный сервер. Вам нужно остановить службу postgresql 12 на резервном сервере, переключиться на учетную запись пользователя postgres, сделать резервную копию каталога данных (/var/lib/pgsql/12/data/), затем удалите все, что находится под ним, как показано, прежде чем делать базовую резервную копию.
# systemctl остановить службу postgresql-12. # su - postgres. $ cp -R / var / lib / pgsql / 12 / data / var / lib / pgsql / 12 / data_orig. $ rm -rf / var / lib / pgsql / 12 / data / *
7. Затем используйте pg_basebackup инструмент для создания базовой резервной копии с правом собственности (пользователь системы базы данных, т.е. Postgres, в пределах Postgres учетная запись пользователя) и с соответствующими разрешениями.
В следующей команде параметр:
-час
- указывает хост, который является главным сервером.-D
- указывает каталог данных.-U
- указывает пользователя подключения.-П
- включает отчеты о проделанной работе.-v
- включает подробный режим.-Р
- позволяет создать конфигурацию восстановления: Создает standby.signal файл и добавьте настройки подключения в postgresql.auto.conf в каталоге данных.-ИКС
- используется для включения необходимых файлов журнала упреждающей записи (файлов WAL) в резервную копию. Значение stream означает потоковую передачу WAL во время создания резервной копии.-C
- позволяет создать слот репликации, названный параметром -S, перед запуском резервного копирования.-S
- указывает имя слота репликации.$ pg_basebackup -h 10.20.20.9 -D / var / lib / pgsql / 12 / data -U replicator -P -v -R -X stream -C -S pgstandby1. $ exit.
8. По завершении процесса резервного копирования новый каталог данных на резервном сервере должен выглядеть так, как показано на снимке экрана. А standby.signal создается, и настройки подключения добавляются к postgresql.auto.conf. Вы можете перечислить его содержимое, используя команда ls.
# ls -l / var / lib / pgsql / 12 / data /
Подчиненное устройство репликации будет работать в «Горячее резервирование”Режим, если hot_standby для параметра установлено значение on (значение по умолчанию) в postgresql.conf и есть standby.signal файл присутствует в каталоге данных.
9. Вернувшись на главный сервер, вы должны увидеть слот репликации, который называется pgstandby1 когда вы открываете pg_replication_slots вид следующим образом.
# su - postgres. $ psql -c "ВЫБРАТЬ * ИЗ pg_replication_slots;" $ exit.
10. Чтобы просмотреть настройки подключения, добавленные в postgresql.auto.conf файл, используйте команда кота.
# cat /var/lib/pgsql/12/data/postgresql.auto.conf.
11. Теперь начните нормальные операции с базой данных на резервном сервере, запустив службу PostgreSQL следующим образом.
# systemctl start postgresql-12.
12. После успешного установления соединения между главным и резервным сервером вы увидите сообщение WAL процесс-приемник на резервном сервере со статусом потоковой передачи, вы можете проверить это с помощью pg_stat_wal_receiver Посмотреть.
$ psql -c "\ x" -c "ВЫБРАТЬ * ИЗ pg_stat_wal_receiver;"
и соответствующий WAL процесс отправителя на главном / основном сервере с состоянием потоковой передачи и sync_state async, вы можете проверить это представление pg_stat_replication pg_stat_replication.
$ psql -c "\ x" -c "ВЫБРАТЬ * ИЗ pg_stat_replication;"
На скриншоте выше потоковая репликация асинхронная. В следующем разделе мы продемонстрируем, как дополнительно включить синхронную репликацию.
13. Теперь проверьте, нормально ли работает репликация, создав тестовую базу данных на главном сервере и проверьте, существует ли она на резервном сервере.
[master] postgres = # СОЗДАТЬ БАЗУ ДАННЫХ tecmint;
[режим ожидания] postgres = # \ l
14. Синхронная репликация предлагает возможность зафиксировать транзакцию (или записать данные) в первичную базу данных и в резервную / реплику одновременно. Он только подтверждает успешность транзакции, когда все изменения, внесенные в транзакцию, были перенесены на один или несколько синхронных резервных серверов.
Чтобы включить синхронную репликацию, synchronous_commit также должен быть включен (это значение по умолчанию, поэтому нет необходимости в каких-либо изменениях), и вам также необходимо установить synchronous_standby_names параметр на непустое значение. В этом руководстве мы установим его для всех.
$ psql -c "ИЗМЕНИТЬ СИСТЕМУ SET synchronous_standby_names TO '*';"
15. Затем перезагрузите службу PostgreSQL 12, чтобы применить новые изменения.
# systemctl перезагрузить postgresql-12.service.
16. Теперь, когда вы запрашиваете WAL отправителя на основном сервере еще раз, он должен показать состояние потоковой передачи и sync_state из синхронизировать.
$ psql -c "\ x" -c "ВЫБРАТЬ * ИЗ pg_stat_replication;"
Мы подошли к концу этого руководства. Мы показали, как настроить PostgreSQL 12 потоковая репликация базы данных master-standby в CentOS 8. Мы также рассмотрели, как включить синхронную репликацию в кластере базы данных PostgreSQL.
Существует множество вариантов использования репликации, и вы всегда можете выбрать решение, которое соответствует вашей ИТ-среде и / или требованиям конкретного приложения. Для получения более подробной информации перейдите на Резервные серверы доставки журналов в документации PostgreSQL 12.