Управляемые облачные базы данных (RDS/Aurora/Cloud SQL/Atlas/Azure SQL)
Симптом
Цель: изучить ключевые отличия управляемых облачных баз данных от самостоятельно управляемых установок; понять, как в облаке работают резервное копирование, параметры, отработка отказа, мониторинг, обновления и подключение.
1. Смена мышления: вы работаете с сервисом, а не с сервером
В управляемых базах данных у вас НЕТ shell-доступа к ОС, файловой системе или процессу базы данных; нельзя зайти по SSH, вручную править конфигурационные файлы или стать суперпользователем. Доступны только API/консоль управления провайдера и обычное SQL-подключение. AWS RDS/Aurora: управление на уровне ресурса (экземпляр/кластер), сервер скрыт. GCP Cloud SQL: только API экземпляра, ОС недоступна. MongoDB Atlas: полностью управляемый кластер, доступа к mongod нет. Azure SQL Database: PaaS, ни сервер, ни ОС под ним не видны (Managed Instance даёт несколько больше контроля). Поэтому большинство привычек самостоятельного администрирования вроде «посмотреть файл», «убить процесс» или «запустить утилиту ОС» не применимы.
2. Бэкап: автоматические снапшоты + восстановление на момент времени (PITR)
Вы не планируете бэкапы — провайдер делает их автоматически. Восстановление обычно означает «восстановить на определённый момент времени» (PITR) или создать новый экземпляр из снапшота; существующий экземпляр не перезаписывается. AWS RDS/Aurora: автоматические бэкапы + окно хранения; восстановление PITR с точностью до секунды открывается как новый экземпляр/кластер; возможны и ручные снапшоты. GCP Cloud SQL: автоматические бэкапы + PITR через бинарные журналы; восстановление выполняется в новый экземпляр. MongoDB Atlas: непрерывный облачный бэкап + PITR (M10+); восстановление из снапшотов. Azure SQL: встроенные автоматические бэкапы, хранение 1-35 дней, PITR на любой момент и восстановление удалённых БД. Общее правило: проверяйте конфигурацию бэкапов (окно, срок хранения) и регулярно проводите тесты восстановления.
3. Параметры: группы параметров / флаги, а не конфигурационный файл
Вместо ручного редактирования postgresql.conf или my.cnf используется абстракция параметров провайдера; часть параметров заблокирована, а часть требует перезапуска (статические). AWS RDS/Aurora: задаются через DB parameter group (и cluster parameter group); динамические параметры применяются сразу, статические — после перезагрузки. GCP Cloud SQL: «database flags» задаются из консоли/gcloud. MongoDB Atlas: ограниченные «Additional Settings» + размер oplog и т. п.; большинство внутренних параметров управляется провайдером. Azure SQL: большинство настроек уровня сервера управляется провайдером; поведение меняется через SCOPED CONFIGURATION и выбор уровня сервиса. Перед применением проверьте, динамический параметр или статический.
4. Высокая доступность / отработка отказа: управляемые Multi-AZ и реплики
Отработку отказа вы не строите сами — достаточно поставить галочку и доверить это провайдеру. Standby и автоматическая отработка отказа управляются провайдером, а подключения перенаправляются на новый primary через стабильный endpoint. AWS RDS: Multi-AZ (синхронный standby, автоматическая отработка отказа); Aurora: хранилище с несколькими копиями + автоматическая отработка отказа, cluster endpoint указывает на writer. GCP Cloud SQL: конфигурация HA (региональная, standby во вторичной зоне) одним щелчком; реплики для чтения добавляются отдельно. MongoDB Atlas: набор реплик встроен, доступно развёртывание в нескольких регионах/облаках, отработка отказа автоматическая. Azure SQL: встроенная HA (локальные реплики в Business Critical), вариант с избыточностью по зонам и межрегиональная active geo-replication / failover groups. Приложение всегда должно подключаться к endpoint, а не к фиксированному IP.
5. Мониторинг: сервис метрик и журналов провайдера
Поскольку запускать утилиты ОС (top, iostat) нельзя, мониторинг ведётся через платформу метрик провайдера; там находятся метрики CPU, числа подключений, IOPS, отставания репликации и хранилища. AWS: метрики CloudWatch + Enhanced Monitoring + Performance Insights (анализ на уровне запросов). GCP Cloud SQL: Cloud Monitoring (ранее Stackdriver) + Query Insights. MongoDB Atlas: встроенные метрики/графики Atlas + Performance Advisor + панель реального времени. Azure SQL: Azure Monitor + SQL Analytics + Query Performance Insight. Всегда настраивайте пороговые оповещения (использование хранилища, CPU, лимит подключений, отставание реплик).
6. Обновление версий и обслуживание: из консоли, в окне обслуживания
Вместо ручного обновления бинарных файлов вы выбираете целевую версию; патчи минорных версий в основном применяются автоматически, а обновления мажорных версий планируются и обычно связаны с простоем/отработкой отказа HA. AWS RDS/Aurora: выбор версии движка + опция автоматического минорного обновления + малорисковые мажорные обновления через Blue/Green Deployments. GCP Cloud SQL: окно обслуживания + самостоятельное обновление мажорной версии. MongoDB Atlas: обновление версии одним щелчком, почти без простоя, поэтапно (rolling). Azure SQL: патчи применяются платформой автоматически (понятие версии в значительной мере абстрагировано); поведение управляется уровнем совместимости (compatibility level). Всегда сначала проверяйте на тестовой/staging-копии и планируйте окно обслуживания вне рабочего времени.
7. Подключение и безопасность: endpoint + IAM/TLS
Подключения всегда идут через DNS endpoint, предоставляемый провайдером, и шифруются (TLS); сетевой доступ и идентификацию можно привязать к облачной системе управления идентификацией. AWS RDS/Aurora: endpoint экземпляра/кластера + Security Group для сети + опциональная IAM-аутентификация в базе данных + TLS (сертификат rds-ca). GCP Cloud SQL: публичный IP + Authorized Networks или частный IP/VPC, Cloud SQL Auth Proxy, IAM-аутентификация в базе данных, TLS. MongoDB Atlas: строка подключения SRV (mongodb+srv://), IP access list + private endpoint/peering, SCRAM или IAM/X.509, TLS обязателен. Azure SQL: endpoint FQDN сервера + межсетевой экран/Private Link + аутентификация Microsoft Entra ID (ранее Azure AD) + TLS обязателен. Правило: используйте в строке подключения endpoint, а не фиксированный IP, требуйте TLS и по возможности подключайтесь с облачной IAM-идентичностью.