Сначала уточните СУБД, версию и то, что называли кластером: репликация не равна готовому автоматическому failover. Объясните фактические требования, рассмотренные варианты и собственный вклад в решение. Сравнивают обнаружение отказа, выбор нового primary, защиту от split-brain, переключение клиентов, RPO/RTO и сопровождение. Базовый PostgreSQL не предоставляет весь этот механизм автоматически.
Почему не использовали внутренние возможности кластера для управления ролями primary/replica?
Как обосновать выбор механизма переключения БД, не приписывая неизвестному продукту автоматический failover и не выдумывая историю проекта.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
В условии не указаны СУБД и кластерный менеджер, поэтому нельзя сразу согласиться с предпосылкой, что система сама безопасно переключает роли. Уточните продукт, версию и используемый режим. Под «встроенными возможностями» могли понимать репликацию, выбор лидера, отдельный оператор или управляемую услугу — это разные варианты.
Затем объясните реальное решение команды. Какие требования были к потере данных и времени восстановления? Какие возможности имелись в выбранной версии? Кто оценивал варианты и что проверяли лично вы? Если решение приняли до вашего прихода, отделите известные причины от собственных предположений.
Полезно сравнивать не названия инструментов, а обязанности механизма:
- обнаружение отказа и отличие отказавшего узла от сетевого разделения;
- выбор пригодной реплики с учётом отставания;
- исключение одновременной записи на двух ведущих узлах;
- перенаправление клиентов и восстановление соединений;
- возвращение прежнего primary в безопасной роли;
- сопровождение, наблюдаемость и проверка восстановления.
Например, если речь о PostgreSQL, сама СУБД поддерживает репликацию и перевод standby в primary, но не предоставляет всю систему обнаружения отказа и уведомления standby. Документация отдельно подчёркивает необходимость не допустить возвращения прежнего primary как второго ведущего. Это условный пример, не утверждение о вашем проекте. Failover PostgreSQL.
Также автоматическое переключение не означает нулевую потерю данных: при асинхронной репликации подтверждённые изменения могут не успеть попасть на выбранную реплику. Репликация PostgreSQL.
Если штатный механизм удовлетворял требованиям, отказ от него требует конкретного обоснования. Если нет — назовите проверенное ограничение и компромисс альтернативы. Не оправдывайте дополнительный инструмент одной привычкой и не представляйте ручное переключение универсально более безопасным.