TL;DR
- Certificationのタイミングで綺麗に連番(GNO)を払い出しているのかとか思ったら全然そんなことはなかった
- 各サーバー内ではちゃんと直列化して、サーバーまたいだ部分は100万番ずつズラしてユニークになるようにしているらしい。
- 99万9999まで本物のトランザクションが来たら更にオフセットするのかしらん
取り敢えず構築してマルチマスターモードに変更したところ。
MySQL localhost:33060+ ssl JS > cluster.status()
{
"clusterName": "myfabric",
"defaultReplicaSet": {
"name": "default",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"node1:3306": {
"address": "node1:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.19"
},
"node2:3306": {
"address": "node2:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.19"
},
"node3:3306": {
"address": "node3:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.19"
}
},
"topologyMode": "Multi-Primary"
},
"groupInformationSourceMember": "node2:3306"
}
ここに向かって単にsysbenchのoltp_insertを3台それぞれから叩き込んでみた(prepareはnode1に対してだけ行って、その後MySQL Shellを使ってCloneメソッドでInnoDB Clusterにした)
### node1
$ sysbench --mysql-user=root oltp_insert run
### node2
$ sysbench --mysql-user=root oltp_insert run
### node3
$ sysbench --mysql-user=root oltp_insert run
そしたらこんなじゃよ。
MySQL localhost:33060+ ssl SQL > SHOW MASTER STATUS;
+---------------+-----------+--------------+------------------+--------------------------------------------------------------------------------------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+-----------+--------------+------------------+--------------------------------------------------------------------------------------------------------------------------+
| binlog.000004 | 841384752 | | | 4fefc956-5c63-11ea-8b67-12ca68111319:1-3744,
b5984af1-5c64-11ea-b314-12ca68111319:1-5153:1000049-1005124:2000049-2005337 |
+---------------+-----------+--------------+------------------+--------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.0003 sec)
4fef.. のGTIDがnode1がグループレプリケーションになる前にやった sysbench oltp_common prepare のぶん(node1の server_uuid なので)、 b598.. のGTIDの1-5153はnode1、1000049-5124はnode2、2000049-2005337はnode3のものだった。
この「どのGTIDをどのサーバーが吐いたか」はバイナリログに
GTID_NEXT と server_id が記録されているところを見れば何となくわかった。$ mysqlbinlog -vv binlog.000002
..
# at 10860366
#200302 10:30:47 server id 1967205333 end_log_pos 10860448 GTID last_committed=23215 sequence_number=23216 rbr_only=yes
original_committed_timestamp=1583145047671259 immediate_commit_timestamp=1583145053357357 transaction_length=466
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1583145047671259 (2020-03-02 10:30:47.671259 UTC)
# immediate_commit_timestamp=1583145053357357 (2020-03-02 10:30:53.357357 UTC)
/*!80001 SET @@session.original_commit_timestamp=1583145047671259*//*!*/;
/*!80014 SET @@session.original_server_version=80019*//*!*/;
/*!80014 SET @@session.immediate_server_version=80019*//*!*/;
SET @@SESSION.GTID_NEXT= 'b5984af1-5c64-11ea-b314-12ca68111319:2007954'/*!*/;
..
Σ(ﾟдﾟlll) 確かにカブらないだろうけど、雑！！！
次はアレだな、99万9999まで本物のトランザクションが来たらどうなるかだな…（さすがにそんなわかりきってるのは対応してあろうが）
