Логическая репликация PostgreSQL зависит от сегментов WAL?

Question

Я успешно использую логическую репликацию между 2 облачными виртуальными машинами PG 11 для получения последних данных.Но я попытался опубликовать также некоторые старые таблицы для передачи данных между базами данных и получил странную ошибку об отсутствующем сегменте WAL.

Эти старые разделы содержат данные 5-6 дней.Я успешно опубликовал их на master и обновил подписку на логическую реплику.Но теперь я получаю странные сообщения об ошибках на логической реплике:

2019-01-21 15:03:14.713 UTC [17203] LOG:  logical replication table synchronization worker for subscription "mysubscription", table "mytable_20190115" has finished
2019-01-21 15:03:19.768 UTC [18877] LOG:  logical replication apply worker for subscription "mysubscription" has started
2019-01-21 15:03:19.797 UTC [18877] ERROR:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000098E000000CB has already been removed
2019-01-21 15:03:19.799 UTC [29534] LOG:  background worker "logical replication worker" (PID 18877) exited with exit code 1
2019-01-21 15:03:24.806 UTC [18910] LOG:  logical replication apply worker for subscription "mysubscription" has started
2019-01-21 15:03:24.824 UTC [18911] LOG:  logical replication table synchronization worker for subscription "mysubscription", table "mytable_20190116" has started
2019-01-21 15:03:24.831 UTC [18910] ERROR:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000098E000000CB has already been removed
2019-01-21 15:03:24.834 UTC [29534] LOG:  background worker "logical replication worker" (PID 18910) exited with exit code 1

, что меня смущает.Я попытался найти некоторую информацию, но не нашел ничего о логической репликации в зависимости от сегментов WAL.

Нет потоковой репликации на этом конкретном главном сервере, и эти сообщения об ошибках, которые я вижу как на главном сервере, так и на реплике, связаны только с логическимрепликация.

Я что-то не так делаю?Есть ли какой-то особый способ публикации более старых данных?Для новых данных и последних данных все работает без проблем.

Конечно, поскольку я опубликовал около 20 таблиц, реплике потребовалось некоторое время для обработки всех таблиц - в настоящее время она обрабатывает всегда 2 одновременно.Но я до сих пор не понимаю, почему это должно зависеть от сегментов WAL ... Большое спасибо.

ОБНОВЛЕНИЕ: Я пытался отменить публикацию и отписаться от этих старых таблиц, а также опубликовать и снова подписать ихно получаю все то же сообщение об ошибке для точно такого же номера сегмента WAL.

ОБНОВЛЕНИЕ 2: Я не опубликовал и отменил подписку на эти проблемные таблицы и сообщения об ошибках, остановленные, так что они определенно были связаны с логической репликацией,Могут ли они быть вызваны моментальным снимком?

ОБНОВЛЕНИЕ 3: Я только что получил дополнительный странный опыт с ошибками сегментов WAL - у моей логической реплики был только очень маленький диск, и во время всей этой работы я забыл проверитьиспользование диска.Таким образом, postgresql на логической реплике потерпел крах из-за полного диска.Поскольку я использую GCE, я просто изменил размер корневого диска и после перезапуска экземпляра получил больше места.Но я также получил недостающие ошибки сегментов WAL в соединениях с логической репликацией.Мой журнал postgresql на реплике теперь полон последовательности этих 3 строк:

2019-01-22 09:47:14.408 UTC [1946] LOG:  logical replication apply worker for subscription "mysubscription" has started
2019-01-22 09:47:14.429 UTC [1946] ERROR:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000099D0000007A has already been removed
2019-01-22 09:47:14.431 UTC [737] LOG:  background worker "logical replication worker" (PID 1946) exited with exit code 1

Почему логическая репликация зависит от сегментов WAL?

Answer 1

Так что я нашел, что было не так, благодаря умным людям в списке рассылки pgsql-general.

1. Логическая репликация действительно зависит от сегментов WAL - https://www.postgresql.org/docs/11/logical-replication-architecture.html - изменения распространяютсяиспользование сегментов WAL - вот почему параметр «wal_level» должен быть установлен на «логический» на ведущем устройстве.

2. Моя проблема с сегментами WAL заключалась в сочетании следующих обстоятельств:

   • Я пытался публиковать и подписывать все наши огромные таблицы вместе - для объяснения мы имеем около 500 миллионов записей в день, самая большая таблица имеет ежедневный раздел ~ 30 ГБ, другие 1 - 5 ГБ
   • PostgreSQL в таком случае создаетснимок и после активации подписки начинает передавать данные из снимка в реплику.Только после передачи всего снимка Walsender начнет отправлять журналы WAL для последних изменений
   • Поскольку я опубликовал около 200 ГБ данных за несколько дней сразу, вы можете себе представить, что передача заняла очень много времени - для передачи 2 новых логических репликацииСлоты создаются и данные передаются в реплику с использованием 2. Walsender.
   • Обычно это работает хорошо, но у нас есть экстренный cronjob, который удаляет журналы WAL, которые слишком устарели, потому что в прошлом у нас были проблемы с почти полным диском.И это была проблема, с которой я столкнулся - экстренный cronjob удалил сегменты WAL, которые еще не были перенесены в реплику.Поэтому, как правило, необходимо иметь достаточно места на диске, чтобы можно было хранить в нем гораздо больше времени, чем обычно.Которого у нас раньше не было - но я его изменил.

3. Джереми Финзел из pgsql-general предложил мне на самом деле использовать другой способ для репликации данных из master - публиковать и подписываться толькоодна таблица в то время и дать время реплики для синхронизации данных.что я и сделал, и теперь логическая репликация работает как шарм ...