MySQL 8.0 アトミック DDL 構文の詳細な説明

01 アトミックDDLの紹介

アトミック DDL ステートメントは、DDL 操作に関連付けられたデータ ディクショナリの更新、ストレージ エンジン操作、およびバイナリ ログ書き込みを 1 つのアトミック操作に結合します。操作はコミットされ、データ ディクショナリ、ストレージ エンジン、およびバイナリ ログへの適用可能な変更が保持されるか、ロールバックされます。

MySQL 8.0 では、アトミック DDL 操作機能により、テーブルの作成やテーブルの削除などのテーブル関連の操作だけでなく、ルーチンの作成やトリガーの削除などのテーブルに関連しない操作もサポートされます。

で：

サポートされているテーブル操作は次のとおりです。

削除、作成、変更（操作対象はデータベース、表領域、表、索引）構文、切り捨て構文

サポートされている非テーブル操作は次のとおりです。

作成、削除、変更 (操作オブジェクトはトリガー、イベント、ビューなど)

アカウント管理ステートメント: ユーザーとロールの作成、変更、削除、名前変更ステートメント、および許可と取り消しステートメント

テーブル関連の DDL 操作の場合、ストレージ エンジンは Innodb である必要があることに注意してください。テーブルに関連しない操作の場合、そのような要件はありません。

一部の SQL ステートメントはアトミック DDL をサポートしていません。次に例を示します。

1. Innodb以外のストレージエンジンのテーブル操作

2. プラグインのインストールとアンインストールの操作（プラグインのインストール）

3. installcomponent および uninstallcomponent ステートメント

4. サーバーの作成、サーバーの変更、サーバーの削除のステートメント (このステートメントは FEDERATED ストレージ エンジンによって使用され、一時的に無視できます)

02 一部のDDL操作の実行動作の変更

アトミック操作の実行動作の変更は、データ ディクショナリの編成構造の変更に関連しています。MySQL 8.0 より前では、データ ディクショナリは、.FRM、.TRG、および .OPT ファイルに加えて、システム テーブル (MyISAM 非トランザクション エンジン テーブル) に存在していました。MySQL 8.0 では、データ ディクショナリは完全にデータ ディクショナリ ストレージ エンジン (つまり、InnoDB テーブル) 内に存在するため、クラッシュ リカバリ時にアトミック性を維持できます。次の図は、データ辞書の構造の変更を示しています。

MySQL 8.0 より前のデータ辞書の構造は次のとおりでした。

MySQL 8.0 以降、データ ディクショナリは次のようになります。

2 つの具体的な構文の変更点を見てみましょう。

（１）Drop構文の変更：

データベースに test1 というテーブルを作成しますが、test2 というテーブルは作成しません。次に、drop table test1, test2 を実行して結果を確認します。

MySQL 5.7 のパフォーマンス:

mysql> テーブル test1(id int) を作成します。
クエリは正常、影響を受けた行は 0 行 (0.01 秒)

mysql> テーブルを表示します。
+----------------+
| テーブル_in_yeyz |
+----------------+
| t1 |
| t2 |
| t3 |
| テスト1 |
+----------------+
セット内の 4 行 (0.00 秒)

mysql> テーブル test1、test2 を削除します。
エラー 1051 (42S02): 不明なテーブル 'yeyz.test2'
mysql> テーブルを表示します。
+----------------+
| テーブル_in_yeyz |
+----------------+
| t1 |
| t2 |
| t3 |
+----------------+
セット内の 3 行 (0.00 秒)

MySQL 8.0 のパフォーマンス:

mysql> テーブル test1(id int) を作成します。
クエリは正常、影響を受けた行は 0 行 (0.17 秒)

mysql> テーブルを表示します。
+----------------+
| テーブル_in_yeyz |
+----------------+
| テスト1 |
+----------------+
セット内の 1 行 (0.00 秒)

mysql> テーブル test1、test2 を削除します。
エラー 1051 (42S02): 不明なテーブル 'yeyz.test2'
mysql> テーブルを表示します。
+----------------+
| テーブル_in_yeyz |
+----------------+
| テスト1 |
+----------------+
セット内の 1 行 (0.00 秒)

MySQL 8.0 では、test2 がない場合、test1 テーブルは削除されず、ステートメント全体が完全にロールバックされますが、MySQL 5.7 では、test1 テーブルが誤って削除され、ステートメント全体が完全にロールバックされないことがわかります。

