Как вернуть систему репликации в postgresql, если главный ip-адрес был изменен в ubuntu?

Question

Postgresql Репликация базы данных имеет два сервера, один для главного и другой для подчиненного. По какой-то причине изменился главный IP-адрес, который использовался в нескольких местах на подчиненном сервере. С новым IP-адресом после замены старых на последний на ведомом сервере репликация не работает, как раньше. Может кто-нибудь помочь решить эту проблему? Ниже приведены шаги, используемые при настройке подчиненного сервера:

1.добавьте главный IP-адрес в файл pg_hba.conf для репликации пользователя

nano /etc/postgresql/11/main/pg_hba.conf host
    replication  master-IP/24  md5

2.modify the following lines in the PostgreSQL.conf file of slave server where listen_addresses should be the IP of the slave server
    nano /etc/postgresql/11/main/postgresql.conf
    listen_addresses = 'localhost,slave-IP'
    wal_level = replica
    max_wal_senders = 10
    wal_keep_segments = 64

3. Take the backup of the master server by entering the IP


pg_basebackup -h master-ip -D /var/lib/postgresql/11/main/ -P -U
    replication --wal-method=fetch

4.create a recovery file and adding the following commands


 standby_mode          = 'on'
    primary_conninfo      = 'host=master-ip port=5432 user=replication password= '
    trigger_file = '/tmp/MasterNow'

Ниже приведена ошибка от файл журнала:

started streaming WAL from primary at A/B3000000 on timeline 2
FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000020000000A000000B3 has already been removed

FATAL:  could not connect to the primary server: could not connect to server: Connection timed out
        Is the server running on host "master ip" and accepting
        TCP/IP connections on port 5432?

record with incorrect prev-link 33018C00/0 at 0/D8E15D18

Answer 1

хост-репликация master-IP / 24 md5

В этой строке отсутствует поле. Поле USER.

listen_addresses = 'localhost, slave-IP'

Редко бывает необходимо, чтобы это было что-то отличное от '*'. Если вы не пытаетесь управлять ею, это еще одна вещь, которую вам нужно изменить. Кроме того, изменение wal_keep_segments на реплике мало что даст, если вы не используете каскадную репликацию. Его необходимо изменить на главном сервере.

pg_basebackup -h master-ip -D / var / lib / postgresql / 11 / main / -P -U репликация --wal-method = fetch

Указывало ли это, что это удалось?

FATAL: не удалось получить данные из потока WAL: ОШИБКА: запрошенный сегмент WAL 000000020000000A000000B3 уже удален

ФАТАЛЬНО: не удалось подключиться к основному серверу: не удалось подключиться к серверу: истекло время ожидания подключения Сервер работает на хосте "master ip" и принимает соединения TCP / IP через порт 5432?

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

Answer 2

Резервный сервер не работал достаточно долго, чтобы на первичном сервере больше не было необходимой информации журнала транзакций.

Существует три способа устранения:

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

   Это единственный вариант, который позволяет восстанавливать, не перестраивая резервный сервер с нуля.

2. Установите wal_keep_segments на первичном сервере высокого уровня Достаточно, чтобы в нем было достаточно WAL для покрытия сбоя.

   Это не поможет вам восстановиться сейчас, но позволит избежать проблемы в будущем.

3. Определите физический слот репликации на первичном сервере и введите его имя в параметре primary_slot_name в конфигурации восстановления резервного сервера.

   Это не поможет вам восстановиться сейчас, но позволит избежать проблемы в будущем.

   Примечание: При использовании слотов репликации следите за репликацией. В противном случае отказ в режиме ожидания приведет к накоплению сегментов WAL на первичном сервере, что в конечном итоге приведет к заполнению диска.

Для всех вариантов, кроме первого, требуется перестроить резерв с помощью pg_basebackup потому что требуемая информация WAL больше не доступна.