MariaDB Backup: налаштування гарячого резервного копіювання під ключ

MariaDB backup: де ламається гаряче копіювання

Гаряча копія знімається без зупинки сервісу — і ламається не в момент копіювання, а в момент відновлення. Типовий сценарій: дампер для консистентності на короткий час бере блокування таблиць на запис.

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

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

Гаряче резервне копіювання MariaDB у режимі однієї транзакції (--single-transaction) дає узгоджений зріз лише для транзакційних таблиць, а в одній схемі сусідять таблиці без транзакцій — вони читаються в інший момент.

У копії з'являються замовлення без позицій і зовнішні ключі в порожнечу: відновлення проходить формально, а дані не сходяться.

Друга пастка — копія не пам'ятає точку, на яку її зняли. Для відновлення на довільний момент потрібна узгоджена позиція в журналі змін; без неї відтворення подій заводить базу не туди.

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

І головне: копія, яку жодного разу не відновлювали, — не резерв, а архів невідомої якості.

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

Що дає гаряче резервне копіювання без зупинки сервісу

Вікно недоступності схлопується до секунд

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

У результаті резервне копіювання без зупинки бази перестає бути подією календаря: його можна ставити будь-коли, а не в проміжок, коли всі сплять.

Відновлення за десятки хвилин

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

Копія узгоджена на момент зняття

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

Узгодженість налаштовується на рівні процедури, а не перевіряється очима чергового, — тому копія придатна до використання одразу.

Контроль копій без ручних перевірок

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

Плюс витрати на зберігання перестають зростати безконтрольно — старі набори витісняються за політикою, а свіжі точки відкату залишаються доступними.

Порівняння підходів: логічний дамп, знімок тому, репліка

Три підходи закривають різні завдання, і вибір диктує не звичка команди, а обсяг бази, допустиме вікно та потрібна точка відновлення.

Логічний дамп бази даних читається очима, переноситься між версіями та платформами, але на великих обсягах розтягується на години й помітно гріє диск.

Знімок тому сховища знімається за секунди, однак без попередньої узгодженої паузи запису дає розузгоджений набір сторінок, який може просто не піднятися.

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

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

Яка зв'язка підійде вам, залежить від обсягу та допустимого вікна простою — це й розбираємо на старті.

Порядок впровадження: від аудиту до передачі в експлуатацію

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

1. Аудит резервного копіювання. Розбираємо поточні завдання та їхній фактичний результат, швидкість зростання бази, запас за місцем, права на читання з реплік. Фіксуємо ризики: знімання з майстра заважає запису, цілісність не перевіряється, єдина копія лежить на тому самому томі, що й дані.
2. Схема резервування бази. Підбираємо комбінацію: повний знімок mariabackup, інкременти за зміненими сторінками та бінарні журнали для відновлення на точку в часі. Узгоджуємо цільові точки та час відновлення, глибину зберігання та вивантаження за межі сервера.
3. Налаштування розкладу копій. Розкладаємо завдання за вікнами низького навантаження та знімаємо копії з репліки, щоб не конкурувати з майстром за дискові операції. Задаємо ротацію, контроль коду повернення завдання та оповіщення при збої.
4. Тестове відновлення. Розгортаємо копії на окремому стенді та заміряємо реальний час відновлення — бази цілком і окремої таблиці. Звіряємо контрольні суми та проганяємо перевірки на відновлених даних: помилки в схемі спливають тут, а не під час аварії.
5. Передача в експлуатацію. Віддаємо регламенти: що і коли копіюється, де зберігається, хто і як відновлює, як читати оповіщення моніторингу. Проводимо навчальне відновлення силами вашої чергової зміни та залишаємося на підтримці за графіком.

Комплект на виході: конфігурації, схеми, регламенти

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