処理メカニズムの違いにより、MySQL 5.7 と MySQL 8.0 をマスタースレーブレプリケーションに使用する場合、上記と同様のステートメントを使用するとエラーが発生します。実行動作が異なるためです。この問題を解決するには、drop table if not exists 構文を使用する必要があります。同様に、drop database や drop trigger などの一連の操作の処理方法も同様です。注目すべきもう 1 つの点は、データベース内のすべてのテーブルが InnoDB である場合、データベースの削除はアトミックですが、そうでない場合は、データベースの削除はアトミックではないということです。

（2）テーブルの作成...構文を選択:

MySQL 8.0.21 以降、アトミック DDL をサポートするストレージ エンジンでは、行ベースのレプリケーション モードを使用すると、CREATE TABLE ... SELECT ... ステートメントがトランザクションとしてバイナリ ログに記録されます。以前のバージョンでは、テーブルの作成とデータの挿入の 2 つのトランザクションとして記録されていました。トランザクション間またはデータの挿入中にサーバー障害が発生すると、空のテーブルがコピーされる可能性があります。アトミック DDL サポートの導入により、CREATE TABLE ... SELECT ステートメントは行ベースのレプリケーションに対して安全になり、GTID ベースのレプリケーションでも使用できるようになりました。

03 DDL 操作のログを表示するにはどうすればいいですか?

DDL 操作のやり直しとロールバックをサポートするために、InnoDB は DDL ログを mysql.innodb_ddl_log テーブルに書き込みます。このテーブルはデータ ディクショナリ テーブルスペースに存在します。ユーザーがこのテーブルの内容を表示する場合は、パラメータをオンにする必要があります。

mysql> '%innodb_print_ddl_logs%' のような変数を表示します。 
+-----------------------+-------+
| 変数名 | 値 |
+-----------------------+-------+
| innodb_print_ddl_logs | オフ |
+-----------------------+-------+
セット内の1行（0.01秒）

その後、エラー ログで DDL 操作のログを確認できます。関連するログは次のとおりです。

[注記] [000000] InnoDB: DDL ログ挿入: [DDL レコード: DELETE SPACE、id=18、thread_id=7、
スペースID=5、古いファイルパス=./test/t1.ibd]
[注記] [000000] InnoDB: DDL ログ削除: ID 18
[注記] [000000] InnoDB: DDL ログ挿入: [DDL レコード: REMOVE CACHE、id=19、thread_id=7、
テーブルID=1058、新しいファイルパス=test/t1]
[注記] [000000] InnoDB: DDL ログ削除: ID 19
[注記] [000000] InnoDB: DDL ログ挿入: [DDL レコード: FREE、id=20、thread_id=7、
スペースID=5、インデックスID=132、ページ番号=4]
[注記] [000000] InnoDB: DDL ログ削除: ID 20 による
[注記] [000000] InnoDB: DDL ログ post ddl: スレッド ID: 7 の開始
[注記] [000000] InnoDB: DDL ログ post ddl: スレッド ID の終了: 7

mysql.innodb_ddl_log テーブルのフラッシュタイミングは、innodb_flush_logs_at_trx_commit パラメータの影響を受けません。これは、DDL 操作によってデータ ファイルが変更されたが、対応する REDO ログがディスクにフラッシュされておらず、リカバリまたはロールバック中にエラーが発生する状況を回避するために行われます。

最後に、アトミック DDL 操作全体の段階を紹介します。

1. 準備フェーズ: 必要なオブジェクトを作成し、DDL ログを mysql.innodb_ddl_log テーブルに書き込みます。DDL ログは、DDL 操作をロールフォワードおよびロールバックする方法を定義します。

2. 実行フェーズ: DDLを実行する運用プロセス

3. コミットフェーズ: データディクショナリを更新し、データディクショナリトランザクションをコミットする

4. DDL 後フェーズ: mysql.innodb_ddl_log テーブルから DDL ログを再生して削除します。不整合を生じさせることなくロールバックを安全に実行できるようにするために、データ ファイルの名前変更や削除などのディスク上のファイル操作がこの最終フェーズで実行されます。このフェーズでは、 DROP TABLE 、 TRUNCATE TABLE 、およびテーブルを再構築するその他の DDL 操作で使用するために、 mysql.innodb_dynamic_metadata データ ディクショナリ テーブルから動的メタデータも削除されます。

以上がMySQL 8.0のアトミックDDL構文の詳細な説明です。MySQL 8.0のアトミックDDL構文の詳細については、123WORDPRESS.COMの他の関連記事に注目してください。