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