slave中出现错误: 2020-04-09T07:40:18.719203Z 16 [ERROR] Slave sql for channel '': Could not execute
slave中出现错误:
2020-04-09T07:40:18.719203Z 16 [ERROR] Slave sql for channel '': Could not execute Write_rows event on table mytestdb.t1; Duplicate entry '6' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log Mysql-bin.000050, end_log_pos 437, Error_code: 1062
2020-04-09T07:40:18.719237Z 16 [Warning] Slave: Duplicate entry '6' for key 'PRIMARY' Error_code: 1062
2020-04-09T07:40:18.719246Z 16 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000050' position 194.
这是由于我人为往表中制造了主键冲突
查看slave的gtid信息:
mysql> show global variables like '%gtid%';
+----------------------------------+---------------------------------------------------------------------------------------+
| Variable_name | Value |
+----------------------------------+---------------------------------------------------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | 2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-6957,
3853efe2-5dc8-11ea-86cb-000c295618b3:1-2 |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-2 |
| session_track_gtids | OFF |
+----------------------------------+---------------------------------------------------------------------------------------+
查看master的gtid信息:
root@dv 15:40: : [(none)]>show global variables like '%gtid%';
+----------------------------------+---------------------------------------------+
| Variable_name | Value |
+----------------------------------+---------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | 2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-6958 |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-2 |
| session_track_gtids | OFF |
+----------------------------------+---------------------------------------------+
设置从库的gtid_next
mysql> SET GTID_NEXT="2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-6957";
ERROR 1774 (HY000): MalfORMed GTID specification '2ff0b1ed-5dc8-11ea-9878-000c29872e9a:1-6958'.
mysql> SET GTID_NEXT="2ff0b1ed-5dc8-11ea-9878-000c29872e9a:6957";
Query OK, 0 rows affected (0.00 sec)
mysql>
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
这里是模拟一个事务,代替出错的事务
mysql> SET GTID_NEXT="AUTOMATIC"
-> ;
Query OK, 0 rows affected (0.00 sec)
紧接着start slave即可
--结束END--
本文标题: MySQL GTID复制中断修复过程
本文链接: https://lsjlt.com/news/47412.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0