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

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

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

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

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

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

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

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

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

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

До создания откройте курируемый каталог версий в UI. Поддерживаемые версии — эксплуатационный контракт: не закрепляйте произвольную исправляющую версию из исходного проекта и не оставляйте устаревший движок только потому, что его Container ещё запускается. Для данных рабочей среды заранее документируйте путь обновления и совместимость восстановления. Каждая версия каталога закреплена по дайджесту образа. Нода хранилища сначала загружает образ из зеркала Opfield ghcr.io/the-square-labs/gateway, а при неудаче — из Docker Hub, в обоих случаях проверяя тот же дайджест.

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

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

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

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

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

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

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

Учётные данные владельца движка Opfield держит внутри и никогда не возвращает пользователям. Reveal credentials и ротация учётных данных относятся к отдельному пользователю прямого доступа, который существует, пока включена публикация TCP; ротация затрагивает использующих его прямых клиентов. Привязки приложений сохраняют собственные идентичности движка, и ротация их не затрагивает.

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

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

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

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

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

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

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

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

Opfield автоматически продлевает серверный сертификат, проверяя его каждый час: когда прошло две трети срока действия, осталось 30 дней или меньше, не хватает настроенного адреса сервиса или сертификат выпущен другим центром сертификации. Движок загружает новый сертификат на лету — PostgreSQL, Redis и ClickHouse продолжают работать, — а Opfield переключается на него только после того, как экземпляр начал его обслуживать. Database CA не меняется, поэтому клиенты, которые ему доверяют, продолжают работать. В разделе Connection Details базы данных есть неприметная строка TLS Certificate с датой окончания срока действия и пометкой «renewed automatically» или «needs attention». Уведомление на странице появляется, только когда нужно вмешательство — продление не удалось, осталось 7 дней или меньше, продлённый сертификат ещё не загружен, продление ждёт демона ноды или центр сертификации ограничивает срок действия, — с причиной, датой окончания срока и кнопкой Rotate now, если вам разрешено выполнить ротацию. На Dashboard также показывается предупреждение со списком всех управляемых баз данных и управляемых хранилищ, сертификаты которых требуют внимания и которые вы можете просматривать.

Rotate TLS certificate продлевает сертификат сразу, так же загружая его на лету. Перезапуск используется, только если вы его разрешили, если осталось 7 дней или меньше или если демон ноды ещё не умеет загружать сертификаты на лету. Пока продление не удаётся, Opfield поднимает событие уведомлений Managed Service Certificate Renewal Failed. API: GET /api/databases/managed/{id}/certificate и POST /api/databases/managed/{id}/rotate-certificate с необязательным allowRestart; MCP и ассистент: действия certificate_status и rotate_certificate инструмента manage_managed_database.

Собственные подключения Opfield для Explorer, Console, мониторинга и резервного копирования доходят до управляемого экземпляра через туннель Relay со взаимной аутентификацией. Для PostgreSQL с TLS Opfield дополнительно проверяет сертификат сервера по Opfield Database CA и идентичности, выданной этому экземпляру. Redis и ClickHouse внутри туннеля используют незашифрованное соединение.

Привязки приложений доходят до экземпляра через тот же туннель. Для PostgreSQL с TLS клиент привязки может подключаться по обычному URI привязки: демон ноды хранилища сам устанавливает TLS-соединение с PostgreSQL и проверяет сертификат экземпляра, а клиент, который сам запрашивает TLS, сохраняет сквозное TLS-соединение. См. Привязки баз данных приложений.

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

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

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