Какие способы обеспечения высокой доступности баз данных существуют

Что проверяют

Отличаете ли вы высокую доступность от резервного копирования и понимаете ли, что HA это не реплика сама по себе, а автоматическое переключение, маршрутизация клиентов и защита от двух мастеров. Следом спрашивают про RPO и RTO и про то, как вы проверяли переключение.

Как отвечать

Стройте ответ слоями на примере PostgreSQL:

• репликация: потоковая физическая репликация WAL. Асинхронная не тормозит запись, но при аварии теряет хвост транзакций. Синхронная (synchronous_standby_names) даёт RPO около нуля ценой задержки каждого коммита;
• автоматический failover: Patroni с etcd или Consul. Лидер держит ключ в хранилище консенсуса, при потере ключа повышается реплика с минимальным отставанием. В Kubernetes то же делают операторы, например CloudNativePG;
• маршрутизация: клиент не должен знать адрес мастера. HAProxy с проверкой роли через REST API Patroni, виртуальный IP через keepalived или строка подключения с несколькими хостами и target_session_attrs=read-write;
• защита от split-brain: кворум из нечётного числа узлов и fencing старого мастера, чтобы после разрыва сети не было двух узлов, принимающих запись;
• размещение: узлы в разных зонах доступности, иначе одна авария гасит всё.

У других СУБД те же идеи: MySQL InnoDB Cluster, replica set в MongoDB с выборами по большинству. У управляемой базы HA включается хостами в нескольких зонах, но переподключение приложения остаётся на вас.

Бэкапы (pgBackRest, WAL-G, восстановление на момент времени) назовите отдельно: они спасают от ошибочного DELETE, который реплика честно повторит.

Где спотыкаются

Называют резервное копирование способом обеспечить HA. Восстановление занимает часы, это disaster recovery.

Ставят два узла без арбитра. При разрыве связи каждый считает себя главным, и данные расходятся.

Ни разу не проверяли переключение. Сильный ответ включает учения: patronictl switchover, выключение узла под нагрузкой и замер, через сколько приложение снова пишет. Сюда же пул соединений, который после failover продолжает ходить на старый мастер.