MySQL 8.0 DDL-Atomaritätsfunktion und Implementierungsprinzip

1. Übersicht über die Atomizität von DDL

Vor 8.0 gab es kein einheitliches Datenwörterbuch dd. Die Serverebene und die Engineebene hatten jeweils einen Satz Metadaten. Die Metadaten der Serverebene umfassten (.frm, .opt, .par, .trg usw.), die zum Speichern von Tabellendefinitionen, Partitionstabellendefinitionen, Triggerdefinitionen und anderen Informationen verwendet wurden; die InnoDB-Ebene hatte auch ihren eigenen Satz Metadaten, einschließlich Tabelleninformationen, Indexinformationen usw. Es gab keinen Mechanismus, um die Konsistenz dieser beiden Metadatensätze sicherzustellen, was unter abnormalen Umständen zu Problemen mit inkonsistenten Metadaten führte. In einem typischen Szenario wurde bei einem Löschvorgang für eine Tabelle das frm der Serverebene erfolgreich gelöscht, das Datenwörterbuch der Engineebene wurde jedoch nicht aktualisiert, was dazu führte, dass der Wiederaufbau der Tabelle mit demselben Namen fehlschlug. Wenn Sie beispielsweise die Tabellen t1 und t2 löschen, können Probleme auftreten, beispielsweise dass nur t1 gelöscht wird, während t2 noch vorhanden ist.

Eine wichtige Aufgabe von 8.0 besteht darin, das Datenwörterbuch zu vereinheitlichen, das DD-Modul (Datenwörterbuch) zu trennen, die Metadaten der Serverschicht aufzugeben und die Metadaten von InnoDB in eine DD-Schnittstelle zur gemeinsamen Verwendung durch die Serverschicht und die InnoDB-Schicht zu abstrahieren. Basierend auf DD wird die Atomizitätsfunktion von DDL eingeführt, um sicherzustellen, dass DDL-Operationen entweder vollständig oder gar nicht ausgeführt werden. Der Schlüssel zur Implementierung dieser Logik besteht darin, alle an DDL beteiligten Änderungen, einschließlich Änderungen am DD-Datenwörterbuch, Änderungen auf Engine-Ebene (Erstellen von Dateien, Initialisieren des Tablespace, Erstellen eines B-Trees usw.) und Schreiben des Binlogs als „Transaktion“ zu behandeln und die Atomizität von Transaktionen zu nutzen, um die Atomizität von DDL-Operationen sicherzustellen.

2. Prinzipien der DDL-Atomaritätsimplementierung

Der Schlüssel zum Erreichen der Atomarität besteht darin, sicherzustellen, dass die Änderung des DD-Datenwörterbuchs, die Änderung der Engine-Ebene und das Schreiben des Binärprotokolls eine Transaktion sind. Der vorhandene XA-Transaktionsmechanismus von MySQL kann die Konsistenz von DML-Transaktionen und Binlog effektiv sicherstellen. Das DDL-Datenwörterbuch wird auch von der InnoDB-Engine gespeichert, sodass die DD-Datenwörterbuchänderungen leicht mit dem Binlog in Einklang gebracht werden können. Ein weiteres zu lösendes Problem ist die Konsistenz des DD-Datenwörterbuchs und der Änderungen auf Engine-Ebene. Nicht alle Änderungen auf Engine-Ebene werden in Redo aufgezeichnet, z. B. das Erstellen einer Datei, das Umbenennen eines Dateinamens oder das Leeren des Caches usw., was nicht einfach durch den XA-Mechanismus gelöst werden kann. Daher führt 8.0 auch einen DDL_LOG-Mechanismus ein. Insbesondere werden einige Vorgänge, die keine Redo-Aufzeichnungen enthalten, in Form von Protokollen in die ddl_log-Tabelle geschrieben. Diese Tabelle ist eine InnoDB-Engine-Tabelle. Indem sichergestellt wird, dass die ddl_log-Daten mit den DD-Datenwörterbuchänderungen übereinstimmen, werden die Konsistenzprobleme von DD-Datenwörterbuchänderungen, Engine-Layer-Änderungen und Binlog-Schreibvorgängen letztendlich gelöst.

