- GreatSQL The original content of the community shall not be used without authorization , For reprint, please contact the editor and indicate the source .
GTID summary
MySQL5.6 A new replication method is added to the original master-slave replication , That is, based on GTID The way of reproduction , It consists of UUID And transaction ID Two parts , It has the following characteristics .
- GTID Transactions are globally unique , And one transaction corresponds to one GTID value .
- One GTID The value is in the same MySQL The instance will be executed only once .
GTID Compared with traditional replication
- The master-slave construction is simpler , There is no need to manually specify position Location .
- There is a unified identity in the replication cluster , distinguish 、 Management is more convenient .
- Failover is easier , You don't need to find it like traditional replication log_file and log_Pos The location of .
- Usually GTID It's continuous, there's no void , Better ensure data consistency , Zero loss .
- be relative to ROW Copying model , More secure data , Easier switching .
- More secure than traditional replication , One GTID In a MySQL The instance will be executed only once , Avoid data confusion or master-slave inconsistency caused by repeated execution .
GTID What are their limitations
- In a replication group , Must be turned on GTID.
- MySQL5.6 Turn on GTID Need to restart .
- I won't support it sql_slave_skip_counte operation , Traditional replication can use this command to skip transactions .
- Not allowed in one SQL Update the tables of a transaction engine and a non transaction engine at the same time , Such as InnoDB and MyISAM.
- about create temporary table and drop temporary table Statement not supported .
- I won't support it create table … select Sentence copying .
GTID A brief introduction to the working principle
- master When nodes update data , It's going to happen before the transaction GTID Information , Record together binlog In the log .
- slave Node io Thread will binlog Write to local relay log in .
- then SQL The thread from relay log Read from GTID, Set up gtid_next The value of the gtid, Then contrast slave Terminal binlog Is there a record .
- If there are records , Explain the GTID The transaction for is already running ,slave Will ignore .
- If there is no record ,slave Will carry out the GTID The corresponding business , And record the binlog in .
How to open GTID Copy
- In addition to the traditional replication needs to be turned on binlog Other than relevant parameters ,GTID The following parameter settings need to be opened additionally for synchronization , Note that the master and slave nodes need to be started synchronously .
gtid_mode=on # Turn on GTID
enforce-gtid-consistency=on # This parameter needs to be set synchronously
log-slave-updates=1 # 5.6 This parameter needs to be enabled for version see GTID Related parameters
[[email protected]][(none)]>show variables like '%gtid%';
+----------------------------------+-------------------------------------------------------------------------------------+
| Variable_name | Value |
+----------------------------------+-------------------------------------------------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | 613743f5-8b1c-11ec-9922-00155dcff911:1-14 |
| gtid_executed_compression_period | 0 |
| gtid_mode | ON |
| gtid_next | AUTOMATIC |
| gtid_owned | |
| gtid_purged | |
| session_track_gtids | OFF |
+----------------------------------+-------------------------------------------------------------------------------------+
9 rows in set (0.00 sec)
- Brief description of parameters
| Parameter name | Meaning Introduction |
|---|---|
| binlog_gtid_simple_recovery | This parameter controls when MySQL Automatically find when the service restarts or starts GTIDs Value . |
| enforce_gtid_consistency | This parameter is a mandatory requirement that only transaction safe transactions are allowed to be copied , Please see the specific limitations of the above steps . |
| gtid_executed | Already executed GTID Information . |
| gtid_executed_compression_period | Enable GTID when , The server will be on a regular basis mysql.gtid_executed Perform compression on the table . By setting gtid_executed_compression_period System variables , You can control the number of transactions allowed before compressing the table , So as to control the compression ratio . Set to 0 when , No compression . |
| gtid_mode | Open or not GTID Pattern |
| gtid_next | Indicates the next to be executed GTID Information |
| gtid_owned | This parameter contains global and session, Global means that all servers have GTIDs,session Level indicates current client All you have GTIDs. |
| gtid_purged | already purge Dropped GTIDs,purged Dropped GTIDs Will include to gtid_executed in . |
| session_track_gtids | This parameter controls what is used for capture GTIDs And in OK PACKE Return tracker . |
GTID Different from the traditional mode when creating replication statements
# Traditional reproduction
change master to master_host="127.0.0.1",master_port=3310,MASTER_USER='sync',MASTER_PASSWORD='GreatSQL',MASTER_LOG_FILE='log-bin.000005', MASTER_LOG_POS=4111;
# GTID Copy
change master to master_host="127.0.0.1",master_port=3310,MASTER_USER='sync',MASTER_PASSWORD='GreatSQL',MASTER_AUTO_POSITION=1GTID Synchronization is used when establishing replication , The traditional copy is artificially specified binlog Of pos The site is changed to MASTER_AUTO_POSITION=1 Automatic access to binlog Of pos site .
GTID Simple analysis of synchronization status
In addition to the traditional view binlog and pos Beyond value ,GTID Mode can more intuitively view the execution of a transaction .
[[email protected]][(none)]>show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.6.215
Master_User: sync
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000001
Read_Master_Log_Pos: 2425
Relay_Log_File: mgr2-relay-bin.000002
Relay_Log_Pos: 2634
Relay_Master_Log_File: binlog.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 2425
Relay_Log_Space: 2842
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2153306
Master_UUID: 613743f5-8b1c-11ec-9922-00155dcff911
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 613743f5-8b1c-11ec-9922-00155dcff911:1-10
Executed_Gtid_Set: 613743f5-8b1c-11ec-9922-00155dcff911:1-10,
652ade08-8b1c-11ec-9f62-00155dcff90a:1-2
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
Master_public_key_path:
Get_master_public_key: 0
Network_Namespace:
1 row in set, 1 warning (0.01 sec)
ERROR:
No query specified- GTID Description of relevant key parameters
| Parameter name | Meaning Introduction |
|---|---|
| Retrieved_Gtid_Set | Slave The node has received Master Node GTIDs |
| Executed_Gtid_Set | Slave The node has executed GTIDs |
| Auto_Position | Automatic access to position Location , Is shown as 1 |
summary
- Limited by space, I have written so much for the time being , Next week, we will continue to publish content related to master-slave replication , Welcome to catch up , In addition, it is limited by personal ability and experience , The content is inevitably wrong , If there is any error, please point out the correction in the comment area .
Enjoy GreatSQL :)
Article recommendation ：
GreatSQL Quarterly Report （2021.12.26）
https://mp.weixin.qq.com/s/FZ...
Technology sharing |sysbench Usage analysis of pressure measuring tools
https://mp.weixin.qq.com/s/m1...
Fault analysis | linux disk io High utilization , Analyze the correct posture
https://mp.weixin.qq.com/s/7c...
Technology sharing | Flashback at MySQL Implementation and improvement in
https://mp.weixin.qq.com/s/6j...
Wan Da #20, How to filter data in index push down
https://mp.weixin.qq.com/s/pt...
About GreatSQL
GreatSQL It is maintained by Wanli database MySQL Branch , Focus on Improvement MGR Reliability and performance , Support InnoDB Parallel query feature , It is suitable for financial grade applications MySQL Branch version .
Gitee:
https://gitee.com/GreatSQL/Gr...
GitHub:
https://github.com/GreatSQL/G...
Bilibili：
https://space.bilibili.com/13...
WeChat &QQ Group ：
Searchable add GreatSQL Community assistant wechat friend , Send verification information “ Add group ” Join in GreatSQL/MGR Exchange wechat group
QQ Group ：533341697
Wechat assistant ：wanlidbc
This article by the blog one article many sends the platform OpenWrite Release ！
![抓包整理外篇——————状态栏[ 四]](/img/88/8267ab92177788ac17ab665a90b781.png)
![[wave modeling 1] theoretical analysis and MATLAB simulation of wave modeling](/img/c4/46663f64b97e7b25d7222de7025f59.png)
