Резервне копіювання БД

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

Згадай наш Lab Setup — там перед внесенням змін в файл конфігурації ми зробили його копію, щоб у випадку помилки можна було легко відновити роботу свого сервера. Помилитись можна не тільки при роботі з файлом конфігурації, а і з даними, наприклад, випадково видалити потрібні записи.

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

Типи бекапів

Загалом, бекапи бази даних можна розлити на типи за цілим набором критеріїв. Перша з них:

Фізичний — це повна копія бази даних, у вигляді як вона зберігається на диску. У темі про конфігурацію ми вже згадували, що MySQL зберігає бази даних на диску сервера, і що ти можеш задати теку, в які зберігатимуться файли баз за допомогою конфігураційної опції data_dir. Так от, фізичний бекап — це просто копія файлів у цій теці. Недолік фізичного бекапу: коли створюється резервна копія, потрібно щоб дані на диску були повністю коректними. Наприклад, якщо користувач виконуватиме великий запит INSERT під час створення резервної копії, дані з цього запису можуть не встигнути записатись на диск повністю. Якщо спробувати відновити базу з такої резервної копії, вона, через частково записані дані, може виявитись пошкоджено.
Логічний — це набір SQL-команд, які відтворюють структуру бази даних та дані в ній. Це просто файл з SQL-скриптом, що складається з команд CREATE TABLE та INSERT, з якого можна повністю відновити базу. Логічні бекапи зазвичай повільніше створюються, та відновлення з такого бекапу теж займає більше часу. Проте, оскільки такий бекап — це просто набір SQL команд, то навіть якщо він буде пошкоджений, помилки можна буде простежити та виправити.

Бекапи також бувають:

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

Остання класифікація бекапів:

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

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

Резервне копіювання

Процедура резервного копіювання залежить від вимог до системи та можливостей команди. Ось декілька порад:

До системи, яка використовує базу даних, повинні бути встановлені вимоги стійкості (resiliency): RTO та RPO. RTO (recovery time objective) — це час, за який система має відновити свою роботу після збою. Якщо RTO твоєї системи = 60 хвилин, а інструмент для резервного копіювання відновлює твою базу даних більше ніж годину, тоді цей інструмент або спосіб резервного копіювання тобі не підходить. RPO (recovery point objective) — це допустима втрата даних. Зазвичай це значення вказують у вигляді часового проміжку, за який втрата даних вважається допустимою. Наприклад, якщо RPO = 1 день, то твоє рішення для резервного копіювання повинне робити бекапи як мінімум щодня.
Резервне копіювання потрібно здійснювати з певною періодичністю та автоматично. Інструмент, за допомогою якого ти налагоджуєш резервне копіювання, повинен дозволяти визначити розклад, за яким запускається процедура. Генерація резервної копії зазвичай створює додаткове навантаження на сервер бази даних. Тому для того, щоб вирішити, коли саме запускати резервне копіювання, потрібно проаналізувати метрики сервера (зазвичай навантаження на процесор) та визначити час, коли він найменше навантажений.

mysqldump

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

Створення резервної копії

mysqldump може створювати бекапи як на локальному комп’ютері, так і на віддаленому. Для того, щоб створити бекап бази даних, потрібно виконати ось таку команду:

mysqldump -u mysqluser -p P@ssw0rd --databases company  --result-file=backup.sql

Тут:

mysqluser — це користувач MySQL;
P@ssw0rd — це пароль.

За допомогою параметру --databases вказуються бази даних, резервну копію яких потрібно створити. Замість цього параметру можна вказати --all-databases, тоді mysqldump створить резервну копію всіх баз даних, які є на сервері.

--result-file визначає, куди буде збережено результат виконання дампу бази даних.

Відновлення БД з резервної копії

Щоб відновити базу з резервної копії, достатньо виконати запити з файлу, який ми створили. Видалимо базу даних, резервну копію якої ми створили, і протестуємо її відновлення:

mysql -u mysqluser -pP@ssw0rd 
show databases; 
drop database company; 
show databases;

База даних company видалилась. Тепер відновимо її з резервної копії:

mysql -u mysqluser -pP@ssw0rd < backup.sql

Якщо перевірити, то наша база, її таблиці та дані будуть на сервері бази даних:

mysql -u mysqluser -pP@ssw0rd
show databases; 
use database company; 
show tables; 
exit

Параметри mysqldump

При створенні бекапів, тобі буде корисно знати про декілька параметрів mysqldump ⬇️

`--no-create-db`

З параметром --no-create-db файл резервної копії не міститиме SQL-команду CREATE DATABASE. Це може бути корисно, якщо ти хочеш відновити резервну копію у базу даних з іншим ім’ям. На практиці, таке перенесення виглядає ось так:

mysqldump -u mysqluser -pP@ssw0rd company --no-create-db --result-file=backup-no-create-db.sql

💡 Зверни увагу, що в цій команді пропущений параметр --databases. Річ у тім, що коли він вказується, то у результуючий файл додається команда USE з ім'ям оригінальної бази даних. Для того, щоб відновити наш бекап в базу з іншим ім'ям, нам цей параметр не потрібний.

Тепер, відновимо цей бекап в базу з іншим ім’ям:

mysql -u mysqluser -pP@ssw0rd; 
create database companyRestored; 
exit

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

mysql -u mysqluser -pP@ssw0rd  companyRestored < backup-no-create-db.sql
mysql -u mysqluser -pP@ssw0rd
use companyRestored; 
show tables;

`--no-create-info`

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

`--no-data`

За допомогою параметру --no-data можна створити файл бекапу, який міститиме лише інструкції для створення структури бази даних, але не міститиме самі дані.

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