3. Vergleich vor und nach DD-Einführung

 ​

​  ​

4. Implementierungslogik für DDL-Operationen

Nach der Einführung der ddl_log-Tabelle hat sich der DDL-Vorgang gegenüber der ursprünglichen Basis in einigen Punkten geändert. Es gibt zwei Hauptpunkte. Erstens wird der DDL-Vorgang während der Ausführung von DDL in der ddl_log-Tabelle aufgezeichnet. Zweitens wird eine post_ddl-Phase hinzugefügt. Nachdem die DDL-Transaktion festgeschrieben wurde, werden einige DDL-Abschlussaktionen ausgeführt, z. B. Drop-Table. Das eigentliche Löschen physischer Dateien erfolgt in der post-ddl-Phase. Die Hauptfunktion von Post-DDL besteht darin, den DDL-Protokollinhalt zu lesen und wiederzugeben. Die DDL-Operationstypen sind wie folgt:

enum-Klasse Log_Type : uint32_t {
/** Kleinster Protokolltyp */
SMALLEST_LOG = 1,
/** Einen Indexbaum löschen */
FREE_TREE_LOG = 1,
/**Eine Datei löschen */
DELETE_SPACE_LOG,
/** Eine Datei umbenennen */
RENAME_SPACE_LOG,
/** Lösche den Eintrag in innodb_dynamic_metadata */
DROP_LOG,
/** Tabelle im Dict-Cache umbenennen. */
RENAME_TABLE_LOG,
/** Eine Tabelle aus dem Dict-Cache entfernen */
REMOVE_CACHE_LOG,
/**Alter Encrypt einen Tablespace */
ALTER_ENCRYPT_TABLESPACE_LOG,
/** Größter Protokolltyp */
BIGGEST_LOG = ALTER_ENCRYPT_TABLESPACE_LOG
};

Mithilfe des Schalters innodb_print_ddl_logs können Sie den Inhalt sehen, der während des DDL-Prozesses in die Tabelle innodb_ddl_log geschrieben wird. Im Folgenden werden die von mehreren typischen DDL-Operationen generierten DDL-Protokolle verwendet, um zu veranschaulichen, wie die Atomarität von DDL sichergestellt wird.

4.1 Tabelle erstellen

Anweisung: Tabelle erstellen dd_tt(id int Primärschlüssel, c1 int);

[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: DELETE SPACE, ID=352, Thread-ID=23, Space-ID=71, alter Dateipfad=./mysql/dd_tt.ibd]
[InnoDB] DDL-Protokoll löschen: 352
[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: CACHE ENTFERNEN, ID=353, Thread-ID=23, Tabellen-ID=1128, neuer Dateipfad=mysql/dd_tt]
[InnoDB] DDL-Protokoll löschen: 353
[InnoDB] DDL-Log einfügen: [DDL-Eintrag: FREE, id=354, thread_id=23, space_id=71, index_id=231, page_no=4]
[InnoDB] DDL-Protokoll löschen: 354
[InnoDB] DDL-Log-Beitrag ddl: Beginn für Thread-ID: 23
[InnoDB] DDL-Log-Beitrag ddl: Ende für Thread-ID: 23

veranschaulichen:

1. Alle Einfügevorgänge sind separate Transaktionen, und der entsprechende umgekehrte Löschvorgang ist Teil der gesamten DDL-Transaktion.

2. Der Einfügevorgang zeichnet den umgekehrten Vorgang des Dateivorgangs auf. Wenn Sie beispielsweise table_space erstellen, ist der umgekehrte Vorgang delete_space_log.

3. Wenn die DDL-Transaktion letztendlich erfolgreich ist, werden auch alle umgekehrten Löschvorgänge wirksam und das ddl_log wird normal bereinigt. Wenn die DDL-Transaktion während der Ausführung fehlschlägt (z. B. wenn die Instanz abstürzt), wird der Löschvorgang zurückgesetzt und drei insert_logs verbleiben in der ddl_log-Tabelle. Bei der Wiederherstellung werden diese ddl_logs erneut abgespielt, um den während des DDL-Prozesses generierten Müll zu bereinigen.

