MariaDB проти Percona Server: швидкість резервного копіювання та відновлення на маленькому VPS

Практична відповідь (хто перемагає)

На маленькому VPS швидкість бекапу/відновлення визначається вашим вузьким місцем — зазвичай дисковими I/O, іноді CPU (компресія/шифрування), іноді мережею (віддалене сховище), і часто «вашим процесом» (невірний інструмент або хибні припущення).

Якщо ви порівнюєте MariaDB + mariabackup проти Percona Server + xtrabackup на одному InnoDB наборі даних і з подібною конфігурацією, «переможець» рідко визначається смаком сервера. Частіше різниця залежить від:

• Яким інструментом фізичного бекапу ви реально користуєтесь і наскільки він сумісний з версією сервера.
• Скільки redo потрібно застосувати під час підготовки і наскільки ваш VPS пригальмовує випадкові записи.
• Вибору алгоритму стиснення (CPU-залежний) проти «без стиснення» (I/O-залежний).
• Методу відновлення: копіювання файлів, стрімінг чи логічний імпорт.

Моя операційна порада: для відновлень на малому VPS Percona XtraBackup зазвичай дає більш передбачуваний «достатньо швидкий» результат, коли ви в екосистемі MySQL/Percona і хочете фізичні бекапи з адекватними інструментами для стрімінгу та інкрементальних робочих процесів. Для MariaDB — mariabackup є правильним інструментом і може бути так само швидким, проте потрібно стежити за сумісністю з версіями MariaDB і розуміти, що робить етап «prepare» з вашим крихітним диском.

Якщо ви робите логічні бекапи (mysqldump), «переможець» відсутній: ви вже програли, просто ще цього не відчули. Логічні відновлення на малому VPS — це місце, куди йдуть годинники.

Цікаві факти та історичний контекст (бо минуле пояснює сьогодення)

1. MariaDB з’явилась через поглинання Oracle MySQL (епоха 2009–2010); Monty Widenius та інші форкнули MySQL, щоб зберегти відкриту і спільнотну розробку.
2. Percona побудувала бізнес на операційних болях: їх сервер і інструменти з ранніх років фокусувалися на діагностиці продуктивності, інструментації та розумних налаштуваннях для production-навантажень.
3. XtraBackup став де-факто інструментом «гарячого фізичного бекапу» для MySQL/Percona роками тому, оскільки уникав довгих глобальних блокувань і не вимагав дорогих enterprise-додатків.
4. mariabackup — це лінія від XtraBackup, створена для підтримки розбіжностей внутрішніх структур MariaDB і щоб уникнути пасток сумісності.
5. Модель відновлення InnoDB (redo логи + брудні сторінки) — причина, чому фізичні бекапи потребують фази «prepare»: ви по суті програєте redo, щоб зробити копію консистентною.
6. Undo-таблиці та поведінка ibdata змінювалися з роками; новіші макети роблять відновлення передбачуванішим, але також легше неправильно налаштувати при міграції між хостами.
7. Стиснення в інструментах бекапу перейшло від «приємної опції» до «обов’язкового», коли люди почали відправляти бекапи в об’єктні сховища; це перемістило багато відновлень із I/O-залежних у CPU-залежні на невеликих машинах.
8. «Flush tables with read lock» колись був нормою в скриптах бекапу; зараз це ознака того, що ви або робите логічні бекапи, або не оновлювали свою практику десятиліттями.
9. Малі VPS-провайдери часто обмежують тривалі I/O так, що це не видно в бенчмарках для короткого навантаження; перша хвилина швидка, наступні десять — трагічні.

Що насправді контролює швидкість бекапу/відновлення на VPS

1) Схема I/O випереджає голий пропускний канал

Відновлення фізичного бекапу — це не просто «копіювання файлів». Це: копіювання файлів, застосування redo (випадкові записи), запуск InnoDB, який може робити додаткове відновлення, а потім прогрів кешів і статистик в міру відновлення навантаження.

