MySQL проти Aurora MySQL: «керований» не означає «швидший» — що насправді змінюється

«Керований» не означає «швидший»: що змінюється (і що ні)

Коли кажуть «Aurora швидше», часто мають на увазі «Aurora потребує менше роботи». Це слушно. Але це різні твердження, і їх плутання призводить до дорогих сюрпризів.

Що насправді дає «керований» сервіс

• Патчування інфраструктури та вікна обслуговування (переважно). Ви припиняєте вручну робити оновлення ОС, інсталювати бінарники й багато операційної церемонії.
• Інтегровані бекапи та відновлення до точки в часі без додаткових інструментів.
• Автоматичне зростання сховища і менше дзвінків опівночі «диск заповнений» (хоча це все ще можливо при штормі підключень і тимчасових таблицях, тож не заспокоюйтесь надміру).
• Керовані репліки та оркестрація відновлення з меншим обсягом кастомних скриптів — плюс можливість швидко масштабувати читання, якщо ваша навантаження підходить.
• Метрики та логи в загальній платформі (CloudWatch, Performance Insights), які можуть бути реально корисними, якщо ви розумієте, що саме вони означають.

Чого «керований» вам не дасть

• Автоматичної правильності запитів. Ваш ORM усе ще може згенерувати запит, який виглядає як лист із заручниками.
• Свободи від поганих рішень зі схемою. Відсутній індекс на «гарячому» шляху боляче вдарить по будь-якому двигуну.
• Нескінченної одночасності. Потоки, мютекси, contention у buffer pool і очікування блокування все ще існують.
• Передбачуваної затримки під час сплесків. Aurora має інші вузькі місця, але не їх відсутність.
• Миттєвого безболісного відновлення. Завжди є зона ураження: кеші прогріваються, підготовлені вирази втрачаються, транзакції відкочуються, і ваш додаток має адекватно поводитися.

Операційно найважливіша зміна така: у самокерованому MySQL ви володієте всім стеком і можете інструментувати або налаштувати майже будь-що. В Aurora MySQL у вас більша страховка і менше ручок. Цей компроміс часто виправданий, але треба знати, які ручки зникли — до інциденту.

Цитата, що тримає в реальності: «Надія — не стратегія.» (парафразована думка, приписується генералу Гордон Р. Саллівану і широко використовується в інженерії/операціях)

Короткий жарт №1: Aurora — керована, так. Як і ваші брудні сорочки — до того моменту, поки не забули ручку в кишені.

Під капотом: обчислення, зберігання, логування і чому це важливо

Самокерований MySQL (включно з «MySQL на EC2») — класичний дизайн: сервер бази даних володіє своїм buffer pool, redo log, binary log, і читає/записує блоки на дискове сховище (EBS, NVMe, SAN — що б ви не дали). Продуктивність здебільшого залежить від CPU, пам’яті та IOPS/латентності диска — плюс конструкція запитів.

Aurora MySQL зберігає обчислювальний шар сумісний з MySQL, але шар зберігання — це окрема розподілена служба. Одна ця архітектурна зміна змінює все вниз по ланцюжку: відновлення після крешу, створення реплік, відновлення після відмови та певні класи затримок.

Обчислювальний шар: все ще MySQL-подібний, все ще підкоряється поведінці MySQL

Ваші сесії, блокування, транзакції й оптимізатор все ще з родини MySQL. Звичні «злодії» залишаються: погані плани, відсутні індекси, надто широкі рядки, неконтрольовані тимчасові таблиці, metadata locks і «один гарячий рядок» як точка конкуренції.

Шар зберігання: це вже не ваш EBS-том

Сховище Aurora розподілено по кількох вузлах і зонах доступності, спроєктоване як самовідновне. Обчислювальний вузол відправляє лог-записи в сховище; сховище обробляє реплікацію. Деталі різняться між поколіннями Aurora, але операційний результат консистентний:

• Стійкість і реплікація винесені у підсистему зберігання.
• Обчислювальний вузол легше замінний. У багатьох випадках ви не «ремонтуєте том», а замінюєте обчислювий інстанс, який підключається до вже реплікованого сховища.
• Деякі I/O патерни виглядають інакше. Записи іноді дешевші, бо ви надсилаєте лог-записи, а не повні записані сторінки. Читання можуть бути дуже швидкими при кеші й неочікувано болючими, коли кеш пропадає й потрібно багато випадкових доступів.

Логування: тиха різниця, яка кусає під час інцидентів

У класичному MySQL/InnoDB redo-логи й doublewrite buffer відіграють велику роль у продуктивності й відновленні після крешу. Aurora змінює цю історію. Слід очікувати:

• Інші характеристики відновлення після крешу (часто швидші), бо система зберігання вже має стійкий потік логів.
• Іншу чутливість до I/O-спадів. Іноді «зависла база даних» насправді має корінь проблеми вгору по ланцюжку від двигуна (кора сховища, мережевий збій, шумний сусід у невдалому місці).
• Менше варіантів «полагодити через файлову систему». Ви не можете fsck-ити проблему, бо у вас немає прямого доступу до файлової системи.

