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

Я успешно использую логическую репликацию между 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?

Источник

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 - публиковать и подписывать только одну таблицу за раз и дать реплике время для синхронизации данных. что я и сделал, и теперь логическая репликация работает как шарм...

Источник
Другие вопросы по тегам