Skip to content

Инструкция из личного кабинета Это руководство по сервису из личного кабинета Nubes (ЛК). Текст приведён без изменений, «как есть».

Инструкция по развертыванию MariaDB через платформу

1. Общая информация

MariaDB — реляционная база данных, совместимая с MySQL. Разворачивается через mariadb-operator в Kubernetes.

Доступные операции с кластером

  • create — создание кластера
  • delete — удаление кластера
  • suspend — остановка кластера (под реально останавливается, ресурсы не потребляются)
  • resume — запуск ранее остановленного кластера
  • modify — изменение параметров кластера
  • reconcile — синхронизация состояния инстанса с платформой

Доступные операции с базами данных

  • create_database — создание базы данных
  • delete_database — удаление базы данных

Доступные операции с пользователями

  • create_user — создание пользователя
  • delete_user — удаление пользователя

2. Параметры создания кластера

Платформа для развертывания (startupConfiguration.resourceRealm)

Среда, в которой будет развёрнут кластер.

Конфигурация ресурсов (clusterConfiguration)

JSON-объект: * cpu — квота CPU пода в миликорах (1000 = 1 vCPU). Пример: 500 * memory — квота памяти пода в мегабайтах. Пример: 512 * disk — размер диска в гигабайтах. Пример: 10 * replicas — количество реплик. Сервис работает в режиме одного primary-узла (Galera выключена), значение 0 эквивалентно остановке кластера.

Версия MariaDB (mariadbConfiguration.version)

Поддерживаются только две версии: 8.4.0 и 9.4.0.

Внешний доступ (accessConfiguration)

JSON-объект: * masterIpSpace — имя ipSpace для выделения внешнего IP. Укажите no-needed, если внешний адрес не требуется. * masterAccessList — список IP/подсетей, которым разрешён доступ к порту 3306 снаружи. Пустой список — доступ не ограничен на уровне firewall (в рамках выделенного ipSpace).

Резервное копирование (backupConfiguration)

JSON-объект: * s3Uid — идентификатор S3-пользователя/квоты для бэкапов. * schedule — cron-выражение расписания бэкапов. По умолчанию 0 0 * * * (раз в сутки в полночь). * retain — время хранения бэкапов в часах (не в днях!). По умолчанию 7 — то есть 7 часов. При суточном расписании этого значения обычно недостаточно, чтобы между двумя бэкапами всегда оставалась хотя бы одна валидная копия — рекомендуется указывать retain явно, с запасом (например 720 = 30 суток).

Важно: расписание и срок хранения бэкапов задаются только при создании кластера. Оператор MariaDB не позволяет изменить cron-расписание бэкапа после создания (поле spec.schedule.cron неизменяемо на уровне admission-вебхука самого оператора) — поэтому эти параметры недоступны для изменения через modify.

Восстановление из бэкапа пока не реализовано как самостоятельная операция платформы. Бэкапы физически хранятся в S3-бакете инстанса (technicals3backup-<instanceUid>, префикс mariadb/backups/). Если нужно восстановить данные из бэкапа — бэкап нужно скачать из S3 и применить к базе вручную (например через mariabackup/mariadb-backup restore или соответствующий инструмент).

Автомасштабирование диска (autoscaleConfiguration)

JSON-объект: * enabled — включить автоматическое расширение диска при исчерпании места. * quota — максимальный размер диска, до которого разрешено автоматическое расширение (не может быть меньше clusterConfiguration.disk). * percent, schedule — параметры триггера автомасштабирования.


3. Параметры модификации кластера

Все параметры модификации, кроме версии, можно как увеличивать, так и уменьшать (кроме диска — см. ниже) — система подставит текущие сохранённые значения, если их не менять.

Конфигурация ресурсов (clusterConfiguration)

  • cpu, memory — можно менять в любую сторону.
  • disk — можно только увеличивать, уменьшение уже выделенного размера не поддерживается.
  • replicas — 0 останавливает кластер тем же образом, что и suspend (альтернативный способ временной остановки через modify).

Версия MariaDB (mariadbConfiguration.version)

Можно только повышать версию (8.4.0 → 9.4.0). Попытка понизить версию будет отклонена с явной ошибкой ещё до применения изменений.

Внешний доступ (accessConfiguration)

Можно включить внешний доступ (было no-needed → указали реальный masterIpSpace), изменить список разрешённых IP, либо полностью отключить внешний доступ (masterIpSpace: no-needed) — в этом случае внешний Service, DNS-запись и правило firewall будут корректно откреплены и удалены.

Резервное копирование

