Резервне копіювання MySQL на Percona XtraBackup: що ламається
Копії формально є: нічний дамп відпрацьовує, файл їде у сховище, позначка у звіті стоїть.
Проблема в тому, що логічне вивантаження читає базу цілком, і зі зростанням бази вікно резервного копіювання зростає разом із нею — спочатку це година вночі, потім чотири, а далі процес зачіпає ранковий трафік і накладається на продове навантаження.
Гаряче резервне копіювання MySQL через Percona XtraBackup знімає основну частину цього болю: копіюються фізичні сторінки даних, і запис не зупиняється на весь час вивантаження.
Але блокування під час копіювання не зникають зовсім — потрібна коротка фіксація узгодженої точки, і якщо в цей момент у базі висить довга транзакція, точка не береться: запис стає і стоїть рівно стільки, скільки живе транзакція.
Окремий головний біль — розбухання журналів змін на диску, коли читання копії відстає від темпу запису.
Друга половина історії — відновлення. Повна копія розгортається передбачувано, але без ланцюжка інкрементних копій і розібраних журналів відкат перетворюється на ручну роботу чергового: знайти потрібний набір файлів, розгорнути, наздогнати зміни, перевірити консистентність. Вночі, під тиском, з ризиком помилитися в порядку кроків.
Розбираємо, як це закривається: що налаштовується в самому Percona XtraBackup, як будується розклад, щоб вікно не зростало, і як заздалегідь перевіряти, що копія справді відновлюється.
Що дає гаряче резервне копіювання: вимірюваний ефект
Гаряча копія знімається з працюючого сервера: Percona XtraBackup читає сторінки даних фізично, тому зупиняти запис не потрібно, а сервіс продовжує обслуговувати клієнтів.
Ефект ми вимірюємо в трьох величинах — вікно копіювання, час відновлення і клас відмов, які перестають бути аваріями.
Вікно копіювання стискається в рази
Копія читає файли даних безпосередньо, без логічного дампу і проміжних таблиць. Далі працюють інкрементні копії: одна повна, наступні — тільки змінені сторінки. На типовій базі вікно копіювання падає з годин до хвилин, і цикл вкладається в період низького навантаження.
Час відновлення — десятки хвилин замість годин
Копію не потрібно імпортувати рядок за рядком: файли розпаковуються і підключаються на підготовлений екземпляр. Підготовка вирівнює незавершені транзакції, тому після старту сервер віддає консистентний знімок на момент завершення копії.
Для сервісу це вимірюване скорочення простою: відновлення вкладається у вікно, відоме черговій зміні заздалегідь.
Зникає клас відмов «копія є, але не піднімається»
Перевірка відновлення на окремому контурі — частина регламенту, а не разова акція. Ми фіксуємо час підготовки і старту, звіряємо консистентність даних і тільки після цього вважаємо копію придатною.
Точка консистентності дає точку відкату при розсинхронізації репліки: сервіс повертається до стану на момент копії, а не до випадкового знімка.
Режими копіювання та стиснення: порівняння варіантів
Вибір режиму визначається не обсягом бази, а тим, скільки часу займе відновлення і як часто змінюються дані між копіями. Нижче — варіанти, між якими реально вибирають при налаштуванні Percona XtraBackup, та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повна копія | Базовий шар для будь-якого циклу, відкат на довільний момент | Займає весь обсяг даних, час створення та відновлення зростає лінійно |
| Інкрементна копія | Великі бази з малим відсотком змін між знімками | Відновлення потребує ланцюжка «повна + всі інкременти», розрив ланцюжка ламає відкат |
| Потокове передавання | Копія одразу на інший сервер або в об’єктне сховище | Чутлива до пропускної здатності каналу, обрив потоку означає перезапуск |
| Логічне вивантаження | Перенесення між версіями, вибіркові таблиці | Відновлення у рази довше за фізичне, не тягне великі бази |
Стиснення і шифрування накладаються поверх будь-якого режиму. Копія стискається на льоту, але платить за це завантаженням процесора, а ключ шифрування зберігається окремо від самої копії — інакше захист втрачає сенс.
На практиці повну копію ставлять базовим шаром, інкрементні — між ними, а потокове передавання вмикають, коли місця на диску під проміжний шар немає. Ми перевіряємо не тільки створення копії, а й повний цикл відновлення на окремому стенді — інакше режим вважається неперевіреним.
Впровадження Percona XtraBackup: етапи інженерної роботи
Впровадження резервного копіювання починається не зі встановлення утиліти, а з розбору того, як база живе зараз: обсяг, швидкість зростання, вікно мінімального навантаження, допустимий час простою при відновленні.
Спираємося на Percona XtraBackup — гаряче копіювання без зупинки сервісу і тривалих блокувань таблиць, але результат тримається на розкладі та зберіганні, а не на самій утиліті.
- Аудит схеми копіювання. Розбираємо, що і куди копіюється зараз, чи вистачає місця, коли востаннє хтось перевіряв відновлення. Підсумок — карта ризиків: копії на тому самому диску, завдання без контролю коду повернення, вікна з піковим навантаженням.
- Проєктування. Повна копія раз на добу плюс інкрементні між ними, глибина зберігання і ротація, вивезення за межі сервера бази. На виході — розклад і розрахунок, скільки даних втрачаємо при збої.
- Налаштування. Окремий користувач з мінімально потрібними правами, стиснення і шифрування, запуск за розкладом із журналом виконання та оповіщенням про падіння завдання.
- Перевірка відновлення. Розгортаємо копію на окремому контурі, заміряємо час до робочого стану, звіряємо цілісність ключових таблиць. Копія, яку не розгортали, копією не вважається.
- Переведення в експлуатацію. Моніторинг віку останньої успішної копії, розміру, тривалості та вільного місця — алерт приходить раніше, ніж місце закінчиться або завдання впаде.
- Передача. Регламент відновлення з покроковими командами, відповідальні та періодична навчальна перевірка на тестовому контурі, щоб процедура не залишилася усною домовленістю.
Конфігурації, схеми та регламенти відновлення бази
Підсумок роботи — не «налаштований сервер», а комплект артефактів, за яким резервне копіювання відтворюється з нуля і передається іншому інженеру.
Усе лежить поруч із базою: конфігурації в системі контролю версій, регламенти — в документації, доступи — в облікових записах із журналом. Нижче — що саме залишається у вашої команди після впровадження.
- Конфігурація резервного копіювання: файли налаштувань Percona XtraBackup, розклад повних та інкрементних копій, окремий вузол для підготовки знімка перед викладкою.
- Схема зберігання копій: рівні зберігання, термін життя за поколіннями, вивезення копій за межі майданчика, ротація зі збереженням точки відкату на попередній реліз.
- Політики доступу до копій: роздільні облікові записи на запис і читання, шифрування архівів, ключі зберігаються поза сервером бази, журнал звернень до сховища.
- Регламент відновлення: покроковий порядок розгортання, цільовий час відновлення і допустима втрата даних, перевірка цілісності, дії при неповному наборі журналів.
- Автоматична перевірка копій: регулярне розгортання знімка на ізольованому стенді, звірка контрольних сум ключових таблиць, звіт із результатом.
- Оповіщення про стан: сигнали на пропущений запуск, зростання тривалості, помилку підготовки і заповнення сховища — до того, як копія знадобиться.
- Інструкції черговому: перші дії при збої, порядок оповіщення, фіксація інциденту.
- Матриця відповідальності: хто володіє розкладом, хто перевіряє результати перевірок, хто ротує ключі та облікові записи.
Кейс: повернення бази за хвилини замість годин
Клієнт прийшов після інциденту: сервер бази помер у розпал робочого дня, а підняли його тільки до вечора.
Бекап робився нічним повним дампом через mysqldump — вікно копіювання розтягувалося на 4-5 годин, на час вивантаження база відповідала помітно повільніше, а самі копії лежали на тому самому диску, що й дані.
Перевірка копій зводилася до перегляду логу: запуск відновлення на окремому стенді не робили жодного разу, і приблизно третина архівів не розгорталася.
Перевели резервне копіювання на Percona XtraBackup — гаряче фізичне копіювання без зупинки сервера.
Схема: тижневий повний бекап, поверх нього щоденні інкременти за зміненими сторінками, підготовка копії окремою командою на резервному вузлі, щоб вона була готова до розгортання, а не вимагала доопрацювання у момент аварії.
Кожну копію автоматично розгортаємо на тестовому стенді і звіряємо контрольні суми ключових таблиць — перевірка копій стала частиною розкладу, а не ручною операцією на свята.
Метрики до і після: вікно копіювання скоротилося з 4-5 годин до 12 хвилин, повне відновлення — з 6 годин до 9 хвилин, частка успішно розгорнутих копій зросла з 70% до 100%.
Зник цілий клас відмов «архів є, але не піднімається»: якщо копія не проходить перевірку, черговий дізнається про це тієї ж ночі, а не у момент аварії.
В експлуатації залишилися розклад, алерти на пропущений або провалений бекап і короткий регламент відновлення з точними командами — щоб уночі не згадувати порядок дій.
Чим відрізняється гаряча копія від логічної: що вибрати
Різниця в тому, що саме читається з диска. Гаряча фізична копія переносить сторінки табличних просторів і журнал транзакцій на працюючому сервері, логічна — перетворює дані на потік SQL-інструкцій. Звідси розходяться навантаження, час відновлення і гранулярність.
Percona XtraBackup читає файли даних і журнал паралельно, не зупиняючи запис: сервер продовжує обслуговувати запити, а копія залишається узгодженою на момент старту. Відновлення — розпакування і застосування накопиченого журналу, це хвилини навіть на базі в сотні гігабайт.
Логічне вивантаження йде запитами і пише текст. Воно переносиме між версіями і дозволяє забрати одну таблицю, але час знімання зростає лінійно з обсягом, а відновлення займає години: рядки вставляються заново, індекси перебудовуються після завантаження.
| Спосіб | Навантаження при зніманні | Відновлення | Гранулярність |
|---|---|---|---|
| Гаряча фізична копія | Читання диска, запис не блокується | Застосування журналу — хвилини | Вся база цілком |
| Логічне вивантаження | Повний прохід по таблицях запитами | Вставка рядків і перебудова індексів — години | Окремі таблиці |
| Файлова копія із зупинкою | Сервер закритий на запис | Копіювання файлів назад | Вся база цілком |
Правило вибору просте: поки база вкладається в коротке вікно і потрібне вибіркове вивантаження, достатньо логічної. Коли обсяг вимірюється сотнями гігабайт або вікно стиснуто до хвилин, основою стає гаряча фізична копія, а логічна залишається доповненням для точкових задач.
Технічні сумніви: консистентність, навантаження, перевірки
Копія на живій базі піднімає три питання: чи не роз'їдеться знімок, чи не просяде сервіс під читанням і чи можна дістати одну таблицю замість усієї бази.
Нижче — те, що ми уточнюємо до запуску: на цих відповідях будується режим роботи Percona XtraBackup і політика зберігання копій.
Копія залишиться консистентною, якщо база пише під навантаженням?
Файли даних читаються на ходу, а накопичені зміни з журналу транзакцій застосовуються до знімка — на виході стан на один момент часу. Довга транзакція лише утримує позицію журналу, тому ставимо поріг за її тривалістю і попередження: копіювання не зависає мовчки.
Наскільки копіювання навантажує робочий сервер?
Основне навантаження — читання даних і журналу, запис застосунків майже не зачіпається, тому пікова пропускна здатність сервісу не провалюється. Кількість потоків і швидкість читання обмежуємо: на слабкому диску режим м'якший, на швидкому забираємо більше.
Чи можна відновити не всю базу, а одну таблицю?
Так. Потрібна таблиця дістається з підготовленої копії і підключається поруч із робочими даними. Розбір помилкового видалення займає хвилини, повний відкат бази при цьому не потрібен.
Скільки копій тримати і де?
Повна копія раз на тиждень плюс щоденні прирощення і обов'язкове вивезення в незалежне сховище. Ротація задана за віком і кількістю копій: старі знімаються автоматично, обсяг сховища перестає зростати безконтрольно.
Як переконатися, що копія відновлювана?
Копія регулярно розгортається на окремому вузлі, база піднімається і проходить перевірний набір запитів зі звіркою контрольних сум. Поки прогон не пройшов, копія вважається непридатною і не потрапляє до набору для відновлення.
Обговоримо задачу: що підготувати до розмови
Щоб оцінка і план робіт спиралися на факти, а не на припущення, до розмови достатньо принести кілька ввідних. Вони визначають обсяг і те, як ляже Percona XtraBackup на вашу схему — далі обходимося без серії уточнювальних листів і повторних дзвінків.
- Схема сервісів: де живуть бази, чи є репліки, хто пише в майстер і як застосунок переживає відмову вузла.
- Поточні копії: чим робляться, як часто, куди складаються і коли востаннє перевіряли відновлення.
- Вимоги до часу відновлення: який простій допустимий і на яку точку в часі потрібно відкочуватися.
- Обсяги і динаміка: розмір даних, добовий приріст, вікна низького навантаження, доступна смуга до сховища.
- Інфраструктура: де розміщуємо копії, чи є окремий контур, як влаштовані доступи і шифрування.
- Обмеження: терміни зберігання, регламент доступу, що вже траплялося і скільки зайняло відновлення.
Якщо частини даних немає під рукою — відновимо картину на дзвінку. Опишіть задачу резервного копіювання своїми словами: повернемося з оцінкою і планом робіт та переліком перевірок відновлення, які закривають ризик тихої втрати даних.