Що ви втрачаєте: частину контролю, частину спостережуваності, деякі хитрі прийоми

У самокерованому MySQL, якщо дуже потрібно, ви можете: закріпити афінність CPU, налаштувати kernel dirty ratios, тонко налаштувати RAID, обрати XFS vs ext4 або застосувати патчі Percona. З Aurora ви працюєте через parameter groups, розмір інстансу й дизайн запитів/схеми. Це не гірше. Це інакше — і це звужує ваш «інструментарій аварійного реагування».

Правди про продуктивність: де Aurora виграє, де програє і де нічого не змінюється

Aurora може здаватися швидшою через швидше масштабування та відновлення

Репутація Aurora частково заслужена: ви можете швидко запускати рідери, сховище росте без вашого нагляду, а відновлення після відмови може бути чистішим, ніж у самописному MySQL-настроюванні. Якщо ваша базова ситуація була «MySQL на одному EC2 з крихкою реплікою і нічним mysqldump», Aurora виглядає як ракета.

Але движок усе ще підкоряється тим самим законам

Якщо ви обмежені CPU при парсингу, сортуванні, джойнах або contention, Aurora цього не виправить магічно. Якщо ви обмежені I/O через величезні сканування, погані індекси або занадто малий buffer pool, Aurora теж може підвести. Іноді підводить по-новому: ваші сплески затримки читання тепер формуються розподіленою системою зберігання і мережевими шляхами, а не лише локальною латентністю диска.

Навантаження, які часто підходять Aurora

• Переважно читачі з чітким відокремленням на рідери, особливо коли терпимо невелику затримку реплікації.
• Змішані навантаження, що виграють від швидкого відновлення та швидкого створення реплік.
• Великі набори даних, де управління сховищем — це податок, який ви хочете припинити платити вручну.

Навантаження, які можуть розчарувати

• Ультрачутливі до затримок OLTP, де мають значення одиночні мілісекунди p99 і неприпустима джиттерність.
• Навантаження з великими записами та contention — гарячі ключі, висока частота блокувань або інтенсивна зміна вторинних індексів.
• Патерни запитів, що викликають сплески випадкових читань (наприклад: багато point lookup, що промахуються в кеші, плюс великий робочий набір).

«Aurora швидший» іноді означає просто «Aurora більший»

Інстанси Aurora можна надавати великими, і багато міграцій мовчки піднімають розмір інстансу. Вітаємо: ви провели бенчмарк «більше CPU і RAM» і назвали це архітектурою.

Короткий жарт №2: Хмара полегшує масштабування; вона також полегшує прискорене зростання рахунку за нього.

Найчесніший спосіб порівняти: спочатку визначте вузьке місце

Перед вибором платформи напишіть відповіді на ці запитання:

• Ви переважно обмежені CPU, I/O, блокуваннями чи мережею?
• Болить вас середня пропускна здатність чи хвильова затримка (tail latency)?
• Потрібно масштабувати читання горизонтально, чи треба швидші записи?
• Який у вас бюджет на відмови (RTO/RPO), і чи додаток справді коректно поводиться під час відновлення?

Якщо ви не можете відповісти на ці питання, ви не обираєте базу даних. Ви обираєте оповідь.

Цікаві факти та історичний контекст (швидко, конкретно)

1. Рання популярність MySQL (кінець 1990-х/2000-ті) виникла через те, що він був «достатньо добрим» для веб-навантажень і простішим в експлуатації, ніж важчі корпоративні СУБД.
2. InnoDB став дефолтним движком у MySQL 5.5 (2010), що змістило більшість продакшн-сценаріїв на MVCC, відновлення після крешу і блокування на рівні рядка як стандартну базу.
3. Amazon запустив RDS (2009) ще до появи Aurora, задавши очікування, що «керований» означає менше операційної роботи, а не нову архітектуру зберігання.
4. Aurora дебютувала (2014) як окремий двигун сумісний з MySQL, а не як «звичайний MySQL у обгортці». Сумісність — це контракт; внутрішні механізми — ні.
5. Репліки для читання раніше були DIY-справою у багатьох командах — будували репліку, налаштовували, моніторили лаг, скриптували відновлення — тож простіша управління репліками в Aurora здавалася трансформаційною.
6. MySQL 8.0 (GA 2018) привніс значні покращення (зміни в словнику даних, краща робота з JSON, функції вікон, більш розвинена performance schema), що змістило позицію «ванільного MySQL» сьогодні.
7. Реплікація на базі GTID дозріла з часом і зменшила складність відновлення для класичного MySQL — але все ще залежить від binlog і поведінки apply на репліках.
8. Розподілені системи зберігання у хмарних базах даних стали шаблоном: розділення обчислення та зберігання робить обчислювальні вузли замінними, пришвидшує відновлення й дозволяє масштабувати читання через спільне сховище.