Не передаётся при модификации — расписание и срок хранения бэкапов фиксируются на этапе create (см. п.2).


4. Параметры создания базы данных (create_database)

Имя базы данных (dbName)

Строка с именем новой базы. Не может совпадать с зарезервированными системными именами: mysql, sys, information_schema, performance_schema. База с таким же именем не должна уже существовать в кластере.


5. Параметры удаления базы данных (delete_database)

Имя базы данных (dbName)

База должна существовать в кластере. Удаление будет отклонено, если к базе всё ещё привязаны пользователи — сначала нужно снять доступ (delete_user) у всех пользователей, ссылающихся на эту базу.


6. Параметры создания пользователя (create_user)

Имя пользователя (username)

Не может быть root, healthcheck или mariadb.sys — эти имена зарезервированы платформой/оператором.

Пароль (password)

Пароль для подключения от имени создаваемого пользователя.

Базы данных (dbName)

JSON-массив вида [{"dbname": "имя_базы"}] — список баз, к которым выдаётся полный доступ (ALL PRIVILEGES). Все перечисленные базы должны уже существовать в кластере (создать заранее через create_database).

Разрешённые хосты (accessHosts)

MySQL host-паттерн, с которого разрешено подключение под этим пользователем (например % — без ограничений, или конкретная подсеть). Определяет user@host в самой MariaDB — если указать слишком узкое значение, подключение снаружи ожидаемого диапазона будет отклонено сервером на уровне аутентификации, даже если сеть/firewall пропускают трафик.


7. Параметры удаления пользователя (delete_user)

Имя пользователя (username)

Пользователь должен существовать в кластере. root/healthcheck/mariadb.sys удалить нельзя.


8. Выходные параметры

internalConnect

Внутренний адрес для подключения из сервисов, работающих в том же кластере Kubernetes:

{
  "master": {
    "dns": "<clusterResourceName>.<namespace>.svc.<domain>",
    "ip": null,
    "port": 3306
  }
}

externalConnect

Присутствует в выходных данных, только если был запрошен внешний доступ (accessConfiguration.masterIpSpace отличен от no-needed). Если внешний доступ не запрошен или был отключён через modify — этого блока не будет вовсе (пустой блок в состояние не пишется):

{
  "master": {
    "dns": "write.<namespace>.<domain>",
    "ip": "<внешний IP>",
    "port": 3306
  }
}

9. Пример подключения

9.1 Изнутри кластера / того же namespace

mariadb -h <internalConnect.dns> -P 3306 -u <username> -p

9.2 Через port-forward

kubectl port-forward svc/<clusterResourceName> 3306:3306 -n <namespace>

Важно: после port-forward подключайтесь именно по 127.0.0.1, а не localhost:

mariadb -h 127.0.0.1 -P 3306 -u <username> -p

Клиент mysql/mariadb при указании -h localhost игнорирует TCP/порт и всегда пытается подключиться через локальный unix-сокет (/var/lib/mysql/mysql.sock), которого на вашей машине нет — подключение упадёт с ERROR 2002 (HY000): Can't connect to local server through socket. 127.0.0.1 форсирует реальное TCP-подключение. Также не забывайте -P (порт) с заглавной буквы — строчная -p относится к паролю.

9.3 Снаружи (внешний адрес)

mariadb -h <externalConnect.ip или externalConnect.dns> -P 3306 -u <username> -p

Доступно только если при создании/модификации был указан реальный masterIpSpace и подключающийся IP входит в accessConfiguration.masterAccessList (или список пуст).

Где: * <username> — имя пользователя * <password> — пароль пользователя


10. Дополнительная информация

  • Расписание бэкапов (backupConfiguration.schedule/retain) задаётся один раз при создании и не может быть изменено позже — ограничение самого mariadb-operator, а не платформы.
  • Версию MariaDB можно только повышать, откат на более старую версию не поддерживается.
  • Размер диска можно только увеличивать.
  • suspend реально останавливает под (масштабирование StatefulSet в 0 реплик), а не просто помечает кластер как приостановленный — расход ресурсов CPU/RAM/диска (кроме уже занятого диска) прекращается.
  • При отключении внешнего доступа через modify (masterIpSpace: no-needed) внешний Service, DNS-запись и правило firewall удаляются, а externalConnect пропадает из выходных данных.
  • Самостоятельного восстановления из бэкапа (операции restore) пока нет. Бэкапы лежат в S3 инстанса — восстановление данных в существующий кластер выполняется вручную, скачиванием и применением бэкапа самим владельцем инстанса.