Комментарии 4
Простите за некропостинг, но не смог раскопать в доках поведение при начальной синхронизации и при ALTER PUBLICATION ADD TABLE:
1. при начальной синхронизации в доках написано, что сначала создается снапшот таблиц и передается подписчикам. При этом WAL как-то задействуется?
2. если сделать ADD TABLE то снапшот должен создаваться или нет? У меня почему-то начальный снапшот не передается.
3. Можно ли принудительно заставить мастер отправить снапшот таблицы в публикацию?
1. при начальной синхронизации в доках написано, что сначала создается снапшот таблиц и передается подписчикам. При этом WAL как-то задействуется?
2. если сделать ADD TABLE то снапшот должен создаваться или нет? У меня почему-то начальный снапшот не передается.
3. Можно ли принудительно заставить мастер отправить снапшот таблицы в публикацию?
Так как я исходники логической репликации не смотрел, то вопрос переадресовал Косте Книжнику.
Вот его ответ:
1. Посредством libpq copy message делается копия записей таблицы, актуальных на момент создания подписки на получателе, после чего накопившиеся за время копирования изменения транслируются из WAL по протоколу логической репликации. Значит и WAL задействуется — для накопления в нём изменений, которые могут случиться за время первоначального копирования;
2. Скорее всего после добавления таблицы в публикацию вы не выполнили ALTER SUBSCRIPTION… REFRESH PUBLICATION на стороне подписки, поэтому и копирования таблицы не произошло;
3. Так как мастер не отправляет снапшот в принципе, то сделать он это не может ни в добровольном, ни в принудительном порядке.
Вот его ответ:
1. Посредством libpq copy message делается копия записей таблицы, актуальных на момент создания подписки на получателе, после чего накопившиеся за время копирования изменения транслируются из WAL по протоколу логической репликации. Значит и WAL задействуется — для накопления в нём изменений, которые могут случиться за время первоначального копирования;
2. Скорее всего после добавления таблицы в публикацию вы не выполнили ALTER SUBSCRIPTION… REFRESH PUBLICATION на стороне подписки, поэтому и копирования таблицы не произошло;
3. Так как мастер не отправляет снапшот в принципе, то сделать он это не может ни в добровольном, ни в принудительном порядке.
Поправка: слово «snapshot» в PostgreSQL используется в разных контекстах, в данном случае это означает, что посылается состояние таблицы на определённый момент времени.
1. Спасибо. Я так понял, что снапшот — это просто фиксация версии таблицы, не позволяющая вакууму подчистить данные + фиксируется точка в WAL. После передачи копии, pgoutput начинает читать WAL с зафиксированнй точки. Я опасался сначала, что в WAL копируется содержимое таблицы каким-то образом, но нет :) pgoutput вообще не задействован в передаче копии.
2. Да, не сразу нашел про REFRESH, спасибо.
3. При логической репликации таргет таблица не защищена от изменений, хочется иметь возможность принудительно восстановить состояние, если что-то случилось на реплике.
Но вообще я в восторге от логической репликации, планирую построить ODS на этой технологии (с партицированием на реплике в отдельных случаях).
2. Да, не сразу нашел про REFRESH, спасибо.
3. При логической репликации таргет таблица не защищена от изменений, хочется иметь возможность принудительно восстановить состояние, если что-то случилось на реплике.
Но вообще я в восторге от логической репликации, планирую построить ODS на этой технологии (с партицированием на реплике в отдельных случаях).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Логическая репликация в PostgreSQL. Репликационные идентификаторы и популярные ошибки