Реплікація та відновлення після відмов: очікування проти реальності

Класична реплікація MySQL: binlog, apply і відчутний лаг

Стандартна реплікація MySQL — логічна: первинка пише в binary logs; репліки тягнуть і застосовують. Лаг виникає через мережу, CPU репліки, диск або одно-потоковий apply (менш поширено зараз, але все ще можливо в залежності від навантаження). Відновлення — це оркестраційна проблема: підняти репліку, впевнитися у GTID-позиціях, перенаправити додатки, уникнути split-brain.

Репліки Aurora: інша розводка, знайомі симптоми

Aurora використовує спільний розподілений шар зберігання; рідери можна додати без копіювання всього набору даних у традиційному сенсі. Це зазвичай означає швидше підготовлення і іноді менший лаг реплікації. Але симптоми, що вас хвилюють — застарілі читання, неконсистентна read-your-writes поведінка, лаг під навантаженням — все ще з’являються. Просто діагностуються інакше.

Відновлення: швидше — не означає без наслідків

Навіть якщо відновлення бази даних швидке, відновлення додатка може не бути. Типові больові пункти:

• Пули з’єднань штурмують новий writer при перепідключенні.
• Підготовлені вирази або сесійний стан пропадають; додатки, що припускають станові сесії, ламаються дивним чином.
• Транзакції в дорозі відкочуються; повтори множать запис навантаження саме тоді, коли система вразлива.
• Кешування DNS / кешування ендпоїнтів може затримати збіг між «відновлення завершено» і «додаток відновився».

Правило прийняття рішень: якщо ви не можете продемонструвати чисте відновлення в контрольованому тесті — разом із поведінкою додатка — ваш RTO лишається бажанням.

Практично: 14 задач з командами, виводами та рішеннями

Це перевірки, які ви насправді запускаєте, коли продакшн незадоволений. Команди показані так, ніби у вас є shell-доступ до хоста з клієнтськими інструментами MySQL і налаштованим AWS CLI. Не кожне середовище виглядає саме так, але робочий процес зберігається.

Задача 1: Перевірити, до чого ви підключені (MySQL чи Aurora, версія та роль інстансу)

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u app -p -e "SELECT @@version, @@version_comment, @@read_only, @@aurora_version;"
Enter password: 
@@version	@@version_comment	@@read_only	@@aurora_version
8.0.34	Aurora MySQL (Compatible with MySQL 8.0.34)	0	3.05.2

Що це означає: Ви на Aurora MySQL, writer-вузол (@@read_only=0), з версією двигуна Aurora, окремою від версії MySQL.

Рішення: Використовуйте очікування специфічні для Aurora: поведінка зберігання, модель відновлення і parameter groups відрізняються від самокерованого MySQL.

Задача 2: Перевірити поточну форму навантаження: потоки, виконувані запити та очікування блокувань

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Threads_running'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"
Enter password:
Variable_name	Value
Threads_running	42
Variable_name	Value
Threads_connected	980

Що це означає: 980 підключених сесій з 42 активними. Це може бути нормально (великий пул) або попередженням (шторм підключень).

Рішення: Якщо затримки ростуть, підозрюйте чергування: забагато підключень або кілька повільних запитів, що створюють натовп.

Задача 3: Визначити топ очікувань (Aurora / MySQL 8 performance schema)

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "SELECT event_name, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 AS total_s FROM performance_schema.events_waits_summary_global_by_event_name ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;"
Enter password:
event_name	COUNT_STAR	total_s
wait/io/file/innodb/innodb_data_file	8221142	913.42
wait/synch/mutex/innodb/buf_pool_mutex	12882211	540.19
wait/io/table/sql/handler	2321441	210.03
wait/lock/metadata/sql/mdl	11222	98.77
wait/synch/cond/sql/COND_thr_lock	882212	75.11

Що це означає: Інтенсивний I/O даних і contention у buffer pool mutex; також значний час у metadata lock.

Рішення: Для I/O: перевірте cache hit rate і плани запитів. Для mutex: підозрівайте гарячі сторінки, надто багато потоків або тиск на buffer pool. Для MDL: перевірте DDL або довгі транзакції.

Задача 4: Перевірити hit rate buffer pool і читання

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';"
Enter password:
Variable_name	Value
Innodb_buffer_pool_read_requests	9182211443
Innodb_buffer_pool_reads	22184219

Що це означає: Існують читання з диска/сховища. Хіт-раціон приблизно 1 - (reads/read_requests), тут дуже високий, але абсолютні пропуски все одно можуть бути болючими під час сплеску.

Рішення: Якщо хвильова затримка збігається з промахами кешу, зменшіть робочий набір (індекси, форма запитів), додайте пам’яті/змініть розмір інстансу або зменшіть випадкові читання.

