乐趣区

关于mysql:MySQL主从复制之GTID模式介绍

jiezi
  • GreatSQL 社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。

GTID 概述

MySQL5.6 在原有主从复制的根底上减少了一个新的复制形式，即基于 GTID 的复制形式，它由 UUID 和事务 ID 两个局部组成，具备如下特点。

  • GTID 事务是全局唯一性的，并且一个事务对应一个 GTID 值。
  • 一个 GTID 值在同一个 MySQL 实例上只会执行一次。

GTID 相较与传统复制的劣势

  • 主从搭建更加简便，不必手动顺便指定 position 地位。
  • 复制集群内有一个对立的标识，辨认、治理上更不便。
  • 故障转移更容易，不必像传统复制那样须要找 log_file 和 log_Pos 的地位。
  • 通常状况下 GTID 是间断没有空洞的，更能保证数据的一致性，零失落。
  • 绝对于 ROW 复制模式，数据安全性更高，切换更简略。
  • 比传统的复制更加平安，一个 GTID 在一个 MySQL 实例上只会执行一次，防止反复执行导致数据凌乱或者主从不统一。

GTID 本身存在哪些限度

  • 在一个复制组中，必须都要开启 GTID。
  • MySQL5.6 开启 GTID 须要重启。
  • 不反对 sql_slave_skip_counte 操作，传统复制能够应用这个命令跳过事务。
  • 不容许在一个 SQL 同时更新一个事务引擎和非事务引擎的表，如 InnoDB 和 MyISAM。
  • 对于 create temporary table 和 drop temporary table 语句不反对。
  • 不反对 create table … select 语句复制。

GTID 工作原理简略介绍

  • master 节点在更新数据的时候，会在事务前产生 GTID 信息，一起记录到 binlog 日志中。
  • slave 节点的 io 线程将 binlog 写入到本地 relay log 中。
  • 而后 SQL 线程从 relay log 中读取 GTID，设置 gtid_next 的值为该 gtid，而后比照 slave 端的 binlog 是否有记录。
  • 如果有记录的话，阐明该 GTID 的事务曾经运行，slave 会疏忽。
  • 如果没有记录的话，slave 就会执行该 GTID 对应的事务，并记录到 binlog 中。

如何开启 GTID 复制

  • 除传统复制须要开启的 binlog 相干参数之外，GTID 同步需额定开启如下参数设置，留神主从节点须要同步开启。
gtid_mode=on    # 开启 GTID
enforce-gtid-consistency=on  # 须要同步设置该参数
log-slave-updates=1      # 5.6 版本须要开启该参数

查看 GTID 相干参数

[root@GreatSQL][(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)
  • 参数简要阐明
参数名 含意介绍
binlog_gtid_simple_recovery 该参数是管制当 MySQL 服务重启或启动时候主动寻找 GTIDs 的值。
enforce_gtid_consistency 该参数是强制要求只容许复制事务平安的事务，请看下面步骤的具体限度。
gtid_executed 曾经执行过的 GTID 信息。
gtid_executed_compression_period 启用 GTID 时，服务器会定期在 mysql.gtid_executed 表上执行压缩。通过设置 gtid_executed_compression_period 零碎变量，能够管制压缩表之前容许的事务数，从而管制压缩率。设置为 0 时，则不进行压缩。
gtid_mode 是否开启 GTID 模式
gtid_next 示意下一个要执行的 GTID 信息
gtid_owned 该参数蕴含全局和 session，全局示意所有服务器领有 GTIDs，session 级别示意以后 client 领有的所有 GTIDs。
gtid_purged 曾经 purge 掉的 GTIDs，purged 掉的 GTIDs 会蕴含到 gtid_executed 中。
session_track_gtids 该参数是管制用于捕捉的 GTIDs 和在 OK PACKE 返回的跟踪器。

GTID 与传统模式建设复制时候语句的不同点

# 传统复制
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 复制
change master to master_host="127.0.0.1",master_port=3310,MASTER_USER='sync',MASTER_PASSWORD='GreatSQL',MASTER_AUTO_POSITION=1

GTID 同步在建设复制的时候，将传统复制由人为指定 binlog 的 pos 位点改为了 MASTER_AUTO_POSITION=1 主动获取 binlog 的 pos 位点。

GTID 同步状态简略解析

除了传统的查看 binlog 和 pos 值之外，GTID 模式能够更直观的查看某个事务执行的状况。

[root@GreatSQL][(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 相要害参数阐明
参数名 含意介绍
Retrieved_Gtid_Set Slave 节点曾经接管到的 Master 节点的 GTIDs
Executed_Gtid_Set Slave 节点曾经执行的 GTIDs
Auto_Position 主动获取 position 地位，显示为 1

总结

  • 篇幅所限临时写这么多，下周会持续出对于主从复制相干的内容，欢送追更，另外受限于集体能力和教训，内容不免错漏，若有谬误欢送评论区指出更正。

Enjoy GreatSQL :)

文章举荐：

GreatSQL 季报（2021.12.26）
https://mp.weixin.qq.com/s/FZ…

技术分享 |sysbench 压测工具用法浅析
https://mp.weixin.qq.com/s/m1…

故障剖析 | linux 磁盘 io 利用率高，剖析的正确姿态
https://mp.weixin.qq.com/s/7c…

技术分享 | 闪回在 MySQL 中的实现和改良
https://mp.weixin.qq.com/s/6j…

万答 #20，索引下推如何进行数据过滤
https://mp.weixin.qq.com/s/pt…

对于 GreatSQL

GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。

Gitee:
https://gitee.com/GreatSQL/Gr…

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

Bilibili：
https://space.bilibili.com/13…

微信 &QQ 群：
可搜寻增加 GreatSQL 社区助手微信好友，发送验证信息“加群”退出 GreatSQL/MGR 交换微信群

QQ 群：533341697
微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！

退出移动版