pg_ctl способствует быстрой приостановке репликации - PullRequest
1 голос
/ 10 мая 2019

У меня есть двухузловой кластер PostgreSQL. Один является основным (192.168.50.3), а второй - вторичным (192.168.50.4). Мой recovery.conf выглядит ниже 192.168.50.4.

standby_mode          = 'on'
primary_conninfo      = 'host=192.168.50.3 port=5432 user=myuser password=<password_here> sslmode=require sslcompression=0'
trigger_file = '/tmp/make_master'
recovery_target_timeline = 'latest'

Теперь я запускаю pg_ctl promote на вторичном сервере (192.168.50.4) и, как только команда выполняется успешно, я удаляю некоторые данные с главного устройства (192.168.50.3), и удаленные данные также удаляются с вторичного устройства (192.168 .50.4).

Требуется ли pg_ctl promote время, чтобы фактически приостановить репликацию? Как я могу убедиться, что репликация правильно приостановлена?

логи с /var/log/messages на 192.168.50.4:

May 10 06:17:45 cluster-node6 sudo: myuser : TTY=pts/0 ; PWD=/home/myuser ; USER=postgres ; COMMAND=/usr/pgsql-11/bin/pg_ctl promote --pgdata=/var/lib/pgsql/11/data
May 10 06:17:45 cluster-node6 sudo: pam_unix(sudo:session): session opened for user postgres by csadmin(uid=0)
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  received promote request
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  received promote request
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC FATAL:  terminating walreceiver process due to administrator command
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC FATAL:  terminating walreceiver process due to administrator command
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  redo done at 0/891BFB8
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  redo done at 0/891BFB8
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  last completed transaction was at log time 2019-05-10 06:17:45.550363+00
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  last completed transaction was at log time 2019-05-10 06:17:45.550363+00
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  selected new timeline ID: 2
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  selected new timeline ID: 2
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  archive recovery complete
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  archive recovery complete
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  database system is ready to accept connections
May 10 06:17:45 cluster-node6 postmaster: 2019-05-10 06:17:45 UTC LOG:  database system is ready to accept connections
May 10 06:17:45 cluster-node6 sudo: pam_unix(sudo:session): session closed for user postgres

1 Ответ

1 голос
/ 10 мая 2019

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

Поэтому нормально, что репликация продолжается некоторое время после того, как pg_ctl promote успешно отправил сигнал.

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

Начиная с PostgreSQL v12, вы можете вызвать мою функцию pg_promote() для продвижения в режиме ожидания., который по умолчанию будет ждать завершения акции.

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