IT999in1

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
===== (этап 5) Настройка репликации встроенными инструментами СУБД (ручной Failover/Switchover). =====

> Выполняется на Master db1 10.2.0.11 :

Создадим отдельного пользователя для репликации repl - имя пользователя
<code>
sudo -iu postgres psql
CREATE ROLE repl WITH REPLICATION LOGIN ENCRYPTED PASSWORD '12345678';
\password  # сменим пароль на УЗ postgres внутри СУБД Tantor (пример пароль postgres)
</code>
Правим строчку в pg_hba, тут со стороны заказчика нужно указать, что куда добавить
Правило подключения, если необходимо. Не всегда это нужно в рамках тестового пилота,
Можно оставить так.


> !!! чтобы не мучиться с корректировкой настроек после ''pg_rewind'', для repl можно указать всю подсеть ''10.2.0.0/24''

<code>
sudo nano /var/lib/postgresql/tantor-be-16/data/pg_hba.conf
</code>
<code>
host    replication     repl         10.2.0.12/32            scram-sha-256
host    all             all          0.0.0.0/0               scram-sha-256
</code>
Добавляем параметры, ''ip'' адрес ''Master'' сервера в настройку инстанса
<code>
nano /var/lib/postgresql/tantor-be-16/data/postgresql.conf
</code>
или через ''psql'', параметры запишутся в ''postgresql.auto.conf''
<code>
sudo -iu postgres psql
</code>
<code>
alter system set listen_addresses = 'localhost, 10.2.0.11'; -- можно '*', чтобы не перенастраивать после pg_rewind
alter system set wal_level = replica;
alter system set wal_log_hints = on;
alter system set max_wal_senders = 10;
alter system set fsync = on;
alter system set synchronous_commit = on;
alter system set hot_standby = on;
alter system set hot_standby_feedback = on;
alter system set synchronous_standby_names = '1 (db1, db2)'; -- для async репликации оставьте пустое значение
alter system set max_replication_slots = 10;
alter system set wal_keep_size = '1GB';  -- или больше, в зависимости от требований
</code>
После внесение изменений перезапускаем сервис
<code>
sudo systemctl restart tantor-be-server-16.service
</code>


> Выполняем на ''Replica'' сервере ''db2'' ''10.2.0.12'' :

<code>
systemctl stop tantor-be-server-16.service
su - postgres
cd /var/lib/postgresql/tantor-be-16/
</code>
Сохраним архивную копию папки ''data'' если потребуется для восстановления или удаляем
<code>
tar -cvzf main_backup-`date +%s`.tgz data
rm -rf data/
</code>
Переносим папку ''data'' c ''Master'' сервера на Реплику с созданием слота репликации ''-C -S db2_replica'':
<code>
export PGAPPNAME=db2
pg_basebackup -h db1 -U repl -p 5432 -D data -R -X stream -C -S db2_replica -c fast -P
</code>
>''PASSWORD '12345678'''

Проверяем, появилась ли data каталог
<code>
ls -la data/
</code>
Исправим на правильный listen_addresses
Если указывали ''listen_addresses = '*''', то не нужно
<code>
nano /var/lib/postgresql/tantor-be-16/data/postgresql.conf
</code>
или
<code>
nano /var/lib/postgresql/tantor-be-16/data/postgresql.auto.conf
</code>
<code>
listen_addresses = 'localhost, 10.2.0.12'
</code>
Корректируем правило в ''pg_hba.conf'', для того чтобы после смены лидера, ''db1'' смог подключаться к ''db2''.
Если указывали 10.2.0.0/24, то не нужно.
<code>
nano /var/lib/postgresql/tantor-be-16/data/pg_hba.conf
</code>
<code>
host    replication     repl         10.2.0.11/32            scram-sha-256
</code>
Запустим сервис
<code>
sudo systemctl start tantor-be-server-16.service
sudo systemctl status tantor-be-server-16.service
</code>
На мастере ''db1 10.2.0.11'' проверить реплику
<code>
sudo -iu postgres psql -c "select client_addr, usename, application_name, state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn from pg_stat_replication;"
</code>
На реплике ''db2 10.2.0.12'' , вывод должен быть true
<code>
sudo -iu postgres psql -c "select status,sender_host,sender_port, slot_name from pg_stat_wal_receiver;
SELECT pg_is_in_recovery();"
</code>
Проверим репликацию, создадим сущность данных в СУБД на мастере db1 10.2.0.11
<code>
sudo -iu postgres psql -c "create database tesdb2;"
</code>
Проверим на реплике db2 10.2.0.12
<code>
sudo -iu postgres psql -c "\l"
</code>
==== Смена лидера. (меняем роли местами мастер -> реплику). ====

