社群
學習
工具庫
AI工具
休閒
搜尋
繁体中文
目錄
一、GTID的相關特性
四、範例示範
1、從庫報主鍵重複(Errno: 1062)
2、從庫報找不到對應的被更新的記錄(Errno: 1032)
1、GTID是全域事務ID，簡化了主從架構的部署使得從庫不再需要關心log_file和log_pos
配置MySQL GTID 主從複製
、GTID
rrreee
2、由於事務ID的唯一性，使得將其他從庫的GTID應用到其它從庫成為可能，即提供了便利的failover
首頁 資料庫 mysql教程 MySQL GTID 錯誤處理總結

MySQL GTID 錯誤處理總結

黄舟
黄舟
Feb 13, 2017 am 11:20 AM

MySQL GTID是在傳統的mysql主從複製的基礎之上演化而來的產物，即透過UUID加上事務ID的方式來確保每一個事物的唯一性。這樣的操作方式使得我們不再需要關心所謂的log_file和log_Pos，只是簡單的告訴從庫，從哪個伺服器上去找主庫就OK了。簡化了主從的搭建以及failover的過程，同時比傳統的複製更安全可靠。由於GTID是連續沒有空洞的，因此主從庫出現資料衝突時，可以透過注入空事物的方式進行跳過。本文主要講述GTID主從架構的錯誤處理方式。

一、GTID的相關特性

配置MySQL GTID 主從複製
基於mysqldump搭建gtid主從幾個常見類型、GTID 事務衝突

    很多无法预料的情形导致mysql主从发生事务冲突，主从失败或停止的情形，即需要修复主从
    对于GTID方式的主从架构而言，更多的是处理事务冲突来修复主从
    GTID不支持通过传统设置sql_slave_skip_counter方法来跳过事务
    方法：通过注入空事务来填补事务空洞，等同于传统复制的(set global sql_slave_skip_counter = 1)
    步骤：
            stop slave；
            set gtid_next='xxxxxxx:N'; --指定下一个事务执行的版本，即想要跳过的GTID
            begin;
            commit;  --注入一个空事物
            set gtid_next='AUTOMATIC' --自动的寻找GTID事务。
            start slave; --开始同步
登入後複製

    1、主库新增记录，从库提示主键冲突
    2、主库对象可更新，从库无对应的对象可更新
    3、主库对象可删除，从库无对应的对象可删除
    4、通过延迟从修复主库意外删除的对象
    5、主库日志被purged的情形
登入後複製

当前演示的主从架构图
# mysqlrplshow --master=root:pass@192.168.1.233:3306 --discover-slaves-login=root:pass --verboseWARNING: Using a password on the command line interface can be insecure.
# master on 192.168.1.233: ... connected.
# Finding slaves for master: 192.168.1.233:3306

# Replication Topology Graph
192.168.1.233:3306 (MASTER)   |   +--- 192.168.1.245:3306 [IO: Yes, SQL: Yes] - (SLAVE)   |   +--- 192.168.1.247:3306 [IO: Yes, SQL: Yes] - (SLAVE)(root@192.168.1.233)[tempdb]>show slave hosts;+-----------+---------------+------+-----------+--------------------------------------+| Server_id | Host          | Port | Master_id | Slave_UUID                           |
+-----------+---------------+------+-----------+--------------------------------------+|       245 | 192.168.1.245 | 3306 |       233 | 78336cdc-8cfb-11e6-ba9f-000c29328504 ||       247 | 192.168.1.247 | 3306 |       233 | 13a26fc1-555a-11e6-b5e0-000c292e1642 |
+-----------+---------------+------+-----------+--------------------------------------+--演示的mysql版本
(root@192.168.1.233)[tempdb]>show variables like 'version';+---------------+------------+| Variable_name | Value      |
+---------------+------------+| version       | 5.7.12-log |
+---------------+------------+--查看gtid是否开启
(root@192.168.1.233)[tempdb]>show variables like '%gtid_mode%';+---------------+-------+| Variable_name | Value |
+---------------+-------+| gtid_mode     | ON    |
+---------------+-------+--主库上面可以看到基于gtid的dump线程，如下
(root@192.168.1.233)[tempdb]>show processlist;+----+------+-----------------------+--------+------------------+------+| Id | User | Host                  | db     | Command          | Time |
+----+------+-----------------------+--------+------------------+------+| 17 | repl | node245.edq.com:52685 | NULL   | Binlog Dump GTID | 2738 |
| 18 | repl | node247.edq.com:33516 | NULL   | Binlog Dump GTID | 2690 || 24 | root | localhost             | tempdb | Query            |    0 |
+----+------+-----------------------+--------+------------------+------+
登入後複製
登入後複製

四、範例示範

(root@Master)[tempdb]>create table t1 (
            -> id tinyint not null primary key,ename varchar(20),blog varchar(50));

(root@Master)[tempdb]>insert into t1 
            -> values(1,'leshami','http://blog.csdn.net/leshami');

(root@Master)[tempdb]>insert into t1 
            -> values(2,'robin','http://blog.csdn.net/robinson_0612');

(root@Master)[tempdb]>set sql_log_bin=off;

(root@Master)[tempdb]>delete from t1 where ename='robin';

(root@Master)[tempdb]>set sql_log_bin=on;

(root@Master)[tempdb]>insert into t1 
            -> values(2,'robin','http://blog.csdn.net/robinson_0612');

