Skip to content

Resource nubes_mariadb · v1.0.0 · Service ID: 115 · Service Name: Mariadb

Manual · Create params · Modify params · Output params · Operations · Example

Сервис Mariadb (nubes_mariadb). См. Create params для списка параметров.

Справка (MAN)

Инструкция по развертыванию 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 инстанса — восстановление данных в существующий кластер выполняется вручную, скачиванием и применением бэкапа самим владельцем инстанса.