Решение: какое решение HA/DR?
Выбор решения высокой доступности и аварийного восстановления начинается не с технологии, а с баланса между требованиями бизнеса (RTO/RPO), потребностью в географическом распределении и стоимостью. Исходя из допустимых простоя и потери данных, это дерево указывает правильный подход среди синхронных реплик, асинхронных standby, кластеров с автоматической отработкой отказа и бэкапа+PITR.
Какова допустимая потеря данных (RPO)?
Начните с самого жёсткого ограничения: сколько секунд данных вы можете позволить себе потерять при аварии? Если требуется нулевая потеря данных (RPO=0), синхронная репликация обязательна; если допустимы несколько секунд/минут, становятся доступны асинхронные решения и более дешёвые подходы. Цель RPO обычно определяет все остальные решения.
- Нулевая потеря данных обязательна (RPO = 0)
- Потеря данных за несколько секунд/минут допустима
Требуется ли также автоматическое быстрое переключение (низкий RTO)?
Вам нужна нулевая потеря данных; но как быстро нужно восстановить работу при отказе первичного сервера? Автоматическая отработка отказа за секунды или допустимо короткое окно ручного вмешательства? Это определяет разницу между простой синхронной репликой и полностью автоматизированным кластером.
- Требуется автоматическая отработка отказа за секунды
- Достаточно ручного/планового переключения; главное — нулевые потери
Требуется ли другой регион/география (DR)?
Если некоторая потеря данных допустима, реальный вопрос — масштаб устойчивости: нужна ли защита от потери целого ЦОД/региона или достаточно защиты от отказа одного узла в том же регионе? Если требуется географическое распределение, на первый план выходит асинхронный standby; если нет, оцениваются варианты с приоритетом стоимости.
- Да, отдельный регион для защиты от географических катастроф обязателен
- Нет, главное — бюджет и простота
Допустимо ли длительное время восстановления (высокий RTO)?
Вы остаётесь в одном регионе и допускаете некоторую потерю данных. Вы стремитесь к минимальной стоимости или хотите standby-узел, быстро принимающий нагрузку при отказе? Если восстановление в течение часов допустимо, бэкап+PITR сам по себе — самый экономичный путь; иначе нужен тёплый standby.
- Да, восстановление в течение часов допустимо (самый дешёвый вариант)
- Нет, нужен тёплый standby, принимающий нагрузку за минуты
Рекомендация: синхронная реплика (нулевая потеря данных)
Первичный сервер не завершает commit, пока хотя бы один standby не подтвердит его; поэтому даже при потере первичного сервера ни одна подтверждённая транзакция не теряется (RPO=0). Идеальное решение в пределах одного региона в сети с низкой задержкой.
Рекомендация: асинхронный standby (географический DR)
Standby применяет изменения потоком, не задерживая commit на первичном сервере. Это стандартный способ держать копию в другом регионе без ущерба для производительности записи; взамен принимается небольшое окно потери данных (равное задержке репликации).
Рекомендация: кластер с автоматической отработкой отказа
Кластерное решение, объединяющее мониторинг состояния, выбор лидера и автоматическое переключение; оно нацелено и на низкий RTO (автоматическая отработка отказа за секунды), и на низкий/нулевой RPO с синхронной копией. Операционные затраты выше, но вмешательство человека сводится к минимуму.
Рекомендация: бэкап + PITR (самый экономичный вариант)
Вместо работающего standby хранятся только регулярные бэкапы и восстановление на момент времени (PITR) через WAL/архивные журналы. Это самое дешёвое решение; цена — восстановление может занять часы (высокий RTO).