当前位置:网站首页>Introduction to the gtid mode of MySQL master-slave replication

Introduction to the gtid mode of MySQL master-slave replication

2022-07-05 01:03:00 Greatsql community

  • 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=1

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
  • GTID Description of relevant key parameters
Parameter name Meaning Introduction
Retrieved_Gtid_SetSlave The node has received Master Node GTIDs
Executed_Gtid_SetSlave 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 !
原网站

版权声明
本文为[Greatsql community]所创,转载请带上原文链接,感谢
https://yzsam.com/2022/02/202202141058433966.html