Как настроить потоковую репликацию PostgreSQL со слотами репликации в Debian 10

На этой странице

Требования
Шаг 1. Установка PostgreSQL
Шаг 2. Начальная настройка
Шаг 3. Основная конфигурация
Шаг 4. Базовая резервная копия
Шаг 5. Резервная конфигурация
Тестирование
1. Тестирование репликации
2. Тестирование отказоустойчивости
PostgreSQL — это мощная и многофункциональная система управления реляционными базами данных (RDBMS). Это бесплатный продукт с открытым исходным кодом, который разрабатывается с 1996 года. Postgres предлагает различные способы архивирования и репликации данных, одним из которых является потоковая репликация. В этом режиме первичный (главный) экземпляр обрабатывает основную активную базу данных и выполняет операции. Вторичный (подчиненный) экземпляр копирует все изменения из первичного, сохраняя идентичную копию активной базы данных. Дополнительный сервер также может принимать запросы только для чтения. Если первичный выходит из строя, вторичный сервер может выйти из режима ожидания и работать в качестве нового главного сервера (это называется отказоустойчивостью).
Репликация PostgreSQL обычно опирается на ведение журнала с опережением записи (WAL), процесс регистрации изменений данных перед их записью на диск. Затем эти записи WAL либо копируются на второй узел в виде файлов (доставка журналов на основе файлов), либо напрямую передаются между узлами (потоковая репликация). В большинстве случаев последнее уменьшает задержку получения изменений на главном узле резервным узлом.
Проблема с использованием потоковой репликации без доставки журналов на основе файлов заключается в том, что вторичный сервер может пропустить некоторые записи WAL, если первичный отбрасывает их слишком рано. Ряд параметров конфигурации может снизить этот риск, но часто сопряжен с ненужными затратами на хранение. Решением являются слоты репликации, функция, предоставляемая Postgres, которая гарантирует, что основной сервер отбрасывает записи WAL только после того, как они были получены резервным узлом.
Мы будем настраивать потоковую репликацию со слотами репликации на двух узлах Debian 10.
Требования
- Два идентичных экземпляра Debian 10.
- Корневой доступ к обоим экземплярам.
- Переменная среды $EDITOR должна быть установлена в обоих экземплярах.
Шаг 1: Установка PostgreSQL
Обновите и перезагрузите оба узла:
```
apt update
apt upgrade -y
reboot
```
Установите Postgres на обоих узлах и убедитесь, что PostgreSQL включен и работает:
```
apt install -y postgresql
systemctl enable --now 
```
ПРИМЕЧАНИЕ. Согласно их документации, при обновлении PostgreSQL обновление резервного сервера в первую очередь является более безопасным вариантом.
Шаг 2: Начальная конфигурация
По умолчанию PostgreSQL слушает только петлевой интерфейс и недоступен извне. Измените адрес прослушивания на обоих узлах, отредактировав postgresql.conf:
```
$EDITOR /etc/postgresql/11/main/postgresql.conf
```
Найдите следующую строку:
```
#listen_addresses = 'localhost'
```
Измените его на:
```
listen_addresses = 'node_ip_address,127.0.0.1'
```
Если оба узла используют одну и ту же локальную сеть, вы можете использовать частные адреса для node_ip_address, хотя Postgres не будет доступен через Интернет. В противном случае используйте общедоступные адреса.
Сохраните изменение, затем перезапустите оба экземпляра:
```
systemctl restart 
```
Шаг 3: Основная конфигурация
Этот шаг относится только к основному/главному серверу.

