Поиск по сайту:

Как настроить потоковую репликацию PostgreSQL 12 в CentOS 8

База данных PostgreSQL поддерживает несколько решений репликации для создания высокодоступных, масштабируемых и отказоустойчивых приложений, одним из которых является Журнал упреждающей записи (WAL) ) Перевозки. Это решение позволяет реализовать резервный сервер с использованием файловой доставки журналов или потоковой репликации или, где это возможно, комбинации обоих подходов.

При потоковой репликации резервный (подчиненный) сервер базы данных настраивается для подключения к главному/основному серверу, который передает потоковые записи WAL на резервный по мере их создания, не дожидаясь завершения WAL. файл для заполнения.

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

В этом руководстве показано, как настроить потоковую репликацию Postgresql 12 «главный-резервный» в CentOS 8. Мы будем использовать «слоты репликации» для резервного сервера в качестве решения, позволяющего избежать повторного использования главным сервером старых сегментов WAL до того, как резервный сервер их получит.

Обратите внимание, что по сравнению с другими методами, слоты репликации сохраняют только то количество сегментов, которое, как известно, необходимо.

Тестовая среда:

В этом руководстве предполагается, что вы подключились к главному и резервному серверам баз данных в качестве root через SSH (при необходимости используйте команду Sudo, если вы подключаетесь как обычный пользователь с правами администратора):

Postgresql master database server: 		10.20.20.9
Postgresql standby database server:		10.20.20.8

На обоих серверах баз данных должен быть установлен Postgresql 12, в противном случае см. раздел «Как установить PostgreSQL и pgAdmin в CentOS 8».

Примечание. PostgreSQL 12 содержит серьезные изменения в реализации и настройке репликации, такие как замена recovery.conf и преобразование параметров recovery.conf в обычные параметры конфигурации PostgreSQL, что значительно упрощает настройку репликации кластера.

Шаг 1. Настройка главного/основного сервера базы данных PostgreSQL

1. На главном сервере переключитесь на системную учетную запись postgres и настройте IP-адреса, на которых главный сервер будет прослушивать соединения от клиентов.

В этом случае мы будем использовать *, что означает все.

su - postgres
psql -c "ALTER SYSTEM SET listen_addresses TO '*';"

Команда SQL ALTER SYSTEM SET — это мощная функция для изменения параметров конфигурации сервера непосредственно с помощью SQL-запроса. Конфигурации сохраняются в файле postgresql.conf.auto, расположенном в корне папки данных (например, /var/lib/pgsql/12/data/), и читайте дополнение. тем, которые хранятся в postgresql.conf. Но конфигурации в первом имеют приоритет над конфигурациями в более поздних и других связанных файлах.

2. Затем создайте роль репликации, которая будет использоваться для соединений резервного сервера с главным сервером, с помощью программы createuser. В следующей команде флаг -P запрашивает пароль для новой роли, а -e отображает команды, которые createuser генерирует и отправляет на сервер базы данных.

su – postgres
createuser --replication -P -e replicator
exit

3. Затем введите следующую запись в конце файла конфигурации аутентификации клиента /var/lib/pgsql/12/data/pg_hba.conf, указав в поле базы данных значение репликация, как показано на скриншоте.

host    replication     replicator      10.20.20.8/24     md5

4. Теперь перезапустите службу Postgres12, используя следующую команду systemctl, чтобы применить изменения.

systemctl restart postgresql-12.service

5. Далее, если у вас запущена служба firewalld, вам необходимо добавить службу Postgresql в конфигурацию firewalld, чтобы разрешить запросы от резервного сервера к главному.

firewall-cmd --add-service=postgresql --permanent
firewall-cmd --reload

Шаг 2. Создание базовой резервной копии для начальной загрузки резервного сервера

6. Далее необходимо сделать базовую резервную копию главного сервера с резервного сервера; это помогает загрузить резервный сервер. Вам необходимо остановить службу postgresql 12 на резервном сервере, переключиться на учетную запись пользователя postgres, сделать резервную копию каталога данных (/var/lib/pgsql/12/data/), а затем удалить все, что находится под ним. как показано, прежде чем создавать базовую резервную копию.

systemctl stop postgresql-12.service
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) и с соответствующими разрешениями.

В следующей команде опция:

  • -h – указывает хост, который является главным сервером.
  • -D – указывает каталог данных.
  • -U – указывает пользователя подключения.
  • -P – включает отчет о ходе выполнения.
  • -v – включает подробный режим.
  • -R – включает создание конфигурации восстановления: создает файл standby.signal и добавляет настройки подключения в postgresql.auto.conf под данными. каталог.
  • -X — используется для включения в резервную копию необходимых файлов журнала упреждающей записи (файлов WAL). Значение потока означает потоковую передачу 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 "SELECT * FROM pg_replication_slots;"
exit

10. Чтобы просмотреть настройки подключения, добавленные в файл postgresql.auto.conf, используйте команду cat.

cat /var/lib/pgsql/12/data/postgresql.auto.conf

11. Теперь начните обычные операции с базой данных на резервном сервере, запустив службу PostgreSQL следующим образом.

systemctl start postgresql-12

Шаг 3. Тестирование потоковой репликации PostgreSQL

12. После успешного установления соединения между главным и резервным сервером вы увидите процесс-приемник WAL на резервном сервере со статусом потоковой передачи, вы можете это проверить. с помощью представления pg_stat_wal_receiver.

psql -c "\x" -c "SELECT * FROM pg_stat_wal_receiver;"

и соответствующий процесс-отправитель WAL на главном/основном сервере с состоянием потоковой передачи и sync_state асинхронным, вы можете проверить это представление pg_stat_replication pg_stat_replication.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

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

13. Теперь проверьте, работает ли репликация нормально, создав тестовую базу данных на главном сервере и проверьте, существует ли она на резервном сервере.
[master]postgres=# СОЗДАТЬ БАЗУ ДАННЫХ tecmint;
[режим ожидания]postgres=# \l

Необязательно: включение синхронной репликации

14. Синхронная репликация дает возможность одновременно фиксировать транзакцию (или записывать данные) в основную базу данных и резервную базу данных/реплику. Это подтверждает только то, что транзакция прошла успешно, когда все изменения, внесенные транзакцией, были переданы на один или несколько синхронных резервных серверов.

Чтобы включить синхронную репликацию, для synchronous_commit также должно быть включено значение (это значение по умолчанию, поэтому никаких изменений не требуется), а также необходимо установить параметр synchronous_standby_names. на непустое значение. В этом руководстве мы установим его для всех.

psql -c "ALTER SYSTEM SET synchronous_standby_names TO  '*';"

15. Затем перезагрузите службу PostgreSQL 12, чтобы применить новые изменения.

systemctl reload postgresql-12.service

16. Теперь, когда вы еще раз запросите процесс-отправитель WAL на основном сервере, он должен показать состояние потоковой передачи и sync_state . сильная>синхронизация.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Мы подошли к концу этого руководства. Мы показали, как настроить потоковую репликацию главной и резервной базы данных PostgreSQL 12 в CentOS 8. Мы также рассмотрели, как включить синхронную репликацию в кластере базы данных PostgreSQL.

Существует множество вариантов использования репликации, и вы всегда можете выбрать решение, соответствующее вашей ИТ-среде и/или требованиям конкретного приложения. Более подробную информацию можно найти в разделе Резервные серверы доставки журналов документации PostgreSQL 12.