В прошлом у меня был успех с функцией отложенной репликации MySQL, которая позволяет останавливать репликацию, проверять журнал bin, чтобы найти неверный запрос и SLAVE UNTIL непосредственно перед указанным запросом и пропустите его.
Поскольку Postgresql представил min_recovery_apply_delay настройка Я надеялся добиться того же в Postgres, однако я продолжаю читать статьи, которые останавливаются на точке, в которой вы останавливаете репликацию. Итак, теперь у вас есть данные, возраст которых составляет x часов ... как вы снова сможете их запустить? Руководство, подобное тому, что Я писал для MySQL было бы идеально
Изменить: из большого количества поисков я нашел инструменты omnipitr и pghoard вместе с настройками цели восстановления. В частности recovery_target_xid настройка, которая позволит мне восстановить точный запрос. Единственная недостающая часть головоломки - я не знаю, как сказать postgresql пропустить этот неверный запрос и продолжить восстановление после этого.
Возможно, я ошибаюсь, но для потоковой репликации postgresql вам необходимо настроить архивирование на главном сервере (см. В документе https://www.postgresql.org/docs/current/static/continuous-archiving.html). Мастер сохраняет старые XLOGS (журналы WAL) в данном каталоге (и вам нужно периодически удалять их позже, потому что мастер пока не делает это автоматически). Эти заархивированные xlogs необходимы, иначе репликация postgresql теперь выживет после некоторых более длительных сетевых проблем и т. Д. Так вы это имеете в виду?
Это похоже на MySQL, если реплика запускается после некоторого времени простоя или недоступности, а двоичные журналы больше не присутствуют на главном сервере, вы должны воссоздать реплику. В противном случае, если двоичные журналы все еще доступны, реплика будет автоматически синхронизироваться (если ведомое устройство не было остановлено или принудительно не запускалось в файле конфигурации).
Спрашивая некоторых более опытных людей по PostgreSQL, чем я, и продолжая читать, кажется, что вы действительно не можете пропустить запросы, как в MySQL. При возобновлении после восстановления создается новая «временная шкала» в стиле «Назад в будущее».
Возможно, PostgresSQL предложит безопасный способ достижения этого в будущем, но на данный момент кажется, что вы ограничены восстановлением до определенного момента времени, но все данные, записанные после этого, теряются без значительной ручной работы.