Откройте терминал Postgres:
```
sudo -u postgres psql
```
Резервный узел будет использовать пользователя для подключения к ведущему. Создать это:
```
postgres=# CREATE ROLE replicator LOGIN REPLICATION ENCRYPTED PASSWORD 'replicator_password';
```
Затем создайте слот репликации и выйдите:
```
postgres=# SELECT * FROM pg_create_physical_replication_slot('replicator');
postgres=# \q
```
Ради простоты роль репликации и слот названы \репликатор\, хотя они не обязательно должны быть идентичными.
Затем создайте запись в pg_hba.conf, чтобы разрешить пользователю-репликатору подключаться из режима ожидания к мастеру. Открой это:
```
$EDITOR /etc/postgresql/11/main/pg_hba.conf
```
Добавьте в конец следующую строку:
```
host	replication	replicator	standby_ip_address/32		md5
```
Перезапустите главный экземпляр:
```
systemctl restart 
```
Шаг 4: Базовая резервная копия
Команды на этом шаге должны выполняться на вторичном/подчиненном сервере.
Сначала остановите Postgres на вторичном узле:
```
systemctl stop 
```
Сделайте резервную копию старого каталога данных:
```
mv /var/lib/postgresql/11/main/ /var/lib/postgresql/11/main.bak
```
Используйте следующую команду для клонирования каталога данных мастера в ведомое устройство:
```
pg_basebackup -h master_ip_address -U replicator -D /var/lib/postgresql/11/main/ -P --password --slot replicator
```
Вам будет предложено ввести пароль. Введите пароль, который вы выбрали для роли репликатора при ее создании на мастере. После завершения передачи передайте право собственности на каталог данных пользователю postgres:
```
chown -R postgres:postgres /var/lib/postgresql/11/main
```
Шаг 5: Резервная конфигурация
Этот шаг относится только к вторичному/подчиненному серверу.
Включите режим горячего резерва в postgresql.conf:
```
$EDITOR /etc/postgresql/11/main/postgresql.conf
```
Найдите и раскомментируйте следующую строку:
```
#hot_standby = on
```
Создайте файл recovery.conf в каталоге данных Postgres:
```
$EDITOR /var/lib/postgresql/11/main/recovery.conf
```
Включить режим ожидания:
```
standby_mode = 'on'
```
Задайте параметры соединения репликации, используя учетные данные, созданные на мастере:
```
primary_conninfo = 'host=master_ip_address port=5432 user=replicator password=replicator_password'
```
Задайте имя слота репликации, который вы создали на мастере:
```
primary_slot_name = 'replicator'
```
Задайте путь к файлу триггера отработки отказа:
```
trigger_file = '/var/lib/postgresql/11/main/failover.trigger'
```
Если установлен параметр trigger_file, Postgres выйдет из режима ожидания и начнет нормальную работу в качестве основного сервера при создании этого файла триггера. Этот параметр не является обязательным.
После создания recovery.conf передайте право собственности пользователю postgres:
```
chown postgres:postgres /var/lib/postgresql/11/main/recovery.conf
```
Теперь вы можете запустить Postgres:
```
systemctl start 
```
Теперь он находится в режиме ожидания и должен реплицировать любую новую транзакцию.
Тестирование
Тестирование репликации
Чтобы проверить репликацию, выполните любое действие записи на мастере. Например, создайте новую базу данных на мастере:
```
sudo -u postgres psql -c "CREATE DATABASE replitest"
```
Подождите несколько секунд, затем перечислите базы данных на подчиненном устройстве:
```
sudo -u postgres psql -c "\l"
```
Вы должны увидеть, что база данных replitest действительно была реплицирована резервным сервером:
```
List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 replitest | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(4 rows)
```
Тестирование отказоустойчивости
ПРИМЕЧАНИЕ. Тестирование аварийного переключения, как показано здесь, потребует сброса резервного сервера после аварийного переключения.
Поскольку Postgres находится в режиме ожидания, вы не сможете выполнять какие-либо операции записи на вторичном узле до отработки отказа. Например, выполните следующую команду:
```
sudo -u postgres psql -c "CREATE DATABASE test"
```
Команда должна завершиться ошибкой:
```
ERROR:  cannot execute CREATE DATABASE in a read-only transaction
```
Чтобы сигнализировать об отработке отказа, создайте файл триггера, указанный в recovery.conf.
```
touch /var/lib/postgresql/11/main/failover.trigger
```
Подождите несколько секунд, затем попробуйте выполнить операцию записи. Например:
```
sudo -u postgres psql -c "CREATE DATABASE test2"
```
Поскольку Postgres больше не работает в качестве резервного сервера, операция завершится успешно. Postgres также переименует ваш файл recovery.conf в recovery.done и удалит файл триггера.
Чтобы вернуться в режим ожидания, остановите Postgres на (бывшем) вторичном узле:
```
systemctl stop 
```
Сбросить каталог данных:
```
mv /var/lib/postgresql/11/main/ /var/lib/postgresql/11/main.2.bak
pg_basebackup -h master_ip_address -U replicator -D /var/lib/postgresql/11/main/ -P --password --slot replicator
chown -R postgres:postgres /var/lib/postgresql/11/main
```
И пересоздайте recovery.conf:
```
cp /var/lib/postgresql/11/main.2.bak/recovery.done /var/lib/postgresql/11/main/recovery.conf
```
Наконец, перезапустите Postgres:
```
systemctl start 
```
Дополнительный экземпляр теперь вернулся в режим ожидания. На этом этапе вы можете повторно протестировать репликацию.
Заканчивать
Удалите все ненужные базы данных на главном узле, например:
```
sudo -u postgres psql
postgres=# DROP DATABASE replitest;
```
И удалите старые каталоги данных на вашем резервном узле:
```
rm /var/lib/postgresql/11/main.bak -r
rm /var/lib/postgresql/11/main.2.bak -r
```

Как настроить потоковую репликацию PostgreSQL со слотами репликации в Debian 10

На этой странице

Требования

Шаг 1: Установка PostgreSQL

Шаг 2: Начальная конфигурация

Шаг 3: Основная конфигурация

Шаг 4: Базовая резервная копия

Шаг 5: Резервная конфигурация

Тестирование

Тестирование репликации

Тестирование отказоустойчивости

Заканчивать