InnoDB ClusterのマルチプライマリーモードはGTIDの払い出し方が雑…

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まで本物のトランザクションが来たらどうなるかだな…（さすがにそんなわかりきってるのは対応してあろうが）

​