案例:推进GTID解决MySQL主主不同步问题
之前文章介绍过MySQL修改lower_case_table_names参数,如果之前大写存储的表将无法识别,需要特殊处理。
最近遇到一例应用开发人员在修改这个参数之后,为了清除之前大写存储的表,做了误操作,导致主主不同步。
1.故障现象模拟
在lower_case_table_names=0时创建了测试库test和表TT:
root@mysqldb 22:43: [(none)]> create database test;
Query OK, 1 row affected (0.01 sec)
root@mysqldb 22:43: [(none)]> use test;
Database changed
root@mysqldb 22:43: [test]> create table TT(id int);
Query OK, 0 rows affected (0.07 sec)
root@mysqldb 22:43: [test]> show tables;
+----------------+
| Tables_in_test |
+----------------+
| TT |
+----------------+
1 row in set (0.00 sec)
在修改lower_case_table_names=1时删除TT不成功:
root@mysqldb 22:27: [test]> drop table TT;
ERROR 1051 (42S02): Unknown table 'test.tt'
此时误操作来了。。据这样操作的人员反馈,是直接在网络搜索到这个错误就是要到OS层面去删除表的文件,然后就做了
我这里也按照这个误操作在测试环境来模拟下:
[root@test01 test]# rm TT.*
rm: remove regular file `TT.frm'? y
rm: remove regular file `TT.ibd'? y
而且后续根据故障现象推测:操作人员最初只在一个主节点做了这样的操作,随后在这个主节点执行了删除数据库的动作,最后又建立了新的数据库重新建表,最终才发现另一个主节点已经不同步了,尝试自己无法解决后,上报了故障给客户DBA。
此刻现象就是:Master1 删除数据库成功后,但Master2 同步报错1010,内容是删除数据库发生错误,具体如下:
root@mysqldb 23:04: [test]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.121
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mybinlog.000013
Read_Master_Log_Pos: 756
Relay_Log_File: test02-relay-bin.000034
Relay_Log_Pos: 532
Relay_Master_Log_File: mybinlog.000013
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1010
Last_Error: Error 'Error dropping database (can't rmdir './test', errno: 39)' on query. Default database: 'test'. Query: 'drop database test'
Skip_Counter: 0
Exec_Master_Log_Pos: 601
Relay_Log_Space: 1060
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: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1010
Last_SQL_Error: Error 'Error dropping database (can't rmdir './test', errno: 39)' on query. Default database: 'test'. Query: 'drop database test'
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1121
Master_UUID: 08c887bf-98ab-11ea-b70c-080027c2997a
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 200702 23:04:11
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 08c887bf-98ab-11ea-b70c-080027c2997a:549-550
Executed_Gtid_Set: 08c887bf-98ab-11ea-b70c-080027c2997a:5-549,
5d3f3359-98ab-11ea-8101-080027763d24:1-13
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
root@mysqldb 23:04: [test]> \q
2.推进GTID解决
这时就可以用一个空事物将当前执行报错的GTID(Global Transaction Identifier)给跳过去:
set gtid_next='$Master_UUID:$gno';
begin;
commit;
set gtid_next=automatic;
start slave;
这里实际就是选取Master_UUID: 08c887bf-98ab-11ea-b70c-080027c2997a和gno:550(因为Executed_Gtid_Set最后是549,当前报错对应应该是549/550,期望用空事物代替跳过)
注意:这里的gno是连续的。第一次我尝试gtid_next='08c887bf-98ab-11ea-b70c-080027c2997a:549'是不成功的,所以又尝试550:
set gtid_next='08c887bf-98ab-11ea-b70c-080027c2997a:550';
begin;
commit;
set gtid_next=automatic;
start slave;
这次执行后再次查看slave状态,确认已恢复正常:
root@mysqldb 23:11: [(none)]> set gtid_next='08c887bf-98ab-11ea-b70c-080027c2997a:550';
Query OK, 0 rows affected (0.00 sec)
root@mysqldb 23:11: [(none)]> begin;
Query OK, 0 rows affected (0.00 sec)
root@mysqldb 23:11: [(none)]> commit;
Query OK, 0 rows affected (0.00 sec)
root@mysqldb 23:11: [(none)]> set gtid_next=automatic;
Query OK, 0 rows affected (0.00 sec)
root@mysqldb 23:11: [(none)]> start slave;
Query OK, 0 rows affected (0.01 sec)
root@mysqldb 23:11: [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.121
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mybinlog.000013
Read_Master_Log_Pos: 951
Relay_Log_File: test02-relay-bin.000034
Relay_Log_Pos: 687
Relay_Master_Log_File: mybinlog.000013
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: 951
Relay_Log_Space: 1060
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: 1121
Master_UUID: 08c887bf-98ab-11ea-b70c-080027c2997a
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: 08c887bf-98ab-11ea-b70c-080027c2997a:549-550
Executed_Gtid_Set: 08c887bf-98ab-11ea-b70c-080027c2997a:5-550,
5d3f3359-98ab-11ea-8101-080027763d24:1-14
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
root@mysqldb 23:11: [(none)]>
当然Master2遗留的这个test库记得要处理掉,不然以后还会有问题隐患。
案例:推进GTID解决MySQL主主不同步问题的更多相关文章
- 配置percona mysql server 5.7基于gtid主主复制架构
配置mysql基于gtid主主复制架构 环境: 操作系统 centos7. x86_64 mysql版本:Percona-Server-- 测试环境: node1 10.11.0.210 node2 ...
- mysql 主从,主主,主主复制时的主键冲突解决
原理:slave 的i/o thread ,不断的去master抓取 bin_log, 写入到本地relay_log 然后sql thread不断的更新slave的数据 把主服务器所有的数据复制给从服 ...
- MySQL主主互备不同步的解决方法
MySQL主主互备不同步 首先在服务器上执行show slave satus;可以看到很多同步的参数: Master_Log_File: SLAVE中的I/O线程当前正在读取的主服务器二进制日志文件的 ...
- MySQL双主如何解决主键冲突问题
搭建了个双主,突然想到如果表设置了自增主键的话,当业务同时向双库中插入一条数据,这时候情况是什么样子的呢? 比如:主库A和主库B上的一个表数据为: 12 'ninhao' .当业务同时写入数据后主库A ...
- MySQL双主(主主)架构方案
在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用mysql主从方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动.因此,如果是双主或者多主,就会增加mysql入 ...
- MySQL主主
MySQL双主(主主)架构方案 在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用mysql主从方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动.因此,如果 ...
- mysql双主+keepalived
环境 OS: centos7Mysql 版本: mysql 5.7Keepalived: keepalived-1.2.20Mysql-vip:192.168.41.100Mysql-master1: ...
- MariaDB基于GTID主从复制及多主复制
一.简单主从模式配置步骤(必须要mysql5.6,此处以maridb10.0.10为例) 1.配置主从节点的服务配置文件 # vim /etc/my.cnf 1.1.配置master节点: [mysq ...
- MySQL双主.md
MySQL 双主配置 环境说明 系统 IP 主机名 mysql版本 CentOS 6.8 192.168.197.61 C6-node1 5.6.36 CentOS 6.8 192.168.197.6 ...
- MySQL 高可用性—keepalived+mysql双主(有详细步骤和全部配置项解释)
博主QQ:819594300 博客地址:http://zpf666.blog.51cto.com/ 有什么疑问的朋友可以联系博主,博主会帮你们解答,谢谢支持! 前言:生产环境中一台mysql主机存在单 ...
随机推荐
- v-html会导致xss攻击
- go 接口学习笔记
这里是对接口在汇编层面上转换和实现的小结,详细了解可参考 Go 语言接口的原理 1. 类型转换:结构体到接口 1.1 结构体方法实现接口 package main type Duck interfac ...
- [转帖]JVM参数配置及调优
https://cloud.tencent.com/developer/article/2235751 JVM参数分类 jvm 参数可分为三类: 标准参数:以 "-" 开头的参数 ...
- [转帖] TiDB 产品体系介绍
https://www.modb.pro/db/521269#:~:text=%E4%BC%81%E4%B8%9A%E7%89%88%E5%92%8C%E7%A4%BE%E5%8C%BA%E7%89% ...
- [转帖]构建 TiFlash 副本
https://docs.pingcap.com/zh/tidb/stable/create-tiflash-replicas#%E6%8C%89%E8%A1%A8%E6%9E%84%E5%BB%BA ...
- [转帖]Java 认证与授权(JAAS)介绍
https://www.cnblogs.com/wuyongyin/p/16981469.html JAAS(Java Authentication Authorization Service),即 ...
- [转帖]kafka压测多维度分析实战
设置虚拟机不同的带宽来进行模拟压测 ---------kafka数据压测-------------------1.公司生产kafka集群硬盘:单台500G.共3台.日志保留7天. 1. ...
- [转帖]Intel“革命性”X86s架构,带来哪些颠覆及影响?
https://www.eet-china.com/mp/a221822.html 英特尔发布了一份新的白皮书(Intel X86-S扩展架构规格),计划简化其处理器指令集架构(ISA).英特尔提供了 ...
- Oracle 核心列信息查看与处理
Oracle 核心列信息查看与处理 背景 最近想对数据库表进行跨数据之间的比照 因为有一些自增列或者是时间戳的列不需要进行对比 后者是对比容易导致失真. 所以就准备选用其他方式进行一下处理. 本文主要 ...
- 【转帖】通过docker配置DNS服务
https://blog.whsir.com/post-3185.html 在办公室开发人员经常会测试所写的页面,每次都要输入对应的IP地址或者更改hosts,为了让开发大爷省心,不如搭建一个dn ...