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

Introduction to the gtid mode of MySQL master-slave replication

2022-07-05 00:51:00 【Greatsql community】

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 

     
    
      
  • 1.
    • 
      
  • 2.
    • 
      
  • 3.
    •

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)


     
    
      
  • 1.
    • 
      
  • 2.
    • 
      
  • 3.
    • 
      
  • 4.
    • 
      
  • 5.
    • 
      
  • 6.
    • 
      
  • 7.
    • 
      
  • 8.
    • 
      
  • 9.
    • 
      
  • 10.
    • 
      
  • 11.
    • 
      
  • 12.
    • 
      
  • 13.
    • 
      
  • 14.
    • 
      
  • 15.
    • 
      
  • 16.
    •
  • 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

     
    
      
  • 1.
    • 
      
  • 2.
    • 
      
  • 3.
    • 
      
  • 4.
    • 
      
  • 5.
    •

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

     
    
      
  • 1.
    • 
      
  • 2.
    • 
      
  • 3.
    • 
      
  • 4.
    • 
      
  • 5.
    • 
      
  • 6.
    • 
      
  • 7.
    • 
      
  • 8.
    • 
      
  • 9.
    • 
      
  • 10.
    • 
      
  • 11.
    • 
      
  • 12.
    • 
      
  • 13.
    • 
      
  • 14.
    • 
      
  • 15.
    • 
      
  • 16.
    • 
      
  • 17.
    • 
      
  • 18.
    • 
      
  • 19.
    • 
      
  • 20.
    • 
      
  • 21.
    • 
      
  • 22.
    • 
      
  • 23.
    • 
      
  • 24.
    • 
      
  • 25.
    • 
      
  • 26.
    • 
      
  • 27.
    • 
      
  • 28.
    • 
      
  • 29.
    • 
      
  • 30.
    • 
      
  • 31.
    • 
      
  • 32.
    • 
      
  • 33.
    • 
      
  • 34.
    • 
      
  • 35.
    • 
      
  • 36.
    • 
      
  • 37.
    • 
      
  • 38.
    • 
      
  • 39.
    • 
      
  • 40.
    • 
      
  • 41.
    • 
      
  • 42.
    • 
      
  • 43.
    • 
      
  • 44.
    • 
      
  • 45.
    • 
      
  • 46.
    • 
      
  • 47.
    • 
      
  • 48.
    • 
      
  • 49.
    • 
      
  • 50.
    • 
      
  • 51.
    • 
      
  • 52.
    • 
      
  • 53.
    • 
      
  • 54.
    • 
      
  • 55.
    • 
      
  • 56.
    • 
      
  • 57.
    • 
      
  • 58.
    • 
      
  • 59.
    • 
      
  • 60.
    • 
      
  • 61.
    • 
      
  • 62.
    • 
      
  • 63.
    • 
      
  • 64.
    • 
      
  • 65.
    • 
      
  • 66.
    • 
      
  • 67.
    •
  • 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_zSBHflwloHtZ38YJxbA

Technology sharing |sysbench Usage analysis of pressure measuring tools
 https://mp.weixin.qq.com/s/m16LwXWy9bFt0i99HjbRsw

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

Technology sharing | Flashback at MySQL Implementation and improvement in
 https://mp.weixin.qq.com/s/6jepwEE0DnYUpjMYO17VtQ

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

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/GreatSQL

GitHub:
 https://github.com/GreatSQL/GreatSQL

Bilibili：
 https://space.bilibili.com/1363850082/video

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

原网站

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

边栏推荐

猜你喜欢

随机推荐