Задача 5: Знайти найгірші запити за загальним часом (statement digest)

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "SELECT digest_text, count_star, round(sum_timer_wait/1000000000000,1) AS total_s, round(avg_timer_wait/1000000000000,4) AS avg_s FROM performance_schema.events_statements_summary_by_digest ORDER BY sum_timer_wait DESC LIMIT 3\G"
Enter password:
*************************** 1. row ***************************
digest_text: SELECT * FROM orders WHERE customer_id = ? ORDER BY created_at DESC LIMIT ?
count_star: 812112
total_s: 642.7
avg_s: 0.0008
*************************** 2. row ***************************
digest_text: UPDATE inventory SET available = available - ? WHERE sku = ?
count_star: 922111
total_s: 610.3
avg_s: 0.0007
*************************** 3. row ***************************
digest_text: SELECT COUNT(*) FROM events WHERE tenant_id = ? AND created_at > ?
count_star: 2112
total_s: 501.9
avg_s: 0.2377

Що це означає: Третій запит рідкісний, але з великою затримкою; ймовірно виконує великий скан або погано використовує індекси.

Рішення: Виправте «повільні але рідкісні» запити — вони домінують у хвостовій затримці та серйозності інциденту.

Задача 6: Перевірити використання індексів через EXPLAIN (не вгадуйте)

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "EXPLAIN SELECT COUNT(*) FROM events WHERE tenant_id = 42 AND created_at > '2025-12-01'\G"
Enter password:
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: events
partitions: NULL
type: range
possible_keys: idx_tenant_created
key: idx_tenant_created
key_len: 12
ref: NULL
rows: 1822112
filtered: 100.00
Extra: Using where; Using index

Що це означає: Використовується складений індекс. Все ще сканується ~1.8M записів індексу; може бути допустимо, а може бути занадто повільно під навантаженням.

Рішення: Якщо це сторінкує вас, додайте тісніший предикат, таблицю з агрегатами, стратегію партиціонування або попередню агрегацію. Іноді правильне рішення — «припинити рахувати в реальному часі».

Задача 7: Перевірити блокування метаданих (класичний режим помилки при міграції/DDL)

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "SELECT * FROM performance_schema.metadata_locks WHERE LOCK_STATUS='PENDING' LIMIT 5\G"
Enter password:
*************************** 1. row ***************************
OBJECT_TYPE: TABLE
OBJECT_SCHEMA: appdb
OBJECT_NAME: orders
LOCK_TYPE: EXCLUSIVE
LOCK_DURATION: TRANSACTION
LOCK_STATUS: PENDING
OWNER_THREAD_ID: 18211
OWNER_EVENT_ID: 912

Що це означає: Сесія чекає на ексклюзивний лок на orders, зазвичай DDL. Її блокує хтось, хто тримає shared lock (часто довга транзакція або відкритий курсор).

Рішення: Знайдіть блокуючі сесії; обережно вбийте блокуючого або перенесіть DDL на інший час, використовуючи online schema change патерни.

Задача 8: Перевірити лаг репліки / рідера (Aurora через змінні статусу)

cr0x@server:~$ mysql -h mydb-reader.cluster-ro-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Aurora_replica_lag%';"
Enter password:
Variable_name	Value
Aurora_replica_lag_in_msec	128
Aurora_replica_lag_max_in_msec	902

Що це означає: Поточний лаг ~128ms, максимальний спостережуваний ~902ms. Не жахливо, але якщо ваш додаток очікує read-your-writes на рідерах, він час від часу буде помилково показувати дані.

Рішення: Якщо потрібна читання після запису, направляйте ці запити на writer або реалізуйте сесійні гарантії консистентності (токен, кеш або «читати з writer після запису»).

Задача 9: Перевірити тиск тимчасових таблиць (часто ховається за «сплеск CPU»)

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Created_tmp%tables';"
Enter password:
Variable_name	Value
Created_tmp_disk_tables	221122
Created_tmp_files	8122
Created_tmp_tables	982211

Що це означає: Багато тимчасових таблиць на диску. Зазвичай це «запити сортують/групують без хороших індексів» або «tmp_table_size занадто малий», або й те, й інше.

Рішення: Виправте запит першочергово (індекси, зменшення набору результатів). Потім налаштуйте розміри тимчасових таблиць при потребі. Кидання пам’яті на поганий SQL лише змінює, як швидко буде боляче.

Задача 10: Перевірити час очікування рядкових блокувань InnoDB (перевірка contention)

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Innodb_row_lock%';"
Enter password:
Variable_name	Value
Innodb_row_lock_current_waits	18
Innodb_row_lock_time	812211
Innodb_row_lock_time_avg	33
Innodb_row_lock_time_max	12004
Innodb_row_lock_waits	24218

Що це означає: Існують очікування рядкових блокувань і максимальний час очікування — неприємний. Це рівень contention на стороні додатка або дизайн транзакцій.

Рішення: Скоротіть транзакції, уникайте «прочитати потім записати», додайте індекси, щоб зменшити кількість блокованих рядків, або переробіть гарячі рядки (шардінг лічильників, уникнення однорядкових черг).

