В InnoDB журналом скасувань (undo log) і журналом повторів (redo log) є два незамінних компоненти, які відіграють життєво важливу роль у підтримці цілісності даних і забезпеченні узгодженості транзакцій. Обидва журнали мають вирішальне значення для властивостей ACID (атомарність, узгодженість, ізольованість, довговічність) систем баз даних. Крім того, вони необхідні для механізму контролю багатоверсійного паралелізму (MVCC). У цій статті ми розглянемо відмінності між журналом скасувань і журналом повторів InnoDB, пояснимо їх значення і надамо приклади коду, що ілюструють їх використання.
Журнал скасувань InnoDB
Журнал скасувань, також відомий як сегмент відкату, є важливою частиною механізму зберігання даних InnoDB. Його основне призначення - підтримувати узгодженість транзакцій і надавати можливість відкотити зміни, зроблені під час транзакції. Ось як це працює:
Зберігання образу до транзакції: Щоразу, коли транзакція змінює дані в InnoDB, журнал відміни записує попередній образ змінених даних. Цей попередній образ містить оригінальні значення змінених рядків, що дозволяє скасувати або відкотити зміни, якщо це необхідно.
Ізоляція транзакцій: Журнал скасування відіграє важливу роль у забезпеченні таких рівнів ізоляції транзакцій, як READ COMMITTED або REPEATABLE READ. Він гарантує, що в межах транзакції інші паралельні транзакції можуть читати узгоджені дані, використовуючи попередні образи, що зберігаються в журналі відміни.
Відновлення після збоїв: У разі збою системи або перезапуску, журнал відміни допомагає відновити базу даних до узгодженого стану, застосовуючи необхідні операції відміни на основі записаних образів попередніх транзакцій.
Приклад коду - InnoDB Undo Log:
-- Begin a transaction
START TRANSACTION;
-- Modify data
UPDATE employees SET salary = salary * 1.1 WHERE department = 'Sales';
-- Rollback the changes
ROLLBACK;
У Tерміналі 1 ми створили таблицю з назвою employees і вставили в неї кілька записів. Потім ми запустили транзакцію, оновили зарплати працівників відділу Sales і побачили, що це торкнулося десяти рядків. Нарешті, ми вибрали всі записи з таблиці employees, щоб побачити оновлені зарплати.
mysql> CREATE TABLE employees (
-> employee_id INT PRIMARY KEY,
-> name VARCHAR(100),
-> department VARCHAR(100),
-> salary DECIMAL(10, 2)
-> );
Query OK, 0 rows affected (0.03 sec)
Додаємо кілька записів до таблиці працівників.
mysql> INSERT INTO employees (employee_id, name, department, salary)
-> VALUES
-> (1, 'John Smith', 'Sales', 50000.00),
-> (2, 'Jane Doe', 'Sales', 55000.00),
-> (3, 'Michael Johnson', 'Sales', 60000.00),
-> (4, 'Emily Williams', 'Sales', 52000.00),
-> (5, 'David Anderson', 'Sales', 58000.00),
-> (6, 'Sarah Thompson', 'Sales', 51000.00),
-> (7, 'Christopher Lee', 'Sales', 54000.00),
-> (8, 'Jessica Brown', 'Sales', 57000.00),
-> (9, 'Matthew Davis', 'Sales', 53000.00),
-> (10, 'Olivia Taylor', 'Sales', 56000.00);
Query OK, 10 rows affected (0.01 sec)
Records: 10 Duplicates: 0 Warnings: 0
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)
mysql> UPDATE employees SET salary = salary * 1.1 WHERE department = 'Sales';
Query OK, 10 rows affected (0.00 sec)
Rows matched: 10 Changed: 10 Warnings: 0
Використовуючи той самий термінал, зробимо запит до таблиці та побачимо, що запит повертає оновлений запис.
mysql> select * from mytest.employees;
+-------------+-----------------+------------+----------+
| employee_id | name | department | salary |
+-------------+-----------------+------------+----------+
| 1 | John Smith | Sales | 55000.00 |
| 2 | Jane Doe | Sales | 60500.00 |
| 3 | Michael Johnson | Sales | 66000.00 |
| 4 | Emily Williams | Sales | 57200.00 |
| 5 | David Anderson | Sales | 63800.00 |
| 6 | Sarah Thompson | Sales | 56100.00 |
| 7 | Christopher Lee | Sales | 59400.00 |
| 8 | Jessica Brown | Sales | 62700.00 |
| 9 | Matthew Davis | Sales | 58300.00 |
| 10 | Olivia Taylor | Sales | 61600.00 |
+-------------+-----------------+------------+----------+
10 rows in set (0.00 sec)
mysql>
У Терміналі 2 ми зробили запит до таблиці employees і помітили, що він повернув старі записи, які є попередніми образами, що зберігаються у журналі скасувань. Це демонструє, як журнал відміни підтримує узгодженість транзакцій, дозволяючи паралельним транзакціям читати узгоджені дані.
mysql> select * from mytest.employees;
+-------------+-----------------+------------+----------+
| employee_id | name | department | salary |
+-------------+-----------------+------------+----------+
| 1 | John Smith | Sales | 50000.00 |
| 2 | Jane Doe | Sales | 55000.00 |
| 3 | Michael Johnson | Sales | 60000.00 |
| 4 | Emily Williams | Sales | 52000.00 |
| 5 | David Anderson | Sales | 58000.00 |
| 6 | Sarah Thompson | Sales | 51000.00 |
| 7 | Christopher Lee | Sales | 54000.00 |
| 8 | Jessica Brown | Sales | 57000.00 |
| 9 | Matthew Davis | Sales | 53000.00 |
| 10 | Olivia Taylor | Sales | 56000.00 |
+-------------+-----------------+------------+----------+
10 rows in set (0.00 sec)
У Терміналі 1 ми виконали відкат, який використовував попередні зображення, щоб скасувати або відкотити зміни, зроблені під час транзакції. Після відкату ми знову вибрали всі записи з таблиці employees і переконалися, що зарплати повернулися до своїх початкових значень.
Ці дії демонструють роль журналу скасувань у підтримці узгодженості транзакцій і наданні можливості відкотити зміни, коли це необхідно.
mysql> ROLLBACK;
Query OK, 0 rows affected (0.04 sec)
mysql> select * from mytest.employees;
+-------------+-----------------+------------+----------+
| employee_id | name | department | salary |
+-------------+-----------------+------------+----------+
| 1 | John Smith | Sales | 50000.00 |
| 2 | Jane Doe | Sales | 55000.00 |
| 3 | Michael Johnson | Sales | 60000.00 |
| 4 | Emily Williams | Sales | 52000.00 |
| 5 | David Anderson | Sales | 58000.00 |
| 6 | Sarah Thompson | Sales | 51000.00 |
| 7 | Christopher Lee | Sales | 54000.00 |
| 8 | Jessica Brown | Sales | 57000.00 |
| 9 | Matthew Davis | Sales | 53000.00 |
| 10 | Olivia Taylor | Sales | 56000.00 |
+-------------+-----------------+------------+----------+
10 rows in set (0.00 sec)
У наведеному вище фрагменті коду транзакція змінює стовпець salary для працівників відділу продажів. Якщо транзакцію відкотити, журнал скасувань використовується для повернення зроблених змін до початкових значень.
InnoDB Redo Log
Журнал повторних дій, також відомий як журнал транзакцій або журнал InnoDB, має іншу мету, ніж журнал скасувань. Його основна функція - забезпечити довговічність і допомогти у відновленні після збоїв. Давайте розглянемо його характеристики:
Запис змін: Кожного разу, коли транзакція змінює дані в InnoDB, журнал повторення записує зміни, внесені в базу даних. Він зберігає фактично виконані модифікації, такі як вставка нових рядків, оновлення існуючих рядків або видалення рядків.
Журнал повторних змін не тільки записує зміни, внесені до бази даних, але також включає модифікації, які записуються в сегменти відкату. У системі баз даних сегменти відкоту використовуються для тимчасового зберігання даних про скасування під час транзакцій. Таким чином, на додаток до відстеження змін у базі даних, Redo Log також фіксує зміни, внесені до сегментів відкату. Це гарантує, що під час процедур відновлення система зможе належним чином відновити базу даних до узгодженого стану, застосовуючи як зміни в базі даних, так і модифікації, що зберігаються в сегментах відкоту.
Журнал запису на випередження: Журнал повторних операцій працює за принципом запису на випередження, що означає, що зміни записуються до журналу повторних операцій до того, як відповідні сторінки даних будуть оновлені. Це гарантує, що в разі збою, зміни записані в журналі повторення, можуть бути відтворені, щоб відновити базу даних до узгодженого стану.
Відновлення після збою: Під час відновлення після збою журнал повторних внесень має вирішальне значення для відтворення записаних змін, щоб привести базу даних до узгодженого стану. Повторно застосовуючи зміни, записані в журналі повторних дій, InnoDB може відновити транзакції, які були зафіксовані, але ще не записані на диск.
Журнали повторних внесень також використовуються для створення послідовних фізичних резервних копій. Такі інструменти, як Percona XtraBackup, використовують журнали повторного копіювання на етапі підготовки, щоб зробити резервну копію послідовною. Це відрізняє фізичні резервні копії, які включають зміни, зроблені в процесі резервного копіювання, від логічних, які представляють базу даних на початку резервного копіювання. Логічні резервні копії створюють образ бази даних на початку резервного копіювання. Фізичні резервні копії представляють образ бази даних в кінці резервного копіювання.
-- Begin a transaction
START TRANSACTION;
-- Modify data
UPDATE products SET stock = stock - 10 WHERE id = 123;
-- Commit the transaction
COMMIT;
У наведеному вище прикладі транзакція оновлює стовпчик запасів товару, ідентифікованого за ID. Зміни фіксуються в журналі повторних дій, що забезпечує довговічність і дозволяє відновити дані в разі збою.
Висновок
Розуміння відмінностей між журналом скасувань і журналом повторних дій в InnoDB має вирішальне значення для забезпечення цілісності та довговічності даних. Журнал скасувань слугує критично важливим компонентом для підтримки узгодженості транзакцій, дозволяючи відкочувати зміни та підтримуючи рівні ізоляції транзакцій. З іншого боку, журнал повторення відіграє життєво важливу роль у забезпеченні довговічності та допомагає у відновленні після збоїв, реєструючи зміни в базі даних і дотримуючись підходу запису на випередження.
Варто зазначити, що процес скидання (checkpointing vs. redo log) і очищення (purging vs. undo log) може мати значний вплив на продуктивність системи та накладні витрати. Під скиданням мається на увазі періодичний запис брудних сторінок з пам'яті на диск, або за допомогою контрольних точок, або за допомогою журналу повторних дій. Цей процес допомагає гарантувати, що зміни безпечно зберігаються на диску, що сприяє підвищенню довговічності системи. Очищення, з іншого боку, передбачає видалення старих або непотрібних даних з системи, що може включати очищення журналів скасування. Належне управління операціями скидання та очищення має вирішальне значення для продуктивності та налаштування системи.
Розуміючи накладні витрати, міркування щодо налаштування та роль скидання та очищення у відношенні до журналів скасувань та повторень, адміністратори баз даних можуть оптимізувати свої системи для досягнення бажаного балансу між цілісністю даних, продуктивністю та вимогами до сховища.
Таким чином, журнал скасувань і журнал повторних дій InnoDB є незамінними компонентами, які працюють разом, щоб забезпечити узгодженість транзакцій, довговічність і можливості відновлення після збоїв. Поряд з операціями скидання та очищення, ці журнали необхідні для управління цілісністю даних і продуктивністю системи в системах баз даних.
Ще немає коментарів