На сховищі невеликого VPS послідовна пропускна здатність може виглядати прийнятно, але саме випадкові записи (IOPS) — там і ховаються проблеми. Фаза застосування redo і прогрів після відновлення інтенсивно навантажують IOPS. Саме тоді «відновлення минулого разу тривало 7 хвилин» перетворюється на «сьогодні 45 хвилин», коли провайдер тихо перемістив ваш віртуальний диск на іншу backend-ланку.

2) CPU: стиснення і шифрування не безкоштовні

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

3) Пам’ять: buffer pool прямо не прискорює відновлення, але змінює поведінку відновлення

Більше ОЗП допомагає серверу поводитися краще після відновлення (менше читань, швидший прогрів), але сире прискорення відновлення більше залежить від записів на диск та застосування redo. Проте: надто малий buffer pool може зробити період «система запущена, але непридатна» довшим, що фактично рівнозначно повільному відновленню.

4) Вирівнювання версій — тихий вбивця

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

Парафраз ідеї Вернера Вогельса (CTO Amazon): усе постійно ламається, тож проектуйте системи, припускаючи, що відмови — нормальне явище. Відновлення — це та частина «припускаємо відмову», яку ви або відпрацювали, або ні.

Методи резервного копіювання, що мають значення (фізичне vs логічне)

Логічні бекапи: портативні, повільні та повні сюрпризів

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

Швидкість відновлення залежить від парсингу SQL, створення індексів і накладних витрат транзакцій. На маленькому VPS для нетривіальних датасетів це зазвичай години. Якщо потрібен швидкий recovery, використовуйте логічні дампи лише для невеликих баз або як «остання інстанція».

Фізичні бекапи: найшвидше відновлення при правильному підході

Фізичні інструменти бекапу (mariabackup, xtrabackup) копіюють InnoDB файли даних і логи під час роботи сервера, потім «підготовлюють» бекап до консистентної точки. Відновлення — це в основному копіювання файлів назад плюс робота серверного відновлення. На маленькому VPS це єдиний підхід, що масштабується, без перетворення вас на напівпрофесійного археолога старих SQL-дампів.

Що насправді означає «prepare»

Під час --prepare інструмент застосовує redo логи, захоплені під час бекапу, щоб привести файли до узгодженого стану. Якщо ваше навантаження було інтенсивним, обсяг redo може бути великим. Великий обсяг redo означає більше випадкових записів. Випадкові записи на дисках VPS означають часову дилятацію.

Жарт №1: Бекапи як парашути — якщо він знадобився і не спрацював, вам, напевно, вже не доведеться користуватись ним вдруге.

Швидкий план діагностики

Коли відновлення повільне на маленькому VPS, часу на диспут немає. Потрібен короткий список і безжальна послідовність дій.

Спочатку: підтвердіть, яка фаза повільна

• Завантаження/передача (мережа, обмеження віддаленого сховища, накладні витрати на шифрування)
• Розпаковування/дешифрування (CPU-залежне)
• Prepare/apply-log (залежне від випадкових записів — IOPS)
• Copy-back (в основному послідовні записи)
• Перший запуск (InnoDB recovery, права, несумісність конфігурації)

По-друге: ідентифікуйте ваш жорсткий ліміт (диск vs CPU vs мережа)

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

По-третє: застосуйте найменшу зміну, яка зрушить стрілку

• Вимкніть стиснення (або оберіть легший алгоритм), якщо ви CPU-залежні.
• Зменшіть обсяг redo, покращивши час бекапу або стратегію флашування, якщо prepare повільний.
• Використовуйте прямий I/O і розумний рівень паралелізму, якщо copy-back повільний.
• Припиніть робити логічні відновлення для великих датасетів.

Практичні завдання: команди, виводи та рішення (те, що рятує ваш вікенд)

Це реалістичні перевірки, які можна виконати на Linux VPS. Сенс не в зборі курйозів; кожна команда має привести до рішення.

Завдання 1: Визначте, що саме у вас встановлено (MariaDB vs Percona vs Oracle MySQL)

cr0x@server:~$ mysql --version
mysql  Ver 15.1 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper

Що це означає: Це MariaDB 10.11.x. Для фізичних бекапів варто віддавати перевагу mariabackup.

Рішення: Якщо ви планували використовувати XtraBackup, зупиніться і підтвердіть сумісність. Невідповідність інструменту — поширена самонасилка.

Завдання 2: Підтвердіть Percona Server (якщо ви думаєте, що встановили саме його)

cr0x@server:~$ mysqld --version
mysqld  Ver 8.0.35-27 for Linux on x86_64 (Percona Server (GPL), Release 27, Revision 1f4b4a6)

Що це означає: Percona Server для MySQL 8.0. XtraBackup — природний вибір.

Рішення: Використовуйте xtrabackup, сумісний з вашою мажор-версією. Не «фантазуйте» з застарілими пакетами.

Завдання 3: Перевірте тип диску і опції монтування (швидкість відновлення тут живе)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,ROTA,MOUNTPOINT,FSTYPE
NAME   TYPE SIZE ROTA MOUNTPOINT FSTYPE
vda    disk  80G    0
├─vda1 part  79G    0 /          ext4
└─vda15 part  1G    0 /boot/efi  vfat

Що це означає: ROTA=0 вказує на те, що сховище подається як SSD (або принаймні так виглядає).

Рішення: Якщо ROTA=1 або ви на мережевому блочному сховищі, очікуйте проблем із випадковими записами; плануйте мінімізувати час prepare/apply-log і уникати важкого стиснення.

Завдання 4: Перевірте, чи провайдер обмежує ваш диск (швидка і груба перевірка)

cr0x@server:~$ iostat -xm 1 5
Linux 6.1.0-18-amd64 (server) 	12/30/2025 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.20    0.00    4.60   52.40    0.30   36.50

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm  w_await wareq-sz  aqu-sz  %util
vda              4.00    120.0     0.00   0.00    8.50    30.00   220.0   22000.0    15.00   6.38  130.00   100.00   30.20  99.80

Що це означає: Диск завантажений приблизно на 100% і час очікування запису величезний. Ви обмежені I/O; сховище VPS — обмежувач.

Рішення: Припиніть додавати паралелізм і стиснення. Потрібно менше випадкових записів (оптимізація prepare) або краще сховище (більший план, локальний NVMe VPS або приєднаний швидший том).

Завдання 5: Перевірте steal CPU (ваш «vCPU» може бути рекомендацією)

cr0x@server:~$ mpstat 1 5
Linux 6.1.0-18-amd64 (server) 	12/30/2025 	_x86_64_	(2 CPU)

12:10:01 AM  CPU    %usr   %nice    %sys %iowait   %irq   %soft  %steal  %guest  %gnice   %idle
12:10:02 AM  all   18.00    0.00    6.00   10.00   0.00    0.00   22.00    0.00    0.00   44.00

Що це означає: Високий %steal означає, що гіпервізор забирає час CPU. Стиснення буде повільним, і можуть виникати тайм-аути.

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

Завдання 6: Підтвердіть директорію даних і вільне місце (відновлення падають, коли диск заповнений)

cr0x@server:~$ mysql -Nse "SELECT @@datadir, @@tmpdir;"
/var/lib/mysql	/tmp

cr0x@server:~$ df -h /var/lib/mysql /tmp
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        79G   62G   13G  83% /
/dev/vda1        79G   62G   13G  83% /

Що це означає: Лише 13G вільних. Фізичне відновлення плюс тимчасові файли може це перевантажити.

Рішення: Якщо ви не можете гарантувати місце для бекапу + підготовленої копії + логів, відновлюйте на новий том або новий інстанс.

Завдання 7: Перевірте налаштування InnoDB, що впливають на поведінку відновлення

cr0x@server:~$ mysql -Nse "SHOW VARIABLES WHERE Variable_name IN ('innodb_flush_log_at_trx_commit','sync_binlog','innodb_doublewrite','innodb_log_file_size','innodb_buffer_pool_size');"
innodb_buffer_pool_size	1073741824
innodb_doublewrite	ON
innodb_flush_log_at_trx_commit	1
innodb_log_file_size	268435456
sync_binlog	1

Що це означає: Консервативні налаштування durability. Чудово для збереження даних, повільніше під час інтенсивних записів і в деяких сценаріях відновлення.

Рішення: Під час вікна відновлення (не в нормальному режимі) розгляньте тимчасове пом’якшення sync_binlog і innodb_flush_log_at_trx_commit, якщо ви робите логічний імпорт. Для фізичного copy-back це менш критично; для добігу після відновлення це може бути важливим.

Завдання 8: Виміряйте розмір бекапу та коефіцієнт стиснення (передбачте CPU vs I/O проблеми)

cr0x@server:~$ du -sh /backups/full-2025-12-29
18G	/backups/full-2025-12-29

cr0x@server:~$ du -sh /backups/full-2025-12-29.tar.zst
6.2G	/backups/full-2025-12-29.tar.zst

Що це означає: 3x стиснення. Приємно. Також: вартість розпакування реальна.

Рішення: Якщо ви CPU-залежні, оберіть легший рівень стиснення або відмовтесь від нього; якщо ви мережево-обмежені — тримайте стиснення і приймайте CPU-витрати.

Завдання 9: Перевірте наявність mariabackup/xtrabackup і сумісність версій

cr0x@server:~$ mariabackup --version
mariabackup based on MariaDB server 10.11.6-MariaDB Linux (x86_64)

Що це означає: Інструмент вирівняний із сімейством MariaDB 10.11.

Рішення: Продовжуйте з фізичними бекапами/відновленнями. Якщо інструмент повідомляє про іншу мажорну родину, виправте це перш ніж діяти.

Завдання 10: Заміряйте фазу підготовки і спостерігайте за I/O в реальному часі (знайдіть вузьке місце)

cr0x@server:~$ /usr/bin/time -v mariabackup --prepare --target-dir=/backups/full-2025-12-29 2>&1 | tail -n 8
	User time (seconds): 132.10
	System time (seconds): 88.55
	Percent of CPU this job got: 92%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 4:12.33
	Maximum resident set size (kbytes): 612340
	File system outputs: 9483216
	Exit status: 0

Що це означає: Wall time ~4 хв з великим файловим виводом: інтенсивні записи. CPU високий, але не повністю переповнений; ймовірно, змішане навантаження CPU + диск.

Рішення: Якщо wall time величезний і iostat показує високий await, ви обмежені IOPS. Пом’якшіть це, зменшивши обсяг redo (менше записів під час бекапу) або відновлюйте на кращому сховищі.

Завдання 11: Перевірте цілісність бекапу перед тим, як ставити на кон аварію

cr0x@server:~$ mariabackup --check-privileges --target-dir=/backups/full-2025-12-29
mariabackup: Starting to check privileges
mariabackup: All required privileges are granted

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

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

Завдання 12: Відновлення через copy-back і перевірка власності (нудна, але важлива частина)

cr0x@server:~$ systemctl stop mariadb

cr0x@server:~$ mariabackup --copy-back --target-dir=/backups/full-2025-12-29
mariabackup: Starting to copy back
mariabackup: Copying ./ibdata1 to /var/lib/mysql/ibdata1
mariabackup: completed OK!

cr0x@server:~$ chown -R mysql:mysql /var/lib/mysql

Що це означає: Файли даних на місці. Власність критична; systemd за вас цього не зробить.

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

Завдання 13: Спостерігайте час першого запуску (брехня «відновлення завершено»)

cr0x@server:~$ systemctl start mariadb

cr0x@server:~$ journalctl -u mariadb -n 30 --no-pager
Dec 30 00:22:12 server mariadbd[12988]: InnoDB: Starting crash recovery from checkpoint LSN=234887123
Dec 30 00:22:20 server mariadbd[12988]: InnoDB: 2 out of 2 rollback segments are active.
Dec 30 00:22:34 server mariadbd[12988]: InnoDB: Crash recovery finished.
Dec 30 00:22:35 server mariadbd[12988]: mariadbd: ready for connections.

Що це означає: Було відновлення, але воно швидко завершилося.

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

Завдання 14: Заміряйте швидкість копіювання при відновленні (відокремте «копіювати» від «підготувати»)

cr0x@server:~$ rsync -aHAX --info=progress2 /backups/full-2025-12-29/ /var/lib/mysql/
      9,732,145,152  62%  42.31MB/s    0:03:12

Що це означає: ~42 MB/s послідовне копіювання. Для малого VPS це прийнятно.

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

Завдання 15: Якщо мусите використовувати логічне відновлення — зробіть його менш болючим

cr0x@server:~$ mysql -e "SET GLOBAL innodb_flush_log_at_trx_commit=2; SET GLOBAL sync_binlog=0;"

cr0x@server:~$ pv /backups/db.sql | mysql --max-allowed-packet=1G
1.58GiB 0:03:41 [7.30MiB/s] [=====================>     ] 62% ETA 0:02:15

Що це означає: Ви підвищуєте пропускну здатність, тимчасово пом’якшуючи налаштування durability під час імпорту; pv показує прогрес і швидкість.

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

Завдання 16: Підтвердіть положення реплікації/бінлогів після відновлення (щоб уникнути мовчазного дрейфу)

cr0x@server:~$ mysql -e "SHOW MASTER STATUS\G"
*************************** 1. row ***************************
             File: binlog.000014
         Position: 19384721
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set:

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

Рішення: Збережіть ці координати і вирівняйте репліки. Швидке відновлення, що створило невідповідність даних — це лише повільний інцидент трохи пізніше.

Три корпоративні міні-історії (анонімізовані, болісно правдоподібні)

Інцидент через хибне припущення: «SSD — то SSD»

Невелика SaaS-команда працювала на MariaDB на бюджетному VPS, бо на ранньому етапі економили. Їх відновлення історично тривали ~10 хвилин при фізичних бекапах. Вони проводили репетиції щоквартально. Це було не ідеально, але життєздатно.

Одного понеділка через проблему з файловою системою довелося відновлювати. Фаза copy-back копії пройшла нормально. Потім --prepare і перший запуск почали гальмувати. Черговий подумав, що це «просто великий бекап», і чекав. Через сорок хвилин вони все ще дивилися, як повідомлення InnoDB відновлення просуваються повільно, немов у фільмі жахів.

Хибне припущення: «Диск — SSD, отже випадкові записи мають бути добре». Насправді їх VPS був переміщений на бекенд із агресивним обмеженням IOPS. Послідовні записи були ок, а латентність випадкових записів — жахлива. Фази prepare і crash recovery принижували випадкові записи й були задавлені.

Виправлення: вони розгорнулися на іншому класі VPS з передбачуваними IOPS і додали просту перевірку перед відновленням: запуск iostat під час планового тесту prepare і алерт, якщо write await перевищує поріг кілька хвилин. Відновлення не стали миттєвими. Вони стали передбачуваними. Передбачуване — те, що ви продаєте своєму майбутньому я.

Оптимізація, що обернулася проти: «Стиснемо все сильніше»

Середня компанія використовувала Percona Server і стрімила нічні бекапи в інший регіон. Витрати на зберігання росли, тож хтось запропонував сильніше стиснення і одночасне шифрування. Артефакти бекапів стали меншими. Тепер таблиця витрат виглядала краще. Всім сподобалось.

Через два місяці знадобилося відновлення після помилки оператора. Конвеєр відновлення отримав стиснутий/зашифрований потік, а потім витратив години на дешифрування і розпаковування на крихітному stand-by VPS. CPU був завантажений, %steal був ненульовим, і все зайняло так багато часу, що керівництво задумалося, чи варто відновлювати БД з транзакційних подій додатку.

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

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

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

Інша команда — теж на малому VPS — мала правило: щомісяця робити повне відновлення в свіжий інстанс і вимірювати час для кожної фази: завантаження, дешифрування, розпаковування, prepare, copy-back, старт і базовий smoke-тест додатку.

Це було не гламурно. Ніяких видимих клієнтам фіч не приносило. Але коли сталася корупція диска, вони вже знали, що відновлення буде CPU-залежним під час розпаковування і IOPS-залежним під час prepare. У них був задокументований обхід: витягти бекап на тимчасовий compute-оптимізований VPS, підготувати там, а потім rsync підготовлену директорію на ціль.

Вони виконали план. Жодної імпровізації. Ніякого «можливо, спробуємо…» під час простою. Сервіс повернувся в очікуване вікно, а постмортем був коротким, бо результат був нудним.

Жарт №2: Єдина річ дорожча за тестування відновлень — це відсутність тестування; ваш майбутній простій виставить вам рахунок у годинах.

MariaDB vs Percona: важелі швидкості та підводні камені, що справді мають значення

Інструменти: mariabackup і xtrabackup — кузени, а не близнюки

Люди говорять про «XtraBackup», ніби це загальний термін для фізичних бекапів. Це як називати кожен пилосос «Dyson». Зручно, але хибно і іноді дорого.

mariabackup існує тому, що MariaDB відійшла від upstream MySQL/Percona внутрішньо. xtrabackup від Percona налаштований на сумісність із Percona Server/MySQL. На папері обидва роблять гарячі фізичні бекапи InnoDB. У продакшені невідповідності версій і тонкі форматні відмінності можуть перетворити «швидке відновлення» на «чому воно не стартує?».

Швидкість відновлення формується обсягом redo, а не брендом

Якщо ваше навантаження генерує багато redo (висока швидкість записів, великі транзакції, масивні оновлення вторинних індексів), фаза prepare виконає більше роботи. Ця робота по суті записує сторінки — випадково. На малому VPS з посередніми IOPS час відновлення є функцією write amplification.

Іноді ви можете зменшити обсяг redo, запланувавши бекапи під час періодів знижених записів або переконавшись, що база не виконує патологічні операції (наприклад, величезні multi-row оновлення без пакетування). Але чарівної кнопки «Percona — швидше» тут немає.

Вибір компресії створює профілі «CPU-відновлення» vs «дискове відновлення»

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

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

Бінлоги та реплікація: відновлення, що «працює», все ще може підвести

У Percona часто складніші топології реплікації та звички point-in-time recovery, частково тому, що екосистема Percona підштовхує до цього. MariaDB-середовища сильно варіюються. В будь-якому випадку швидкість відновлення — це не тільки копіювання даних: сервер має повернутися в реальність — координати реплікації, GTID, бінлоги, очікування додатку.

На маленькому VPS найшвидше відновлення іноді — «замінити інстанс», а не відновлювати на місці. Новий VM, приєднати підготовлені дані, старт, перемкнути IP/DNS. Це не функція бази даних; це операційний патерн.

Що би я обрав на малому VPS

• Якщо ви вже на Percona Server (MySQL 8.0): використовуйте XtraBackup, тримайте версії вирівняними і проектуйте конвеєр, який мінімізує CPU-біль під час відновлення.
• Якщо ви вже на MariaDB 10.6+: використовуйте mariabackup, відпрацьовуйте відновлення щомісяця і вважайте час prepare ключовим KPI.
• Якщо ви обираєте стек з нуля на крихітному VPS і пріоритет — швидкість відновлення: оберіть стек, який ви зможете чисто експлуатувати, а потім купіть сховище з передбачуваними IOPS. Рахунок за це дешевший за простій.

Типові помилки (симптом → корінь проблеми → виправлення)

1) Симптом: фаза prepare займає вічність, диск на 100% завантаження

Корінь проблеми: Обмеження випадкових записів (IOPS) на сховищі VPS; інтенсивне застосування redo.

Виправлення: Відновлюйте/підготуйте на більшому/швидшому інстансі, потім скопіюйте підготовлені файли назад; або перейдіть на тариф з передбачуваними IOPS. Зменшіть обсяг redo, плануючи бекапи у періоди з низькою інтенсивністю записів.

2) Симптом: відновлення «швидке», але перший запуск тягнеться при crash recovery

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

Виправлення: Переконайтеся, що --prepare успішно завершено; перевірте сумісність налаштувань InnoDB log; перевірте власність і цілісність файлів; стежте за логами відновлення і корелюйте з iostat.

3) Симптом: логічне відновлення повільніше, ніж очікували, CPU не завантажений, диск не завантажений

Корінь проблеми: Однопотокове імпортне обмеження, накладні витрати на відновлення вторинних індексів або налаштування fsync, що примушують затримки на кожен коміт.

Виправлення: Для великих датасетів використовуйте фізичні бекапи. Якщо ви змушені працювати з логічними дампами: вимкніть autocommit під час імпорту, використовуйте --single-transaction при дампі, тимчасово пом’якште sync_binlog/innodb_flush_log_at_trx_commit під час вікна відновлення і імпортуйте схему + дані у розумному порядку.

4) Симптом: бекап завершився, відновлення падає з «permission denied» або datadir недоступна

Корінь проблеми: Неправильна власність/політика SELinux/AppArmor після copy-back.

Виправлення: chown -R mysql:mysql для datadir, перевірте політики безпеки і переконайтеся, що unit systemd має доступ.

5) Симптом: сервер стартує після відновлення, але додаток бачить відсутні таблиці або дивні помилки

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

Виправлення: Перевірте маніфест бекапу, зберігайте бекапи незмінними, і запускайте післявідновні верифікаційні запити (лічильники рядків, вибіркові checksum, smoke-тест додатку).

6) Симптом: відновлення швидке локально, але катастрофічно повільне при завантаженні з віддаленого сховища

Корінь проблеми: Пропускна здатність мережі/латентність, ліміти швидкості або дешифрування/декомпресія на малому CPU.

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

7) Симптом: xtrabackup/mariabackup видає помилки про неподдержувану версію сервера

Корінь проблеми: Невідповідність інструменту й сервера; спроба використати інструмент «іншої» екосистеми.

Виправлення: Встановіть правильну версію інструменту з тієї ж екосистеми і мажор-релізу, що й сервер; повторіть тести бекапу.

8) Симптом: після відновлення реплікація ламається або дані розходяться

Корінь проблеми: Координати бінлогу/GTID не зафіксовані або не застосовані послідовно; відновлення без узгодженої реплікаційної позиції.

Виправлення: Фіксуйте і зберігайте координати реплікації з кожним бекапом; після відновлення налаштовуйте реплікацію явно і перевіряйте статус.

Чеклісти / покроковий план

План A: Швидке фізичне відновлення на тому ж VPS (найменше рухомих частин)

1. Підтвердіть вирівнювання сервера та інструменту (MariaDB→mariabackup, Percona→xtrabackup).
2. Перевірте вільний диск: потрібно місце для підготовленого бекапу і операцій copy-back.
3. Обережно зупиніть сервіс бази даних.
4. Підготуйте бекап (застосуйте redo) і виміряйте час.
5. Скопіюйте назад у datadir і виправте власність.
6. Запустіть сервіс і слідкуйте за логами, поки відновлення не завершиться.
7. Проведіть верифікацію: базові запити, підрахунок рядків, smoke-тест додатку.

План B: Швидке фізичне відновлення з використанням проміжного хоста (коли диск VPS — вузьке місце)

1. Розгорніть тимчасовий compute-оптимізований інстанс з кращими CPU/IOPS, ніж цільовий VPS.
2. Завантажте + дешифруйте + розпакуйте там (уникайте спалювання CPU на крихітному цілі).
3. Запустіть prepare там; це операція з великою кількістю випадкових записів.
4. Rsync підготовлену директорію на цільовий VPS (більш послідовно, передбачуваніше).
5. Запустіть MySQL/MariaDB на цілі і проведіть валідацію.
6. Знiміть проміжний хост після успіху (і задокументуйте процес для наступного разу).

План C: Якщо ви прив’язані до логічних дампів (як вижити)

1. Відновіть спочатку схему (таблиці, індекси, обмеження), але подумайте про відкладення важких індексів.
2. Тимчасово пом’якшіть durability під час імпорту, якщо це прийнятно в межах вікна відновлення.
3. Імпортуйте великими транзакціями (уникати комітів по рядку).
4. Моніторьте прогрес з pv і метрики сервера; не працюйте наосліп.
5. Поверніть безпечні налаштування одразу після імпорту.
6. Перебудуйте або проаналізуйте таблиці за потреби для продуктивності.