Задача 11: Підтвердити шторм підключень / поведінку пулу через processlist

cr0x@server:~$ mysql -h mydb.cluster-xxxx.us-east-1.rds.amazonaws.com -u admin -p -e "SHOW PROCESSLIST LIMIT 5;"
Enter password:
Id	User	Host	db	Command	Time	State	Info
31122	app	10.0.12.55:48122	appdb	Sleep	62		NULL
31123	app	10.0.12.55:48123	appdb	Sleep	62		NULL
31124	app	10.0.13.18:51211	appdb	Query	8	Sending data	SELECT ...
31125	app	10.0.13.18:51212	appdb	Query	8	Sending data	SELECT ...
31126	app	10.0.14.77:39911	appdb	Sleep	62		NULL

Що це означає: Багато сплячих підключень вказує на великі пули. «Sending data» на кількох потоках свідчить про запит, що віддає багато рядків або робить інтенсивні читання.

Рішення: Якщо ви бачите тисячі сплячих з’єднань і сплески під час відновлення, обмежте розміри пулів і додайте джиттер при повторних підключеннях.

Задача 12: Замір на рівні OS у самокерованому MySQL (CPU проти I/O)

cr0x@server:~$ iostat -x 1 3
Linux 6.1.0 (ip-10-0-2-10) 	12/30/2025 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.31    0.00    5.88    9.42    0.12   62.27

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1         820.0   410.0 51200.0 18432.0  6.12  91.3

Що це означає: Високе навантаження диска і значні await-часи. Ви обмежені чи близькі до обмеження I/O.

Рішення: У самокерованому MySQL ви можете покращити сховище (швидший NVMe/EBS), налаштувати флашинг або зменшити I/O через кращі запити/індекси. Якщо ви на Aurora, ви не запускаєте iostat по шару сховища — використовуйте метрики двигуна та wait events замість цього.

Задача 13: Перевірити метрики CloudWatch для Aurora (через CLI) для кореляції симптомів

cr0x@server:~$ aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name DatabaseConnections \
  --statistics Average Maximum \
  --period 60 \
  --start-time 2025-12-30T01:00:00Z \
  --end-time 2025-12-30T01:10:00Z \
  --dimensions Name=DBClusterIdentifier,Value=mydb-cluster
{
  "Label": "DatabaseConnections",
  "Datapoints": [
    {"Timestamp":"2025-12-30T01:02:00Z","Average":812.2,"Maximum":1201.0,"Unit":"Count"},
    {"Timestamp":"2025-12-30T01:03:00Z","Average":910.4,"Maximum":1602.0,"Unit":"Count"}
  ]
}

Що це означає: Підключення різко підскочили. Це часто корелює з деплоєм, відновленням, клієнтськими повторами або поганою конфігурацією пулу.

Рішення: Якщо графік підключень схожий на обрив, стабілізуйте клієнтів перш ніж налаштовувати запити (ліміти пулів, таймаути, backoff).

Задача 14: Перевірити відмінності параметрів, що змінюють поведінку (Aurora parameter group)

cr0x@server:~$ aws rds describe-db-parameters \
  --db-parameter-group-name my-aurora-mysql8-params \
  --query "Parameters[?ParameterName=='innodb_flush_log_at_trx_commit' || ParameterName=='sync_binlog' || ParameterName=='max_connections'].[ParameterName,ParameterValue,ApplyType]" \
  --output table
----------------------------------------------
|           DescribeDBParameters             |
+--------------------------------+----------+
|  innodb_flush_log_at_trx_commit| 1        |
|  max_connections               | 4000     |
|  sync_binlog                   | 1        |
+--------------------------------+----------+

Що це означає: Налаштування стійкості суворі (1), і max connections високе (що може бути не завжди розумно).

Рішення: Не ставте max_connections високо лише тому, що можна; це може посилити contention. Тримайте його в межах CPU і очікуваної одночасності, і спочатку виправляйте поведінку додатка.

Швидка діагностика: знайти вузьке місце за хвилини

Під час інциденту немає часу на філософію. Потрібна воронка, яка швидко звузить до кореня проблеми й не обманюватиме.

Перше: це шторм на боці клієнта чи уповільнення на боці бази даних?

• Перевірте підключення (CloudWatch DatabaseConnections; Threads_connected).
• Перевірте відхилені/провалені підключення у логах додатка. Якщо клієнти агресивно повторюють, база стає жертвою, а не причиною.
• Рішення: Якщо підключення підскочили в 2–10×, стабілізуйте поведінку клієнтів перш за все: обмежте пули, додайте backoff і скоротіть таймаути, щоб мертві підключення не накопичувалися.

Друге: writer CPU-завантажений, блокований або I/O/wait-залежний?

