Как стать автором
Обновить

Комментарии 5

Доброе утро!
А какими инструментами возможно контролировать процесс репликации или процесс передачи лога транзакций? Ведь возможны ситуации, когда по каким-либо причинам лог мастера будет расти, а слейв не будет этот лог успевать принимать. В определённый момент времени восстановить процесс репликации будет возможно только копированием базы с мастера на слейва.
Данная ситуация довольно редка. Я лично никогда не встречался с неуспевающей записывать standby нодой. Однако можно мониторить процесс репликации. Процесс мониторинга описан в официальной документации по PostgreSQL, а конкретный пример уже был описан в другом посте на Хабре.
С уважением, Юрий Трухин
Подскажите, пожалуйста, а каков алгоритм определения, что Master скорее мертв, чем жив, т.е. не отвечает. В каком режим происходит переключение (с точки зрения приложения, использующего такую схему)? Спасибо.
В первом вопросе вы ответили на свой же вопрос. Если master не отвечает — он мертв. И не важно по какой причине: неполадки с софтом, железом или сетью. Он недоступен. Соответственно софт должен переключиться на использование другого сервера. В данной статье показана простейшая схема репликации, направленная на сохранение данных при крахе ноды master. И использование ее для failover сценариев — не самое лучшее решение.

Для того, чтобы реализовать failover сценарий в данную схему надо добавить балансировщик (pgpool-II). Более детально почитать можно в этой статье. Таким образом при крахе Master софт продолжит работать как и прежде, а балансировщик просто начнет использовать slave. Есть варианты делать failover балансировщик и тд, но это уже тема отдельной статьи.

С уважением, Юрий Трухин
Может напишите про такие сценарии было бы интересно посмотреть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий