Вопрос проверяет понимание механизма failover и поведения системы при отказе основной ноды базы данных.
При падении мастера запись в базу становится невозможной, пока не будет выбран новый мастер. Обычно одна из реплик продвигается в master (promotion). Этот процесс может происходить автоматически или вручную. После переключения приложение перенастраивается на новый master.
В архитектуре master-replica мастер отвечает за запись, поэтому его отказ критичен.
Система обычно наблюдает:
ошибки записи
таймауты соединений
рост ошибок в приложении
Чтение с реплик может продолжаться, если оно было настроено.
Типичный сценарий:
обнаружение отказа
выбор реплики
promotion реплики в master
перенастройка клиентов
Пример команды promotion (условный):
pg_ctl promote
Во время failover возможны:
потеря последних транзакций
split brain при неправильной конфигурации
рассинхронизация реплик
Обычно используются:
orchestrator
Patroni
Kubernetes operator
При падении мастера выполняется failover — одна из реплик становится новым мастером, после чего система продолжает работу.