• Ознаки CPU-завантаження: високе завантаження CPU, багато runnable-потоків, запити, що важкі на сортування/джойни. У термінах MySQL: багато «статистики», великі сорти, обробка JSON, regex тощо.
• Ознаки блокувань: підвищений Innodb_row_lock_time_max, wait events на блокування, «Waiting for table metadata lock», гарячі рядки.
• Ознаки I/O/wait: високі file I/O waits, промахи buffer pool, сплески у wait events, і «все повільно, але CPU не високий».
• Рішення: Виберіть один клас вузького місця і копніть у нього; не давайте одночасно багато налаштувань.

Третє: ізолюйте головний шаблон запитів-винуватців

• Використовуйте statement digest, щоб знайти топ за загальним часом і за середнім часом.
• Заберіть репрезентативні запити і запустіть EXPLAIN.
• Рішення: Виправте запит, що домінує або за загальним часом (проблема пропускної здатності), або за середнім часом (проблема хвостової затримки), залежно від симптомів.

Четверте: валідуйте стратегію реплік і маршрутизацію читань

• Перевірте лаг реплік і чи використовує додаток рідери для read-after-write потоків.
• Рішення: Якщо консистентність важлива, направляйте такі читання на writer або реалізуйте явний контроль консистентності.

П’яте: лише тоді розглядайте зміни ємності

• Масштабуйте клас інстансу, якщо CPU або пам’ять явно насичені.
• Додавайте рідера лише якщо перевірили, що читання можна відвантажити і лаг прийнятний.
• Рішення: Масштабування — це корисний захід, а не діагностика. Ставтесь до нього як до знеболювального: корисно, але не живильне.

Три корпоративні міні-історії з реальних інцидентів

Міні-історія №1: Інцидент через хибне припущення («репліки Aurora завжди свіжі»)

Компанія була в процесі міграції з самокерованого MySQL на Aurora MySQL. План здавався безпечним: читання на reader endpoint, запис на writer endpoint і насолода економією від масштабування читань. Команда додатку також зробила «малу» зміну: після оформлення замовлення сторінка підтвердження читала з reader endpoint, бо «читання є читання».

Під час спокійного періоду це працювало. Під час піку кілька клієнтів оновили сторінку і не побачили свого замовлення. Спочатку з’явилися звернення в підтримку; потім команда платежів помітила дублювання авторизацій, бо клієнти повторювали оплату. Спостереження не показували нічого драматичного: CPU writer був у нормі, в логах бази помилок не було, лаг репліки був «тільки кілька сотень мс».

Корінь проблеми — припущення, що «сотні мілісекунд» фактично нуль для бізнесових потоків. Це не так. Шлях оформлення замовлення вимагав read-your-writes консистентності, і система її не гарантувала. Клієнти були праві; архітектура помилилася.

Виправлення було нудним і точним: будь-яке читання підтвердження після запису прив’язали до writer на короткий проміжок через сесійний токен, і UI перестав трактувати «не знайдено» як підставу для повторного платежу. Репліки лишилися для перегляду, пошуку і сторінок історії. Інцидент припинився негайно, і міграція продовжилась — з новим правилом у рукописі: «Reader endpoints для терпимих до застарілості читань.»

Міні-історія №2: Оптимізація, що відкотилася (пули підключень «ввімкнені на 11»)

Інша команда мала класичну проблему: занадто багато мікросервісів, кожен зі своїм пулом, кожен налаштований кимось, хто востаннє працював з базами в 2016 році. Переїхавши на Aurora, вони побачили високий параметр max_connections і вирішили «скористатись». Пули по всьому флоту були збільшені. Веселились, що зникли час від часу помилки «too many connections».

Потім почалася дрейфова деградація затримки під час сплесків трафіку. Не завжди. Достатньо, щоб спричинити повільний збій: таймаути тут, повтори там, зростання глибини черг у фоні. Writer не був завантажений на 100% CPU. Метрики сховища не кричали. Але performance schema показувала зростання mutex waits і lock waits. Потоки витрачали час на координацію, а не на роботу.

Відкат був простим: зменшили розміри пулів, а також ввели чергування на рівні додатка для кількох дорогих endpoint-ів, згладжуючи сплески. Пропускна здатність лишилась та сама, але хвильова затримка значно покращилась. Вони припинили «налаштовувати» MySQL тільки зміною найбільшого числа.

Міні-історія №3: Нудна, але правильна практика, яка врятувала день (репетиція відновлення з клієнтською поведінкою)

Фінтех-компанія використовувала Aurora MySQL для критичного сервісу, пов’язаного з головною книгою. У них була щотижнева рутина: тригерити контрольоване відновлення в непроизводчому середовищі, яке відтворювало топологію продакшну, і дивитися, як поводиться додаток. Не база даних — додаток.

У одній репетиції база відновилась за розумний час, але додаток відновлювався хвилинами. Пули тримали мертві з’єднання. Декілька сервісів миттєво і синхронно повторили запити, створивши синхронізований thundering herd. Прогрівач кешу накидав на writer холодні запити саме тоді, коли система намагалася повернутися до рівноваги.

Вони виправили це до реальної події: скоротили TCP keepalive, встановили адекватні таймаути клієнтів, імплементували експоненційний backoff з джиттером і політику прогріву пулів з глобальним лімітом швидкості. Також додали feature flag «degraded mode», що вимикав дорогі ендпоінти під час відновлення.

Через місяці реальна подія в AZ змусила справжнє відновлення. База виконала свою частину, але клієнти майже не помітили цього через нудну репетицію. Нічого героїчного на виклику не відбувалося. Найкраще реагування — це коли всі трохи роздратовані через дзвінок, а не героїчні подвиги.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: «Aurora повільніша за нашу стару MySQL-машину»

Корінна причина: Ви перейшли з локального NVMe з гарячим кешем на розподілений шлях зберігання з іншими характеристиками латентності, і ваш робочий набір більше не вміщується в пам’ять.

Виправлення: Виміряйте промахи buffer pool і wait events; збільшіть пам’ять інстансу, якщо виправдано; зменшіть випадкові читання (індекси, форма запитів), і припиніть робити великі сканування в OLTP-шляхах.

2) Симптом: p99 затримки під час деплоїв або відновлень

Корінна причина: Шторми підключень і синхронні повторашки. База стає жертвою поведінки клієнтів.

Виправлення: Обмежте пули, додайте джиттерний експоненційний backoff, скоротіть таймаути і переконайтесь, що додаток коректно відбудовує з’єднання і підготовлені вирази.

3) Симптом: Рідери показують «відсутні» дані одразу після записів

Корінна причина: Лаг репліки і eventual consistency, навіть якщо невеликий.

Виправлення: Направляйте read-after-write на writer; реалізуйте сесійні токени; уникайте використання reader endpoint для підтверджувальних потоків.

4) Симптом: «Додавання рідера не допомогло»

Корінна причина: Навантаження write-bound, lock-bound або доміновано запитами, які мусить обробляти writer (read-your-writes, транзакції, запис тимчасових таблиць).

Виправлення: Визначте вузьке місце writer через wait events і топ-запити; зменшіть write amplification (індекси), виправте гарячі рядки і відокремте читання, що безпечно відвантажувати.

5) Симптом: Високий CPU але низька пропускна здатність

Корінна причина: Погані плани запитів, важкі сорти/групування або занадто багато одночасних потоків, що спричиняють contention і контекстні перемикання.

Виправлення: Використовуйте performance schema digest + EXPLAIN; зменшіть одночасність (ліміти пулів), додайте відсутні індекси і усуньте непотрібні per-request запити.

6) Симптом: «База зависла» з багатьма сесіями в ‘Waiting for table metadata lock’

Корінна причина: DDL чекає за довгою транзакцією або відкритим курсором, що тримає metadata lock.

Виправлення: Знайдіть блокувальників через performance schema; завершіть або вбийте блокувальників; плануйте DDL у періоди низького трафіку; використовуйте online schema change техніки.

7) Симптом: Раптові сплески тимчасових дискових таблиць і затримки

Корінна причина: Запити створюють великі проміжні результати; відсутні індекси; великі сорти; group by по неіндексованих стовпцях.

Виправлення: Виправте SQL і індекси; зменшіть набори результатів; лише після цього налаштовуйте розміри тимчасових таблиць.

8) Симптом: «Відновлення було швидким, але додаток був недоступний»

Корінна причина: Кешування на рівні клієнта ендпоїнтів, застарілий DNS, довготривалі з’єднання або драйвери, що не перепідключаються коректно.

Виправлення: Перевірте поведінку клієнтів при перепідключенні; тримайте TTL/очікування кешування реалістичними; тестуйте відновлення end-to-end.

Контрольні списки / поетапний план

Контрольний список A: Вибір між самокерованим MySQL і Aurora MySQL

1. Визначте ваше вузьке місце: CPU, I/O, блокування чи операційна складність.
2. Запишіть ваші RTO/RPO і підтвердіть, що додаток може пережити відновлення без ручного втручання.
3. Класифікуйте читання: які терплять застаріння, які потребують read-after-write.
4. Розішіть, що ви хочете контролювати: ОС/ядро/файлова система і вибір сховища (самокерований) проти меншої кількості ручок і керованої надійності (Aurora).
5. Бенчмарк з репрезентативним навантаженням: не іграшковий датасет, не один запит в циклі. Включіть сплески і фази холодного кешу.
6. План спостережуваності: performance schema і slow logs, плюс cloud метрики і трекінг digest запитів.

Контрольний список B: План міграції, що не принизить вас пізніше

1. Інвентаризуйте фічі: тригери, збережені процедури, event scheduler, SQL-моди, колації, часові пояси.
2. Явно встановіть parameter groups замість того, щоб успадковувати дефолти і надіятися, що вони підходять.
3. Робіть подвійні записи або change data capture тільки якщо маєте чіткий план відкату; інакше зробіть процес простішим.
4. Перевірте плани запитів на Aurora. Той самий SQL може обирати інші плани залежно від версій і статистики.
5. Зіграйтесь у failover game day з додатком, а не лише з базою даних.
6. Переключайте читання обережно: почніть з терпимих до застарілості endpoint-ів; тримайте read-after-write на writer поки не впевнені.
7. Обмежте пули перед cutover, щоб уникнути шоку підключень.

