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 
 Copy code

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)

 Copy code

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=1
 Copy code

GTID 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
 Copy code

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） mp.weixin.qq.com/s/FZ_zSBHfl…

Technology sharing |sysbench Usage analysis of pressure measuring tools mp.weixin.qq.com/s/m16LwXWy9…

Fault analysis | linux disk io High utilization , Analyze the correct posture mp.weixin.qq.com/s/7cu_36jfs…

Technology sharing | Flashback at MySQL Implementation and improvement in mp.weixin.qq.com/s/6jepwEE0D…

Wan Da #20, How to filter data in index push down mp.weixin.qq.com/s/pt6mr3Ge1…

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: gitee.com/GreatSQL/Gr…

GitHub: github.com/GreatSQL/Gr…

Bilibili： space.bilibili.com/1363850082/…

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