Чому mysqldump перестає рятувати на базі, що зростає
Поки база вкладається в десятки гігабайт, нічний mysqldump виглядає безпечним рішенням: одна команда, читабельний текстовий файл, проста перевірка.
Проблема в тому, що копія знімається однією сесією і йде послідовно — спочатку одні таблиці, потім інші, і час зростає не лінійно, а ступенями, коли вона перестає вміщатися в дисковий кеш.
Рано чи пізно вікно копіювання закривається раніше, ніж закінчується вивантаження, а наступний запуск за розкладом стартує поверх ще працюючого і подвоює навантаження на диск і реплікацію.
Підступність у тому, що збій копіювання не завжди помітний. Процес повертає успішний код, файл на місці, розмір ненульовий — звіт зелений, і черговий не йде дивитися, що вивантаження обірвалося на середині або знято в момент активного запису.
Помилка розкривається рівно тоді, коли потрібне відновлення бази даних: імпорт доходить до середини, падає на пошкодженій ділянці, а у вас немає ні цілої копії, ні часу розбиратися, яких транзакцій бракує.
Ціна такого сценарію — не невдала команда, а відсутність точки відкату. Відновлення перестає бути передбачуваною операцією на десятки хвилин і перетворюється на ручний розбір, поки сервіс лежить.
Резервне копіювання MySQL на базі, що зростає, вимагає іншого режиму й перевірки, що копія справді відновлюється, — розбираємо, як це закривається.
Що дає кероване резервне копіювання MySQL
Дамп за розкладом сам по собі ще не захист — важлива придатність копії до відновлення. Налаштовуємо MySQL так, щоб знімок робився в узгодженому режимі, результат перевірявся автоматично, а стан копіювання був видимий інженерам, а не припускався.
Ефект тримається на трьох вимірюваних величинах: час відновлення бази, частка копій, що пройшли перевірку на цілісність копії, і частка відмов, про які ми дізнаємося раніше за замовника.
Передбачуваний час відновлення
Ми заздалегідь визначаємо, за який час база піднімається з копії, і тримаємо цей час стабільним: точка відновлення відома, сценарій розгортання відпрацьований і повторюється без імпровізації в момент аварії.
Регламент проганяється на окремому стенді — від підняття структури до перемикання сервісу на відновлений вузол. Вартість простою сервісу стає передбачуваною: вікно недоступності відоме заздалегідь, а не з'ясовується по ходу інциденту.
Усунений клас відмов: тихі збої копіювання
Тихий збій — це коли завдання завершується без помилки, а копія виявляється неповною або порожньою, і з'ясовується це в найневдаліший момент.
Тому перевірка резервних копій вбудована в процес: структура й розмір дампа звіряються з очікуваними, виконується тестове відновлення, а моніторинг копіювання сигналить про пропущений запуск, аномальну тривалість або розходження контрольних сум.
Клас відмов «пощастило — не пощастило» перетворюється на звичайний алерт, а відновлення перестає бути перевіркою на міцність.
mysqldump, фізична копія чи репліка: що вибрати
Логічний дамп — це SQL-текст: зліпок переноситься між версіями й платформами, з нього дістається одна таблиця, його можна прочитати й виправити руками. Плата за це — відновлення йде запит за запитом, і на великій базі воно займає години.
Фізична копія знімає файли даних і журналів цілісно й піднімається швидко, репліка тримає постійний дубль для відмовостійкості та звітів.
Вибір визначається тим, що критичніше: переносність, час підняття чи гаряча заміна. Нижче — межі кожного варіанта.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Логічний дамп (mysqldump) | Переїзд, вибіркове відновлення, відкат однієї таблиці | Час відновлення зростає разом з обсягом, важкі таблиці читаються годинами, точки відновлення між запусками немає |
| Фізична копія (знімок томів) | Велика база, потрібно підняти все за хвилини | Прив'язана до версії та платформи, одну таблицю не дістати, потрібна узгодженість із рушієм зберігання |
| Репліка | Гаряча заміна та розвантаження основного сервера | Не замінює копію: видалення таблиці повторюється за основним, зростає затримка при відставанні |
Обмеження логічного дампа на великих таблицях
Дамп іде одним потоком читання: на таблицях у сотні гігабайт це багатогодинне читання, яке тримає знімок транзакції та заважає очищенню старих версій рядків. Журнал скасування накопичується, а разом із ним зростає й час відновлення. Дістати з дампа одну таблицю теж не швидко — файл розбирається цілком.
Коли одного способу недостатньо
На практиці способи поєднують: дамп за розкладом дає переносний зліпок і вибіркове відновлення, фізичний знімок — швидке підняття всієї бази, репліка — відмовостійкість і звітні запити.
Тоді в кожного класу відмов є свій інструмент: зіпсований рядок лікується дампом, завалений вузол піднімається зі знімка.
Порядок робіт: від інвентаризації баз до регламентів
Порядок робіт будуємо так, щоб копія перевірялася раніше, ніж на неї покладуть надію в аварії. Починаємо з аудиту резервного копіювання: що вже вивантажується, якими засобами, куди складається і хто знає про результат.
Далі інвентаризація баз даних і лише потім вибір схеми — інакше розклад закриває не те, що справді критично.
Інвентаризація та пріоритети баз
- Збираємо перелік баз: розмір, тип таблиць, швидкість зростання, пов'язані сервіси та власники.
- Розмічаємо пріоритети — критичні для виручки, довідкові, тимчасові. Для кожної групи свій термін зберігання та частота копій.
- Вибираємо схему резервного копіювання: повний дамп плюс журнали змін для відновлення на момент збою, окреме вивантаження для великих таблиць.
- Налаштовуємо розклад копіювання у вікна поза піковим навантаженням, з вивантаженням на окремий том, стисненням, шифруванням і ротацією за правилом зберігання.
- Автоматизуємо запуск: код повернення, повідомлення при збої, запис у журнал кожного прогону й контроль розміру файлу копії.
Перевірка відновлення на копії стенда
- Розгортаємо копію на окремому стенді: імпорт дампа, застосування журналів, звірка кількості записів і контрольних сум за ключовими таблицями.
- Закріплюємо регламент: цільовий час відновлення, відповідальні, порядок дій чергового при відмові диска або псуванні даних.
Після цього розклад вважається робочим — документуємо його й переглядаємо при появі нових баз.
Що залишається у вашої команди після впровадження
Після впровадження у команди залишається не набір разових дій, а відтворюваний контур резервного копіювання. Будь-який інженер піднімає копію за інструкцією, не збираючи контекст із листування, а mysqldump відпрацьовує за розкладом і сам повідомляє про збій.
Передаємо все, що потрібно для самостійної експлуатації та спокійної передачі завдання новому співробітнику.
Скрипти та конфігурації копіювання
- Скрипти запуску з логуванням коду повернення: видно, що саме впало і на якому кроці.
- Конфігурація копіювання: перелік баз, розклад, глибина зліпка, параметри консистентності.
- Політика зберігання копій: скільки тримаємо добових, тижневих і місячних наборів і коли чистимо старе.
- Завдання в планувальнику із захистом від перекриття прогонів, щоб дві копії однієї бази не йшли одночасно.
- Автоперевірки після прогону: розмір архіву, контрольна сума, тестове відновлення в окрему схему.
- Схема інфраструктури: де лежать копії, як переносяться на резервний вузол, які сервіси задіяні.
Документація та регламенти відновлення
- Документація резервного копіювання: що копіюється, в якому обсязі, куди потрапляє і як довго живе.
- Регламент відновлення: покроковий порядок підняття з архіву з точками, де потрібне рішення інженера.
- Інструкція з розгортання копії на інший сервер і на іншу гілку сервера баз.
- Цільові терміни відновлення та допустимий обсяг втрати даних, зафіксовані із замовником.
- Журнал навчань: дати перевірок відновлення, що спрацювало, що виправили після.
- Пам'ятка черговому: що робити при відмові вночі, куди дивитися в першу чергу і кого підключати.
З практики: відновлення бази інтернет-магазину
Інтернет-магазин із базою на сотні гігабайт: каталог, замовлення, залишки. Нічний дамп знімався mysqldump за розкладом, файли вирушали на окремий том, звіт про успішне завершення приходив у чат.
Формально резервне копіювання працювало — але жодну копію жодного разу не розгортали, і це з'ясувалося в найневдаліший момент.
Як було: копія є, відновлення не перевірялося
Дамп знімався без ключа --single-transaction: поки утиліта читала таблиці, у них продовжували йти записи, і узгодженість даних на виході ніхто не гарантував.
Окремо з'ясувалося, що частина копій обривалася за таймаутом, а звіт про успіх приходив за фактом запуску, а не завершення.
Аварія на основному сервері обернулася простоєм у шість годин: дві пішли на пошук актуального файлу й розбір помилок, ще чотири — на ручну звірку замовлень, платежів і залишків, що розійшлися між таблицями.
Як стало: відновлення за розкладом і на стенді
Розгорнули стенд, куди раз на тиждень автоматично розгортається останній дамп: спочатку чисте завантаження на окремий інстанс, потім контрольний набір запитів — звірка кількості рядків за ключовими таблицями, суми замовлень за добу, цілісність зовнішніх ключів.
Успішне відновлення без розходжень стало єдиним критерієм, за яким копія вважається придатною, а невдалий прогін піднімає тривогу до того, як щось зламається в бою.
Сам дамп перевели на --single-transaction зі стисненням: розмір артефакту впав утричі, термін зберігання зріс, відкат на попередній зріз залишається можливим.
Час відновлення бази скоротився з шести годин до сорока хвилин, більша частина шляху проходить за прогнаним на стенді сценарієм.
mysqldump уже налаштований, а відновлення не перевірялося?
Так, копіювання працює — але mysqldump, який жодного разу не розгортали, це не резервна копія, а надія.
Ризики неперевірених копій майже ніколи не в тому, що файл не створюється: він створюється, тільки неповним — без тригерів, збережених процедур і подій, або зі зрізом таблиць, що роз'їхався при активному записі.
З'ясовується це рівно в той момент, коли база потрібна цілком, а поруч немає нічого, крім дампа невідомої якості.
Чинне копіювання при цьому ламати не потрібно — перевірка відновлення дампа ставиться поверх. Свіжий архів розгортається в ізольований екземпляр, після чого звіряються склад об'єктів схеми, число рядків за ключовими таблицями та контрольні суми за кількома великими таблицями.
Розходження дає оповіщення до того, як зіпсується наступний архів, а заодно вимірюється реальний час відновлення — цифра, від якої залежить допустимий простій.
Сам дамп знімається в узгодженому режимі: --single-transaction для InnoDB і флаги --routines --triggers --events, інакше відновлення формально проходить, а частина логіки у схемі відсутня.
Передавання копій іде на окремий майданчик або в зовнішнє сховище з шифруванням і ротацією за терміном — копія, що лежить на тому самому диску, що й база, відмови не переживає.
План переходу будується так, щоб нічого не зупиняти: спочатку вмикаємо щоденну перевірку на поточних архівах і спостерігаємо, потім додаємо вивантаження за межі майданчика і лише потім змінюємо розклад і параметри самого копіювання.
На виході — відновлюваний дамп із відомим часом розгортання та процедура відкату, яку можна показати й повторити на будь-якій копії.
Часті технічні сумніви щодо копіювання MySQL
Основний сумнів — навантаження від копіювання: дамп читає всі сторінки таблиць і на великій базі надовго займає диск.
Режим узгодженого знімка в mysqldump не блокує запис у InnoDB, а пауза між порціями та знижений пріоритет процесу прибирають пік за дисковими операціями — копія знімається довше, але робоча база не провалюється за затримками.
Другий шар питань — де зберігати копії, як ротувати і з якою частотою запускати.
Як копіювати, щоб не заважати робочому навантаженню?
Узгоджений знімок в одній транзакції, порційні паузи між таблицями та низький пріоритет процесу. На репліці додатково обмежують число паралельних потоків читання, щоб не зростало її відставання.
Як зберігати та ротувати копії?
Повний дамп раз на добу, між ними — журнали для відновлення на точку в часі. Ротація залишає останні кілька копій і місячні: сховище не зростає безкінечно, а відкат на потрібний день залишається можливим.
Чи можна знімати копію з репліки?
Так, для навантажених баз це кращий варіант: знімок віддає репліка, основний вузол не бере участі. Стежать за відставанням і не запускають дамп у вікно реплікації великих пакетів.
Що робити з великими таблицями?
Їх виносять окремими потоками або розбивають за діапазонами ключа: одна гігантська таблиця в загальному дампі розтягує вікно копіювання й ускладнює відновлення. Стиснення потоку на льоту зменшує артефакт.
Обговоримо ваше завдання з резервного копіювання
Щоб повернутися з оцінкою робіт і планом резервного копіювання, нам потрібен короткий зріз з інфраструктури: де живуть бази, який обсяг даних і що критично зберегти при збої.
Зазвичай достатньо однієї розмови з інженером — далі ми рахуємо обсяг робіт і надсилаємо документ із розкладом і порядком перевірки копій.
Що варто підготувати до обговорення завдання:
- Список баз і серверів: скільки екземплярів обслуговуємо, де розміщені, чи є репліки.
- Обсяг і характер даних: повний розмір, частка таблиць різних типів, великі бінарні поля.
- Вимоги до точки відновлення: скільки даних допустимо втратити при аварії і за який час база має повернутися в роботу.
- Вікно копіювання: коли навантаження мінімальне і чи можна знімати повний дамп mysqldump без впливу на відзивчивість сервісу.
- Зберігання копій: локальні диски, окремий сервер або об'єктне сховище, скільки копій тримаємо і на який термін.
- Регламент перевірки: як часто розгортаємо копію на тестовому контурі і хто підтверджує результат.
- Доступи та обмеження: сервісні облікові записи, мережеві правила, вимоги до шифрування вивантажень.
- Поточний процес: що вже налаштовано, які збої були, чи потрібно переносити наявні скрипти.
- Передача на підтримку: хто з команди приймає регламент і чи потрібен інструктаж чергових.
Якщо частини даних під рукою немає — не страшно, зберемо їх разом. Після розмови повернемося з оцінкою, планом робіт і описом передачі на підтримку.
