Не уверен, что материал будет простым, но публикую как есть, как всё знал на момент этой стори.
Ко мне снова обратились с привычной проблемой: AWS, есть Aurora MySQL 3.*, большая нагрузка по кверям, увеличили инстанс, добавили CPU и памяти, даже меняли IOPS - но тормоза не ушли.
Особенно заметно на пиковых нагрузках, когда в систему летят десятки тысяч инсертов в секунду.
Знакомая история, которая всегда начинается с "мы уже всё перепробовали" и заканчивается у моего терминала.
Таска говно - впарить лоху (мне).
Не, ну ладно, зарплата сама себя не отработает, поехали разбираться.
Делаю привычное
SHOW PROCESSLIST - вижу волну wait/io/redo_log_flush.Коммиты висят по 50-100 мс, хотя дисковая подсистема вроде бы не жалуется.
Первое, что приходит в голову: а чо там, а чо, давайте смотреть на sync_binlog.
SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin | ON |
+---------------+-------+
SHOW VARIABLES LIKE 'sync_binlog';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
Сука.
Бинлог включен. Синхронный.
Каждый коммит ждёт фсинка на диск.
На Aurora MySQL 3.x, где кто-то раньше включил Enhanced Binlog (по дефолту он выключен, но у нас был исторически включён).
Вспоминаю, что на этом проекте был Дебезиум. Вроде бы.
Ладно, зацепка, иду в поиск.
Поднимаю историю по слаку, страницам RFC/PoC в Confluence.
Года три назад у нас был активный конвейер CDC на Debezium - реплицировали данные в Snowflake для аналитики.
Потом проект закрылся, команда разошлась, а инфраструктура осталась.
Кто-то выключил Debezium, кто-то отключил коннекторы, но binlog почему-то остался включённым.
"На всякий случай", "вдруг понадобится", "не трогай, оно работает".
Ну или девопс забыл 🤡 (а девопс там был я, фить-ха! )
Только вот работает оно медленно. Каждый INSERT ... VALUES (...), (...), (...) из условных 5000 строк теперь не просто пишет в таблицу, а ещё и в binlog, синхронно, с фсинком.
На пике нагрузки это добавляет 20-30 мс к каждому батчу.
А когда таких батчей 100 в секунду - получаем как раз наш bottleneck.
Перед тем как вырубать, нужно убедиться, что никто не читает этот binlog.
Вдруг там не только дебезум был.
Сперва в консоли нечто типа:
aws dms describe-replication-tasks --region us-east-1 --query "ReplicationTasks[?Status!='stopped'].ReplicationTaskIdentifier"
aws iam list-roles --region us-east-1 --query "Roles[?contains(RoleName, 'DMS')].RoleName"
aws rds describe-db-parameters --db-parameter-group-name aurora-mysql3-params --query "Parameters[?ParameterName=='binlog_format'].ParameterValue"
Затем аудит самой MySQL:
SHOW BINARY LOGS;
+---------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000123 | 1073741824 | No |
| binlog.000124 | 1073741824 | No |
| binlog.000125 | 536870912 | No |
+---------------+-----------+-----------+
Логи растут, но кто их читает?
Бегу проверять:
SHOW REPLICAS;
Empty set (0.00 sec)
SELECT * FROM mysql.ro_replica_status;
Empty set (0.00 sec)
Никаких реплик.
Проверяю в AWS Console - DMS tasks нет.
Проверяю во всех Kubernetes - нет подов с Debezium, нет коннекторов.
Проверяем в IAM - нет ролей для DMS.
Проверяем в CloudWatch - нет метрик от коннекторов.
Теперь самое главное: спрашиваем бизнес. 😁
Собираем три команды: дата-инженеров, аналитиков, девопсов.
Вопрос простой: "Кто-нибудь реплицирует данные из Aurora куда-то ещё?"
Ответы:
- "Нет, мы теперь всё через Kinesis делаем"
- "Нет, мы используем S3 snapshots"
- "Нет, у нас только internal реплики на Aurora"
Сука.
Ок, Убедился, что binlog никому не нужен.
Теперь можно всё кильнуть.