-- 从库状态报错，提示重复的primary key
(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************Last_Errno: 1062Last_Error: Could not execute Write_rows event on table tempdb.t1; Duplicate entry '2' for key 'PRIMARY', 
                        Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; 
                        the event's master log node233-binlog.000004, end_log_pos 4426
Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-90
 Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-89
     Auto_Position: 1

-- 如下解决方案，可以通过删除重库的这条记录
(root@Slave)[tempdb]>stop slave;

(root@Slave)[tempdb]>delete from t1 where ename='robin';

(root@Slave)[tempdb]>start slave;

(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-90
            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-90,
 78336cdc-8cfb-11e6-ba9f-000c29328504:1  --这里多了一个GTID，注意这个是从库上执行的，这里的UUID跟IP 245的UUID一致
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 

(root@Slave)[tempdb]>show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | 78336cdc-8cfb-11e6-ba9f-000c29328504 |
+---------------+--------------------------------------+
登入後複製
登入後複製

1、從庫報主鍵重複(Errno: 1062)

--首先在从库上删除leshami这条记录
(root@Slave)[tempdb]>delete from t1 where ename='leshami';

--接下来再主库尝试更新leshami这条记录
(root@Master)[tempdb]>update t1 set 
            -> blog='http://blog.csdn.net/robinson_0612' where ename='leshami';Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

-- 查看从库状态
(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Update_rows event on table tempdb.t1; Can't find record in 't1',                                Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;                            the event's master log node233-binlog.000004, end_log_pos 4769Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-91
Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-90,        78336cdc-8cfb-11e6-ba9f-000c29328504:1-2-- 通过mysqlbinlog在主服务器上寻找报错的binglog日志文件及位置，找到对应的SQL语句，如下所示
-- update中的where后面的部分为更新前的数据，set部分为更新后的数据，因此可以将更新前的数据插入到从库# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /data/node233-binlog.000004|grep -A '10' 4769#161009 13:46:34 server id 233 end_log_pos 4769 CRC32 0xb60df74e Update_rows: table id 147 flags: STMT_END_F### UPDATE `tempdb`.`t1`### WHERE###   @1=1 /* TINYINT meta=0 nullable=0 is_null=0 */###   @2='leshami' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */###   @3='http://blog.csdn.net/leshami' /* VARSTRING(50) meta=50 nullable=1 is_null=0 */### SET###   @1=1 /* TINYINT meta=0 nullable=0 is_null=0 */###   @2='leshami' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */###   @3='http://blog.csdn.net/robinson_0612' /* VARSTRING(50) meta=50 nullable=1 is_null=0 */# at 4769#161009 13:46:34 server id 233  end_log_pos 4800 CRC32 0xa9669811       Xid = 1749COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;# End of log file/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;   

(root@Slave)[tempdb]>select * from t1;
+----+-------+------------------------------------+
| id | ename | blog                               |
+----+-------+------------------------------------+
|  2 | robin | http://www.php.cn/ |
+----+-------+------------------------------------+

(root@Slave)[tempdb]>stop slave sql_thread;

(root@Slave)[tempdb]>insert into t1 values(1,'leshami','http://blog.csdn.net/leshami');

(root@Slave)[tempdb]>start slave sql_thread;

(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-91            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-91,                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-3                Auto_Position: 1
登入後複製
登入後複製

2、從庫報找不到對應的被更新的記錄(Errno: 1032)

-- 如果是在主库上删除记录，而从库上找不到对应的记录，则可以直接跳过该事务
-- 下面我们首选在从库上删除一条记录
(root@Slave)[tempdb]>delete from t1 where ename='robin';

-- 接下来在主库上删除该记录
(root@Master)[tempdb]>delete from t1 where ename='robin';

-- 从库端提示无法找到对应的记录
(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************Last_SQL_Error: Could not execute Delete_rows event on table tempdb.t1; Can't find record in 't1',                Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;                 the event's master log node233-binlog.000004, end_log_pos 5070Last_SQL_Error_Timestamp: 161009 15:08:06    Master_SSL_Crl: Master_SSL_Crlpath: 
Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-92
 Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-91,                    78336cdc-8cfb-11e6-ba9f-000c29328504:1-4     Auto_Position: 1      -- 下面通过注入空事务来跳过
(root@Slave)[tempdb]>stop slave sql_thread;

(root@Slave)[tempdb]>set gtid_next='1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:92';

(root@Slave)[tempdb]>begin;commit;

(root@Slave)[tempdb]>set gtid_next='AUTOMATIC';

(root@Slave)[tempdb]>start slave sql_thread;

(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-92            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-92,                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4                Auto_Position: 1         Replicate_Rewrite_DB:                  Channel_Name:            Master_TLS_Version:
登入後複製
登入後複製

-- 主库上面新增表及记录             
(root@Master)[tempdb]>create table t2 (id tinyint not null primary key, 
        -> ename varchar(20),blog varchar(50));(root@Master)[tempdb]>insert into t2  
            -> values(1,'leshami','http://blog.csdn.net/leshami');(root@Master)[tempdb]>insert into t2  
            -> values(2,'robin','http://blog.csdn.net/robinson_0612');(root@Master)[tempdb]>select * from t2;
+----+---------+------------------------------------+
| id | ename   | blog                               |
+----+---------+------------------------------------+
|  1 | leshami | http://www.php.cn/       |
|  2 | robin   | http://www.php.cn/ |
+----+---------+------------------------------------+

--先将从库配置为延迟从
(root@Slave)[tempdb]>stop slave sql_thread;
Query OK, 0 rows affected (0.01 sec)

(root@Slave)[tempdb]>CHANGE MASTER TO MASTER_DELAY = 300;
Query OK, 0 rows affected (0.00 sec)

(root@Slave)[tempdb]>start slave sql_thread;
Query OK, 0 rows affected (0.02 sec)

(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************             Slave_IO_Running: Yes            Slave_SQL_Running: Yes                    SQL_Delay: 300  root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-99            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-99,                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4                Auto_Position: 1--查看主库上的binglog gtid
(root@Master)[tempdb]>show master status\G*************************** 1. row ***************************             File: node233-binlog.000004         Position: 6970     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-99
1 row in set (0.00 sec)

--在主库上truncate t2
(root@Master)[tempdb]>truncate table t2;
Query OK, 0 rows affected (0.03 sec)

--再次查看主库上的binglog gtid，有99变成了100，这个100即是我们需要跳过的ID
(root@Master)[tempdb]>show master status\G*************************** 1. row ***************************             File: node233-binlog.000004         Position: 7121     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100
1 row in set (0.00 sec)

--从库上跳过被意外truncate的事务
(root@Slave)[tempdb]>stop slave sql_thread;
Query OK, 0 rows affected (0.01 sec)

(root@Slave)[tempdb]>set gtid_next='1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:100';
Query OK, 0 rows affected (0.00 sec)

(root@Slave)[tempdb]>begin;commit;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

(root@Slave)[tempdb]>set gtid_next='AUTOMATIC';
Query OK, 0 rows affected (0.00 sec)

(root@Slave)[tempdb]>start slave sql_thread;
Query OK, 0 rows affected (0.02 sec)

(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: Master                  Master_User: repl                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: node233-binlog.000004          Read_Master_Log_Pos: 7121               Relay_Log_File: node245-relay-bin.000003                Relay_Log_Pos: 2982        Relay_Master_Log_File: node233-binlog.000004             Slave_IO_Running: Yes            Slave_SQL_Running: Yes             ...........................                    Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-100            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100,                                                             78336cdc-8cfb-11e6-ba9f-000c29328504:1-4                Auto_Position: 1-- 很多时候我们并不知道表何时被truncate，因此可以从binlog日志得到其gtid
-- 如下所示，可以得到这串 SET @@SESSION.GTID_NEXT= '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:100'
-- 100即为这个truncate对应的gtid的事务号# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /data/node233-binlog.000004|grep -i \> "truncate table t2" -A3 -B10  ###   @3='http://blog.csdn.net/robinson_0612' /* VARSTRING(50) meta=50 nullable=1 is_null=0 */# at 6939#161009 18:04:58 server id 233  end_log_pos 6970 CRC32 0x71c5121c     Xid = 1775COMMIT/*!*/;# at 6970#161009 18:08:42 server id 233 end_log_pos 7035 CRC32 0x00ba9437 GTID last_committed=26 sequence_number=27SET @@SESSION.GTID_NEXT= '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:100'/*!*/;# at 7035#161009 18:08:42 server id 233 end_log_pos 7121 CRC32 0x5a8b9723 Query thread_id=26 exec_time=0 error_code=0SET TIMESTAMP=1476007722/*!*/;
truncate table t2
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
登入後複製
登入後複製

3、從庫找不到對應的被刪除的記錄(Errno: 1032)

-- 首先停止从库，模拟从库被意外宕机
(root@Slave)[tempdb]>stop slave;
Query OK, 0 rows affected (0.08 sec)

--在主库上进行相应的操作
--此时主库上的gtid_purged为空
(root@Master)[tempdb]>show variables like '%gtid_purged%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_purged   |       |
+---------------+-------+

--查看主库binlog
(root@Master)[tempdb]>show binary logs;
+-----------------------+-----------+
| Log_name              | File_size |
+-----------------------+-----------+
| node233-binlog.000001 |   1362104 |
| node233-binlog.000002 |      1331 |
| node233-binlog.000003 |       217 |
| node233-binlog.000004 |      7121 |
+-----------------------+-----------+

(root@Master)[tempdb]>select * from t1;
+----+---------+------------------------------------+
| id | ename   | blog                               |
+----+---------+------------------------------------+
|  1 | leshami | http://www.php.cn/ |
|  2 | robin   | http://www.php.cn/       |
+----+---------+------------------------------------+

--从主库删除记录
(root@Master)[tempdb]>delete from t1;

--切换日志
(root@Master)[tempdb]>flush logs;

--新增记录
(root@Master)[tempdb]>insert into t1 values(1,    -> 'xuputi','http://blog.csdn.net/leshami');(root@Master)[tempdb]>show binary logs;
+-----------------------+-----------+
| Log_name              | File_size |
+-----------------------+-----------+
| node233-binlog.000001 |   1362104 |
| node233-binlog.000002 |      1331 |
| node233-binlog.000003 |       217 |
| node233-binlog.000004 |      7513 |
| node233-binlog.000005 |       490 |
+-----------------------+-----------+

--清理binlog
(root@Master)[tempdb]>purge binary logs to 'node233-binlog.000005';
Query OK, 0 rows affected (0.01 sec)

(root@Master)[tempdb]>show binary logs;
+-----------------------+-----------+
| Log_name              | File_size |
+-----------------------+-----------+
| node233-binlog.000005 |       490 |
+-----------------------+-----------+

--此时可以看到相应的gtid_purged值
(root@Master)[tempdb]>show variables like '%gtid_purged%';
+---------------+--------------------------------------------+
| Variable_name | Value                                      |
+---------------+--------------------------------------------+
| gtid_purged   | 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101 |
+---------------+--------------------------------------------+

--下面启动从库
(root@Slave)[tempdb]>start slave;
Query OK, 0 rows affected (0.00 sec)

--从库状态提示有日志被purged
(root@Slave)[tempdb]>show slave status\G*************************** 1. row ***************************               Slave_IO_State:                   Master_Host: Master                  Master_User: repl                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: node233-binlog.000004          Read_Master_Log_Pos: 7121               Relay_Log_File: node245-relay-bin.000003                Relay_Log_Pos: 3133        Relay_Master_Log_File: node233-binlog.000004             Slave_IO_Running: No            Slave_SQL_Running: Yes                    ...............                Last_IO_Errno: 1236                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log:                'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1,                  but the master has purged binary logs containing GTIDs that the slave requires.'                       ..................           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-100            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100,                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4                Auto_Position: 1-- 从库上gtid_purged参数，此时为75
(root@Slave)[tempdb]>show variables like '%gtid_purged%';
+---------------+-------------------------------------------+
| Variable_name | Value                                     |
+---------------+-------------------------------------------+
| gtid_purged   | 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-75 |
+---------------+-------------------------------------------+                

--停止从库
(root@Slave)[tempdb]>stop slave;
Query OK, 0 rows affected (0.01 sec)

--下面尝试使用gtid_purged进行跳过事务，，如下，提示仅仅当GLOBAL.GTID_EXECUTED为空才能被设置
(root@Slave)[tempdb]>set global gtid_purged = '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101';
ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

--如下查看，已经存在被执行的gtid，即gtid_executed肯定是不为空，且这些gtid记录在从库的binary log中
(root@Slave)[tempdb]>show global variables like '%gtid_executed%'\G*************************** 1. row ***************************Variable_name: gtid_executed        Value: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100,               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4*************************** 2. row ***************************Variable_name: gtid_executed_compression_period        Value: 1000--下面我们在从库上reset master，即清空从库binlog
(root@Slave)[tempdb]>reset master;
Query OK, 0 rows affected (0.05 sec)

--再次查看gtid_executed已经为空值
(root@Slave)[tempdb]>show global variables like '%gtid_executed%'\G*************************** 1. row ***************************Variable_name: gtid_executed        Value: *************************** 2. row ***************************Variable_name: gtid_executed_compression_period        Value: 1000--此时再次设置gtid_purged的值
(root@Slave)[tempdb]>set global gtid_purged = '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101';
Query OK, 0 rows affected (0.01 sec)

--启动从库
(root@Slave)[tempdb]>start slave;
Query OK, 0 rows affected (0.03 sec)

--提示有重复记录，如下所示
--是由于我们在从库停止期间delete这个事务没有被从库的relay log接受到
--其次主从的binlog又被purged，而且从库启动后，执行了gtid_purged，因此主库上新增的记录在从库上提示主键重复
(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: Master                  Master_User: repl                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: node233-binlog.000005          Read_Master_Log_Pos: 490               Relay_Log_File: node245-relay-bin.000004                Relay_Log_Pos: 417        Relay_Master_Log_File: node233-binlog.000005             Slave_IO_Running: Yes            Slave_SQL_Running: No                ................               Last_SQL_Error: Could not execute Write_rows event on table tempdb.t1; 
 Duplicate entry '1' for key 'PRIMARY', Error_code: 1062;
 handler error HA_ERR_FOUND_DUPP_KEY; the event's master log node233-binlog.000005, end_log_pos 459           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-100:102            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101                Auto_Position: 1--在从库上删除id为1的记录
(root@Slave)[tempdb]>delete from t1 where id=1;
Query OK, 1 row affected (0.05 sec)

--启动从库的sql_thread线程
(root@Slave)[tempdb]>start slave sql_thread;
Query OK, 0 rows affected (0.02 sec)

--再次查看正常
(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: Master                  Master_User: repl                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: node233-binlog.000005          Read_Master_Log_Pos: 490               Relay_Log_File: node245-relay-bin.000004                Relay_Log_Pos: 713        Relay_Master_Log_File: node233-binlog.000005             Slave_IO_Running: Yes            Slave_SQL_Running: Yes--上面的这个示例，主要是演示我们使用gtid_purged方式来达到跳过事务的目的
--事实上，主从的数据已经不一致了，应根据实际的需要考虑是否进行相应的修复
登入後複製
登入後複製

4、延遲從修復主庫意外truncate

    很多无法预料的情形导致mysql主从发生事务冲突，主从失败或停止的情形，即需要修复主从
    对于GTID方式的主从架构而言，更多的是处理事务冲突来修复主从
    GTID不支持通过传统设置sql_slave_skip_counter方法来跳过事务
    方法：通过注入空事务来填补事务空洞，等同于传统复制的(set global sql_slave_skip_counter = 1)
    步骤：
            stop slave；
            set gtid_next='xxxxxxx:N'; --指定下一个事务执行的版本，即想要跳过的GTID
            begin;
            commit;  --注入一个空事物
            set gtid_next='AUTOMATIC' --自动的寻找GTID事务。
            start slave; --开始同步
登入後複製

5、主庫binlog被purge的情形(Errno: 1236)

    1、主库新增记录，从库提示主键冲突
    2、主库对象可更新，从库无对应的对象可更新
    3、主库对象可删除，从库无对应的对象可删除
    4、通过延迟从修复主库意外删除的对象
    5、主库日志被purged的情形
登入後複製

五、小結

1、GTID是全域事務ID，簡化了主從架構的部署使得從庫不再需要關心log_file和log_pos

2、由於事務ID的唯一性，使得將其他從庫的GTID應用到其它從庫成為可能，即提供了便利的failover

3、GTID是連續的，非空洞性的，因此，對於衝突的情形，需要注入空的事務來實現
4、可以通過配置延遲從來避免主庫上意外的刪除對象導致的人為錯誤

MySQL GTID是在傳統的mysql主從複製的基礎之上演化而來的產物，即透過UUID加上事務ID的方式來確保每一個事物的唯一性。這樣的操作方式使得我們不再需要關心所謂的log_file和log_Pos，只是簡單的告訴從庫，從哪個伺服器上去找主庫就OK了。簡化了主從的搭建以及failover的過程，同時比傳統的複製更安全可靠。由於GTID是連續沒有空洞的，因此主從庫出現資料衝突時，可以透過注入空事物的方式進行跳過。本文主要講述GTID主從架構的錯誤處理方式。

一、GTID的相關特性

配置MySQL GTID 主從複製

基於mysqldump搭建gtid主從


二、GTID如何跳過事務衝突

当前演示的主从架构图
# mysqlrplshow --master=root:pass@192.168.1.233:3306 --discover-slaves-login=root:pass --verboseWARNING: Using a password on the command line interface can be insecure.
# master on 192.168.1.233: ... connected.
# Finding slaves for master: 192.168.1.233:3306

# Replication Topology Graph
192.168.1.233:3306 (MASTER)   |   +--- 192.168.1.245:3306 [IO: Yes, SQL: Yes] - (SLAVE)   |   +--- 192.168.1.247:3306 [IO: Yes, SQL: Yes] - (SLAVE)(root@192.168.1.233)[tempdb]>show slave hosts;+-----------+---------------+------+-----------+--------------------------------------+| Server_id | Host          | Port | Master_id | Slave_UUID                           |
+-----------+---------------+------+-----------+--------------------------------------+|       245 | 192.168.1.245 | 3306 |       233 | 78336cdc-8cfb-11e6-ba9f-000c29328504 ||       247 | 192.168.1.247 | 3306 |       233 | 13a26fc1-555a-11e6-b5e0-000c292e1642 |
+-----------+---------------+------+-----------+--------------------------------------+--演示的mysql版本
(root@192.168.1.233)[tempdb]>show variables like 'version';+---------------+------------+| Variable_name | Value      |
+---------------+------------+| version       | 5.7.12-log |
+---------------+------------+--查看gtid是否开启
(root@192.168.1.233)[tempdb]>show variables like '%gtid_mode%';+---------------+-------+| Variable_name | Value |
+---------------+-------+| gtid_mode     | ON    |
+---------------+-------+--主库上面可以看到基于gtid的dump线程，如下
(root@192.168.1.233)[tempdb]>show processlist;+----+------+-----------------------+--------+------------------+------+| Id | User | Host                  | db     | Command          | Time |
+----+------+-----------------------+--------+------------------+------+| 17 | repl | node245.edq.com:52685 | NULL   | Binlog Dump GTID | 2738 |
| 18 | repl | node247.edq.com:33516 | NULL   | Binlog Dump GTID | 2690 || 24 | root | localhost             | tempdb | Query            |    0 |
+----+------+-----------------------+--------+------------------+------+
登入後複製
登入後複製

、GTID

二、GTID如何跳過事務衝突

(root@Master)[tempdb]>create table t1 (
            -> id tinyint not null primary key,ename varchar(20),blog varchar(50));

(root@Master)[tempdb]>insert into t1 
            -> values(1,'leshami','http://blog.csdn.net/leshami');

(root@Master)[tempdb]>insert into t1 
            -> values(2,'robin','http://blog.csdn.net/robinson_0612');

(root@Master)[tempdb]>set sql_log_bin=off;

(root@Master)[tempdb]>delete from t1 where ename='robin';

(root@Master)[tempdb]>set sql_log_bin=on;

(root@Master)[tempdb]>insert into t1 
            -> values(2,'robin','http://blog.csdn.net/robinson_0612');

-- 从库状态报错，提示重复的primary key
(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************Last_Errno: 1062Last_Error: Could not execute Write_rows event on table tempdb.t1; Duplicate entry '2' for key 'PRIMARY', 
                        Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; 
                        the event's master log node233-binlog.000004, end_log_pos 4426
Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-90
 Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-89
     Auto_Position: 1

-- 如下解决方案，可以通过删除重库的这条记录
(root@Slave)[tempdb]>stop slave;

(root@Slave)[tempdb]>delete from t1 where ename='robin';

(root@Slave)[tempdb]>start slave;

(root@Slave)[tempdb]>show slave status \G
*************************** 1. row ***************************
           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-90
            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-90,
 78336cdc-8cfb-11e6-ba9f-000c29328504:1  --这里多了一个GTID，注意这个是从库上执行的，这里的UUID跟IP 245的UUID一致
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 

(root@Slave)[tempdb]>show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | 78336cdc-8cfb-11e6-ba9f-000c29328504 |
+---------------+--------------------------------------+
登入後複製
登入後複製

、GTID。四、範例示範

--首先在从库上删除leshami这条记录
(root@Slave)[tempdb]>delete from t1 where ename='leshami';

--接下来再主库尝试更新leshami这条记录
(root@Master)[tempdb]>update t1 set 
            -> blog='http://blog.csdn.net/robinson_0612' where ename='leshami';Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

-- 查看从库状态
(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Update_rows event on table tempdb.t1; Can't find record in 't1',                                Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;                            the event's master log node233-binlog.000004, end_log_pos 4769Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-91
Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-90,        78336cdc-8cfb-11e6-ba9f-000c29328504:1-2-- 通过mysqlbinlog在主服务器上寻找报错的binglog日志文件及位置，找到对应的SQL语句，如下所示
-- update中的where后面的部分为更新前的数据，set部分为更新后的数据，因此可以将更新前的数据插入到从库# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /data/node233-binlog.000004|grep -A '10' 4769#161009 13:46:34 server id 233 end_log_pos 4769 CRC32 0xb60df74e Update_rows: table id 147 flags: STMT_END_F### UPDATE `tempdb`.`t1`### WHERE###   @1=1 /* TINYINT meta=0 nullable=0 is_null=0 */###   @2='leshami' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */###   @3='http://blog.csdn.net/leshami' /* VARSTRING(50) meta=50 nullable=1 is_null=0 */### SET###   @1=1 /* TINYINT meta=0 nullable=0 is_null=0 */###   @2='leshami' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */###   @3='http://blog.csdn.net/robinson_0612' /* VARSTRING(50) meta=50 nullable=1 is_null=0 */# at 4769#161009 13:46:34 server id 233  end_log_pos 4800 CRC32 0xa9669811       Xid = 1749COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;# End of log file/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;   

(root@Slave)[tempdb]>select * from t1;
+----+-------+------------------------------------+
| id | ename | blog                               |
+----+-------+------------------------------------+
|  2 | robin | http://www.php.cn/ |
+----+-------+------------------------------------+

(root@Slave)[tempdb]>stop slave sql_thread;

(root@Slave)[tempdb]>insert into t1 values(1,'leshami','http://blog.csdn.net/leshami');

(root@Slave)[tempdb]>start slave sql_thread;

(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-91            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-91,                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-3                Auto_Position: 1
登入後複製
登入後複製

1、從庫報主鍵重複(Errno: 1062)

-- 如果是在主库上删除记录，而从库上找不到对应的记录，则可以直接跳过该事务
-- 下面我们首选在从库上删除一条记录
(root@Slave)[tempdb]>delete from t1 where ename='robin';

-- 接下来在主库上删除该记录
(root@Master)[tempdb]>delete from t1 where ename='robin';

-- 从库端提示无法找到对应的记录
(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************Last_SQL_Error: Could not execute Delete_rows event on table tempdb.t1; Can't find record in 't1',                Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;                 the event's master log node233-binlog.000004, end_log_pos 5070Last_SQL_Error_Timestamp: 161009 15:08:06    Master_SSL_Crl: Master_SSL_Crlpath: 
Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-92
 Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-91,                    78336cdc-8cfb-11e6-ba9f-000c29328504:1-4     Auto_Position: 1      -- 下面通过注入空事务来跳过
(root@Slave)[tempdb]>stop slave sql_thread;

(root@Slave)[tempdb]>set gtid_next='1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:92';

(root@Slave)[tempdb]>begin;commit;

(root@Slave)[tempdb]>set gtid_next='AUTOMATIC';

(root@Slave)[tempdb]>start slave sql_thread;

(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-92            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-92,                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4                Auto_Position: 1         Replicate_Rewrite_DB:                  Channel_Name:            Master_TLS_Version:
登入後複製
登入後複製

2、從庫報找不到對應的被更新的記錄(Errno: 1032)

-- 主库上面新增表及记录             
(root@Master)[tempdb]>create table t2 (id tinyint not null primary key, 
        -> ename varchar(20),blog varchar(50));(root@Master)[tempdb]>insert into t2  
            -> values(1,'leshami','http://blog.csdn.net/leshami');(root@Master)[tempdb]>insert into t2  
            -> values(2,'robin','http://blog.csdn.net/robinson_0612');(root@Master)[tempdb]>select * from t2;
+----+---------+------------------------------------+
| id | ename   | blog                               |
+----+---------+------------------------------------+
|  1 | leshami | http://www.php.cn/       |
|  2 | robin   | http://www.php.cn/ |
+----+---------+------------------------------------+

--先将从库配置为延迟从
(root@Slave)[tempdb]>stop slave sql_thread;
Query OK, 0 rows affected (0.01 sec)

(root@Slave)[tempdb]>CHANGE MASTER TO MASTER_DELAY = 300;
Query OK, 0 rows affected (0.00 sec)

(root@Slave)[tempdb]>start slave sql_thread;
Query OK, 0 rows affected (0.02 sec)

(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************             Slave_IO_Running: Yes            Slave_SQL_Running: Yes                    SQL_Delay: 300  root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-99            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-99,                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4                Auto_Position: 1--查看主库上的binglog gtid
(root@Master)[tempdb]>show master status\G*************************** 1. row ***************************             File: node233-binlog.000004         Position: 6970     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-99
1 row in set (0.00 sec)

--在主库上truncate t2
(root@Master)[tempdb]>truncate table t2;
Query OK, 0 rows affected (0.03 sec)

--再次查看主库上的binglog gtid，有99变成了100，这个100即是我们需要跳过的ID
(root@Master)[tempdb]>show master status\G*************************** 1. row ***************************             File: node233-binlog.000004         Position: 7121     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100
1 row in set (0.00 sec)

--从库上跳过被意外truncate的事务
(root@Slave)[tempdb]>stop slave sql_thread;
Query OK, 0 rows affected (0.01 sec)

(root@Slave)[tempdb]>set gtid_next='1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:100';
Query OK, 0 rows affected (0.00 sec)

(root@Slave)[tempdb]>begin;commit;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

(root@Slave)[tempdb]>set gtid_next='AUTOMATIC';
Query OK, 0 rows affected (0.00 sec)

(root@Slave)[tempdb]>start slave sql_thread;
Query OK, 0 rows affected (0.02 sec)

(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: Master                  Master_User: repl                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: node233-binlog.000004          Read_Master_Log_Pos: 7121               Relay_Log_File: node245-relay-bin.000003                Relay_Log_Pos: 2982        Relay_Master_Log_File: node233-binlog.000004             Slave_IO_Running: Yes            Slave_SQL_Running: Yes             ...........................                    Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-100            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100,                                                             78336cdc-8cfb-11e6-ba9f-000c29328504:1-4                Auto_Position: 1-- 很多时候我们并不知道表何时被truncate，因此可以从binlog日志得到其gtid
-- 如下所示，可以得到这串 SET @@SESSION.GTID_NEXT= '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:100'
-- 100即为这个truncate对应的gtid的事务号# mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /data/node233-binlog.000004|grep -i \> "truncate table t2" -A3 -B10  ###   @3='http://blog.csdn.net/robinson_0612' /* VARSTRING(50) meta=50 nullable=1 is_null=0 */# at 6939#161009 18:04:58 server id 233  end_log_pos 6970 CRC32 0x71c5121c     Xid = 1775COMMIT/*!*/;# at 6970#161009 18:08:42 server id 233 end_log_pos 7035 CRC32 0x00ba9437 GTID last_committed=26 sequence_number=27SET @@SESSION.GTID_NEXT= '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:100'/*!*/;# at 7035#161009 18:08:42 server id 233 end_log_pos 7121 CRC32 0x5a8b9723 Query thread_id=26 exec_time=0 error_code=0SET TIMESTAMP=1476007722/*!*/;
truncate table t2
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
登入後複製
登入後複製

3、從庫找不到對應的被刪除的記錄(Errno: 1032)

-- 首先停止从库，模拟从库被意外宕机
(root@Slave)[tempdb]>stop slave;
Query OK, 0 rows affected (0.08 sec)

--在主库上进行相应的操作
--此时主库上的gtid_purged为空
(root@Master)[tempdb]>show variables like '%gtid_purged%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_purged   |       |
+---------------+-------+

--查看主库binlog
(root@Master)[tempdb]>show binary logs;
+-----------------------+-----------+
| Log_name              | File_size |
+-----------------------+-----------+
| node233-binlog.000001 |   1362104 |
| node233-binlog.000002 |      1331 |
| node233-binlog.000003 |       217 |
| node233-binlog.000004 |      7121 |
+-----------------------+-----------+

(root@Master)[tempdb]>select * from t1;
+----+---------+------------------------------------+
| id | ename   | blog                               |
+----+---------+------------------------------------+
|  1 | leshami | http://www.php.cn/ |
|  2 | robin   | http://www.php.cn/       |
+----+---------+------------------------------------+

--从主库删除记录
(root@Master)[tempdb]>delete from t1;

--切换日志
(root@Master)[tempdb]>flush logs;

--新增记录
(root@Master)[tempdb]>insert into t1 values(1,    -> 'xuputi','http://blog.csdn.net/leshami');(root@Master)[tempdb]>show binary logs;
+-----------------------+-----------+
| Log_name              | File_size |
+-----------------------+-----------+
| node233-binlog.000001 |   1362104 |
| node233-binlog.000002 |      1331 |
| node233-binlog.000003 |       217 |
| node233-binlog.000004 |      7513 |
| node233-binlog.000005 |       490 |
+-----------------------+-----------+

--清理binlog
(root@Master)[tempdb]>purge binary logs to 'node233-binlog.000005';
Query OK, 0 rows affected (0.01 sec)

(root@Master)[tempdb]>show binary logs;
+-----------------------+-----------+
| Log_name              | File_size |
+-----------------------+-----------+
| node233-binlog.000005 |       490 |
+-----------------------+-----------+

--此时可以看到相应的gtid_purged值
(root@Master)[tempdb]>show variables like '%gtid_purged%';
+---------------+--------------------------------------------+
| Variable_name | Value                                      |
+---------------+--------------------------------------------+
| gtid_purged   | 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101 |
+---------------+--------------------------------------------+

--下面启动从库
(root@Slave)[tempdb]>start slave;
Query OK, 0 rows affected (0.00 sec)

--从库状态提示有日志被purged
(root@Slave)[tempdb]>show slave status\G*************************** 1. row ***************************               Slave_IO_State:                   Master_Host: Master                  Master_User: repl                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: node233-binlog.000004          Read_Master_Log_Pos: 7121               Relay_Log_File: node245-relay-bin.000003                Relay_Log_Pos: 3133        Relay_Master_Log_File: node233-binlog.000004             Slave_IO_Running: No            Slave_SQL_Running: Yes                    ...............                Last_IO_Errno: 1236                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log:                'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1,                  but the master has purged binary logs containing GTIDs that the slave requires.'                       ..................           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-100            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100,                               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4                Auto_Position: 1-- 从库上gtid_purged参数，此时为75
(root@Slave)[tempdb]>show variables like '%gtid_purged%';
+---------------+-------------------------------------------+
| Variable_name | Value                                     |
+---------------+-------------------------------------------+
| gtid_purged   | 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-75 |
+---------------+-------------------------------------------+                

--停止从库
(root@Slave)[tempdb]>stop slave;
Query OK, 0 rows affected (0.01 sec)

--下面尝试使用gtid_purged进行跳过事务，，如下，提示仅仅当GLOBAL.GTID_EXECUTED为空才能被设置
(root@Slave)[tempdb]>set global gtid_purged = '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101';
ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

--如下查看，已经存在被执行的gtid，即gtid_executed肯定是不为空，且这些gtid记录在从库的binary log中
(root@Slave)[tempdb]>show global variables like '%gtid_executed%'\G*************************** 1. row ***************************Variable_name: gtid_executed        Value: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-100,               78336cdc-8cfb-11e6-ba9f-000c29328504:1-4*************************** 2. row ***************************Variable_name: gtid_executed_compression_period        Value: 1000--下面我们在从库上reset master，即清空从库binlog
(root@Slave)[tempdb]>reset master;
Query OK, 0 rows affected (0.05 sec)

--再次查看gtid_executed已经为空值
(root@Slave)[tempdb]>show global variables like '%gtid_executed%'\G*************************** 1. row ***************************Variable_name: gtid_executed        Value: *************************** 2. row ***************************Variable_name: gtid_executed_compression_period        Value: 1000--此时再次设置gtid_purged的值
(root@Slave)[tempdb]>set global gtid_purged = '1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101';
Query OK, 0 rows affected (0.01 sec)

--启动从库
(root@Slave)[tempdb]>start slave;
Query OK, 0 rows affected (0.03 sec)

--提示有重复记录，如下所示
--是由于我们在从库停止期间delete这个事务没有被从库的relay log接受到
--其次主从的binlog又被purged，而且从库启动后，执行了gtid_purged，因此主库上新增的记录在从库上提示主键重复
(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: Master                  Master_User: repl                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: node233-binlog.000005          Read_Master_Log_Pos: 490               Relay_Log_File: node245-relay-bin.000004                Relay_Log_Pos: 417        Relay_Master_Log_File: node233-binlog.000005             Slave_IO_Running: Yes            Slave_SQL_Running: No                ................               Last_SQL_Error: Could not execute Write_rows event on table tempdb.t1; 
 Duplicate entry '1' for key 'PRIMARY', Error_code: 1062;
 handler error HA_ERR_FOUND_DUPP_KEY; the event's master log node233-binlog.000005, end_log_pos 459           Retrieved_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:76-100:102            Executed_Gtid_Set: 1b64c25d-8d2b-11e6-9ac0-000c29b82d0d:1-101                Auto_Position: 1--在从库上删除id为1的记录
(root@Slave)[tempdb]>delete from t1 where id=1;
Query OK, 1 row affected (0.05 sec)

--启动从库的sql_thread线程
(root@Slave)[tempdb]>start slave sql_thread;
Query OK, 0 rows affected (0.02 sec)

--再次查看正常
(root@Slave)[tempdb]>show slave status \G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: Master                  Master_User: repl                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: node233-binlog.000005          Read_Master_Log_Pos: 490               Relay_Log_File: node245-relay-bin.000004                Relay_Log_Pos: 713        Relay_Master_Log_File: node233-binlog.000005             Slave_IO_Running: Yes            Slave_SQL_Running: Yes--上面的这个示例，主要是演示我们使用gtid_purged方式来达到跳过事务的目的
--事实上，主从的数据已经不一致了，应根据实际的需要考虑是否进行相应的修复
登入後複製
登入後複製
4、延遲從修復主庫意外truncate

rrreee

5、主庫binlog被purge的情形(Errno: 1236)

rrreee

五、1 、GTID是全域事務ID，簡化了主從架構的部署使得從庫不再需要關心log_file和log_pos

2、由於事務ID的唯一性，使得將其他從庫的GTID應用到其它從庫成為可能，即提供了便利的failover

3、GTID是連續的，非空洞性的，因此，對於衝突的情形，需要注入空的事務來實現

4、可以通過配置延遲從來避免主庫上意外的刪除對象導致的人為錯誤

以上就是的內容，更多相關內容請關注PHP中文網（www.php.cn）！

本網站聲明
本文內容由網友自願投稿，版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容，請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序，用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具，輕鬆在任何影片中換臉！

顯示更多

熱門文章

Windows 11 KB5054979中的新功能以及如何解決更新問題
3 週前 By DDD
如何修復KB5055523無法在Windows 11中安裝？
2 週前 By DDD
Inzoi：如何申請學校和大學
3 週前 By DDD
如何修復KB5055518無法在Windows 10中安裝？
2 週前 By DDD
Roblox：Dead Rails - 如何召喚和擊敗Nikola Tesla
4 週前 By 尊渡假赌尊渡假赌尊渡假赌
顯示更多

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版，非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)

顯示更多

熱門話題

gmail信箱登陸入口在哪裡
7801
15
Java教學
1644
14
CakePHP 教程
1402
52
Laravel 教程
1299
25
PHP教程
1236
29
顯示更多
Related knowledge
MySQL：世界上最受歡迎的數據庫的簡介 MySQL：世界上最受歡迎的數據庫的簡介 Apr 12, 2025 am 12:18 AM

MySQL是一種開源的關係型數據庫管理系統，主要用於快速、可靠地存儲和檢索數據。其工作原理包括客戶端請求、查詢解析、執行查詢和返回結果。使用示例包括創建表、插入和查詢數據，以及高級功能如JOIN操作。常見錯誤涉及SQL語法、數據類型和權限問題，優化建議包括使用索引、優化查詢和分錶分區。

apache怎麼連接數據庫 apache怎麼連接數據庫 Apr 13, 2025 pm 01:03 PM

Apache 連接數據庫需要以下步驟：安裝數據庫驅動程序。配置 web.xml 文件以創建連接池。創建 JDBC 數據源，指定連接設置。從 Java 代碼中使用 JDBC API 訪問數據庫，包括獲取連接、創建語句、綁定參數、執行查詢或更新以及處理結果。

MySQL的位置：數據庫和編程 MySQL的位置：數據庫和編程 Apr 13, 2025 am 12:18 AM

MySQL在數據庫和編程中的地位非常重要，它是一個開源的關係型數據庫管理系統，廣泛應用於各種應用場景。 1）MySQL提供高效的數據存儲、組織和檢索功能，支持Web、移動和企業級系統。 2）它使用客戶端-服務器架構，支持多種存儲引擎和索引優化。 3）基本用法包括創建表和插入數據，高級用法涉及多表JOIN和復雜查詢。 4）常見問題如SQL語法錯誤和性能問題可以通過EXPLAIN命令和慢查詢日誌調試。 5）性能優化方法包括合理使用索引、優化查詢和使用緩存，最佳實踐包括使用事務和PreparedStatemen

為什麼要使用mysql？利益和優勢 為什麼要使用mysql？利益和優勢 Apr 12, 2025 am 12:17 AM

選擇MySQL的原因是其性能、可靠性、易用性和社區支持。 1.MySQL提供高效的數據存儲和檢索功能，支持多種數據類型和高級查詢操作。 2.採用客戶端-服務器架構和多種存儲引擎，支持事務和查詢優化。 3.易於使用，支持多種操作系統和編程語言。 4.擁有強大的社區支持，提供豐富的資源和解決方案。

MySQL的角色：Web應用程序中的數據庫 MySQL的角色：Web應用程序中的數據庫 Apr 17, 2025 am 12:23 AM

MySQL在Web應用中的主要作用是存儲和管理數據。 1.MySQL高效處理用戶信息、產品目錄和交易記錄等數據。 2.通過SQL查詢，開發者能從數據庫提取信息生成動態內容。 3.MySQL基於客戶端-服務器模型工作，確保查詢速度可接受。

docker怎麼啟動mysql docker怎麼啟動mysql Apr 15, 2025 pm 12:09 PM

在 Docker 中啟動 MySQL 的過程包含以下步驟：拉取 MySQL 鏡像創建並啟動容器，設置根用戶密碼並映射端口驗證連接創建數據庫和用戶授予對數據庫的所有權限

laravel入門實例 laravel入門實例 Apr 18, 2025 pm 12:45 PM

Laravel 是一款 PHP 框架，用於輕鬆構建 Web 應用程序。它提供一系列強大的功能，包括：安裝： 使用 Composer 全局安裝 Laravel CLI，並在項目目錄中創建應用程序。路由： 在 routes/web.php 中定義 URL 和處理函數之間的關係。視圖： 在 resources/views 中創建視圖以呈現應用程序的界面。數據庫集成： 提供與 MySQL 等數據庫的開箱即用集成，並使用遷移來創建和修改表。模型和控制器： 模型表示數據庫實體，控制器處理 HTTP 請求。

centos7如何安裝mysql centos7如何安裝mysql Apr 14, 2025 pm 08:30 PM

優雅安裝 MySQL 的關鍵在於添加 MySQL 官方倉庫。具體步驟如下：下載 MySQL 官方 GPG 密鑰，防止釣魚攻擊。添加 MySQL 倉庫文件：rpm -Uvh https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm更新 yum 倉庫緩存：yum update安裝 MySQL：yum install mysql-server啟動 MySQL 服務：systemctl start mysqld設置開機自啟動

See all articles