Правила прийняття рішень (запам’ятайте їх)

• Якщо prepare домінує в часі: ви IOPS-залежні або багато redo → використайте staging з кращим сховищем/хостом.
• Якщо декомпресія домінує: ви CPU-залежні → легше стиснення або відвантаження обчислень.
• Якщо передача домінує: налаштуйте стрімінг або тримайте локальну свіжу копію.
• Якщо ви відновлюєте через mysqldump для великих датасетів: у вас немає RTO, у вас є бажання.

Часті питання

1) То хто швидший: MariaDB чи Percona Server?

Якщо ви використовуєте фізичні бекапи з правильним інструментом (mariabackup для MariaDB, xtrabackup для Percona/MySQL), вони зазвичай в одному діапазоні. Реальний результат вирішують ваш диск VPS і вибір стиснення.

2) Який найшвидший метод відновлення на малому VPS?

Підготовлений фізичний бекап, скопійований назад на місце (або rsynced із проміжного хоста), зазвичай найшвидший. Логічні відновлення майже завжди повільніші для нетривіальних наборів даних.

3) Чому іноді «prepare» займає так багато часу?

Prepare відтворює redo і робить копію консистентною. Це може вміщувати багато випадкових записів. На сховищі VPS з обмеженими IOPS випадкові записи — це податок.

4) Чи варто стиснювати бекапи на 2-vCPU VPS?

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

5) Чи можна відновити MariaDB бекап за допомогою xtrabackup (або навпаки)?

Іноді це працює в вузьких діапазонах версій, але це пастка надійності. У разі простою ви хочете «підтверджено і протестовано», а не «раніше в staging якось працювало».

6) Чи швидше відновлення на абсолютно новому VPS, ніж на місці?

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

7) Які метрики слід дивитись під час відновлення?

Використовуйте зайнятість диска і await (iostat -xm), steal CPU (mpstat), вільне місце (df -h) і логи бази даних для прогресу відновлення (journalctl). Якщо ви не можете зрозуміти, чи ви CPU- чи I/O-залежні, ви не зможете швидко виправити проблему.

8) Чи збільшення innodb_buffer_pool_size пришвидшить відновлення?

Рідко воно пришвидшить суто копію чи prepare напряму. Воно може зменшити біль після відновлення, покращивши hit rate кешу і пришвидшивши «повернення до нормальної роботи». Це гра стабільності, а не магічний акселератор відновлення.

9) А що з моментальними знімками (LVM/ZFS)?

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

10) Як зробити час відновлення передбачуваним?

Відпрацьовуйте відновлення, фіксуйте часи для фаз і ставте алерти на зміни. Передбачуваність приходить з репетиціями і з інфраструктурою, що не тріщить під навантаженням I/O.

Висновок: наступні кроки, що реально скорочують час відновлення

MariaDB проти Percona Server — це не головна важіль швидкості відновлення на маленькому VPS. Це вибір інструментів та екосистеми, і обидва можуть бути швидкими, якщо правильно використовувати їх фізичні інструменти бекапу. Справжня боротьба — проти обмежень випадкових записів на крихітних дисках, нестачі CPU через стиснення та операційних звичок, що трактують відновлення як теоретичну річ.

Зробіть наступне:

1. Оберіть фізичні бекапи як дефолт (mariabackup або xtrabackup) і припиніть уявляти, що логічні дампи — це стратегія RTO для великих даних.
2. Запускайте щомісячну репетицію відновлення і фіксуйте часи для передачі, розпакування, prepare, copy-back і першого старту.
3. Розв’яжіться, де виконується prepare. Якщо сховище VPS слабке, робіть prepare на staging-хості з кращими IOPS і переносіть підготовлені файли.
4. Правильно підбирайте стиснення залежно від того, від чого ви реально залежите: CPU, мережа чи диск.
5. Бюджетуйте передбачуване сховище. Якщо час відновлення важливий, «burst IOPS» — несерйозна стратегія.

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