• Робочі конфігурації резервного копіювання по кожній базі: розклад, набір об'єктів, режим зняття копій без зупинки запису, параметри стиснення та шифрування — однаковий набір проходить і по стендах, і по бойовому середовищу.
• Схема резервного контуру: які вузли беруть участь, де розміщуються копії, як розділені основна та зовнішня площадки, що відбувається при відмові одного зі сховищ.
• Політика зберігання копій: глибина за типами — щоденні, тижневі, місячні, правила продовження та видалення, прив'язка до регламентних вікон, щоб обсяг реєстру не зростав безконтрольно.
• Регламент відновлення бази: покроковий порядок із точками повного та часткового відновлення, очікуваний час повернення в стрій та обов'язкова звірка даних після підняття.
• Ролі доступу до копій і журнал операцій: хто знімає копію, хто читає, хто відновлює; доступ до бойових даних винесено в окремий контур.
• Документація з резервного копіювання: описи, схеми та контрольні списки лежать у репозиторії поряд із конфігураціями та версіонуються разом із ними.
• Журнали перевірок відновлення: дати, що піднімали, розбіжності, фактичний час — доказ, що копія жива, а не просто файл у сховищі.

Кейс: відновлення бази після відмови вузла

Що було до змін

У замовника — інтернет-магазин з інтенсивним записом у MariaDB. Нічний дамп знімався з того самого вузла, що обслуговував навантаження, лягав на сусідній розділ і жодного разу не відновлювався.

Перевірку придатності проходила приблизно половина копій: частина обривалася на вивантаженні, частина не сходилася за контрольними сумами — дізнавалися про це в момент аварії.

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

Що змінили і що стало

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

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

Перевірку проходять усі архіви — непридатні відбраковуються та перезнімаються, не потрапляючи в історію.

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

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

Чим відрізняється MariaDB backup від реплікації?

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

DELETE без умови або UPDATE із забутим WHERE розмножиться по всіх репліках за секунди. Відкладена репліка із затримкою в кілька годин дає вікно на порятунок, але тільки якщо помилку помітили всередині цього вікна, і не захищає від псування, що почалося раніше.

Відновлення на момент часу можливе лише з копії. Знімок MariaDB, знятий mariadb-backup на працюючому сервері, плюс бінарні журнали дають повну історію змін. Ми розгортаємо знімок і програємо журнали до потрібної позиції або мітки часу — до запиту, який усе зламав. Так працює відкат видалених даних: база повертається в стан на секунду раніше збою.

Є клас відмов, який репліка не закриває: видалення таблиць і логічне псування на основному вузлі, збій сховища, вимога аудиту показати дані на конкретну дату. До того ж репліка часто живе в тій самій стійці й під тим самим акаунтом — інцидент забирає і її. Копії ми виносимо в окремий контур.

Підсумок: реплікація та резервне копіювання доповнюють одне одного — перша відповідає за доступність, друге за відновлення. Обидва контури перевіряємо на тестовому стенді, а не в момент аварії.

Часті технічні питання з резервного копіювання

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

Чи потрібно зупиняти застосунок?

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

Скільки місця займуть копії?

Повна копія зіставна з обсягом даних, інкремент — лише змінені сторінки. Ланцюжок згортаємо в нову повну, старі версії витісняємо за терміном зберігання — зростання обсягу передбачуване.

Як перевірити, що копія придатна?

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

У нас уже налаштоване резервування — що міняти?

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

Обговоримо задачу: що потрібно для оцінки резервного контуру

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

• Топологія: одиночний сервер, ведучий зі слейвами або кластер — від цього залежить, знімаємо ми логічний дамп чи фізичну копію.
• Обсяг баз і профіль запису: розмір даних, добова частка змін, вікна мінімальної активності.
• Цілі відновлення: на який момент часу допустимо втратити дані і за який час база зобов'язана повернутися в стрій.
• Вимоги до узгодженості: потрібен узгоджений знімок усіх таблиць чи достатньо відкату за журналом на потрібну секунду.
• Куди складати копії: локальний диск, мережеве сховище або окремий контур, з політикою зберігання та глибиною ротації.
• Доступи та шифрування: де зберігаються ключі, хто отримує доступ до копій, чи потрібен аудит операцій.
• Що вже є: поточні регламенти, скрипти, розклади та стенд, на якому можна відпрацювати відновлення.

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

Окремо проговоримо супровід резервного контуру — моніторинг, ротацію копій і регулярні навчання з відновлення, щоб копії не залишалися «на папері».