Операции с базами данных

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

Цель — защитить данные и восстановить клиентский путь минимальным обоснованным изменением. Владелец базы отвечает за резервные копии, целостность и решения по движку; владелец платформы — за доступность ноды и хранилища; владелец приложения — за реальные запросы и границы прав. Успешное восстановление возвращает исходный путь, объясняет причину, сохраняет диагностические данные и удаляет временный доступ или публикацию.

До того как база станет критичной, согласуйте допустимую точку потери данных (RPO), допустимое время восстановления (RTO), владельца эскалации и доказательства восстановления. Мониторинг и Restart ускоряют диагностику, но не заменяют проверенный план восстановления данных.

За чем наблюдать

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

Внешние подключения получают те же проверки состояния, метрики движка, Explorer и Console, но не журналы движка, действия жизненного цикла и привязки, потому что Opfield не запускает этот движок. См. Управляемые и внешние базы данных: сравнение. Если для внешнего подключения показывается TLS certificate is not verified, добавьте его CA-сертификат или выберите Test and enable verification; см. Проверка TLS-сертификатов.

Приостановленный экземпляр намеренно отключает обычные функции состояния, метрик, Explorer и Console до возобновления. Не считайте их ожидаемое отсутствие сбоем движка. Зафиксируйте окно приостановки и дождитесь возвращения статуса Ready, прежде чем снова включать зависимые рабочие нагрузки.

Журналы, Explorer и Console

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

Explorer показывает схемы и строки PostgreSQL и ClickHouse; изменение схемы, например добавление или изменение столбцов, доступно для PostgreSQL. Для Redis используется консоль команд. Каждая инструкция консоли относится к чтению, записи или администрированию и требует соответственно databases:query:read, databases:query:write или databases:query:admin.

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

В управляемом экземпляре PostgreSQL база данных и все объекты приложения в ней принадлежат роли приложения этого экземпляра, и каждая привязка работает от имени этой роли. SQL Console тоже выполняет выражения записи и администрирования от имени роли приложения, поэтому таблица, созданная или заполненная из Console, сразу доступна каждой привязке; выражения только для чтения по-прежнему выполняются субъектом только для чтения. Для выражения, которому нужен собственный управляющий субъект Opfield, например для создания роли или расширения, требующего суперпользователя, начните запрос с RESET ROLE; созданные им объекты сразу после этого передаются роли приложения. Opfield также восстанавливает такое владение при каждом создании или согласовании привязки — это исправляет таблицы, созданные из Console в прежних релизах. Восстановление меняет объекты только внутри базы данных приложения и пропускает системные схемы и объекты расширений. Привязки остаются готовыми, пока нода базы данных переподключается.

Интерактивная Console намеренно ограничена общим бюджетом выполнения для всех выражений. Это инструмент оператора, а не средство пакетных миграций. Для изменений схемы и длительных работ используйте версионируемые инструменты миграции, а в Console по возможности выбирайте идентичность только для чтения или с узкими правами. Разрыв соединения браузера не доказывает отмену запроса; до повтора проверьте состояние движка.

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

Восстановите неисправную привязку рабочей нагрузки

Проверяйте неисправную привязку по порядку:

1. Убедитесь, что управляемая база имеет статус Ready, а нода хранилища подключена.
2. Убедитесь, что целевая нода Docker и рабочая нагрузка подключены и сообщают актуальное состояние.
3. Откройте долговременное желаемое состояние привязки и её последнюю Task.
4. Проверьте, что связь привязки в общем коннекторе защищённых связей ноды согласована и рабочая нагрузка подключена к сети связи.
5. Проверьте отдельную идентичность движка привязки и необходимые права.
6. Проверьте полученную рабочей нагрузкой конфигурацию и журналы приложения.

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

Эксплуатационные изменения и удаление

После Pause/Unpause, Restart, изменения размера, ротации учётных данных или сертификата, прямой публикации, удаления привязки и удаления базы выполняйте соответствующую проверку: состояние движка, клиентское подключение, состояние Route или службы приёма соединений, журналы, метрики и записанный результат Task. Прямая публикация включается явно; наблюдайте за ней как за внешним клиентским путём отдельно от приватных привязок.

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

Для операторов: резервное копирование и восстановление

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

Для проверки восстановления:

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

Управление жизненным циклом Container не означает, что Opfield предоставляет восстановление на произвольный момент времени. WAL, сохранение данных Redis, стратегия резервных копий ClickHouse, репликация и внешнее хранение остаются в зоне ответственности эксплуатации баз данных.

Классификация инцидента

До изменения состояния определите уровень: сбои контура управления затрагивают Tasks или согласование; сбои ноды — свежесть данных демона и локальную среду выполнения; сбои движка видны в состоянии и журналах базы; сбои хранилища связаны с монтированием или ёмкостью; сбои привязки — со службой приёма соединений или идентичностью; сбои приложения проявляются после успешного подключения. Такой порядок не позволяет перезапустить исправный движок ради ошибки прав приложения.

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