PXC中的GTIDs
基本環境：PXC 5.7.19 Row+Gtid，3節點html
1、Galera GTID vs MySQL GTID
1.一、Galera GTID vs MySQL GTID
Both kinds of GTIDs are using the same format: <source_id:trx_number>.
For Galera, <source_id> is generated when the cluster is bootstrapped. This <source_id> is shared by all nodes.
For MySQL, <source_id> is the server uuid. So it is easy to identify from which server a transaction originates.
咱們先來看下PXC環境Galera GTID和MySQL GTID分別指的是什麼node
# node1的server_uuid mydba@192.168.85.132,3326 [replcrash]> select @@server_uuid; +--------------------------------------+ | @@server_uuid | +--------------------------------------+ | 31304898-67d8-11e8-bb20-000c29c1025c | +--------------------------------------+ 1 row in set (0.00 sec) # node1寫入一條數據 mydba@192.168.85.132,3326 [replcrash]> insert into py_user(name,add_time,server_id) select left(uuid(),32),now(),@@server_id; Query OK, 1 row affected (0.02 sec) Records: 1 Duplicates: 0 Warnings: 0 # node1查看gtid_executed mydba@192.168.85.132,3326 [replcrash]> select @@global.gtid_executed; +----------------------------------------+ | @@global.gtid_executed | +----------------------------------------+ | 0f0f1664-9769-ee17-7834-ec71884d9f25:1 | +----------------------------------------+ 1 row in set (0.00 sec) # node2的server_uuid mydba@192.168.85.133,3326 [replcrash]> select @@server_uuid; +--------------------------------------+ | @@server_uuid | +--------------------------------------+ | 570e2242-6898-11e8-bcae-000c2900c99c | +--------------------------------------+ 1 row in set (0.01 sec) # node2寫入一條數據 mydba@192.168.85.133,3326 [replcrash]> insert into py_user(name,add_time,server_id) select left(uuid(),32),now(),@@server_id; Query OK, 1 row affected (0.45 sec) Records: 1 Duplicates: 0 Warnings: 0 # node2查看gtid_executed mydba@192.168.85.133,3326 [replcrash]> select @@global.gtid_executed; +------------------------------------------+ | @@global.gtid_executed | +------------------------------------------+ | 0f0f1664-9769-ee17-7834-ec71884d9f25:1-2 | +------------------------------------------+ 1 row in set (0.00 sec)
上面@@server_uuid對應的是MySQL，@@global.gtid_executed對應的是Galera
node一、node2上執行的insert語句使用相同的<source_id>，彷彿它們在同一臺實例上執行，而且與node1/node2本身的@@server_uuid不一樣
咱們能夠把Cluster看成MySQL複製中的Master，全部節點獲取來自相同<source_id>的數據mysql
1.二、UUID
咱們知道MySQL GTID的<source_id>存儲於$/datadir/auto.cnf，Galera GTID的<source_id>是否也存在相關的文件？若是你足夠仔細的話，你會發現Galera GTID與$/datadir/grastate.dat存在下面的關聯web
# 查看grastate.dat [root@ZST1 data]# cat grastate.dat # GALERA saved state version: 2.1 uuid: f0f0e99b-6896-11e8-87cb-138e77b260da seqno: -1 safe_to_bootstrap: 0 [root@ZST1 data]# # Galera GTID與$/datadir/grastate.dat的關聯 Galera GTID<source_id> + grastate.dat<uuid> = 0f0f1664-9769-ee17-7834-ec71884d9f25 + f0f0e99b-6896-11e8-87cb-138e77b260da = ffffffff-ffff-ffff-ffff-ffffffffffff
Cluster的第一節點啓動時，會讀取grastate.dat文件，用它裏面的uuid信息構建Galera GTID的<source_id>。若是刪除$/datadir/grastate.dat文件，下次從新啓動集羣，它的Galera GTID會改變(相似刪除$/datadir/auto.cnf文件，從新啓動實例MySQL GTID也會改變)。Galera GTID與MySQL GTID之間並無對應關係，它們是相互獨立的。PXC中的@@global.gtid_executed的初始化能夠參考：gtid_executed和gtid_purged變量是如何初始化的 ，只要明白Galera GTID的<source_id>來源，其餘徹底能夠套用MySQL GTID
PXC中其實還存在其餘uuidsql
mydba@192.168.85.132,3326 [replcrash]> show status like '%uuid%'; +--------------------------+--------------------------------------+ | Variable_name | Value | +--------------------------+--------------------------------------+ | wsrep_local_state_uuid | f0f0e99b-6896-11e8-87cb-138e77b260da | | wsrep_gcomm_uuid | 8ab36be3-6897-11e8-bf70-cee6630daa30 | | wsrep_cluster_state_uuid | f0f0e99b-6896-11e8-87cb-138e77b260da | +--------------------------+--------------------------------------+ 3 rows in set (0.00 sec) wsrep_cluster_state_uuid Provides the current State UUID. This is a unique identifier for the current state of the cluster and the sequence of changes it undergoes. wsrep_local_state_uuid The UUID of the state stored on this node. wsrep_gcomm_uuid Displays the group communications UUID.
wsrep_cluster_state_uuid、wsrep_local_state_uuid對應的就是grastate.dat中的uuid，wsrep_gcomm_uuid是group communications uuidbootstrap
2、什麼狀況下當前節點的事務不會複製到其餘節點
普通主從環境，從庫@@global.gtid_executed只會顯示主庫執行的事務。若是咱們在從庫手動執行事務，那麼從庫@@global.gtid_executed就會包含本地的信息
對於PXC來講，它支持多節點寫入，任何節點的DML操做先在本地執行，在提交前將全部的變動和對應主鍵保存到write-set，集羣下發write-set給每一個節點(包括DML執行的節點)，使用主鍵驗證各節點是否能夠應用write-set。若是驗證失敗，則刪除write-set並回滾原始事務；若是驗證成功，提交事務並應用其餘未完成的write-set。
是否是任何節點上的任何事務都能複製全部節點？有沒有可能某個事務只存在於一個節點？
• DML On MyISAM
最大的多是對MyISAM表的DML操做，會使用server_uuid記錄binlog，而且不會被複制到集羣中的其餘節點！app
# node1建立myisam引擎的表 mydba@192.168.85.132,3326 [replcrash]> create table py_user_myisam(id int not null primary key) engine=myisam; Query OK, 0 rows affected (0.66 sec) # 往py_user_myisam表中插入數據 mydba@192.168.85.132,3326 [replcrash]> insert into py_user_myisam(id) select 1; ERROR 1105 (HY000): Percona-XtraDB-Cluster prohibits use of DML command on a table (replcrash.py_user_myisam) that resides in non-transactional storage engine with pxc_strict_mode = ENFORCING or MASTER # 修改mode爲permissive mydba@192.168.85.132,3326 [replcrash]> set global pxc_strict_mode='permissive'; Query OK, 0 rows affected (0.00 sec) # 從新插入數據 mydba@192.168.85.132,3326 [replcrash]> insert into py_user_myisam(id) select 1; Query OK, 1 row affected, 1 warning (0.09 sec) Records: 1 Duplicates: 0 Warnings: 1 # node1查看gtid_executed mydba@192.168.85.132,3326 [replcrash]> select @@global.gtid_executed; +----------------------------------------------------------------------------------+ | @@global.gtid_executed | +----------------------------------------------------------------------------------+ | 0f0f1664-9769-ee17-7834-ec71884d9f25:1-3, 31304898-67d8-11e8-bb20-000c29c1025c:1 | +----------------------------------------------------------------------------------+ 1 row in set (0.00 sec) # 查看binlog events mydba@192.168.85.132,3326 [replcrash]> show binlog events in 'mysql-bin.000003'; +------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------+ | mysql-bin.000003 | 4 | Format_desc | 1323326 | 123 | Server ver: 5.7.19-17-29.22-log, Binlog ver: 4 | | mysql-bin.000003 | 123 | Previous_gtids | 1323326 | 194 | 0f0f1664-9769-ee17-7834-ec71884d9f25:1 | | mysql-bin.000003 | 194 | Gtid | 1333326 | 259 | SET @@SESSION.GTID_NEXT= '0f0f1664-9769-ee17-7834-ec71884d9f25:2' | | mysql-bin.000003 | 259 | Query | 1333326 | 327 | BEGIN | | mysql-bin.000003 | 327 | Table_map | 1333326 | 390 | table_id: 121 (replcrash.py_user) | | mysql-bin.000003 | 390 | Write_rows | 1333326 | 476 | table_id: 121 flags: STMT_END_F | | mysql-bin.000003 | 476 | Xid | 1333326 | 507 | COMMIT /* xid=3 */ | | mysql-bin.000003 | 507 | Gtid | 1323326 | 572 | SET @@SESSION.GTID_NEXT= '0f0f1664-9769-ee17-7834-ec71884d9f25:3' | | mysql-bin.000003 | 572 | Query | 1323326 | 726 | use `replcrash`; create table py_user_myisam(id int not null primary key) engine=myisam | | mysql-bin.000003 | 726 | Gtid | 1323326 | 791 | SET @@SESSION.GTID_NEXT= '31304898-67d8-11e8-bb20-000c29c1025c:1' | | mysql-bin.000003 | 791 | Query | 1323326 | 873 | BEGIN | | mysql-bin.000003 | 873 | Table_map | 1323326 | 935 | table_id: 224 (replcrash.py_user_myisam) | | mysql-bin.000003 | 935 | Write_rows | 1323326 | 975 | table_id: 224 flags: STMT_END_F | | mysql-bin.000003 | 975 | Query | 1323326 | 1058 | COMMIT | +------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------+ 14 rows in set (0.05 sec) # node2查看gtid_executed mydba@192.168.85.133,3326 [replcrash]> select @@global.gtid_executed; +------------------------------------------+ | @@global.gtid_executed | +------------------------------------------+ | 0f0f1664-9769-ee17-7834-ec71884d9f25:1-3 | +------------------------------------------+ 1 row in set (0.10 sec)
建立MyISAM表的語句使用DDL機制，它能複製到各節點；可是對MyISAM表執行DML操做，它使用@@server_uuid(相似常規MySQL複製)，不會複製到Cluster的其餘節點，可是它能複製到node1節點的異步Slave
• Flush Commands異步
# node1執行flush privileges mydba@192.168.85.132,3326 [replcrash]> flush privileges; Query OK, 0 rows affected (0.26 sec) # node1查看gtid_executed mydba@192.168.85.132,3326 [replcrash]> select @@global.gtid_executed; +----------------------------------------------------------------------------------+ | @@global.gtid_executed | +----------------------------------------------------------------------------------+ | 0f0f1664-9769-ee17-7834-ec71884d9f25:1-4, 31304898-67d8-11e8-bb20-000c29c1025c:1 | +----------------------------------------------------------------------------------+ 1 row in set (0.00 sec) # node1查看binlog events mydba@192.168.85.132,3326 [replcrash]> show binlog events in 'mysql-bin.000003'; +------------------+------+----------------+-----------+-------------+-----------------------------------------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+------+----------------+-----------+-------------+-----------------------------------------------------------------------------------------+ | mysql-bin.000003 | 4 | Format_desc | 1323326 | 123 | Server ver: 5.7.19-17-29.22-log, Binlog ver: 4 | | mysql-bin.000003 | 123 | Previous_gtids | 1323326 | 194 | 0f0f1664-9769-ee17-7834-ec71884d9f25:1 | | mysql-bin.000003 | 194 | Gtid | 1333326 | 259 | SET @@SESSION.GTID_NEXT= '0f0f1664-9769-ee17-7834-ec71884d9f25:2' | | mysql-bin.000003 | 259 | Query | 1333326 | 327 | BEGIN | | mysql-bin.000003 | 327 | Table_map | 1333326 | 390 | table_id: 121 (replcrash.py_user) | | mysql-bin.000003 | 390 | Write_rows | 1333326 | 476 | table_id: 121 flags: STMT_END_F | | mysql-bin.000003 | 476 | Xid | 1333326 | 507 | COMMIT /* xid=3 */ | | mysql-bin.000003 | 507 | Gtid | 1323326 | 572 | SET @@SESSION.GTID_NEXT= '0f0f1664-9769-ee17-7834-ec71884d9f25:3' | | mysql-bin.000003 | 572 | Query | 1323326 | 726 | use `replcrash`; create table py_user_myisam(id int not null primary key) engine=myisam | | mysql-bin.000003 | 726 | Gtid | 1323326 | 791 | SET @@SESSION.GTID_NEXT= '31304898-67d8-11e8-bb20-000c29c1025c:1' | | mysql-bin.000003 | 791 | Query | 1323326 | 873 | BEGIN | | mysql-bin.000003 | 873 | Table_map | 1323326 | 935 | table_id: 224 (replcrash.py_user_myisam) | | mysql-bin.000003 | 935 | Write_rows | 1323326 | 975 | table_id: 224 flags: STMT_END_F | | mysql-bin.000003 | 975 | Query | 1323326 | 1058 | COMMIT | | mysql-bin.000003 | 1058 | Gtid | 1323326 | 1123 | SET @@SESSION.GTID_NEXT= '0f0f1664-9769-ee17-7834-ec71884d9f25:4' | | mysql-bin.000003 | 1123 | Query | 1323326 | 1219 | use `replcrash`; flush privileges | +------------------+------+----------------+-----------+-------------+-----------------------------------------------------------------------------------------+ 16 rows in set (0.00 sec) # node2查看gtid_executed mydba@192.168.85.133,3326 [replcrash]> select @@global.gtid_executed; +------------------------------------------+ | @@global.gtid_executed | +------------------------------------------+ | 0f0f1664-9769-ee17-7834-ec71884d9f25:1-4 | +------------------------------------------+ 1 row in set (0.00 sec) # node2查看binlog events mydba@192.168.85.133,3326 [replcrash]> show binlog events in 'mysql-bin.000004'; +------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------+ | mysql-bin.000004 | 4 | Format_desc | 1333326 | 123 | Server ver: 5.7.19-17-29.22-log, Binlog ver: 4 | | mysql-bin.000004 | 123 | Previous_gtids | 1333326 | 194 | 0f0f1664-9769-ee17-7834-ec71884d9f25:1 | | mysql-bin.000004 | 194 | Gtid | 1333326 | 259 | SET @@SESSION.GTID_NEXT= '0f0f1664-9769-ee17-7834-ec71884d9f25:2' | | mysql-bin.000004 | 259 | Query | 1333326 | 349 | BEGIN | | mysql-bin.000004 | 349 | Table_map | 1333326 | 412 | table_id: 121 (replcrash.py_user) | | mysql-bin.000004 | 412 | Write_rows | 1333326 | 498 | table_id: 121 flags: STMT_END_F | | mysql-bin.000004 | 498 | Xid | 1333326 | 529 | COMMIT /* xid=3 */ | | mysql-bin.000004 | 529 | Gtid | 1323326 | 594 | SET @@SESSION.GTID_NEXT= '0f0f1664-9769-ee17-7834-ec71884d9f25:3' | | mysql-bin.000004 | 594 | Query | 1323326 | 748 | use `replcrash`; create table py_user_myisam(id int not null primary key) engine=myisam | | mysql-bin.000004 | 748 | Gtid | 1323326 | 813 | SET @@SESSION.GTID_NEXT= '0f0f1664-9769-ee17-7834-ec71884d9f25:4' | | mysql-bin.000004 | 813 | Query | 1323326 | 909 | use `replcrash`; flush privileges | +------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------+ 11 rows in set (0.00 sec)
實驗代表，flush命令被正常複製到其餘節點，binlog中使用的是Cluster UUID。看來Issuing FLUSH commands on a node will create a local transaction on GTID-configured clusters已經被修復●-●
• SQL_LOG_BIN=0
在當前節點 SET SQL_LOG_BIN=0，不會記錄對應的binlog，難道就沒有對應的write-set？這種狀況對於過後也沒辦法知道原始事務發生在哪一個節點，沒GTID，沒binlog，太闊怕･ω･async
3、參考文檔
Percona XtraDB Cluster 5.6: a tale of 2 GTIDs：https://www.percona.com/blog/2015/02/13/percona-xtradb-cluster-5-6-a-tale-of-2-mysql-gtids/
How to setup a PXC cluster with GTIDs (and have async slaves replicating from it!)：https://www.percona.com/blog/2015/02/20/how-to-setup-a-pxc-cluster-with-gtids-and-have-async-slaves-replicating-from-it/
Webinar Q/A: MySQL High Availability with Percona XtraDB Cluster 5.7：http://feed.askmaclean.com/archives/webinar-qa-mysql-high-availability-with-percona-xtradb-cluster-5-7.html
GALERA CLUSTER DOCUMENTATION：http://galeracluster.com/documentation-webpages/index.htmlide
相關文章
- 1. MySQL基於GTIDs的MySQL Replication
- 2. Mysql基於GTIDs的複製
- 3. MySQL基於GTIDs的主從複製
- 4. 配置mysql中的PXC服務
- 5. Mycat+Pxc的配置
- 6. mysql replication（主從複製）（三）GTIDs
- 7. centos6安裝pxc
- 8. MySQL集羣(PXC)
- 9. mysql PXC 安裝
- 10. Mysql PXC集羣
- 更多相關文章...
- • Spring中Bean的作用域 - Spring教程
- • 現實生活中的 XML - XML 教程
- • C# 中 foreach 遍歷的用法
- • Scala 中文亂碼解決
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章