はじめに
皆さん、こんにちは。株式会社BTMの風間と申します。
MySQL8.0のGTIDについて確認する機会があったので、その時の内容を書きたいと思います。
GTIDを確認したきっかけ
開発中の動作確認をするにあたり、「DBの状態をある時点に繰り返し戻したい」ということがありました。
mysqldumpしたファイルを都度インポートしようと考えたのですが、mysqldumpで次のWarningが出てきました。
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.
Warning: A dump from a server that has GTIDs enabled will by default include the GTIDs of all transactions, even those that were executed during its extraction and might not be represented in the dumped data. This might result in an inconsistent data dump.
この時、「GTIDって何？」「Warningがでたダンプファイルを利用していいの？」と思い、GTIDを調べることにしました。
GTIDについて
MySQLのドキュメントやネットを検索してみたところ、GTIDは次のような内容となります。
GTIDとは
- Global Transaction Identiferの略
- 発生元のサーバー (ソース) でコミットされた各トランザクションに作成および関連付けられる一意の識別子
- GTID は次に示すように、コロン文字 (:) で区切られている
GTID = source_id:transaction_id
※source_id：発生元サーバーを識別するUUIDで起動時に自動生成される
※transaction_id：コミットされたトランザクション順のシーケンス番号 - GTIDセットは、1つ以上のGTIDまたはGTID の範囲で構成される
- GTIDを使うには、gtid_modeをONにする（デフォルトはOFF）
※gtid_mode=ONにする場合、合わせてenforce_gtid_consistencyをON（GTIDの整合性を強制化）にする（ON以外に設定できない） - GTIDはMySQL システムテーブル mysql.gtid_executed に保持される
- GTIDはバイナリログに出力される
バイナリログについて
- テーブル作成操作やテーブルデータへの変更などのデータベース変更を記述する「イベント」が格納される
- データを変更しないSELECTやSHOWなどのステートメントでは使用されない
- バイナリログはデフォルトでONになっている
- デフォルトは/var/mysql/libの直下にbinlog.xxxxxxというファイルで出力される
- SHOW BINARY LOGSでバイナリログのファイル一覧を確認できる
- SHOW MASTER STATUSで現在のバイナリログのファイル名が分かる
- SHOW BINLOG EVENTS IN 'バイナリログのファイル名' でバイナリログの一部を確認できる
- バイナリログを完全に見るにはmysqlbinlogを利用する
GTID/バイナリログの使われ方
- レプリケーション構成時に利用される
- ソースで記録されたバイナリログをレプリカが受け取り適用することで、ソースと同じデータを持つレプリカが実現できる
- ソースとレプリカで同じGTIDを持つことで、レプリカにどこまでソースが反映されたか、ソースのどこから反映するかなどを管理する
- ポイントタイムリカバリ時に利用される
- リカバリするサーバーの特定の状態の指定にGTIDを使う
- 指定された箇所までロールフォワードするためにバイナリログを使う
参考
- GTID：https://dev.mysql.com/doc/refman/8.0/ja/replication-gtids-concepts.html
- バイナリログ：https://dev.mysql.com/doc/refman/8.0/ja/binary-log.html
GTIDを確認してみる
百聞は一見にしかず、ということで、実際にGTIDについて確認していきます。
確認する内容
- gtid_modeをONにする
- gtid_mode=ONの時にGTIDが記録されているか。バイナリログに出力されているか
- gtid_mode=OFFの時にGTIDが記録されていないか。バイナリログに出力されてないか
- GTIDは一意なのか
検証環境
ローカルで確認するだけなので、MySQLをrootユーザー・パスワードなしで利用しています。実際の開発や運用では絶対にやめましょう。
確認はwsl2でdockerを利用して行います。
OS:Widdows11 Pro（24H2）
wslバージョン： 2.4.10.0
ディストリビューション：Ubuntu（22.04.2 LTS）
docker：27.5.1
MySQL：8.0.41（Dockerイメージ mysql:8.0.41-debianを利用）
docker composeを実行するフォルダ構成
├ compose.yml
└ conf
└my.cnf
compose.ymlの内容
- 3つのコンテナをたてmysqlを稼働させる
- 1番目のコンテナ（mysql_gtid_on1）：gtid_mode=ON。GTIDがあるときの動きの確認に利用
- 2番目のコンテナ（mysql_gtid_on2）：gtid_mode=ON。1番目と比較してGTIDが一意であるかの確認に利用
- 3番目のコンテナ（mysql_gtid_off）：gtid_mode=OFF（デフォルト）。GTIDがない時の動きの確認に利用
- MySQLでtestというスキーマを作成する
- my.cnfを利用してMySQLのgtid_modeとenforce_gtid_consistencyをONにする
services:
db1:
image: mysql:8.0.41-debian
container_name: mysql_gtid_on1
restart: always
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
MYSQL_DATABASE: "test"
TZ: "Asia/Tokyo"
ports:
- 13306:3306
volumes:
- ./conf/my.cnf:/etc/my.cnf
db2:
image: mysql:8.0.41-debian
container_name: mysql_gtid_on2
restart: always
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
MYSQL_DATABASE: "test"
TZ: "Asia/Tokyo"
ports:
- 23306:3306
volumes:
- ./conf/my.cnf:/etc/my.cnf
db3:
image: mysql:8.0.41-debian
container_name: mysql_gtid_off
restart: always
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
MYSQL_DATABASE: "test"
TZ: "Asia/Tokyo"
ports:
- 33306:3306
./conf/my.cnfの内容
[mysqld]
enforce_gtid_consistency=true
gtid_mode=ON
本記事でのコマンドやSQLの記述について
コンテナ内でのコマンド実行は以下と記載します。※各コンテナ内の接続方法は後述
# <コマンド>
MySQLでのSQL実行は下記内容で記述します。※MySQLへの接続方法は後述
mysql> <SQL>
WSL2上でのコマンド実行は下記内容で記述します。
% <コマンド>
また、本記事では説明で利用するために、コマンドの出力結果の先頭に「★」印＋番号をつけている箇所があります。
# ls | grep *.txt
★1 sample1.txt
sample2.txt
検証環境の起動
上記のcompose.ymlを利用してdockerを立ち上げます。
% sudo docker compose up -d
コンテナへの接続
各コンテナに接続する時は以下のコマンドを実行します。
コンテナ1
% sudo docker exec -it mysql_gtid_on1 /bin/bash
コンテナ2
% sudo docker exec -it mysql_gtid_on2 /bin/bash
コンテナ3
% sudo docker exec -it mysql_gtid_off /bin/bash
MySQLへの接続
各コンテナでMySQLに接続する時は以下を実行します。
# mysql -u root -p -h localhost test
GTIDが記録されているか確認してみる
検証環境の準備が整ったので、各コンテナに接続し、gtid_modeがONになっているか、GTIDが記録されているか、バイナリログが出力されているかを確認していきます。
コンテナ１（mysql_gtid_on1）で確認
コンテナ1に接続し、gtid_modeがONになっているか確認してみます。
mysql> SELECT @@gtid_mode;
+-------------+
| @@gtid_mode |
+-------------+
| ON |
+-------------+
ONになってることが確認できました。次にGTIDが記録されているか確認します。
mysql> SELECT * FROM mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| f2a09049-e78c-11ef-8ff8-0242ac120002 | 1 | 6 |
+--------------------------------------+----------------+--------------+
GTIDが記録されているのが分かりました。
source_uuidがGTIDの構成にあるserver_idで、interval_startとintarval_endがtransaction_idになります。1番から6番まで進んでいます。
次にバイナリログファイルの一覧を確認してみます。
mysql> SHOW BINARY LOGS;
+---------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000001 | 2942501 | No |
| binlog.000002 | 197 | No |
+---------------+-----------+-----------+
binlog.000001とbinlog.0000002という２つのファイルを確認できました。
現在進行中のバイナリログファイルを調べてみます。
mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+------------------------------------------+
| binlog.000002 | 197 | | | f2a09049-e78c-11ef-8ff8-0242ac120002:1-6 |
+---------------+----------+--------------+------------------+------------------------------------------+
進行しているのがbinlog.000002であることが分かりました。
バイナリログbinlog.000002の内容を確認してみます。
mysql> SHOW BINLOG EVENTS IN 'binlog.000002';
+---------------+-----+----------------+-----------+-------------+------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+-----+----------------+-----------+-------------+------------------------------------------+
| binlog.000002 | 4 | Format_desc | 1 | 126 | Server ver: 8.0.41, Binlog ver: 4 |
| binlog.000002 | 126 | Previous_gtids | 1 | 197 | f2a09049-e78c-11ef-8ff8-0242ac120002:1-6 |
+---------------+-----+----------------+-----------+-------------+------------------------------------------+
ここでは詳しく内容はみませんが、ログが記録されていることが分かりました。
実際にバイナリログのファイルが存在しているか確認してみます。
# ls /var/lib/mysql/ | grep binlog
binlog.000001
binlog.000002
binlog.index
実際のファイルbinlog.000001とbinlog.000002の存在を確認できました。
では、ファイルbinlog.000002をmysqlbinlogで覗いてみます。
# mysqlbinlog /var/lib/mysql/binlog.000002
# The proper term is pseudo_replica_mode, but we use this compatibility alias
# to make the statement usable on server versions 8.0.24 and older.
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#250210 17:56:55 server id 1 end_log_pos 126 CRC32 0xfbac1441 Start: binlog v 4, server v 8.0.41 created 250210 17:56:55 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
V7+pZw8BAAAAegAAAH4AAAABAAQAOC4wLjQxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABXv6lnEwANAAgAAAAABAAEAAAAYgAEGggAAAAICAgCAAAACgoKKioAEjQA
CigAAUEUrPs=
'/*!*/;
# at 126
★1 #250210 17:56:55 server id 1 end_log_pos 197 CRC32 0xb6d23ddb Previous-GTIDs
★2 # f2a09049-e78c-11ef-8ff8-0242ac120002:1-6
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
詳しい内容はここでは見ませんが、バイナリログの内容を見ることができました。
また、★の箇所を見ると、Previous-GTIDsにGTIDセット「f2a09049-e78c-11ef-8ff8-0242ac120002:1-6」が出力されていることが分かります。
ここまでで、コンテナ1ではgtid_modeがONで、GTIDが記録され、バイナリログが出力されていることを確認できました。
コンテナ2（mysql_gtid_on2）で確認
今度はコンテナ2で確認してみます。
※コンテナ1とほぼ変わらないので、ここではGTIDが違うかだけ確認してみます。
mysql> SELECT * FROM mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| f2a12894-e78c-11ef-84e5-0242ac120004 | 1 | 6 |
+--------------------------------------+----------------+--------------+
GTIDセットが記録されており、source_uuidがコンテナ1と違うことが確認できました。
GTIDは一意であることが分かります（コンテナを作り直すとsource_uuidが変わります、興味ある方は試してみてください）。
コンテナ3（mysql_gtid_off）で確認
次は、gtid_modeがOFFの時の状態をコンテナ3で確認してみます。
gtid_modeがOFFになっているか確認します。
mysql> SELECT @@gtid_mode;
+-------------+
| @@gtid_mode |
+-------------+
| OFF |
+-------------+
OFFになってることが確認できました。
GTIDが記録されているのか確認します。
mysql> SELECT * FROM mysql.gtid_executed;
Empty set (0.00 sec)
何も表示されず、GTIDが記録されていないことが分かりました。
バイナリログファイルの一覧を確認してみます。
mysql> SHOW BINARY LOGS;
+---------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000001 | 2942501 | No |
| binlog.000002 | 157 | No |
+---------------+-----------+-----------+
gtid_mode=ONの時と同じく、バイナリログはあることが分かりました。
バイナリログbinlog.000002の内容を確認してみます。
mysql> SHOW BINLOG EVENTS IN 'binlog.000002';
+---------------+-----+----------------+-----------+-------------+-----------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+-----+----------------+-----------+-------------+-----------------------------------+
| binlog.000002 | 4 | Format_desc | 1 | 126 | Server ver: 8.0.41, Binlog ver: 4 |
| binlog.000002 | 126 | Previous_gtids | 1 | 157 | |
+---------------+-----+----------------+-----------+-------------+-----------------------------------+
バイナリログの内容を見ることができました。コンテナ1では2行目のInfoにGTIDの記載がありましたが、ここではありません。GTIDが出力されていないのが分かります。
バイナリログのファイルの存在を確認してみます。
# ls /var/lib/mysql/ | grep binlog
binlog.000001
binlog.000002
binlog.index
バイナリログのファイルがありました。では、ファイルを覗いてみます。
# mysqlbinlog /var/lib/mysql/binlog.000002
# The proper term is pseudo_replica_mode, but we use this compatibility alias
# to make the statement usable on server versions 8.0.24 and older.
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#250210 17:56:55 server id 1 end_log_pos 126 CRC32 0xfbac1441 Start: binlog v 4, server v8.0.41 created 250210 17:56:55 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
BINLOG '
V7+pZw8BAAAAegAAAH4AAAABAAQAOC4wLjQxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABXv6lnEwANAAgAAAAABAAEAAAAYgAEGggAAAAICAgCAAAACgoKKioAEjQA
CigAAUEUrPs=
'/*!*/;
# at 126
★1 #250210 17:56:55 server id 1 end_log_pos 157 CRC32 0xbc8c2d8e Previous-GTIDs
★2 # [empty]
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
バイナリログの内容を見ることができました。★の箇所を見ると、コンテナ1と違い、Previous-GTIDsが#emptyになっています。ここでも、GTIDが出力されていないのが分かります。
実際にDBの操作をしてGTIDがどうなるか確認してみる
次にSQLを実行することで、GTIDやバイナリログがどうなるかを各コンテナで試してみます。
※なお、ここから先のコマンドの実行結果は、上記で記載した結果の差分のみを記載しています。
準備
各コンテナで以下のSQLを実行して、データが登録されているか確認しておきます。
mysql> CREATE TABLE sample (
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY(id)
);
mysql> INSERT INTO sample VALUES ();
mysql> SELECT * FROM sample;
+----+
| id |
+----+
| 1 |
+----+
コンテナ１（mysql-gtid-on1）で確認
SQLを実行したことでバイナリログがどうなったかを確認してみます。
mysql> SHOW BINLOG EVENTS IN 'binlog.000002';
+---------------+-----+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+-----+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------+
| binlog.000002 | 197 | Gtid | 1 | 274 | SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:7' |
★1 | binlog.000002 | 274 | Query | 1 | 437 | use `test`; CREATE TABLE sample ( id INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(id)) /* xid=40 */ |
| binlog.000002 | 437 | Gtid | 1 | 516 | SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:8' |
★2 | binlog.000002 | 516 | Query | 1 | 591 | BEGIN |
| binlog.000002 | 591 | Table_map | 1 | 643 | table_id: 94 (test.sample) |
| binlog.000002 | 643 | Write_rows | 1 | 683 | table_id: 94 flags: STMT_END_F |
| binlog.000002 | 683 | Xid | 1 | 714 | COMMIT /* xid=41 */ |
+---------------+-----+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------+
新しい行が追加されています。★1の箇所を見るとEventy_typeがQueryで、InfoにCREATE文が記載されています。SQLの実行のログが残っているようです。
ただ、INSERTとSELECTは記録されていないようです。★2の箇所もEvent_typeがQueryなので、このあたりがINSERTだと思うのですが、内容が分からなくなっています。
SHOW BINLOG EVENTSでは全て表示されないようなので、バイナリログを直接見てみます。
# mysqlbinlog /var/lib/mysql/binlog.000002
# at 197
#250210 18:11:48 server id 1 end_log_pos 274 CRC32 0xe0b84d4d GTID last_committed=0 sequence_number=1 rbr_only=no original_committed_timestamp=1739178708989648 immediate_commit_timestamp=1739178708989648 transaction_length=240
# original_commit_timestamp=1739178708989648 (2025-02-10 18:11:48.989648 JST)
# immediate_commit_timestamp=1739178708989648 (2025-02-10 18:11:48.989648 JST)
/*!80001 SET @@session.original_commit_timestamp=1739178708989648*//*!*/;
/*!80014 SET @@session.original_server_version=80041*//*!*/;
/*!80014 SET @@session.immediate_server_version=80041*//*!*/;
SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:7'/*!*/;
# at 274
#250210 18:11:48 server id 1 end_log_pos 437 CRC32 0x38502ef7 Query thread_id=11 exec_time=0 error_code=0 Xid = 40
use `test`/*!*/;
SET TIMESTAMP=1739178708/*!*/;
SET @@session.pseudo_thread_id=11/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
★1 CREATE TABLE sample (
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY(id)
)
/*!*/;
# at 437
#250210 18:11:54 server id 1 end_log_pos 516 CRC32 0x5a171389 GTID last_committed=1 sequence_number=2 rbr_only=yes original_committed_timestamp=1739178714089247 immediate_commit_timestamp=1739178714089247 transaction_length=277
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1739178714089247 (2025-02-10 18:11:54.089247 JST)
# immediate_commit_timestamp=1739178714089247 (2025-02-10 18:11:54.089247 JST)
/*!80001 SET @@session.original_commit_timestamp=1739178714089247*//*!*/;
/*!80014 SET @@session.original_server_version=80041*//*!*/;
/*!80014 SET @@session.immediate_server_version=80041*//*!*/;
SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:8'/*!*/;
# at 516
#250210 18:11:54 server id 1 end_log_pos 591 CRC32 0xc94f8845 Query thread_id=11 exec_time=0 error_code=0
SET TIMESTAMP=1739178714/*!*/;
BEGIN
/*!*/;
# at 591
#250210 18:11:54 server id 1 end_log_pos 643 CRC32 0xcb975985 Table_map: `test`.`sample` mapped to number 94
# has_generated_invisible_primary_key=0
# at 643
#250210 18:11:54 server id 1 end_log_pos 683 CRC32 0x3b741dc7 Write_rows: table id 94 flags: STMT_END_F
★2 BINLOG '
2sKpZxMBAAAANAAAAIMCAAAAAF4AAAAAAAEABHRlc3QABnNhbXBsZQABAwAAAQEAhVmXyw==
2sKpZx4BAAAAKAAAAKsCAAAAAF4AAAAAAAEAAgAB/wABAAAAxx10Ow==
'/*!*/;
# at 683
#250210 18:11:54 server id 1 end_log_pos 714 CRC32 0xc1dc5df7 Xid = 41
COMMIT/*!*/;
★1の箇所にCREATE文があり、それ以降にINSERTやSELECTはないのですが、★2の箇所にBINLOGがあります。BINLOGの内容を確認するためmysqlbinlogにオプション-vをつけてみます。
# mysqlbinlog -v /var/lib/mysql/binlog.000002
BINLOG '
2sKpZxMBAAAANAAAAIMCAAAAAF4AAAAAAAEABHRlc3QABnNhbXBsZQABAwAAAQEAhVmXyw==
2sKpZx4BAAAAKAAAAKsCAAAAAF4AAAAAAAEAAgAB/wABAAAAxx10Ow==
'/*!*/;
### INSERT INTO `test`.`sample`
### SET
### @1=1
BONLOGの下にINSERTが表示されました。このBINLOGがINSERTのログだと分かりました。
SELECTのようなデータを変更しないものはバイナリログに出力されずGTIDも付与されません。
CREATEの前とINSERTの前にSET @@SESSION.GTID_NEXT=がありますが、これがコミット時のGTIDとなっています。
次にバイナリログに出力されていたGTIDがMySQLシステムテーブルに記録されているか確認します。
mysql> SELECT * FROM mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| f2a09049-e78c-11ef-8ff8-0242ac120002 | 7 | 7 |
| f2a09049-e78c-11ef-8ff8-0242ac120002 | 8 | 8 |
+--------------------------------------+----------------+--------------+
GTIDの記録を確認できました。バイナリログと合わせると、transaction_idの7番がCREATE文、8番がINSERT文だと分かります。
コンテナ2（mysql_gtid_on2）で確認
※コンテナ1とコンテナ2ではGTIDが違うだけなので、記載を省きます。
コンテナ3（mysql_gtid_off）で確認
コンテナ1で行った確認をコンテナ3でも実施します。
バイナリログの内容をmysqlから見てみます。
mysql> SHOW BINLOG EVENTS IN 'binlog.000002';
+---------------+-----+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+-----+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------+
★1 | binlog.000002 | 157 | Anonymous_Gtid | 1 | 234 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| binlog.000002 | 234 | Query | 1 | 397 | use `test`; CREATE TABLE sample (id INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(id)) /* xid=11 */ |
★2 | binlog.000002 | 397 | Anonymous_Gtid | 1 | 476 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| binlog.000002 | 476 | Query | 1 | 551 | BEGIN |
| binlog.000002 | 551 | Table_map | 1 | 603 | table_id: 90 (test.sample) |
| binlog.000002 | 603 | Write_rows | 1 | 643 | table_id: 90 flags: STMT_END_F |
| binlog.000002 | 643 | Xid | 1 | 674 | COMMIT /* xid=12 */ |
+---------------+-----+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------+
こちらも実行したSQLの内容が増えています。★の箇所を見るとコンテナ1ではEvent_typeがGTIDだったところが、Anonymous_Gtidとなっています。次にバイナリログをみてみます。
# mysqlbinlog -v /var/lib/mysql/binlog.000002
# at 157
#250210 18:13:27 server id 1 end_log_pos 234 CRC32 0xc896530d Anonymous_GTID last_committed=0 sequence_number=1 rbr_only=no original_committed_timestamp=1739178807869516 immediate_commit_timestamp=1739178807869516 transaction_length=240
# original_commit_timestamp=1739178807869516 (2025-02-10 18:13:27.869516 JST)
# immediate_commit_timestamp=1739178807869516 (2025-02-10 18:13:27.869516 JST)
/*!80001 SET @@session.original_commit_timestamp=1739178807869516*//*!*/;
/*!80014 SET @@session.original_server_version=80041*//*!*/;
/*!80014 SET @@session.immediate_server_version=80041*//*!*/;
★1 SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 234
#250210 18:13:27 server id 1 end_log_pos 397 CRC32 0x03fdb355 Query thread_id=9 exec_time=0 error_code=0 Xid = 11
use `test`/*!*/;
SET TIMESTAMP=1739178807/*!*/;
SET @@session.pseudo_thread_id=9/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
CREATE TABLE sample (
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY(id)
)
/*!*/;
# at 397
#250210 18:13:32 server id 1 end_log_pos 476 CRC32 0x521563e4 Anonymous_GTID last_committed=1 sequence_number=2 rbr_only=yes original_committed_timestamp=1739178812534032 immediate_commit_timestamp=1739178812534032 transaction_length=277
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1739178812534032 (2025-02-10 18:13:32.534032 JST)
# immediate_commit_timestamp=1739178812534032 (2025-02-10 18:13:32.534032 JST)
/*!80001 SET @@session.original_commit_timestamp=1739178812534032*//*!*/;
/*!80014 SET @@session.original_server_version=80041*//*!*/;
/*!80014 SET @@session.immediate_server_version=80041*//*!*/;
★2 SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 476
#250210 18:13:32 server id 1 end_log_pos 551 CRC32 0x2b33eac3 Query thread_id=9 exec_time=0 error_code=0
SET TIMESTAMP=1739178812/*!*/;
BEGIN
/*!*/;
# at 551
#250210 18:13:32 server id 1 end_log_pos 603 CRC32 0x653d071e Table_map: `test`.`sample` mapped to number 90
# has_generated_invisible_primary_key=0
# at 603
#250210 18:13:32 server id 1 end_log_pos 643 CRC32 0x01a5d96d Write_rows: table id 90 flags: STMT_END_F
BINLOG '
PMOpZxMBAAAANAAAAFsCAAAAAFoAAAAAAAEABHRlc3QABnNhbXBsZQABAwAAAQEAHgc9ZQ==
PMOpZx4BAAAAKAAAAIMCAAAAAFoAAAAAAAEAAgAB/wABAAAAbdmlAQ==
'/*!*/;
### INSERT INTO `test`.`sample`
### SET
### @1=1
# at 643
#250210 18:13:32 server id 1 end_log_pos 674 CRC32 0x14f6f65e Xid = 12
COMMIT/*!*/;
CREATEとINSERTがきちんと記録されています。CREATEとINSERTの前の★の箇所にSET @@SESSION.GTID_NEXT=がありますが、値は'ANONYMOUS'となっていて、GTIDは記録されていないようです。
実際にMySQLシステムテーブルにGTIDが記録されていないか確認します。
mysql> mysql> SELECT * FROM mysql.gtid_executed;
Empty set (0.00 sec)
GTIDは記録されていませんでした。
ここまでで、以下を確認できました。
- データ変更があるSQLを実行した時、その内容がバイナリログに出力される
- gtid_mode=ON時はGTIDが付与されバイナリログに出力される
ダンプしたデータを取り込めるのかの確認
GTIDが確認できたので、今回調べたかった「Warningがでたダンプファイル利用していいの？」を確認していきます。
準備
各コンテナのデータの違いが分かるように以下を実行しsampleテーブルの内容を確認しておきます。
コンテナ1
mysql> SELECT * FROM sample;
+----+
| id |
+----+
| 1 |
+----+
コンテナ2
mysql> INSERT INTO sample VALUES ();
mysql> SELECT * FROM sample;
+----+
| id |
+----+
| 1 |
| 2 |
+----+
コンテナ3
mysql> INSERT INTO sample VALUES ();
mysql> INSERT INTO sample VALUES ();
mysql> SELECT * FROM sample;
+----+
| id |
+----+
| 1 |
| 2 |
| 3 |
+----+
各コンテナで以下のコマンドを実行してダンプファイルを作成します。
# mysqldump -u root -p -h localhost test > ~/dump_test.sql
コンテナ2とコンテナ3のダンプファイルをコンテナ1にコピーしておきます。
% sudo docker cp mysql_gtid_on2:/root/dump_test.sql ./dump_test2.sql
% sudo docker cp ./dump_test2.sql mysql_gtid_on1:/root/dump_test2.sql
% sudo docker cp mysql_gtid_off:/root/dump_test.sql ./dump_test3.sql
% sudo docker cp ./dump_test3.sql mysql_gtid_on1:/root/dump_test3.sql
ダンプしたファイルの差分の確認
各コンテナのダンプファイルの違いを見てみます（INSERTしたデータ部分の差分の記載は省略します）。
コンテナ１とコンテナ２の違い
違いは以下となります。GTIDが違うことが分かります。
+ コンテナ1：SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ 'f2a09049-e78c-11ef-8ff8-0242ac120002:1-8';
- コンテナ2：SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ 'f2a12894-e78c-11ef-84e5-0242ac120004:1-9';
コンテナ1とコンテナ3の違い
コンテナ1のダンプファイルにだけ以下があります。
+ SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
+ SET @@SESSION.SQL_LOG_BIN= 0;
+ SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ 'f2a09049-e78c-11ef-8ff8-0242ac120002:1-8';
(省略)
+ SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
内容は以下となります。
- バイナリログの設定を一時保存
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN; - バイナリログ出力をOFFにする
SET @@SESSION.SQL_LOG_BIN= 0; - mysql.gtid_executedにGTIDセットを書き込む
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ 'f2a09049-e78c-11ef-8ff8-0242ac120002:1-8'; - （省略 テーブル作成やデータの登録など各SQLの実行）
- バイナリログの出力をONにする（１の状態に戻す）
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
考察
上記を見る限り、gtid_mode=ONのダンプファイルをインポートすると以下となりそうです。
- 登録してあるGTIDは登録できない
- 登録していないGTIDは登録できる
- バイナリログに記録されない
実際に試してみます。
登録済みのGTID_PURGEDがあるダンプファイルをインポートする
コンテナ1で以下を実行してみます。
# mysql -u root -p -h localhost test < ~/dump_test.sql
ERROR 3546 (HY000) at line 24: @@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED
想定通り、エラーとなりました。mysql.gtid_executedに登録済みのGTIDセットは登録できないようです。
登録していないGTID_PURGEDのダンプファイルをインポートする
コンテナ1にコンテナ2のダンプファイルをインポートします。
# mysql -u root -p -h localhost test < ~/dump_test2.sql
インポートできました。コンテナ２と同じデータ内容になっているか確認してみます。
mysql> SELECT * FROM sample;
+----+
| id |
+----+
| 1 |
| 2 |
+----+
コンテナ2と同じ内容になっているので、正常にインポートできています。
では、GTIDがどのように登録されているかみてみます。
mysql> SELECT * FROM mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| f2a09049-e78c-11ef-8ff8-0242ac120002 | 1 | 8 |
| f2a12894-e78c-11ef-84e5-0242ac120004 | 1 | 9 |
+--------------------------------------+----------------+--------------+
コンテナ2のsource_uuidが登録されているのが分かります。
バイナリログにコミット内容が記録されているか見てみます。
mysql> SHOW BINLOG EVENTS IN 'binlog.000002';
（差分なし）
前回確認した内容から、差分がありませんでした。バイナリログを見てます。
# mysqlbinlog -v /var/lib/mysql/binlog.000002
（差分なし）
こちらも差分がありませんでした。
インポートしたダンプファイルでバイナリログ出力をOFFにしているので、当然の結果となります。
バイナリログがないということは、レプリケーション構成時にレプリカへデータが反映されないといった問題がでてきそうです。
GTID_PURGEDがないダンプファイルをインポートする
コンテナ1にコンテア3のダンプファイルをインポートしてみます。
# mysql -u root -p -h localhost test < ~/dump_test3.sql
インポートできました。コンテナ3と同じデータ内容になっているか確認してみます。
mysql> SELECT * FROM sample;
+----+
| id |
+----+
| 1 |
| 2 |
| 3 |
+----+
コンテナ3と同じ内容になっています。では、GTIDがどのように登録されているかみてみます。
mysql> SELECT * FROM mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| f2a09049-e78c-11ef-8ff8-0242ac120002 | 1 | 8 |
★1 | f2a09049-e78c-11ef-8ff8-0242ac120002 | 9 | 10 |
★2 | f2a09049-e78c-11ef-8ff8-0242ac120002 | 12 | 12 |
| f2a12894-e78c-11ef-84e5-0242ac120004 | 1 | 9 |
+--------------------------------------+----------------+--------------+
★の箇所を見ると、コンテナ1のsource_uudidで新しいコミットが追加されているのが分かります。
ただ、transaction_idの11番がありません。
バイナリログを見てみます。
mysql> SHOW BINLOG EVENTS IN 'binlog.000002';
+---------------+------+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+------+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| binlog.000002 | 683 | Xid | 1 | 714 | COMMIT /* xid=41 */ |
| binlog.000002 | 714 | Gtid | 1 | 791 | SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:9' |
| binlog.000002 | 791 | Query | 1 | 932 | use `test`; DROP TABLE IF EXISTS `sample` /* generated by server */ /* xid=156 */ |
| binlog.000002 | 932 | Gtid | 1 | 1011 | SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:10' |
| binlog.000002 | 1011 | Query | 1 | 1263 | use `test`; CREATE TABLE `sample` ( `id` int NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci /* xid=159 */ |
★1 | binlog.000002 | 1263 | Gtid | 1 | 1340 | SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:11' |
★2 | binlog.000002 | 1340 | Query | 1 | 1473 | use `test`; /*!40000 ALTER TABLE `sample` DISABLE KEYS */ /* xid=162 */ |
| binlog.000002 | 1473 | Gtid | 1 | 1552 | SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:12' |
| binlog.000002 | 1552 | Query | 1 | 1627 | BEGIN |
| binlog.000002 | 1627 | Table_map | 1 | 1679 | table_id: 102 (test.sample) |
| binlog.000002 | 1679 | Write_rows | 1 | 1729 | table_id: 102 flags: STMT_END_F |
| binlog.000002 | 1729 | Xid | 1 | 1760 | COMMIT /* xid=163 */ |
★3 | binlog.000002 | 1760 | Gtid | 1 | 1837 | SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:13' |
★4 | binlog.000002 | 1837 | Query | 1 | 1969 | use `test`; /*!40000 ALTER TABLE `sample` ENABLE KEYS */ /* xid=164 */ |
+---------------+------+----------------+-----------+-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
新しいログが追加されています。
★1を見ると、Event_TypeがGtidで、InfoがSET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:11'となっているので、ここがmysql.gtid_exectedに記録されていないtransaction_idの11番目だと分かります。
そして内容は、★2を見るとEvent_TypeがQueryなので、Infoに記録されている、ALTER TABLE `sample` DISABLE KEYだと分かります。
また、★3と★4を見ると、mysql.gtid_exectedに記録されていないtransaction_idが13番のALTER TABLE `sample` ENABLE KEYもあることが分かります。
バイナリログのファイルを見てみます。
# mysqlbinlog -v /var/lib/mysql/binlog.000002
# at 714
#250210 18:46:20 server id 1 end_log_pos 791 CRC32 0x85825935 GTID last_committed=2 sequence_number=3 rbr_only=no original_committed_timestamp=1739180780691563 immediate_commit_timestamp=1739180780691563 transaction_length=218
# original_commit_timestamp=1739180780691563 (2025-02-10 18:46:20.691563 JST)
# immediate_commit_timestamp=1739180780691563 (2025-02-10 18:46:20.691563 JST)
/*!80001 SET @@session.original_commit_timestamp=1739180780691563*//*!*/;
/*!80014 SET @@session.original_server_version=80041*//*!*/;
/*!80014 SET @@session.immediate_server_version=80041*//*!*/;
SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:9'/*!*/;
# at 791
#250210 18:46:20 server id 1 end_log_pos 932 CRC32 0xd3c00c87 Query thread_id=17 exec_time=0 error_code=0 Xid = 156
SET TIMESTAMP=1739180780/*!*/;
SET @@session.pseudo_thread_id=17/*!*/;
SET @@session.foreign_key_checks=0, @@session.unique_checks=0/*!*/;
SET @@session.sql_mode=524288/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/;
DROP TABLE IF EXISTS `sample` /* generated by server */
/*!*/;
# at 932
#250210 18:46:20 server id 1 end_log_pos 1011 CRC32 0x2eb8d8be GTID last_committed=3 sequence_number=4 rbr_only=no original_committed_timestamp=1739180780728725 immediate_commit_timestamp=1739180780728725 transaction_length=331
# original_commit_timestamp=1739180780728725 (2025-02-10 18:46:20.728725 JST)
# immediate_commit_timestamp=1739180780728725 (2025-02-10 18:46:20.728725 JST)
/*!80001 SET @@session.original_commit_timestamp=1739180780728725*//*!*/;
/*!80014 SET @@session.original_server_version=80041*//*!*/;
/*!80014 SET @@session.immediate_server_version=80041*//*!*/;
SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:10'/*!*/;
# at 1011
#250210 18:46:20 server id 1 end_log_pos 1263 CRC32 0x8eeb6e1b Query thread_id=17 exec_time=0 error_code=0 Xid = 159
SET TIMESTAMP=1739180780/*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
CREATE TABLE `sample` (
`id` int NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
/*!*/;
# at 1263
#250210 18:46:20 server id 1 end_log_pos 1340 CRC32 0x70943104 GTID last_committed=4 sequence_number=5 rbr_only=no original_committed_timestamp=1739180780737536 immediate_commit_timestamp=1739180780737536 transaction_length=210
# original_commit_timestamp=1739180780737536 (2025-02-10 18:46:20.737536 JST)
# immediate_commit_timestamp=1739180780737536 (2025-02-10 18:46:20.737536 JST)
/*!80001 SET @@session.original_commit_timestamp=1739180780737536*//*!*/;
/*!80014 SET @@session.original_server_version=80041*//*!*/;
/*!80014 SET @@session.immediate_server_version=80041*//*!*/;
SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:11'/*!*/;
# at 1340
#250210 18:46:20 server id 1 end_log_pos 1473 CRC32 0xcafee251 Query thread_id=17 exec_time=0 error_code=0 Xid = 162
SET TIMESTAMP=1739180780/*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
/*!40000 ALTER TABLE `sample` DISABLE KEYS */
/*!*/;
# at 1473
#250210 18:46:20 server id 1 end_log_pos 1552 CRC32 0xf2e53b6c GTID last_committed=5 sequence_number=6 rbr_only=yes original_committed_timestamp=1739180780741665 immediate_commit_timestamp=1739180780741665 transaction_length=287
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1739180780741665 (2025-02-10 18:46:20.741665 JST)
# immediate_commit_timestamp=1739180780741665 (2025-02-10 18:46:20.741665 JST)
/*!80001 SET @@session.original_commit_timestamp=1739180780741665*//*!*/;
/*!80014 SET @@session.original_server_version=80041*//*!*/;
/*!80014 SET @@session.immediate_server_version=80041*//*!*/;
SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:12'/*!*/;
# at 1552
#250210 18:46:20 server id 1 end_log_pos 1627 CRC32 0x75a7670f Query thread_id=17 exec_time=0 error_code=0
SET TIMESTAMP=1739180780/*!*/;
BEGIN
/*!*/;
# at 1627
#250210 18:46:20 server id 1 end_log_pos 1679 CRC32 0x233ec5b2 Table_map: `test`.`sample` mapped to number 102
# has_generated_invisible_primary_key=0
# at 1679
#250210 18:46:20 server id 1 end_log_pos 1729 CRC32 0x4e6497c6 Write_rows: table id 102 flags: STMT_END_F
BINLOG '
7MqpZxMBAAAANAAAAI8GAAAAAGYAAAAAAAEABHRlc3QABnNhbXBsZQABAwAAAQEAssU+Iw==
7MqpZx4BAAAAMgAAAMEGAAAAAGYAAAAAAAcAAgAB/wABAAAAAAIAAAAAAwAAAMaXZE4=
'/*!*/;
### INSERT INTO `test`.`sample`
### SET
### @1=1
### INSERT INTO `test`.`sample`
### SET
### @1=2
### INSERT INTO `test`.`sample`
### SET
### @1=3
# at 1729
#250210 18:46:20 server id 1 end_log_pos 1760 CRC32 0xd72081b4 Xid = 163
COMMIT/*!*/;
# at 1760
#250210 18:46:20 server id 1 end_log_pos 1837 CRC32 0x007872b4 GTID last_committed=6 sequence_number=7 rbr_only=no original_committed_timestamp=1739180780747273 immediate_commit_timestamp=1739180780747273 transaction_length=209
# original_commit_timestamp=1739180780747273 (2025-02-10 18:46:20.747273 JST)
# immediate_commit_timestamp=1739180780747273 (2025-02-10 18:46:20.747273 JST)
/*!80001 SET @@session.original_commit_timestamp=1739180780747273*//*!*/;
/*!80014 SET @@session.original_server_version=80041*//*!*/;
/*!80014 SET @@session.immediate_server_version=80041*//*!*/;
SET @@SESSION.GTID_NEXT= 'f2a09049-e78c-11ef-8ff8-0242ac120002:13'/*!*/;
# at 1837
#250210 18:46:20 server id 1 end_log_pos 1969 CRC32 0x339dcb1a Query thread_id=17 exec_time=0 error_code=0 Xid = 164
SET TIMESTAMP=1739180780/*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
/*!40000 ALTER TABLE `sample` ENABLE KEYS */
/*!*/;
インポートしたダンプファイルにあったSQLの実行ログが記録されているのが分かります。
コンテナ2をインポートした時と違い、バイナリログに記録があるのでレプリケーション構成でも問題なさそうです。
※ALTER TABLE tbl_name {DISABLE | ENABLE} KEYSのGITDがmysql.gtid_exectedに記録されない理由
こちらは調べたのですが（MySQL8.0のソースは確認していません）、理由は分かりませんでした。
推測ですが、インデックス更新の停止/再開自体はデータ登録の速度向上を目的で、テーブルの更新には関係がないため記録されないのかもしれません。
ダンプしたデータを取り込めるのかの結論
SET @@GLOBAL.GTID_PURGEDを出力しないようにすれば問題なさそうです。
これは、mysqldumpをする際にオプション「--set-gtid-purged=OFF」を指定することで実現できます。
参考：https://dev.mysql.com/doc/refman/8.0/ja/mysqldump.html#option_mysqldump_set-gtid-purged
OFF
SET @@GLOBAL.gtid_purged は出力に追加されず、SET @@SESSION.sql_log_bin=0 は出力に追加されません。 GTID が使用されていないサーバーの場合は、このオプションまたは AUTO を使用します。 GTID が使用されているサーバーでは、必要な GTID セットがターゲットサーバーの gtid_purged にすでに存在し、変更しないことが確実な場合、または欠落している GTID を手動で識別して追加する予定の場合にのみ、このオプションを使用します。
※今回の私の用途（mysqldumpで出力したSQLを実行したい）ではこの方法で良いのですが、実際のリカバリなどの場合は問題となる可能性がありますのでご注意ください。
さいごに
今回は「GTIDって何？」「Warningがでたダンプファイルを利用していいの？」が知りたくて、GTIDを確認してみました。
何も調べずにWarningが出たダンプファイルをインポートしてたら、大変なことになっていたかもしれません。
GTIDに限らずDB周りの設定は知らないことがまだまだ多く、大切なデータを安全に扱うためにも、これからも精進していきたいと思います。
次はせっかくなので、GTIDの本来の目的であるDBのレプリケーション構築や復元方法などについて確認してみます。
株式会社BTMではエンジニアの採用をしております。
ご興味がある方はぜひコチラをご覧ください