Postgres 11 Standby никогда не догоняет - PullRequest
Новая
       43

Postgres 11 Standby никогда не догоняет

0 голосов
/ 07 февраля 2019

После обновления до Postgres 11 я не могу заставить свой рабочий резервный сервер догнать.В журналах все выглядит хорошо в конечном итоге: 

2019-02-06 19:23:53.659 UTC [14021] LOG:  consistent recovery state reached at 3C772/8912C508
2019-02-06 19:23:53.660 UTC [13820] LOG:  database system is ready to accept read only connections
2019-02-06 19:23:53.680 UTC [24261] LOG:  started streaming WAL from primary at 3C772/8A000000 on timeline 1

Но следующие запросы показывают, что все не в порядке: 

warehouse=# SELECT coalesce(abs(pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn())), -1) / 1024 / 1024 / 1024 AS replication_delay_gbytes;
 replication_delay_gbytes
-------------------------
    208.2317776754498486
(1 row)

warehouse=# select now() - pg_last_xact_replay_timestamp() AS replication_delay;
 replication_delay
-------------------
 01:54:19.150381
(1 row)

Через некоторое время (пару часов) replication_delay остается околото же самое, но replication_delay_gbytes растет, хотя примечание replication_delay отстает от начала и replication_delay_gbytes начинается около 0.Во время запуска было несколько таких сообщений: 

2019-02-06 18:24:36.867 UTC [14036] WARNING:  xlog min recovery request 3C734/FA802AA8 is past current point 3C700/371ED080
2019-02-06 18:24:36.867 UTC [14036] CONTEXT:  writing block 0 of relation base/16436/2106308310_vm

, но Googling предполагает, что это нормально.

Реплика была создана с использованием repmgr, запустив pg_basebackup для выполнения клонирования, а затем запустивточная копия и видя, что это нагоняет.Ранее это работало с Postgres 10.

Есть мысли о том, почему эта реплика появляется, но постоянно отстает?

1 Ответ

0 голосов
/ 08 февраля 2019

Я до сих пор не уверен, в чем проблема / была, но мне удалось получить доступ к резерву с этими двумя изменениями:

  • set use_replication_slots=true в конфигурации repmgr
  • установить wal_compression=on в конфигурации postgres

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

По-прежнему кажется, что здесь есть какая-то основная проблема, потому что, например, когда я делаю pg_basebackup, чтобы создать резерв, он генерирует примерно 500 МБ / с сетевого трафика, нозатем, когда потоковая передача WAL после того, как резервное устройство завершает восстановление, падает до ~ 250 МБ / с без сжатия WAL и до 100 МБ / с со сжатием WAL, но сетевой трафик не уменьшается после того, как он догнал сжатие WAL, поэтому яя не уверен, что там происходит, что позволило ему наверстать упущенное.

...