Selectel запустил Multi-AZ кластеры облачных баз данных

23 июля 2026 года Selectel сообщил о запуске Multi-AZ кластеров облачных баз данных в геораспределённом регионе ru-6. Пользователям доступны актуальные версии PostgreSQL, MySQL, Redis, TimescaleDB и ClickHouse, а узлы каждого кластера распределяются между тремя независимыми зонами доступности.

По данным провайдера, площадки разнесены на 10–15 километров и соединены сетью со скоростью до 10 Гбит/с. Задача архитектуры — сохранить работу сервиса при отказе одной зоны. Для бизнеса это заметное улучшение базовой инфраструктуры, но Multi-AZ не следует воспринимать как готовый план непрерывности целиком.

Что даёт распределение по зонам

Зона доступности — изолированная часть облачной инфраструктуры со своими инженерными системами и сетевым контуром. Если реплики базы находятся в разных зонах, отказ питания, оборудования или части сети на одной площадке не должен одновременно вывести из строя весь кластер.

Multi-AZ снижает риск единой точки отказа на уровне дата-центра и избавляет команду от самостоятельной настройки части кластерных механизмов. Поставщик управляет размещением узлов, а приложение подключается к сервису базы данных.

Однако доступность приложения определяется не только базой. Если балансировщик, очередь, хранилище секретов или сервис авторизации остались в одной зоне, общий бизнес-процесс всё равно может остановиться. Поэтому нововведение нужно оценивать в контексте всей схемы зависимостей.

Multi-AZ, резервная копия и резервный регион — разные меры

Эти механизмы защищают от разных событий:

• реплика в другой зоне помогает пережить отказ площадки;
• резервная копия нужна при ошибочном удалении, повреждении данных или неудачной миграции;
• резервный регион снижает последствия крупного регионального сбоя;
• экспортируемая копия уменьшает зависимость от одного облачного аккаунта или провайдера.

Репликация может быстро распространить логическую ошибку на все узлы. Поэтому Multi-AZ не отменяет изолированные бэкапы и регулярную проверку восстановления. Практическая схема этих уровней описана в материале о резервном копировании и отказоустойчивости.

Что уточнить до переноса продуктивной базы

Официальный анонс подтверждает состав поддерживаемых СУБД, три зоны, расстояние между площадками и пропускную способность сети. Для проектного решения дополнительно нужны условия из актуальной документации и договора:

1. Какой режим репликации используется для выбранной СУБД.
2. Как система определяет отказ и сколько занимает переключение.
3. Меняется ли адрес подключения во время failover.
4. Возможна ли потеря последних подтверждённых транзакций.
5. Какие операции обновления вызывают перерыв.
6. Где физически хранятся резервные копии.
7. Какие значения RPO, RTO и SLA закреплены договором.
8. Как клиент получает события о переключениях и деградации.

Необходимо также проверить квоты, доступные конфигурации, версии расширений и сетевые ограничения. Название одной и той же СУБД не гарантирует полной совместимости с текущим окружением приложения.

Как провести проверяемый пилот

Пилот должен включать не только нагрузочный тест, но и управляемые отказы. Сначала команда фиксирует нормальные задержки, пропускную способность и стоимость. Затем имитирует обрыв соединения с узлом, перезапуск реплики, длительную транзакцию в момент переключения и недоступность одной зоны.

На стороне приложения проверяются:

• тайм-ауты и повторные попытки подключения;
• идемпотентность повторяемых операций;
• корректность пула соединений после смены роли узла;
• отсутствие дублей и потерянных задач;
• работа мониторинга и оповещений;
• фактическое время восстановления пользовательской операции.

Именно пользовательская операция, а не статус кластера в панели, является итоговой метрикой. База может считаться доступной, пока приложение продолжает использовать устаревшее соединение или ждёт слишком долгий тайм-аут.

Практический вывод

Multi-AZ DBaaS сокращает объём инфраструктуры, которую команда должна строить и сопровождать самостоятельно. Это особенно полезно для систем, где простой базы сразу останавливает продажи, обслуживание или внутренние процессы.

Но решение о переносе следует принимать после проверки архитектуры приложения, сценариев отказа и договорных показателей. При сравнении управляемого сервиса с собственной площадкой можно использовать наш разбор IaaS и собственного дата-центра, а требования к восстановлению закрепить в отдельном плане аварийного восстановления.

Источник: официальный блог Selectel; адрес первоисточника указан в карточке материала.