Проверить статус репликации на ''db2 10.2.0.12''
Должно вернуть ''true'' (реплика в режиме восстановления)
<code>
sudo -iu postgres psql
SELECT pg_is_in_recovery();
</code>
Проверить отставание на ''db2 10.2.0.12''
<code>
SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(), pg_last_xact_replay_timestamp();
</code>
смотрим статус синхронизации на мастере ''db1 10.2.0.11''
<code>
sudo -iu postgres psql
\x
SELECT * FROM pg_stat_replication;
</code>


>Перед переключением мастера на реплику, рекомендуется остановить режим записи СУБД на мастере db1, чтобы избежать потери данных.

Это можно сделать с помощью команды:
<code>
ALTER SYSTEM SET default_transaction_read_only = ON;
SELECT pg_reload_conf();
</code>
На реплике выполните ''db2 10.2.0.12''
Относительно видео - скорректировано создание слота репликации ''db1_replica''
<code>
SELECT pg_promote();
SELECT pg_is_in_recovery();   ## Должно быть `false` (теперь это мастер)
SELECT * FROM pg_create_physical_replication_slot('db1_replica'); ## создать слот репликации для новой реплики
SELECT slot_name, slot_type FROM pg_replication_slots;  ## проверим что новый слот создался
</code>
Остановить сервис ''tantor'' на мастере ''db1 10.2.0.11''
<code>
sudo systemctl stop tantor-be-server-16.service
</code>
выполняем догон ''db1 10.2.0.11'' , новой реплики относительно нового мастера. \\
Делаем ''pg_rewind'' под УЗ ''postgres'', так как пользователь должен иметь права с доступом к функции ''pg_read_binary_file''. \\
либо при создании УЗ ''repl'' дать привилегии, если планируете использовать ее для ''pg_rewind''. \\
''GRANT EXECUTE ON FUNCTION pg_read_binary_file(text, bigint, bigint, boolean) TO repl;'' \\
В PostgreSQL доступ к функции pg_read_binary_file ограничен по соображениям безопасности, так как она позволяет читать произвольные файлы на сервере.
Обычно только суперпользователи (superuser) имеют к ней доступ.
<code>
su - postgres
pg_rewind --target-pgdata=/var/lib/postgresql/tantor-be-16/data --source-server="host=db2 port=5432 user=postgres dbname=postgres password=postgres" -P
</code>
Создайте файл ''standby.signal db1 10.2.0.11''
<code>
touch /var/lib/postgresql/tantor-be-16/data/standby.signal
rm -f /var/lib/postgresql/tantor-be-16/data/postmaster.pid  ## на всякий случай
</code>
Настроить старый мастер db1 10.2.0.11 как новую реплику.
Отредактируем строчки в файле \\
''primary_slot_name = 'db1_replica''' \\
''host=db2 , application_name=db1''
<code>
nano /var/lib/postgresql/tantor-be-16/data/postgresql.auto.conf
</code>


> primary_conninfo = 'user=repl password=12345678 channel_binding=prefer host=db2 port=5432 application_name=db1 sslmode=prefer sslcompression=0 sslcertmode=allow sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres gssdelegation=0 target_session_attrs=any load_balance_hosts=disable'
> primary_slot_name = 'db1_replica'


Корректируем правило в ''pg_hba.conf'', для того чтобы после смены лидера, ''db2'' смог подключаться к ''db1''.
Если указывали ''10.2.0.0/24'', то не нужно.
<code>
nano /var/lib/postgresql/tantor-be-16/data/pg_hba.conf
</code>
<code>
host    replication     repl         10.2.0.12/32            scram-sha-256
</code>
Запустить сервис ''tantor'' на  ''db1 10.2.0.11''
<code>
sudo systemctl start tantor-be-server-16.service
</code>
Проверим на новом мастере ''db2 10.2.0.12'':
<code>
sudo -iu postgres psql -c "select client_addr, usename, application_name, state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn from pg_stat_replication;"
</code>
На новой реплике ''db1 10.2.0.11'':
<code>
sudo -iu postgres psql -c "select status,sender_host,sender_port, slot_name from pg_stat_wal_receiver;
SELECT pg_is_in_recovery();"
</code>
Если мы хотим полностью разделить БД и сделать самостоятельными:
''synchronous_commit = off'' делать ненужно, это
отключает синхронную фиксацию записи данных транзакции на диск, нарушит надежность сохранности данных.
<code>
SELECT pg_promote();
alter system set synchronous_standby_names = '';
SELECT pg_reload_conf();
SELECT  pg_is_in_recovery();                      ## убедитесь, что сервер действительно стал основным, должно быть false
select pg_drop_replication_slot('db1_replica');   ## на db2
</code>