Контрольний список C: Реагування на інцидент при зростанні затримок

1. Стабілізуйте клієнтів: припиніть шторм повторів, обмежте пули, застосуйте backoff.
2. Визначте топ очікувань (performance schema) і топ запитів (digest summaries).
3. Виберіть один важіль: вбийте runaway-запити, додайте індекс, масштабніть інстанс або зніміть навантаження — але робіть це свідомо.
4. Захистіть writer: переведіть некритичні читання на рідери лише якщо консистентність дозволяє, інакше застосуйте rate-limit.
5. Задокументуйте тригер: деплой, зміна трафіку, batch job або зміна схеми — щоб проблема не повернулась наступного тижня.

Поширені питання

1) Чи є Aurora MySQL буквально MySQL?

Ні. Вона сумісна з MySQL на рівні протоколу і фіч, але архітектура зберігання і реплікації інша. Ставтесь до неї як до окремого двигуна з шаром сумісності.

2) Чи Aurora завжди буде швидшою за самокерований MySQL?

Ні. Деякі навантаження покращуються через швидше відновлення, легше масштабування і вдалі дефолти. Інші можуть деградувати через поведінку кешу, латентність розподіленого сховища або невідповідний розмір інстансу. Проводьте бенчмарки для вашого навантаження.

3) Якщо Aurora роз’єднує обчислення і зберігання, чи означає це, що латентність сховища не має значення?

Латентність сховища все одно має значення; вона просто проявляється інакше. Ви не можете «налаштувати диск», але ваші запити все ще чекають на I/O при промахах кешу або інтенсивних записах.

4) Чи можна вирішити проблеми продуктивності в Aurora тими самими ручками, що й у MySQL?

Частково. У вас все ще є багато MySQL-параметрів і важелі схеми/запитів. Але ви втрачаєте налаштування на рівні ОС/файлової системи і частину глибокої інструментації. Очікуйте менше «хитрих трюків» і більше «основних речей».

5) Чи всі читання треба посилати на рідери Aurora?

Ні. Надсилайте тільки терпимі до застаріння читання. Все, що вимагає read-your-writes, має або читатися з writer, або реалізовувати явну сесійну логіку консистентності.

6) Чому додавання рідера не зменшило CPU автора?

Бо ваше навантаження може бути write-bound, lock-bound, або додаток все ще читає з writer через транзакційну поведінку, маршрутизацію або обмеження консистентності. Вимірюйте реальний розподіл запитів.

7) Як порівняти витрати між MySQL на EC2 і Aurora чесно?

Врахуйте час операторів, зберігання бекапів, інструменти для реплікації/відновлення і частоту інцидентів. Також врахуйте «приховані» витрати: надмірно підготовлені інстанси, щоб пережити відновлення і шторм підключень.

8) Який найбільший ризик надійності під час міграції?

Поведінка додатка під час відновлення і припущення про консистентність. Більшість міграцій провалюються тому, що додаток чекав, що база поводитиметься як єдиний безсмертний сервер.

9) Чи Aurora скасовує необхідність оптимізації запитів?

Ні. Вона зменшує частину операційного навантаження, але не прибирає потребу в хороших індексах і адекватних запитах. Поганий SQL універсальний; він боляче вдарить в будь-якому середовищі.

Висновок: практичні наступні кроки

Якщо ви вирішуєте між самокерованим MySQL і Aurora MySQL, не замінюйте «керований» на «швидкий». Приймайте рішення так само, як будь-яке продакшн-рішення: визначаючи реальне вузьке місце і моделі відмов, які ви не можете собі дозволити.

• Запустіть реальний бенчмарк з вашим навантаженням: включіть сплески, фази холодного кешу і заміряйте p95/p99 — не лише середню пропускну здатність.
• Напишіть політику маршрутизації читань, що визначає, які читання можна відправляти на репліки, а які мають йти на writer.
• Зміцніть поведінку клієнтів: ліміти пулів, адекватні таймаути, джиттерні повторашки і перевірена логіка перепідключення.
• Інструментуйте важливе: топ wait events, топ digest запитів, метрики очікування блокувань, створення тимчасових таблиць і лаг реплік.
• Репетируйте відновлення end-to-end. Не лише «кластер відновився». Переконайтесь, що додаток відновився. Це не одне й те саме.

Aurora — сильний вибір, коли ви хочете керованої стійкості, простішої реплікації та менше рухомих частин, за якими потрібно слідкувати особисто. Самокерований MySQL залишається хорошим вибором, коли потрібен максимальний контроль, передбачувана низька латентність на локальному сховищі або кастомні збірки двигуна і глибоке тонке налаштування. Вибирайте систему, що відповідає вашим обмеженням, а не вашим сподіванням.