Bitrix Dba

---
name: bitrix-dba
description: >
  DBA для 1С-Битрикс на MySQL/MariaDB (Percona тоже применимо): тюнинг СУБД под Битрикс,
  регламентное обслуживание, диагностика и снятие блокировок, мониторинг, резервное копирование
  и восстановление, репликация и масштабирование на уровне СЕРВЕРА БД (не запросов приложения).
  Используй всякий раз, когда речь о настройке `my.cnf`/`my.ini` под Битрикс (innodb_buffer_pool_size,
  innodb_log_file_size, max_connections, query_cache — удалён в MySQL 8 / обычно выключен в MariaDB,
  transaction-isolation);
  о блокировках/deadlock (`SHOW ENGINE INNODB STATUS`, `information_schema.INNODB_TRX/INNODB_LOCKS`,
  `KILL`); о регламенте `OPTIMIZE TABLE`/`ANALYZE TABLE`/чистке логов ротацией; о репликации
  master-slave (в т.ч. под веб-кластер Битрикс) и её задержке; о резервном копировании
  (`mysqldump`/`mariabackup`/`xtrabackup`) и проверке восстановимости; о «Панели проверки системы»
  Битрикс в части СУБД. Срабатывай даже без слова «DBA», если речь о том, что «СУБД под Битрикс
  тормозит/не хватает соединений/реплика отстаёт/бэкап не восстанавливается». Железное правило:
  НЕ угадывай параметры и поведение СУБД по памяти — сначала сними измерение (`SHOW STATUS`,
  `EXPLAIN`, slow query log), потом делай вывод; непроверенное помечай [проверить]. Оптимизация
  КОНКРЕТНОГО запроса/ORM-вызова и кэш-стратегия — скилл `bitrix-performance`; разработка PHP —
  `bitrix-dev`.
---

# DBA для 1С-Битрикс (MySQL/MariaDB) — настраивать и обслуживать СУБД по измерениям, не по памяти

## Локализация (сначала, если есть)
Если в скилле есть каталог `references/local/` — прочитай его ПЕРЕД работой: версия СУБД, ОС,
объём RAM/ядер проекта, где лежат бэкапы, схема репликации. При противоречии локальное побеждает
generic. Контракт — `docs/LOCALIZATION.md` toolkit.

Разделение со скиллом `bitrix-performance`: он оптимизирует ЗАПРОСЫ и КЭШ на стороне приложения
(D7 ORM, `CIBlockElement::GetList`, тегированный кэш) — это то, что видит разработчик в коде.
`bitrix-dba` настраивает и обслуживает сам СЕРВЕР СУБД (память, диск, соединения, репликация,
бэкап) — то, что видит администратор в `my.cnf` и мониторинге. Один и тот же симптом «тормозит»
может требовать обоих: сначала `bitrix-performance` смотрит, нет ли N+1/отключённого кэша, затем
`bitrix-dba` — упирается ли СУБД в буфер/IO/соединения при уже оптимизированных запросах.

## Главное правило: сначала измерь, потом меняй
- **Перед выводом** сними данные: `SHOW GLOBAL STATUS`, `SHOW ENGINE INNODB STATUS`,
  `information_schema.INNODB_TRX`/`INNODB_LOCKS`, slow query log + `EXPLAIN`, `iostat`/`vmstat`/`top`.
  Сначала корневая причина (буфер мал? диск насыщен? запрос без индекса?), потом фикс.
- **Любую правку `my.cnf`** — сначала на стейджинге/предпроде, с замером ДО/ПОСЛЕ и планом отката;
  параметры считаются от RAM/ядер/дисков КОНКРЕТНОГО сервера, не берутся константой.
- Параметры/поведение конкретной версии MySQL/MariaDB/Percona, в которых не уверен — помечай
  **[проверить]** по официальной документации версии, не выдавай за факт.
- Пароли/доступы — никогда в чат/репозиторий (см. «Безопасность»).

## Версии и железо — НАСТРОЙ ПОД СВОЙ ПРОЕКТ
Зафиксируй: СУБД и версия (MySQL 8.x / MariaDB / Percona Server), ОС, RAM, число физических ядер,
тип диска (SSD/NVMe), число одновременных соединений (веб + фоновые агенты Битрикс + консольные
скрипты), размер базы. Формулы ниже считаются от этих чисел.

## Тюнинг `my.cnf` под Битрикс
Конкретные ini-значения (`innodb_buffer_pool_size`, `innodb_log_file_size`,
`transaction-isolation`, `innodb_flush_log_at_trx_commit` и т.д.) уже собраны в
`core/skills/bitrix-performance/references/infrastructure.md` — **бери их оттуда, не дублируй**
(единый источник, чтобы не разъезжались числа между скиллами). Здесь — то, чего там нет:
- **`max_connections`** — считай от реального пика одновременных соединений (веб-процессы через
  PHP-FPM `pm.max_children`, фоновые агенты Битрикс, консольные скрипты импорта/обмена), а не
  «с запасом на всякий случай»: `sort_buffer_size`/`join_buffer_size` выделяются по потребности
  под конкретную операцию, а не фиксированно на каждое соединение — риск не в статичном резерве
  памяти, а в том, что при реальном росте конкурентных соединений с тяжёлыми операциями суммарное
  потребление может неожиданно вырасти. Считай лимит от ожидаемого пика, не от «побольше на всякий
  случай».
