之前文章介绍过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-080027c2997agno: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主主不同步问题的更多相关文章

  1. 配置percona mysql server 5.7基于gtid主主复制架构

    配置mysql基于gtid主主复制架构 环境: 操作系统 centos7. x86_64 mysql版本:Percona-Server-- 测试环境: node1 10.11.0.210 node2 ...

  2. mysql 主从,主主,主主复制时的主键冲突解决

    原理:slave 的i/o thread ,不断的去master抓取 bin_log, 写入到本地relay_log 然后sql thread不断的更新slave的数据 把主服务器所有的数据复制给从服 ...

  3. MySQL主主互备不同步的解决方法

    MySQL主主互备不同步 首先在服务器上执行show slave satus;可以看到很多同步的参数: Master_Log_File: SLAVE中的I/O线程当前正在读取的主服务器二进制日志文件的 ...

  4. MySQL双主如何解决主键冲突问题

    搭建了个双主,突然想到如果表设置了自增主键的话,当业务同时向双库中插入一条数据,这时候情况是什么样子的呢? 比如:主库A和主库B上的一个表数据为: 12 'ninhao' .当业务同时写入数据后主库A ...

  5. MySQL双主(主主)架构方案

    在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用mysql主从方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动.因此,如果是双主或者多主,就会增加mysql入 ...

  6. MySQL主主

    MySQL双主(主主)架构方案   在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用mysql主从方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动.因此,如果 ...

  7. mysql双主+keepalived

    环境 OS: centos7Mysql 版本: mysql 5.7Keepalived: keepalived-1.2.20Mysql-vip:192.168.41.100Mysql-master1: ...

  8. MariaDB基于GTID主从复制及多主复制

    一.简单主从模式配置步骤(必须要mysql5.6,此处以maridb10.0.10为例) 1.配置主从节点的服务配置文件 # vim /etc/my.cnf 1.1.配置master节点: [mysq ...

  9. MySQL双主.md

    MySQL 双主配置 环境说明 系统 IP 主机名 mysql版本 CentOS 6.8 192.168.197.61 C6-node1 5.6.36 CentOS 6.8 192.168.197.6 ...

  10. MySQL 高可用性—keepalived+mysql双主(有详细步骤和全部配置项解释)

    博主QQ:819594300 博客地址:http://zpf666.blog.51cto.com/ 有什么疑问的朋友可以联系博主,博主会帮你们解答,谢谢支持! 前言:生产环境中一台mysql主机存在单 ...

随机推荐

  1. 九、dockerfile指令讲解

    系列导航 一.docker入门(概念) 二.docker的安装和镜像管理 三.docker容器的常用命令 四.容器的网络访问 五.容器端口转发 六.docker数据卷 七.手动制作docker镜像 八 ...

  2. 高级数据结构---B树和B+树及mysql索引分析

    mysql索引数据结构:https://www.cnblogs.com/nijunyang/p/11406688.html 几种树结构的对比: 二叉查找树:二叉搜索树,二叉排序树,优点查找快,但是在某 ...

  3. python+appium使用方法

    一.python环境安装 确保需安装Appium-Python-Client包

  4. 聊一聊数字孪生与3D可视化

    前言 在当代科技发展的背景下,数字孪生和3D可视化技术逐渐成为各行业的关键工具和解决方案.数字孪生是一种将实物事物与数字模型相结合的概念,通过将物理世界和数字世界实时连接,创造出一个对实体进行虚拟建模 ...

  5. SpringMVC04——数据处理及跳转

    结果跳转 1.ModelAndView 设置ModelAndView对象,根据view的名称,和试图解析器跳到指定的页面. 页面:{视图解析器前缀} + viewName + {视图解析器后缀} &l ...

  6. Linux-日期时间-date

  7. [转帖]Nginx中if语句中的判断条件

    https://www.cnblogs.com/songxingzhu/p/6382007.html 一.if语句中的判断条件(nginx) 1.正则表达式匹配: ==:等值比较; ~:与指定正则表达 ...

  8. [转帖]goofys

     Goofys is a high-performance, POSIX-ish Amazon S3 file system written in Go     Overview Goofys all ...

  9. 一个Redis dump文件的简要分析过程

    摘要 遇到一个老大难的问题. 让帮忙分析一下一个Redis的dump文件. 虽然之前写过了rdb和rdr的文档 但是感觉大家都喜欢拿来主义. 没办法. 今天继续进行深入一点的分析. 原理其实还是基于r ...

  10. Linux部分参数的学习

    Linux部分参数的学习 简介 之前总结过很多Nginx或者是部署软件时的一些注意事项. 但是感觉对linux系统参数部分掌握的不是很好. 今天周末想着整理一下,作为备忘. limits.conf i ...