Чому міграція таблиці MySQL без gh-ost зупиняє сервіс
Найдорожча міграція — та, що виглядає невинно: додати колонку, змінити тип, перебудувати індекс. Інструмент надсилає ALTER TABLE до таблиці з сотнями мільйонів рядків, і на етапі підготовки запит захоплює блокування метаданих.
Поки воно тримається, у чергу стають уже не лише записи за цією таблицею, а й звичайні читання: з’єднання накопичуються, час відгуку зростає в рази, застосунок починає віддавати помилки раніше, ніж адміністратор устигає помітити причину.
Далі спрацьовує арифметика. Якщо операція потребує перезбирання таблиці, база читає й записує копію всіх рядків — накладні витрати зростають лінійно від обсягу, і години роботи перетворюються на нічне вікно, яке ніхто не гарантує.
На репліках зміна відтворюється послідовно й із затримкою, тому читання з реплік віддає застарілі дані, а відкат уже розпочатої перебудови без втрат неможливий.
Онлайн-міграція схеми закриває це розділенням роботи. gh-ost читає бінарний лог основного вузла, створює тіньову копію таблиці в новому вигляді та переносить рядки невеликими порціями, самостійно добираючи темп за навантаженням на сервер і відставанням реплік.
Зміни, що надійшли під час перенесення, докатуються з логу, тому копія залишається актуальною. Перемикання виконується атомарною перестановкою імен — блокування таблиці тримається частки секунди, а не години.
Процес можна призупинити, відновити й перевірити будь-якої миті; вихідна таблиця залишається до підтвердження результату й слугує точкою повернення.
Далі розбираємо, як це закривається на практиці: порядок кроків, контроль відставання реплік і критерії, за якими перемикання безпечне.
Що змінюється на практиці: час блокування й клас відмов
Перехід на онлайн-схему змінює не «зручність», а вимірювані параметри: час блокування запису, простій сервісу під час міграції, вікно відкату міграції.
gh-ost не тримає блокуючий ALTER на бойовій таблиці — він будує копію поруч і переносить до неї зміни з журналу реплікації, а блокування запису зводиться до короткого перемикання в самому кінці.
На таблицях із сотнями мільйонів рядків копіювання триває годинами, і весь цей час сервіс приймає запис.
Навантаження на майстер і поведінка реплік
Основна робота відбувається в окремій таблиці-привиді: читання рядків порціями, запис чанками, паузи між ними. Майстер отримує додаткове навантаження від копіювання, але його обмежують явно — кількістю рядків за секунду й порогом за навантаженням реплік.
Якщо відставання реплік зростає вище заданого порогу, міграція сама призупиняється й продовжується, коли репліки наздогнали. Відставання реплік стає керованою величиною замість аварії на проді.
Вікно відкату й клас відмов, що зник
Поки перемикання не виконано, відкат — це зупинка процесу й видалення таблиці-привида: бойова таблиця не зачеплена, дані в ній актуальні. Після перемикання відкат — зворотний обмін за збереженою схемою, і він теж не потребує простою.
Зникає цілий клас відмов: блокування на час ALTER, падіння міграції на середині через таймаут, деградація реплік під навантаженням. Замість «міграція пройшла або все впало» з’являється керований процес із передбачуваним вікном відкату.
Порівняння підходів: gh-ost, тригери й перебудова таблиці
Спосіб міграції обирають за профілем навантаження, а не за обсягом таблиці: важливо, скільки часу допустимо тримати операцію і що станеться під час обриву. Нижче — п’ять маршрутів і обмеження, через які один із них доводиться виключати відразу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| gh-ost: читання журналу й перенесення в тіньову таблицю | Великі таблиці під постійним записом | Потрібен доступ до журналу реплікації та місце під тіньову копію |
| Тригерна міграція | Сервери, де журнал реплікації недоступний | Тригери подвоюють навантаження на запис, конфліктують із наявними |
| Перебудова в нову таблицю з перемиканням | Зміна типу стовпця, розбиття або злиття таблиць | Період наздоганяння змін і коротке блокування на перейменування |
| Міграція через репліку | Переїзд між серверами й версіями | Відставання реплікації, перевірка збіжності даних |
| Обслуговуване вікно | Малі таблиці й операції, несумісні з онлайном | Простій на весь час копіювання |
Де ламається тригерний підхід
Таблиці без первинного ключа, часті оновлення одного рядка й уже наявні тригери: накладні витрати на запис подвоюються, а відставання копіювання зростає швидше, ніж воно наздоганяється.
Де gh-ost потребує перевірки
Зовнішні ключі, широкі рядки й сервери з вимкненим журналом реплікації. Перед запуском звіряють схему, темп запису й місце під тіньову таблицю — інакше процес доведеться зупиняти й перезапускати.
Етапи онлайн-міграції: від заміру навантаження до перемикання трафіку
Порядок робіт в онлайн-міграції не довільний: gh-ost створює тіньову таблицю, порціями копіює до неї рядки й паралельно застосовує зміни з журналу реплікації, тому помилка в схемі або в запитах спливає вже під бойовим навантаженням.
План міграції бази даних будується так, щоб кожен ризик знімався до перемикання таблиці, а не після.
Підготовка й перевірки
- Аудит схеми й запитів — фіксуємо склад індексів, зовнішні ключі, тригери й звернення до таблиці в коді; шукаємо все, що інструмент не переносить автоматично.
- Замір навантаження — знімаємо профіль читання й запису, добовий пік, швидкість зростання таблиці; за цими даними рахуємо очікуваний час копіювання й допустимий поріг відставання реплік.
- Тестовий прогін міграції — на відновленій копії бойових даних проганяємо цикл повністю, включно з відкатом і перевіркою планів запитів до й після.
Запуск, перемикання й контроль
- Запуск копіювання — gh-ost стартує з автоматичним гальмуванням за відставанням реплік і за навантаженням на провідний вузол.
- Спостереження за чергою — стежимо за швидкістю перенесення й затримкою реплік; у разі виходу за поріг процес призупиняється, не зачіпаючи читання.
- Перемикання таблиці — зміна імен виконується однією атомарною операцією з коротким блокуванням запису, потім старе ім’я залишається доступним для відкату.
- Контроль після міграції — звіряємо контрольні суми рядків, порівнюємо відгук за ключовими запитами й тримаємо попередню таблицю, поки метрики не вийдуть на рівний фон.
Артефакти міграції: конфігурації, схеми реплікації, регламенти
Міграція закінчується не в момент перемикання трафіку, а коли в репозиторії лежить комплект, за яким завдання повторить інший інженер, а чергова зміна відкотить її без автора.
Тому всі артефакти зберігаємо поруч із конфігурацією запуску й оновлюємо в тій самій зміні, що й сам прогін — інакше документація з міграції розходиться з реальністю в перший же інцидент.
- Параметри запуску: точка підключення, репліка-джерело, пороги навантаження й відставання, інтервали перевірок, умови автоматичної паузи — з поясненням, чому вибрано саме таке значення.
- Схема потоків даних: як процес читає журнал змін із репліки, пише в тіньову таблицю й виконує фінальне перемикання; окремо позначаємо точки, де міграцію можна безпечно перервати.
- Схема реплікації: топологія «майстер — репліки», допустиме відставання, спосіб перевірки перед стартом і роль кожної репліки в процесі.
- Службові таблиці міграції: повний перелік створюваних об’єктів, їхнє призначення, строк життя й відповідальний за видалення; політика доступу — застосунок і черговий у них не пишуть.
- Регламент відкату: ознаки, за яких прогін зупиняється, порядок скасування, що робити з уже перемкненим трафіком і скільки часу відводиться на рішення.
- Інструкція для чергової зміни: які метрики дивитися, які відхилення вважати тривожними й у який момент піднімати відповідального інженера.
- Журнал прогону: результати тесту на копії, фактичні значення проти планових, зафіксовані розходження й висновок про повторний запуск.
Кожен пункт проходить рев’ю до старту, а не після: регламент відкату, який ніхто не читав, у момент збою марний.
Кейс: планова міграція великої таблиці без зупинки сервісу
Таблицю замовлень на кілька сотень мільйонів рядків переводили на нову схему на живому сервісі: звернення йдуть цілодобово, а звичайний ALTER блокує запис на весь час копіювання.
Перейшли на gh-ost — інструмент читає журнал змін і переносить рядки порціями, тому робоча таблиця залишається доступною і на запис, і на читання.
| Метрика | До | Після |
|---|---|---|
| Блокування запису під час перемикання | десятки секунд, вікно простою вночі | частки секунди, користувачі не помітили |
| Частка невдалих запитів | 0,4% у пікові години | 0 |
| Відставання реплік | до кількох хвилин | у межах штатного порогу |
| Ручні операції | нічна зміна за чек-листом | дві команди під контролем чергового |
Що пішло не за планом
За годину до перемикання репліка не встигала за потоком змін. Замість перемикання за розкладом ми зупинили крок і дали репліці наздогнати джерело — простій не знадобився. Після цього кейса в процес додали поріг: поки відставання вище заданого, перемикання не запускається.
Відкат перевірили заздалегідь: стара таблиця залишається на місці, повернення — одна операція, без відновлення з копії. На наступній міграції це скоротило підготовку й дало змогу провести роботу без вікна обслуговування.
Що робити, якщо репліка відстає в момент перемикання?
Відставання репліки — найчастіший сценарій, у якому онлайн-міграція перестає бути безпечною. Поки gh-ost переносить рядки в тіньову таблицю, репліки отримують той самий потік подій, але застосовують його повільніше за майстер.
Якщо перемкнути читання на відсталу репліку, застосунок побачить стан до частини змін. Губляться не всі рядки, а окремі — такі розходження діагностуються найгірше.
Ознаки відставання видно заздалегідь: зростає затримка застосування журналу, накопичується черга необроблених подій, а пік запису в момент перемикання додає сплеск.
Вбудований індикатор бреше на довгих транзакціях — надійніша службова таблиця-пульс, яку gh-ost оновлює окремим потоком.
Перед перемиканням ставимо жорсткі умови: затримка нижче порогу тримається безперервно все вікно спостереження, черга подій порожня, відставання немає на жодній репліці під трафіком.
Окремо звіряємо кількість рядків і контрольні суми за блоками між тіньовою й вихідною таблицею — це підтверджує цілісність даних, а не лише факт завершення копіювання.
Відкат міграції закладаємо заздалегідь: gh-ost залишає вихідну таблицю, тому повернення — це зупинка процесу й зворотне перейменування, трафік повертається на попередню схему за секунди. Видаляти артефакти до звірки не можна, інакше відкочуватися буде нікуди.
Якщо відставання продовжує зростати, попри обмеження навантаження, перемикання не робимо: шукаємо вузьке місце — диск, мережу, важкі запити на репліці — і повертаємося до перенесення після його усунення.
Технічні сумніви: блокування, відкат і відставання репліки
Інженерні сумніви навколо онлайн-міграції зазвичай зводяться до чотирьох питань: чи тримає процес блокування на робочій таблиці, що станеться під час обриву з’єднання, які права потрібні на майстері й чи не роз’їдуться репліки під час паралельного перенесення. Нижче — короткі відповіді за кожним пунктом і вимоги до середовища, які ми перевіряємо до старту.
Таблиця стане на блокування під час міграції?
Ні. gh-ost читає журнал змін і переносить їх у тіньову копію, а робоча таблиця продовжує приймати запис і читання. Блокування виникає лише на фінальному перемиканні імен і тримається частки секунди, тому черга запитів не встигає вирости.
Що буде, якщо процес міграції перерветься?
Операція зупиняється на поточному етапі: тіньова таблиця й допоміжні об’єкти видаляються, вихідні дані залишаються недоторканими. Запуск можна повторити — перед стартом стан синхронізації перевіряється заново, а неповна копія не потрапляє в роботу.
Чи потрібен прямий доступ до майстер-сервера?
Так: запис змін і перемикання йдуть через майстер, тому потрібні права на створення таблиць, тригерів і перейменування. Репліки при цьому використовуються лише для контролю відставання, окремих облікових записів під них не потрібно.
Чи можна мігрувати кілька таблиць одночасно?
Так, але паралельний запуск за багатьма таблицями створює конкуренцію за дискові операції й прискорює відставання репліки. Безпечніше вести перенесення хвилями по одній-двох таблицях, звіряючи затримку реплікації між етапами.
Обговоримо вашу міграцію: схема, ризики, план робіт
Вступна розмова триває близько години й іде по суті: розбираємо вашу схему, обсяг даних і вимоги до доступності, щоб побачити, де перенесення може зачепити живий трафік.
За підсумками ви отримуєте не загальні обіцянки, а план робіт із міграції з етапами, відповідальними й точками зупинки.
- Оцінка обсягу міграції: розмір таблиць, кількість реплік, пікова швидкість запису й частка довгих транзакцій — від цього залежить темп перенесення.
- Режим роботи gh-ost: перенесення через репліку або з основного вузла, ліміти навантаження, поріг відставання, за якого процес сам призупиняється.
- Вікно міграції: коли робимо фінальне перемикання, скільки тримаємо вихідну таблицю як страховку, як повертаємо трафік назад.
- Ролі й зв’язок: хто підтверджує старт, кого піднімаємо в разі відхилення, де ведемо журнал дій за кроками.
- Критерії успіху: сходяться контрольні суми, відставання реплік у нормі, час відповіді застосунку не зріс.
- Порядок дій у разі збою: зупиняємо перенесення, повертаємо трафік на вихідну таблицю, розбираємо журнал і призначаємо повторний запуск.
Заздалегідь домовляємося, що вважаємо невдачею і за якою ознакою відкочуємося — тоді рішення ухвалюється за фактом, а не поспіхом. Щоб обговорити міграцію предметно, опишіть завдання: повернемося з оцінкою обсягу, планом робіт і складом команди.
