Changes between Version 1 and Version 2 of InnoDB

Timestamp:

09/20/26 01:15:17 (7 days ago)

Author:

222004

Comment:

--

InnoDB

@@ -1 +1 @@
 = Crash Recovery – Опоравување на трансакции по пад на MySQL сервер =
+
+== 1. Вовед и цел ==
+
+Во оваа фаза се испитува што се случува со трансакциите кога MySQL серверот неочекувано ќе престане да работи. Практичниот пример е поврзан со претходната фаза за трансакции во AirportDB: резервација на седиште и промена на седиште.
+
+Целта е да се провери дали по повторното стартување:
+ * веќе потврдените промени (`COMMIT`) остануваат зачувани;
+ * промените од незавршена трансакција се поништуваат;
+ * повеќе промени во една трансакција не остануваат делумно запишани.
+
+Ова е '''Crash Recovery''', а не враќање од резервна копија (Backup). Во експериментите повторно се стартува истиот MySQL сервер со истиот податочен волумен; не се користат `mysqldump` или враќање на база од backup.
+
+== 2. Како работи опоравувањето ==
+
+Во InnoDB, трансакцијата се потврдува со `COMMIT`. При ненадеен прекин не е доволно само повторно да се стартува апликацијата: базата треба да утврди кои промени биле потврдени, а кои не биле довршени.
+
+|| '''Поим''' || '''Едноставно објаснување''' ||
+|| '''Redo log''' || Чува информации потребни за повторно применување на промени што треба да се сочуваат. При стартување InnoDB го проверува логот и, кога е потребно, ги применува промените што не биле запишани во податочните страници. ||
+|| '''Undo log''' || Овозможува поништување на промените од незавршените трансакции. ||
+|| '''Write-ahead logging (WAL)''' || Потребните информации за опоравување се запишуваат во логот пред соодветните податочни страници да се запишат на диск. ||
+|| '''Checkpoint''' || Забележува до која точка податочните страници се запишани, со што се намалува обемот на работа при опоравување. ||
+
+Во оваа демонстрација се проверуваат две ACID својства: '''трајност (Durability)''' – потврдената резервација останува по падот; и '''атомичност (Atomicity)''' – незавршените операции се поништуваат како целина.
+
+== 3. Тест околина ==
+
+За да не се менува оригиналната база, користена е посебна Docker околина во WSL2 Ubuntu. MySQL Workbench на Windows се поврзува со портата `33307`.
+
+|| '''Поставка''' || '''Вредност''' ||
+|| MySQL || `8.0.43` ||
+|| Docker контејнер || `airportdb_recovery_lab_mysql` ||
+|| Постојан Docker волумен || `airportdb_recovery_lab_data` ||
+|| База || `airportdb_recovery_lab` ||
+|| Host / порта за Workbench || `127.0.0.1:33307` ||
+|| Внатрешна MySQL порта || `3306` ||
+|| `innodb_flush_log_at_trx_commit` || `1` ||
+|| `sync_binlog` || `1` ||
+|| `log_bin` || `1` ||
+
+Поставката `innodb_flush_log_at_trx_commit=1` е користена за тестот на трајноста. Binary log е вклучен како дел од конфигурацијата, но '''не се користи за враќање на податоци''' во оваа фаза; за InnoDB crash recovery се важни неговите сопствени redo/undo информации.
+
+Проверката во Workbench е направена со:
+
+{{{
+
+SELECT @@version AS mysql_version,
+       DATABASE() AS selected_database,
+       @@port AS mysql_port,
+       @@innodb_flush_log_at_trx_commit AS innodb_flush_log_at_trx_commit,
+       @@sync_binlog AS sync_binlog,
+       @@log_bin AS binary_logging;
+
+}}}
+
+'''Слика 1 – Верзија, база и поставки за трајност.''' [[BR]]
+[[Image(01_environment_configuration.png, width=850)]]
+
+Користен е издвоен, минимален модел од AirportDB со табелите `airplane`, `flight` и `booking`, како и помошната `recovery_operation_event` за тестот на атомарност. Логиката за резервација е клонирана од претходната фаза; оригиналните процедури и бази не се менувани.
+
+Почетната состојба на двата лета е:
+
+|| '''Лет''' || '''Авион''' || '''Капацитет''' || '''Број резервации''' ||
+|| 100 || 1 || 2 || 0 ||
+|| 200 || 2 || 1 || 0 ||
+
+{{{
+
+SELECT f.flight_id, f.airplane_id, a.capacity,
+       COUNT(b.booking_id) AS booking_count
+FROM flight AS f
+JOIN airplane AS a ON a.airplane_id = f.airplane_id
+LEFT JOIN booking AS b ON b.flight_id = f.flight_id
+GROUP BY f.flight_id, f.airplane_id, a.capacity
+ORDER BY f.flight_id;
+
+}}}
+
+'''Слика 2 – Почетна состојба на летовите и резервациите.''' [[BR]]
+[[Image(02_initial_booking_state.png, width=850)]]
+
+== 4. Експеримент 1 – Опоравување на потврдена резервација ==
+
+'''Цел:''' да се провери дали резервацијата останува зачувана по прекин што се случува '''по `COMMIT`'''.
+
+Во Workbench беше повикана постојната клонирана процедура за резервација:
+
+{{{#!sql
+CALL sp_reserve_seat(100, '1A', 9101, 100.00);
+
+SELECT booking_id, flight_id, passenger_id, seat, price
+FROM booking
+WHERE passenger_id = 9101;
+}}}
+
+Процедурата успешно ја заврши резервацијата. Во рачниот тест беше добиена резервација со `booking_id = 31`, за патник `9101`, лет `100` и седиште `1A`.
+
+'''Слика 3 – Резервацијата пред прекинот.''' [[BR]]
+[[Image(03_committed_booking_before_crash.png, width=850)]]
+
+Потоа, во WSL терминалот серверот беше насилно прекинат со `SIGKILL` и беше стартуван повторно со истиот податочен волумен:
+
+{{{
+
+docker kill --signal=KILL airportdb_recovery_lab_mysql
+docker start airportdb_recovery_lab_mysql
+
+}}}
+
+'''Слика 4 – Прекин и повторно стартување на Docker контејнерот.''' [[BR]]
+[[Image(03_committed_booking_before_crash_docker.png, width=850)]]
+
+По повторното поврзување беше извршена проверка:
+
+{{{#!sql
+SELECT booking_id, flight_id, passenger_id, seat, price
+FROM booking
+WHERE passenger_id = 9101 AND flight_id = 100 AND seat = '1A';
+}}}
+
+'''Резултат:''' резервацијата со `booking_id = 31` остана присутна со истите податоци. Со тоа тестот ја потврди трајноста на потврдената трансакција во испитаните услови.
+
+'''Слика 5 – Истата резервација по опоравувањето.''' [[BR]]
+[[Image(04_committed_booking_after_recovery.png, width=850)]]
+
+== 5. Контролиран прекин пред COMMIT ==
+
+За следните два експеримента прекинот мора да се случи '''пред''' `COMMIT`. Затоа се користени три независни Workbench сесии:
+
+|| '''Сесија''' || '''Улога''' ||
+|| A – Target || Ги извршува измените и чека пред `COMMIT`. ||
+|| B – Controller || Претходно го зазема именуваниот lock со `GET_LOCK(...)`. ||
+|| C – Monitor || Проверува кој го поседува lock-от и дали Target чека. ||
+
+Именуваниот lock служи само за '''точно одредување на моментот за пад'''. Тој не претставува замена за транскацискиот механизам на InnoDB. Target мора да остане блокиран; доколку `GET_LOCK` врати `1` и се изврши `COMMIT`, тестот не е валиден.
+
+== 6. Експеримент 2 – Поништување на незавршена резервација ==
+
+'''Цел:''' да остане претходно потврдената резервација, а да се поништи новата резервација што не стигнала до `COMMIT`.
+
+Прво е поставена потврдена почетна резервација: патник `9101`, лет `100`, седиште `1A`. Во овој рачен тест почетната резервација имаше `booking_id = 35`.
+
+Во Controller е заземен lock-от:
+
+{{{#!sql
+SELECT GET_LOCK('recovery_gate_exp2', 600) AS lock_acquired;
+}}}
+
+Потоа во Target е започната незавршената трансакција:
+
+{{{#!sql
+START TRANSACTION;
+INSERT INTO booking (flight_id, passenger_id, seat, price)
+VALUES (100, 9102, '1B', 100.00);
+SELECT GET_LOCK('recovery_gate_exp2', 600) AS target_gate_acquired;
+COMMIT;
+}}}
+
+`COMMIT` е намерно поставен по чекањето. Додека Controller го држи lock-от, Target останува блокиран пред таа наредба.
+
+'''Слика 6 – Target чека пред COMMIT; INSERT е извршен во незавршената трансакција.''' [[BR]]
+[[Image(05_connection_A_test.PNG, width=850)]]
+
+Во рачната проверка Monitor потврди дека Controller со ID `10` го поседува lock-от и Target со ID `8` е во состојба `User lock`. ID-вредностите се менуваат при ново поврзување.
+
+{{{
+
+SELECT IS_USED_LOCK('recovery_gate_exp2') AS lock_owner;
+
+SELECT ID, DB, TIME, STATE, INFO
+FROM information_schema.processlist
+WHERE DB = 'airportdb_recovery_lab'
+  AND STATE = 'User lock'
+  AND INFO LIKE '%recovery_gate_exp2%';
+
+}}}
+
+Без ослободување на lock-от, контејнерот е прекинат со `docker kill --signal=KILL` и повторно стартуван. По поврзувањето беше проверено:
+
+{{{#!sql
+SELECT 'Потврдена 9101/1A' AS check_name, COUNT(*) AS actual_rows
+FROM booking
+WHERE passenger_id = 9101 AND flight_id = 100 AND seat = '1A'
+UNION ALL
+SELECT 'Незавршена 9102/1B', COUNT(*)
+FROM booking
+WHERE passenger_id = 9102 OR (flight_id = 100 AND seat = '1B');
+}}}
+
+|| '''Проверка''' || '''Очекувано''' || '''Добиено''' ||
+|| Потврдена резервација `9101/1A` || 1 || 1 ||
+|| Незавршена резервација `9102/1B` || 0 || 0 ||
+
+'''Резултат:''' потврдената резервација остана, а незавршената беше поништена. При пребарување на табелата `booking` остана само резервацијата на патник `9101`.
+
+'''Слика 7 – Состојба по опоравувањето: зачувана е само потврдената резервација.''' [[BR]]
+[[Image(06_uncommitted_after_recovery.png, width=850)]]
+
+== 7. Експеримент 3 – Атомарност на две поврзани промени ==
+
+'''Цел:''' да се провери дека по падот не останува делумна промена: промена на седиште без соодветниот помошен запис, или обратно.
+
+За почетна состојба е креирана потврдена резервација за патник `9201`, лет `100`, седиште `1A` (`booking_id = 37`). Табелата `recovery_operation_event` нема записи за `exp3`.
+
+'''Слика 8 – Почетна резервација на седиште 1A.''' [[BR]]
+[[Image(07_atomicity_initial_state.png, width=850)]]
+
+Controller го зазема `recovery_gate_exp3`. Во Target се извршени две измени во истата трансакција:
+
+{{{#!sql
+SELECT booking_id INTO @exp3_booking_id
+FROM booking
+WHERE passenger_id = 9201 AND flight_id = 100 AND seat = '1A';
+
+START TRANSACTION;
+UPDATE booking SET seat = '1C'
+WHERE booking_id = @exp3_booking_id;
+
+INSERT INTO recovery_operation_event
+    (experiment, booking_id, before_seat, after_seat)
+VALUES ('exp3', @exp3_booking_id, '1A', '1C');
+
+SELECT GET_LOCK('recovery_gate_exp3', 600) AS target_gate_acquired;
+COMMIT;
+}}}
+
+Мониторингот покажа дека Target со ID `19` чека во `User lock`, додека Controller со ID `21` го поседува lock-от. Затоа `COMMIT` сѐ уште не е извршен.
+
+'''Слика 9 – Контролирано чекање пред COMMIT во експериментот за атомарност.''' [[BR]]
+[[Image(08_atomicity_precommit_gate.png, width=850)]]
+
+Потоа следеше истиот насилен прекин (`SIGKILL`) и повторно стартување. По опоравувањето беа проверени трите исходи:
+
+{{{#!sql
+SELECT 'Оригинално 1A' AS check_name, COUNT(*) AS actual_rows
+FROM booking WHERE passenger_id = 9201 AND flight_id = 100 AND seat = '1A'
+UNION ALL
+SELECT 'Незавршено 1C', COUNT(*)
+FROM booking WHERE passenger_id = 9201 AND seat = '1C'
+UNION ALL
+SELECT 'Незавршен exp3 запис', COUNT(*)
+FROM recovery_operation_event WHERE experiment = 'exp3';
+}}}
+
+|| '''Проверка''' || '''Очекувано''' || '''Добиено''' ||
+|| Оригиналното седиште `1A` постои || 1 || 1 ||
+|| Промената на `1C` не постои || 0 || 0 ||
+|| Новиот `exp3` запис не постои || 0 || 0 ||
+
+'''Резултат:''' двете незавршени измени се поништени. Патникот `9201` повторно е на `1A`, а во помошната табела нема `exp3` запис. Ова ја потврдува атомарноста на трансакцијата во експериментот.
+
+'''Слика 10 – Проверка по опоравувањето: резултати 1, 0 и 0.''' [[BR]]
+[[Image(08_atomicity_after_recovery.png, width=850)]]
+
+== 8. Логови и checkpoint по опоравувањето ==
+
+Логовите на Docker контејнерот се прегледани со:
+
+{{{
+
+docker logs airportdb_recovery_lab_mysql 2>&1 | grep -Ei \
+'not shutdown normally|Starting crash recovery|Doing recovery|Applying a batch|resurrected|must be rolled back|Rolling back|Rollback of non-prepared|ready for connections'
+
+}}}
+
+Во зачуваната снимка се гледаат повеќе стартувања. При едно од претходните стартувања, во `10:41 UTC`, InnoDB пријави примена на серија од '''12 redo log records''', откри '''една незавршена трансакција''' и пријави '''1 row to undo'''. Поновите стартувања прикажуваат и `Applying a batch of 0 redo log records`. Ова не значи дека redo секогаш применува промени; обемот на работа зависи од состојбата при конкретниот пад.
+
+'''Важно:''' овие лог-пораки се за лабораторијата низ повеќе извршувања. Пораките од `10:41 UTC` не се означуваат како лог исклучиво од рачниот експеримент 3.
+
+'''Слика 11 – InnoDB логи: неочекуван прекин, redo проверка и rollback.''' [[BR]]
+[[Image(11_innodb_recovery_log.png, width=850)]]
+
+По рачните тестови, со `SHOW ENGINE INNODB STATUS;` беше проверен делот `LOG`. Во моментот на проверката се добиени следните вредности:
+
+|| '''Показател''' || '''Добиена вредност''' ||
+|| Log sequence number || 30.912.187 ||
+|| Log written up to || 30.912.187 ||
+|| Log flushed up to || 30.912.187 ||
+|| Pages flushed up to || 30.912.187 ||
+|| Last checkpoint at || 30.912.187 ||
+|| Modified db pages || 0 ||
+|| History list length || 0 ||
+
+Еднаквите позиции на логот и checkpoint, заедно со `Modified db pages = 0`, покажуваат дека во моментот на оваа проверка немало модифицирани страници што чекале запис. Ова е '''снимка на состојбата по опоравувањето'''; само по себе не е доказ дека при тој конкретен старт биле применети redo записи. Доказот за активноста при recovery доаѓа од startup логовите и SQL-проверките по прекинот.
+
+== 9. Сумаризација на тестирањето ==
+
+|| '''Експеримент''' || '''Начин на проверка''' || '''Исход''' ||
+|| 1. Потврдена резервација || Резервацијата постои пред и по `SIGKILL`. || PASS – рачно проверено ||
+|| 2. Незавршена резервација || Потврдената останува, незавршената отсуствува (`1, 0`). || PASS – рачно проверено ||
+|| 3. Две измени во иста трансакција || Старото седиште останува, двете нови промени отсуствуваат (`1, 0, 0`). || PASS – рачно проверено ||
+|| 4. Потврдена и незавршена паралелно || Според зачуваниот извештај од автоматското тестирање `results/run-20260919T124053/summary.tsv`. || PASS – пријавено од автоматскиот тест; не е повторено рачно за оваа wiki страница ||
+
+Експериментите намерно го прекинуваат '''MySQL процесот/контејнерот''', а не целиот оперативен систем или физичкото напојување. Затоа резултатите не треба да се претставуваат како тест на физички прекин на струја. Податоците се зачувани во истиот Docker волумен, без враќање од backup.
+
+== 10. Заклучок ==
+
+Рачните тестови покажаа дека InnoDB ја зачувува потврдената резервација, ги поништува незавршените промени и не дозволува делумно зачувување на двете измени од експериментот за атомарност. Логовите ја дополнуваат SQL-проверката со увид во механизмите за опоравување. Оваа фаза се надоврзува на претходната фаза за трансакции, но проверува што се случува '''по ненадеен прекин на серверот''', наместо само како трансакциите работат додека серверот е активен.