Выступили на IT-Elements
И делимся с вами записью доклада «Cпасти рядовую БД, или стратегии резервного копирования PostgreSQL»
➡ Смотреть запись
А ещё интересным вопросом от слушателя:
А вот наш ответ:
При failover узла, когда есть необходимость восстановить standby (испорченную реплику) с помощью primary (текущего мастера), CopyWala предоставляет функциональность Catchup. Он устанавливает канал связи между standby и primary, чтобы синхронизировать их по наиболее предпочтительной стратегии для каждого случая.
Тут важно уточнить, что «процедура улучшения восстановления бывшего мастера» зависит от конкретной ситуации, которая произошла на восстанавливаемом standy, а именно:
→ Если standby отстал от primary узла (произошёл promote, затёрлись WAL-файлы на мастере и т.д.). Выполняется полная реинициализация данных, то есть удаление старой /pgdata и скачивание актуальной из primary узла. А также на мастере происходит подключение по репликационному протоколу и синхронизируются WAL-файлы.
→ Если отстал повреждённый узел, но из-за большой нагрузки на БД восстановление через WAL с помощью restore_command слишком долгое. Здесь можно воспользоваться догонкой реплики до мастера с синхронизацией страниц с мастера по текущему LSN реплики (Технология Page Scan, Wal summarizer или с помощью Ptrack расширения), не загружая всю /pgdata целиком с одновременной загрузкой валов через репликационный протокол.
Неважно, какой из сценариев вы выберете, главное улучшение — синхронизация файлов между standby и primary в многопоточном режиме, благодаря собственному протоколу взаимодействия в Catchup. Он увеличивает скорость загрузки файлов в несколько десятков раз. А настроить сам Catchup, его стратегию, количество потоков и другие настройки можно по документации.
И делимся с вами записью доклада «Cпасти рядовую БД, или стратегии резервного копирования PostgreSQL»
➡ Смотреть запись
А ещё интересным вопросом от слушателя:
«Представим, что у нас есть настроенный кластер Pangolin (или любой другой PostgreSQL совместимой СУБД), в котором есть синхронная реплика. Срабатывает сценарий failover и система переключится на реплику. Как можно улучшить процедуру восстановления бывшего мастера, если установлена Copywala?»
А вот наш ответ:
При failover узла, когда есть необходимость восстановить standby (испорченную реплику) с помощью primary (текущего мастера), CopyWala предоставляет функциональность Catchup. Он устанавливает канал связи между standby и primary, чтобы синхронизировать их по наиболее предпочтительной стратегии для каждого случая.
Тут важно уточнить, что «процедура улучшения восстановления бывшего мастера» зависит от конкретной ситуации, которая произошла на восстанавливаемом standy, а именно:
→ Если standby отстал от primary узла (произошёл promote, затёрлись WAL-файлы на мастере и т.д.). Выполняется полная реинициализация данных, то есть удаление старой /pgdata и скачивание актуальной из primary узла. А также на мастере происходит подключение по репликационному протоколу и синхронизируются WAL-файлы.
→ Если отстал повреждённый узел, но из-за большой нагрузки на БД восстановление через WAL с помощью restore_command слишком долгое. Здесь можно воспользоваться догонкой реплики до мастера с синхронизацией страниц с мастера по текущему LSN реплики (Технология Page Scan, Wal summarizer или с помощью Ptrack расширения), не загружая всю /pgdata целиком с одновременной загрузкой валов через репликационный протокол.
Неважно, какой из сценариев вы выберете, главное улучшение — синхронизация файлов между standby и primary в многопоточном режиме, благодаря собственному протоколу взаимодействия в Catchup. Он увеличивает скорость загрузки файлов в несколько десятков раз. А настроить сам Catchup, его стратегию, количество потоков и другие настройки можно по документации.
Видео Pangolin DB | HelpCenter
Диагностика производительности, или как упростить себе жизнь