ApsaraDB RDS объединяет управление экземплярами, репликацией и бэкапами для популярных реляционных СУБД

Реляционные СУБД остаются основой для большинства транзакционных приложений — систем заказов, финансовых реестров, сервисов идентификации и CMS-но их эксплуатация требует значительных усилий. Обзор фиксирует типичные операционные задачи: подбор оборудования, патчинг движков, настройка синхронной репликации, автоматизация бэкапов, тесты аварийного переключения, ужесточение сетевых правил и поддержание производительности под нагрузкой. ApsaraDB RDS позиционируется как управляемый сервис, который сводит эти операции в единый интерфейс для нескольких движков. В RDS экземпляр реализован как набор компонентов: бинарник выбранного движка, выделенные вычислительные ресурсы, подключённое хранилище и сетевой endpoint. Класс экземпляра выбирается по наборам CPU и памяти, а хранилище выделяется отдельно на базе ESSD с возможностью выбора уровня производительности. Такой подход разделяет вопросы вычислительной мощности и I/O, упрощая масштабирование и конфигурацию.

Хранилище ESSD предоставляет уровни PL1, PL2 и PL3, различающиеся потолками IOPS и пропускной способностью. PL1 предназначен для типичных OLTP‑нагрузок; PL2 и PL3 ориентированы на высококонкурентные сценарии или большие рабочие наборы, где критичны задержки диска. Выбор уровня влияет на устойчивость работы под пиковыми нагрузками и на стоимость обслуживания.

Высокая доступность реализуется через топологию primary — standby внутри зоны или между зонами. По умолчанию для MySQL используется полусинхронная репликация: транзакция подтверждается клиенту только после записи в relay‑лог standby, что снижает риск потери данных по сравнению с чисто асинхронной схемой. Автоматическое переключение на standby инициируется при провале проверок здоровья и обычно завершает промоцию за десятки секунд; кросс‑зональное развертывание добавляет небольшую сетевую задержку, но повышает устойчивость к падению зоны. Для разгрузки чтений к primary можно прикреплять read‑only экземпляры с независимыми асинхронными потоками репликации; для MySQL рекомендуются RDS Proxy или другие слои read/write‑splitting для распределения SELECT‑запросов по чтениям.

Производственные развертывания рекомендуется размещать в VPC: экземпляры получают приватные endpoint, доступные только внутри VPC или через связку VPC/Cloud Enterprise Network (CEN)/VPN. Публичные endpoint оставляют для разработки и миграций и, при отсутствии явной необходимости, отключают в продакшне. Доступ следует контролировать с помощью IP‑белых списков (CIDR или конкретные адреса) и ограничивать подсетью приложения. По умолчанию используются стандартные порты, например 3306 для MySQL и 5432 для PostgreSQL.