- **`query_cache`** — в MySQL 8+ полностью удалён из ядра (не выключается — его нет). В
  MariaDB query cache ещё существует, но обычно выключен по умолчанию на новых версиях. В обоих
  случаях Битрикс не полагается на него — использует собственный тегированный кэш приложения
  (`bitrix-performance`); проверяй по факту версии СУБД проекта, не утверждай «выключен» не глядя.
- Проверка после любой правки: «Панель проверки системы» Битрикс (`Настройки → Инструменты →
  Проверка системы`) — секция СУБД показывает несоответствия рекомендациям прямо в интерфейсе.

## Регламентное обслуживание
- `OPTIMIZE TABLE` — точечно на таблицах с высокой фрагментацией (частые UPDATE/DELETE — заказы,
  корзина, логи), не на всей базе разом; поведение по блокировкам версия-зависимое — см.
  `references/maintenance.md`, планируй окно, не считай безопасным по умолчанию.
- `ANALYZE TABLE` после массовых изменений данных (импорт каталога, миграция) — обновляет
  статистику индексов, от которой зависит план запроса оптимизатора.
- Ротация и чистка `b_event_log`, `b_perf_*` (модуль perfmon), логов агентов — растут бесконтрольно
  на активном сайте, регламент чистки — отдельным заданием (крон/агент), не ручной операцией.
- Полная процедура, пороги, скрипты — `references/maintenance.md`.

## Мониторинг и блокировки
`SHOW GLOBAL STATUS` (Threads_connected, Innodb_buffer_pool_read_requests/reads — cache hit ratio,
Slow_queries), `SHOW ENGINE INNODB STATUS` (текущие блокировки, deadlock-секция), slow query log +
`pt-query-digest`/`mysqldumpslow` (топ запросов по суммарному времени). Deadlock у Битрикс типично
на `b_sale_order`/корзине при высокой конкурентности — снимать через `information_schema` и
`SHOW PROCESSLIST`; эскалация снятия сеанса требует сначала проверить, есть ли у него открытая
транзакция (`KILL QUERY` не закрывает её). Детали, включая разбор частых причин deadlock (не
только «изоляция») — `references/monitoring-and-locks.md`.

## Резервное копирование и восстановление
Логический бэкап (`mysqldump`, с `--single-transaction` для InnoDB без блокировки на чтение) vs
физический (`mariabackup`/`xtrabackup`, быстрее на больших базах, без простоя). Регламент:
ежедневный дамп + физический бэкап на объёмных базах + **обязательная регулярная проверка
восстановимости** (бэкап без проверенного restore — не бэкап). Согласовать с выгрузкой `bitrix
backup`/файловым бэкапом `/upload` (данные и файлы должны быть консистентны по времени снятия).
Детали и runbook — `references/backup-recovery.md`.

## Репликация и масштабирование (веб-кластер)
Master-slave репликация под веб-кластер Битрикс: модуль `cluster` требует настройки реплик, слейвы
только для чтения (Битрикс сам умеет распределять read/write через модуль веб-кластера — не любой
код автоматически безопасен на реплике из-за возможной задержки репликации). Диагностика задержки
(`SHOW SLAVE STATUS` → `Seconds_Behind_Master`). Детали — `references/ha-and-scaling.md`.

## Роли-режимы (под задачу — переключай фокус)
tuner (расчёт и правка `my.cnf` от железа, замер ДО/ПОСЛЕ) · maintainer (регламент
OPTIMIZE/ANALYZE/ротация логов) · firefighter (инцидент: блокировки/deadlock/насыщение IO —
сначала диагностика, потом снятие) · monitor (метрики, cache hit ratio, топ медленных запросов) ·
backup-admin (регламент бэкапа + проверка восстановимости) · architect (репликация, веб-кластер,
сайзинг).

## Граница ответственности
DBA настраивает и обслуживает СУБД и сервер, но не правит PHP-код и структуру инфоблоков — она
формируется через админку/API Битрикс и миграции (`sprint.migration`), не руками в БД без
версионирования (см. `bitrix-dev` — «Гейт: правки только в /local»). Если корень медленного
запроса — сам запрос без индексов/с N+1 на уровне PHP-кода, фикс уходит к `bitrix-dev`/
`bitrix-performance`, не в тюнинг СУБД.

## Безопасность
- Пароли БД — только в env/секрет-хранилище, никогда в чат, скрипт, репозиторий, лог.
- Дампы содержат персональные данные клиентов (email, телефон, адреса заказов) — НЕ передавать во
  внешние сервисы/LLM, хранить по регламенту ИБ, доступ ограничивать; обезличивать перед показом
  вовне.

## Смежные скиллы
`bitrix-performance` (запросы/кэш на стороне приложения — куда чаще всего уходит корень «тормозит»
на практике), `bitrix-dev` (разработка/ревью PHP), `bitrix-analyst` (анализ задачи, влияние на
систему).