4. Wenn während der Wiederherstellung nach einem Absturz das Binärprotokoll auf die Festplatte geschrieben wurde und sich die entsprechende DDL-Transaktion im Vorbereitungszustand befindet, muss die letzte Transaktion festgeschrieben und das DDL-Protokoll bereinigt werden. Wenn das Binärprotokoll nicht auf die Festplatte geschrieben wurde, muss die DDL-Transaktion zurückgesetzt werden, und in der DDL-Protokolltabelle verbleiben 3 Datensätze. Nach Abschluss der Fehlerbehebung müssen diese Datensätze erneut abgespielt werden. Dies ist eigentlich der umgekehrte Vorgang zum Erstellen von Dateien und Erstellen von B-Bäumen, um sicherzustellen, dass sie nach dem Rollback bereinigt sind.

4.2 Drop-Tabelle

Anweisung: drop table dd_tt;

[InnoDB] DDL-Protokoll einfügen: [DDL-Datensatz: DROP, ID=355, Thread-ID=23, Tabellen-ID=1128]
[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: DELETE SPACE, ID=356, Thread-ID=23, Space-ID=71, alter Dateipfad=./mysql/dd_tt.ibd]
[InnoDB] DDL-Log-Beitrag ddl: Beginn für Thread-ID: 23
[InnoDB] DDL-Logwiedergabe: [DDL-Eintrag: DELETE SPACE, id=356, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL-Protokollwiedergabe: [DDL-Datensatz: DROP, ID=355, Thread-ID=23, Tabellen-ID=1128]
[InnoDB] DDL-Log-Beitrag ddl: Ende für Thread-ID: 23

Hinweis: Beim Drop-Vorgang wird während des Ausführungsvorgangs nur das ddl_log ausgeführt, der eigentliche Drop-Vorgang der physischen Tabelle wird nicht ausgeführt. In der Post-DDL-Phase werden die Datensätze in der DDL_Log-Tabelle gelesen und erneut wiedergegeben, um den eigentlichen Löschvorgang durchzuführen. Wenn während der Ausführung ein Absturz auftritt, wird die gesamte DDL-Transaktion einschließlich des Inhalts von ddl_log zurückgesetzt, und der gesamte Drop-Vorgang wird ausgeführt, als hätte er nicht stattgefunden.

4.3 Index hinzufügen

Anweisung: alter table dd_tt add index idx_c1(c1);

[InnoDB] DDL-Log einfügen: [DDL-Eintrag: FREE, id=360, thread_id=23, space_id=72, index_id=233, page_no=5]   
[InnoDB] DDL-Protokoll löschen: 360
[InnoDB] DDL-Log-Beitrag ddl: Beginn für Thread-ID: 23                
[InnoDB] DDL-Log-Beitrag ddl: Ende für Thread-ID: 23

Hinweis: Das Erstellen eines Indexes ist dem Erstellen einer Tabelle ähnlich. Der Einfügevorgang ist eine Transaktion und wird separat übermittelt. Ein Löschvorgang wird als Teil der gesamten DDL-Transaktion aufgezeichnet. Wenn die Transaktion schließlich übermittelt wird, wird der Inhalt des DDL-Protokolls gelöscht. Wenn die Transaktion schließlich zurückgesetzt wird, verbleibt ein FREE-Protokoll im DDL-Protokoll. Mit Replay kann der erstellte Index bereinigt werden, um den Rollback-Effekt zu erzielen.

4.4 Tropfenindex

Anweisung: alter table dd_tt drop index idx_c1;

[InnoDB] DDL-Log einfügen: [DDL-Eintrag: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5]
[InnoDB] DDL-Log-Beitrag ddl: Beginn für Thread-ID: 23
[InnoDB] DDL-Logwiedergabe: [DDL-Datensatz: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5]
[InnoDB] DDL-Log-Beitrag ddl: Ende für Thread-ID: 23

veranschaulichen:

Ähnlich wie bei der Drop-Tabelle werden während des Ausführungsprozesses nur Protokolle aufgezeichnet und der eigentliche Löschvorgang wird in der Post-DDL-Phase ausgeführt.

4.5 Spalte hinzufügen

Anweisung: alter table dd_tt, add column c2 int;

[InnoDB] DDL-Log-Beitrag ddl: Beginn für Thread-ID: 23
[InnoDB] DDL-Log-Beitrag ddl: Ende für Thread-ID: 23

veranschaulichen:

8.0 fügt Spalten mithilfe von Instant-DDL hinzu, das ähnlich wie DML-Transaktionen nur Metadaten ändert und sich nicht auf DDL-Log verlässt, um Atomizität sicherzustellen.

4.6 Drop-Säule

Anweisung: alter table dd_tt drop column c2;

Aufschlüsselung der Aussagen:

1.Vorbereitungsphase:

Tabelle erstellen #sql-ib1129-2815969725;

[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: DELETE SPACE, id=362, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1129-2815969725.ibd] 
[InnoDB] DDL-Protokoll löschen: 362
[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: CACHE ENTFERNEN, ID=363, Thread-ID=23, Tabellen-ID=1130, neuer Dateipfad=mysql/#sql-ib1129-2815969725]  
[InnoDB] DDL-Protokoll löschen: 363
[InnoDB] DDL-Log einfügen: [DDL-Eintrag: FREE, id=364, thread_id=23, space_id=73, index_id=234, page_no=4]         
[InnoDB] DDL-Protokoll löschen: 364

2.Perform-Phase: nichts über DDL-Log

3. Commit-Phase:

3.1 alter table dd_tt rename to #sql-ib1130-2815969726;

[InnoDB] DDL-Protokoll einfügen: [DDL-Datensatz: DROP, ID=365, Thread-ID=23, Tabellen-ID=1129] <br>[InnoDB] DDL-Protokoll einfügen: [DDL-Datensatz: RENAME SPACE, ID=366, Thread-ID=23, Space-ID=72, alter Dateipfad=./mysql/#sql-ib1130-2815969726.ibd, neuer Dateipfad=./mysql/dd_tt.ibd]
[InnoDB] DDL-Protokoll löschen: 366
[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: RENAME TABLE, id=367, thread_id=23, table_id=1129, old_file_path=mysql/#sql-ib1130-2815969726, new_file_path=mysql/dd_tt]
[InnoDB] DDL-Protokoll löschen: 367

Umgekehrte Operation: alter table mysql/#sql-ib1130-2815969726 rename to dd_tt;

3.2 Tabelle #sql-ib1129-2815969725 ändern und in dd_tt umbenennen;

[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: RENAME SPACE, ID=368, Thread-ID=23, Space-ID=73, alter Dateipfad=./mysql/dd_tt.ibd, neuer Dateipfad=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL-Protokoll löschen: 368
[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL-Protokoll löschen: 369

Umgekehrter Vorgang: ter table dd_tt rename to mysql/#sql-ib1129-2815969725;

[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: RENAME SPACE, ID=368, Thread-ID=23, Space-ID=73, alter Dateipfad=./mysql/dd_tt.ibd, neuer Dateipfad=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL-Protokoll löschen: 368
[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL-Protokoll löschen: 369

In der Post-DDL-Phase werden nur Vorgänge aufgezeichnet und bereinigt.

Post-DDL-Phase:

Tabelle löschen #sql-ib1130-2815969726;

[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: RENAME SPACE, ID=368, Thread-ID=23, Space-ID=73, alter Dateipfad=./mysql/dd_tt.ibd, neuer Dateipfad=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL-Protokoll löschen: 368
[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL-Protokoll löschen: 369

Hinweis: Drop Column ist ein DDL vom Typ „Kopierer“. Die grundlegende Logik besteht darin, eine temporäre Tabelle zu erstellen, die Daten zu kopieren und dann eine Umbenennungsoperation durchzuführen. Es umfasst im Wesentlichen vier Phasen:

1. Vorbereitungsphase: Der Vorgang zum Erstellen einer temporären Tabelle ähnelt dem DDL-Protokollvorgang beim Tabellenerstellungsprozess. Das Einfügeprotokoll wird direkt als separate Transaktion übermittelt, und das Löschprotokoll ist Teil der gesamten Transaktion.

Wenn in dieser Phase eine Ausnahme auftritt, verbleiben Datensätze zum Rückwärtsvorgang in der DDL-Protokolltabelle, die bei der Wiedergabe während der Absturzwiederherstellung bereinigt werden können.

2. Durchführungsphase: Das Kopieren der Daten ist abgeschlossen und die Online-DDL-Logik ist implementiert.

3. Nach dem Kopieren der Daten müssen Sie eine Umbenennungsoperation durchführen, um den Tabellennamen auszutauschen.

1) DROP, löscht die temporäre Tabelle

2) RAUM/TABELLE UMBENENNEN. ./mysql/#sql-ib1130-2815969726.ibd in dd_tt.idb umbenennen.

3)REANAME SPACE/TABLE Benennen Sie dd_tt.idb um in /#sql-ib1129-2815969725.idb

4) Zeichnen Sie den Vorgang zum Löschen der alten Tabelle sql-ib1130-2815969726.ibd auf und führen Sie die eigentliche Löschung in der Post-DDL-Phase durch.

Wenn in dieser Phase eine Ausnahme auftritt, ist dasselbe Einfügeprotokoll eine separate Transaktion und das Löschen ist Teil der gesamten Transaktion. Das Einfügeprotokoll verbleibt in der DDL-Protokolltabelle. Sie können es durch erneutes Abspielen bereinigen, die dd_tt-Daten wiederherstellen und die temporäre Tabelle #sql-ib1130-2815969726.ibd bereinigen.

4. Post-DDL-Phase:

1). Löschen Sie physisch die alte Datei ./mysql/#sql-ib1130-2815969726.ibd

2). Bereinigen Sie die relevanten Informationen in mysql.innodb_dynamic_metadata.

Es ist zu beachten, dass die in der DDL-Protokolltabelle gespeicherten Inhalte tatsächlich in umgekehrter Reihenfolge verarbeitet werden und daher beim Sammeln von DDL-Protokollen tatsächlich in umgekehrter Reihenfolge gesammelt und wiedergegeben werden.

4.7 Tabelle abschneiden

Anweisung: truncate table dd_tt;

Aufschlüsselung der Aussagen:

1. dd_tt in #sql-ib1130-2815969727 umbenennen;

[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: RENAME SPACE, ID=372, Thread-ID=23, Space-ID=73, alter Dateipfad=./mysql/#sql-ib1130-2815969727.ibd, neuer Dateipfad=./mysql/dd_tt.ibd
[InnoDB] DDL-Protokoll löschen: 372

2.Tabelle löschen #sql-ib1130-2815969727;

[InnoDB] DDL-Protokoll einfügen: [DDL-Datensatz: DROP, ID=373, Thread-ID=23, Tabellen-ID=1130]     
[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd]

3. Tabelle dd_tt erstellen;

[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: DELETE SPACE, ID=375, Thread-ID=23, Space-ID=74, alter Dateipfad=./mysql/dd_tt.ibd]     
[InnoDB] DDL-Protokoll löschen: 375
[InnoDB] DDL-Protokoll einfügen: [DDL-Eintrag: CACHE ENTFERNEN, ID=376, Thread-ID=23, Tabellen-ID=1131, neuer Dateipfad=mysql/dd_tt]      
[InnoDB] DDL-Protokoll löschen: 376
[InnoDB] DDL-Log einfügen: [DDL-Eintrag: FREE, id=377, thread_id=23, space_id=74, index_id=235, page_no=4]         
[InnoDB] DDL-Protokoll löschen: 377
[InnoDB] DDL-Log-Beitrag ddl: Beginn für Thread-ID: 23                      
[InnoDB] DDL-Protokollwiedergabe: [DDL-Eintrag: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd] 
[InnoDB] DDL-Protokollwiedergabe: [DDL-Datensatz: DROP, ID=373, Thread-ID=23, Tabellen-ID=1130]    

[InnoDB] DDL-Log-Beitrag ddl: Ende für Thread-ID: 23

veranschaulichen:

1. Benennen Sie dd_tt in sql-ib1130-2815969727 um

2. Markieren Sie die Tabelle sql-ib1130-2815969727 zum Löschen. Sie wird tatsächlich in der Post-DDL-Phase gelöscht.

3. Erstellen Sie eine neue Tabelle dd_tt. Derselbe Einfügevorgang wird als separate Transaktion übermittelt, und der Löschvorgang ist Teil der gesamten Transaktion. Wenn ein Rollback durchgeführt wird, bleibt der Einfügevorgang bestehen und wird durch die Wiedergabeaktion bereinigt.

5.DDL-Operationscodestapel

5.1 Tabelle erstellen

Sql_cmd_create_table::ausführen
-->mysql_erstelle_tabelle
 -->mysql_create_table_no_lock
  -->Tabelle erstellen_impl
  -->Basistabelle erstellen
   -->ha_Tabelle erstellen
    -->ha_erstellen
     -->ha_innobase::erstellen
     -->innobase_basic_ddl::erstellen_impl
      -->Tabelleninfo_t erstellen::Tabelle erstellen
      {
       ......
      }
 -->trans_commit_implicit
  -->ha_commit_trans
  -->MYSQL_BIN_LOG::vorbereiten
   -->ha_prepare_low //Alle Transaktions-Engines bereiten sich vor
    {
    binlog_prepare
    innobase_xa_prepare
    }
  -->MYSQL_BIN_LOG::commit
   -->MYSQL_BIN_LOG::ordered_commit
    -->MYSQL_BIN_LOG::Prozess_Flush_Stage_Queue
     -->MYSQL_BIN_LOG::flush_thread_caches
     -->binlog_cache_mngr::flush
      -->binlog_cache_data::flush
       -->MYSQL_BIN_LOG::write_gtid
        -->Log_event::schreiben
        -->MYSQL_BIN_LOG::Binlog_ofile::write //Binlog-gtid schreiben
       -->MYSQL_BIN_LOG::write_cache
        --> MYSQL_BIN_LOG::do_write_cache
         -->Binlog_cache_storage::kopieren_nach
         -->stream_kopie
          -->Binlog_event_writer::schreiben
           -->MYSQL_BIN_LOG::Binlog_ofile::write //Binlog-DDL-Anweisung schreiben -->MYSQL_BIN_LOG::sync_binlog_file
    -->MYSQL_BIN_LOG::Prozess-Commit-Stage-Warteschlange
     -->ha_commit_low
     {
      binlog_commit
      innobase_commit
      -->trx_commit_für_mysql
       -->trx_commit
        -->trx_commit_low
         -->trx_commit_in_memory
         -->trx_undo_insert_cleanup
     }
 -->innobase_post_ddl(ht->post_ddl(thd))
  -->Log_DDL::post_ddl
  -->Wiedergabe nach Thread-ID


-->Tabelleninfo_t erstellen::Tabelle erstellen
 -->Tabellendefinition erstellen
  -->dict_mem_table_create //InnoDB-Speicher als Dictionary-Speicherobjekt erstellen -->row_create_table_for_mysql
  -->dict_build_table_def
   -->dict_build_tablespace_for_table
    -->Erstellen Sie eine neue xxx.idb-Datei-->Log_DDL::write_delete_space_log
    {
     -->Log_DDL::Speicherplatzprotokoll einfügen_löschen
     -->trx_start_internal //Transaktion intern starten und separat übermitteln.
     -->DDL_Record erstellen (DELETE_SPACE_LOG)
     -->DDL_Log_Table::insert (physischen B-Baum schreiben)
     -->Log_DDL:delete_by_id //Löschen Sie den ddl_log-Vorgang als Teil der DDL-Transaktion.
    }
    -->fil_ibd_create
    -->Segment, Umfang, Seite initialisieren
  -->Log_DDL::cache_log_schreiben_entfernen
  -->Log_DDL::insert_remove_cache_log
  -->Log_DDL::löschen_nach_id
 -->create_index (Primärtabelle, Sekundärindex)
  -->dict_erstellt_Indexbaum_im_Speicher
  -->btr_erstellen
  -->Log_DDL::Freischreiben_des_Baumprotokolls
   -->Log_DDL::freies_Baumprotokoll_einfügen
   -->Log_DDL:Löschen_nach_ID<br>
Absturzwiederherstellung
 -->ha_post_recover
  -->post_recover_handlerton
    -->innobase_post_recover
     -->Log_DDL::wiederherstellen
      -->Log_DDL::alles_wiedergeben
       -->Log_DDL::Wiedergabe
        {
         replay_delete_space_log
         Cache-Protokoll erneut abspielen und entfernen
         replay_free_tree_log
         ......
        }
       -->nach_IDs_löschen
        -->DDL_Log_Table::entfernen

5.2 Drop-Tabelle

mysql_rm_table
 -->mysql_rm_table_no_locks
  -->Basistabelle löschen
   -->ha_delete_table
    -—>handler::ha_delete_table
     -->ha_innobase::Tabelle löschen
     -->innobase_basic_ddl::delete_impl
      -->Zeilenablagetabelle für MySQL
       -->Log_DDL::write_drop_log // Löschung des innodb_dynamic_metadata-Protokolls aufzeichnen-—>Log_DDL::write_delete_space_log // Löschung des ibd-Protokolls aufzeichnen-->dd::drop_table
    -->dd::cache::Dictionary_client::drop<dd::Tabelle>
     -->dd::cache::Storage_adapter::drop<dd::Tabelle>
      -->dd::sdi::fallen lassen
  -->innobase_post_ddl
   -->Log_DDL::post_ddl
    -->Log_DDL::Wiedergabe nach Thread-ID
     -->Log_DDL::Wiedergabe
      —>Log_DDL::replay_delete_space_log // post-ddl löscht tatsächlich innodb_dynamic_metadata
      —>Log_DDL::replay_drop_log // post-ddl löscht tatsächlich ibd
     -->nach_IDs_löschen
      -->DDL_Log_Table::entfernen

Beim Löschen einer Tabelle wird nur das Löschaktionsprotokoll aufgezeichnet. Diese Protokolle sind Teil der gesamten Transaktion. Wenn die Transaktion endgültig festgeschrieben wird, liest die Phase „post_ddl“ das Protokoll, um die Tabelle tatsächlich zu löschen. Wenn die Transaktion zurückgesetzt wird, wird das DDL-Protokoll ebenfalls als Teil der Transaktion zurückgesetzt.

Referenzdokumentation

https://dev.mysql.com/worklog/task/?id=9045

https://dev.mysql.com/worklog/task/?id=9173

https://dev.mysql.com/worklog/task/?id=9175

https://dev.mysql.com/worklog/task/?id=9525

https://dev.mysql.com/worklog/task/?id=9536

Zusammenfassen

Oben finden Sie eine Einführung in die Atomizitätseigenschaften und Implementierungsprinzipien von MySQL 8.0 DDL durch den Herausgeber. Ich hoffe, dass es für alle hilfreich sein wird. Wenn Sie Fragen haben, hinterlassen Sie mir bitte eine Nachricht und der Herausgeber wird Ihnen rechtzeitig antworten. Ich möchte auch allen für ihre Unterstützung der Website 123WORDPRESS.COM danken!
Wenn Sie diesen Artikel hilfreich finden, können Sie ihn gerne abdrucken und dabei bitte die Quelle angeben. Vielen Dank!