Управляемые базы данных

Управляемые базы данных предоставляют экземпляры PostgreSQL, Redis и ClickHouse под контролем Gateway на нодах профиля Databases. Gateway отвечает за жизненный цикл ресурса и желаемую конфигурацию, а нода баз данных — за работающий движок и локальную среду выполнения. Поэтому отключение ноды не стирает сохранённую конфигурацию экземпляра, а восстановление начинается с состояния ноды, а не с ручного изменения движка.

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

Управляемый экземпляр не означает отсутствие обслуживания или автоматическую высокую доступность. Gateway автоматизирует подготовку, конфигурацию, мониторинг и операции жизненного цикла, но организация по-прежнему отвечает за классификацию данных, резервные копии, проверку восстановления, обновления движка, планирование ёмкости и непрерывность работы.

Граница возможностей

Возможность	Что сейчас предоставляет Gateway	Что остаётся за оператором
Создание	Ограниченный экземпляр PostgreSQL, Redis или ClickHouse на одной ноде баз данных	Ёмкость и размещение ноды, надёжность хранилища и выбор поддерживаемой версии
Настройка и жизненный цикл	Желаемая конфигурация, запуск, пауза, перезапуск, поддерживаемое изменение размера, публикация, мониторинг и удаление	Окно изменений, совместимость приложения, независимая проверка и решение об откате
Доступ приложений	Управляемые приватные привязки и необязательная прямая публикация с TLS	Поведение клиента, минимальные права, доверие сертификату и правила ротации учётных данных
Резервное копирование	Автоматическое управляемое копирование и восстановление баз данных пока не является готовой функцией	Штатные средства движка, внешнее хранилище, сроки хранения, шифрование и проверка восстановления
Восстановление на момент времени	Автоматически не предоставляется	Архитектура WAL, AOF или другого непрерывного копирования и проверенная процедура восстановления
Репликация и автоматический failover	Не входят в ограниченный односерверный жизненный цикл	Реплики, кворум, failover, fencing и повторное подключение приложения
Обновление основной версии	Не является автоматической гарантией	Проверка совместимости, план миграции, резервная копия, тестовое восстановление, окно обслуживания и точка отката
Аварийное восстановление	Gateway хранит описание ресурса, но не восстанавливает потерянные данные приложения	Независимое место восстановления, копии данных, ключи, восстановление сети и DNS, согласованные RPO и RTO

Если сервису нужны HA, восстановление на момент времени, несколько регионов или автоматический failover, используйте внешнюю платформу баз данных с этими свойствами и подключите её к Gateway как внешнюю базу. Зелёное состояние ресурса Gateway само по себе не доказывает доступность данных.

Перед созданием

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

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

До создания откройте курируемый каталог версий в UI. Поддерживаемые версии — эксплуатационный контракт: не закрепляйте произвольную исправляющую версию из исходного проекта и не оставляйте устаревший движок только потому, что его Container ещё запускается. Для данных рабочей среды заранее документируйте путь обновления и совместимость восстановления.

Создайте и проверьте

1. Выберите движок, поддерживаемую версию, ноду баз данных, размер хранилища и профиль памяти.
2. Проверьте приватную по умолчанию сетевую модель и настройку прямой публикации.
3. Создайте экземпляр и проследите операцию подготовки до завершения.
4. Дождитесь статуса Ready, прежде чем создавать привязку приложения или использовать Explorer, Console либо метрики.
5. Проверьте состояние движка, последние журналы, данные о хранилище и разрешённый путь подключения.

Первая проверка должна включать подходящую движку запись и чтение результата через ту же идентичность, которую будет использовать настоящий клиент. Для PostgreSQL проверьте нужную базу и схему, для Redis — доступ к ожидаемым ключам и политику сохранения данных, для ClickHouse — целевые базу и таблицу, запросы и работу хранилища. После проверки удалите синтетические данные.

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

Измените существующий экземпляр

Pause и Unpause управляют вычислениями, сохраняя данные базы. Пока экземпляр приостановлен, обычные функции состояния, метрик, Explorer и Console недоступны. Restart вызывает короткий перерыв в обслуживании; предупредите зависимые приложения, если они не умеют переподключаться автоматически.

Изменяйте размер только в пределах ограничений движка и хранилища. Перед существенным увеличением ёмкости создайте резервную копию, проследите Task изменения размера, затем проверьте данные о хранилище и поведение приложения. Ротация учётных данных затрагивает использующих их прямых клиентов, тогда как привязки приложений сохраняют собственные идентичности движка. Ротация сертификата может ненадолго пересоздать службу базы данных, поэтому клиенты должны продолжать доверять Gateway Database CA.

Перед плановым изменением зафиксируйте версию движка, использование хранилища, число подключений, текущие привязки, состояние публикации, последнюю успешную резервную копию и владельца операции. После изменения сравните те же сигналы и выполните реальный клиентский запрос. Если операция завершилась ошибкой, сохраните Task и журналы движка до повтора: слепые повторные попытки могут заменить полезные свидетельства вторичными ошибками.

Публикация и вывод из эксплуатации

Прямая публикация TCP включается явно и образует отдельный контракт внешнего клиента. После включения проверьте нужного клиента, доверие к сертификату, учётные данные и сетевой путь. Отключение публикации удаляет прямой путь, но не экземпляр и не приватные привязки рабочих нагрузок.

Удаление разрушительно. Сначала удалите или перенесите зависимые привязки, определите срок хранения резервных копий и убедитесь, что внешним клиентам больше не нужна прямая публикация. Затем Gateway удаляет управляемый экземпляр, связанную идентичность и состояние хранилища в рамках его жизненного цикла. Не удаляйте вручную пользователей движка, внутренние сетевые объекты или хранилище ради ускорения: дождитесь завершения записанной операции, чтобы очистка оставалась согласованной.

Для операторов: хранилище и прямой TLS

Нода баз данных должна пройти ту же предварительную проверку хранилища, которую использует среда выполнения. Управляемые базы Gateway используют предварительно выделенные ext4-образы фиксированного размера, а не неограниченный том Docker. Виртуальные машины и физические хосты обычно предоставляют необходимые loop-устройства и возможности монтирования. Для контейнеризированного хоста нужна явная поддержка loop-устройств и монтирования; неподдерживаемый хост отклоняется без скрытого перехода к более слабой изоляции хранилища.

Прямая публикация использует нативный TLS. Gateway выпускает серверный сертификат через отдельный Database CA и хранит закрытый ключ в принадлежащем демону хранилище вне образа базы. PostgreSQL и Redis публикуют один адрес TLS, а ClickHouse — HTTPS и нативный адрес TLS. Клиенты должны доверять показанному Database CA и следовать документированной политике имени хоста или отпечатка сертификата, а не отключать проверку.

Решения при восстановлении

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

Pause не является резервной копией, а Restart — откатом. Gateway может согласовать состояние инфраструктуры, но не может отменить миграцию схемы приложения или восстановить данные, для которых не было резервной копии.