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

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

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

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

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

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

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

Журналы, Explorer и Console

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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