之前文章介绍过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. win32com操作word API精讲 第八集 Range和Selection的区别

    本课程<win32com操作word API精讲&项目实战>以视频为主,文字为辅,公众号ID:一灯编程 众所周知,在word编程中Range和Selection都能实现范围的选中, ...

  2. java基础-反射-day15

    目录 1. 案例引入 2. Class 的理解 3. 反射的详细使用 4. Class 类都有哪些实例 5. 详细使用 6. 获取属性 7. 获取方法 8 获取类的 接口 注解 所在的包 9. 思考 ...

  3. idea 配置 service 服务,多模块同时启动

    转载请注明出处: 1,打开IDEA项目 .idea 下 的workspace.xml 2,查找"RunDashboard" 节点 3,添加如下内容 <option name= ...

  4. jenkins构建报错: Send build artifacts over SSH' changed build result to UNSTABLE

    原因包括: ssh配置的用户没有相关的权限. 最好是配置root用户

  5. Laravel - 创建项目

    1,创建目录 ( 路径不要带有中文 ) 2,进入目录,执行下列命令 composer create-project --prefer-dist laravel/laravel project

  6. MongoDB的安装使用与监控

    MongoDB的安装使用与监控 下载 https://www.mongodb.com/try/download/community 我这边习惯于下载 Windows 的 MSI 进行安装 Linux ...

  7. 【转帖】高性能异步io机制:io_uring

    文章目录 1.性能测试 1.1.FIO 1.2.rust_echo_benc 2.io_uring 2.1.io_uring_setup 2.2.io_uring_enter 2.3.io_uring ...

  8. overcommit_memory的简单学习

    overcommit_memory的简单学习 背景 前几天一个测试环境启动失败. 总是有如下的提示: Native memory allocation (mmap) failed to map 122 ...

  9. [转帖]12.计算机网络---iptables防火墙管理工具

    文章目录 一.防火墙基础知识 1.1 防火墙是什么? 1.2 iptables基础知识 1.3 netfilter和iptables的关系: 1.4 新型防火墙工具:firewalld 二.iptab ...

  10. [转帖]kubelet 原理解析四:probeManager

    https://segmentfault.com/a/1190000022163835 概述 在Kubernetes 中,系统和应用程序的健康检查任务是由 kubelet 来完成的,本文主要讨论kub ...