mysql生产环境____主从同步修复案例
2017-07-22 21:18
435 查看
一、 硬件环境
Master: Dell R720 Intel(R)Xeon(R) CPU E5-2640 v2 @ 2.00GHz
MEM 64G。disk 4*2.5 SAS 网络4* 千兆
Slave: Dell R720 Intel(R)Xeon(R) CPU E5-2640 v2 @ 2.00GHz
MEM 64G,disk 4*2.5 SAS 网络4* 千兆
二、 软件环境
系统软件:
Master: cento5.8
Slave: cento5.8
数据库软件:mysql-5.5.10
三、 问题现象
3.1收到报警,发现问题
2014年XX月XX日收到mysql主从同步监控报警。登陆Slave,用show slavestatus \G; 查看结果例如以下。错误代码为1146,错误描写叙述为 “库名.表名不存在。插入语句”
图1
3.2 分析解决这个问题
有上述slave截图中的错误描写叙述,表不存在。我们须要进一步验证。在slave上运行show databases; 查看发现库存在,如图2,继续输入命令,
use 库名。
show tables;
发现表也存在,既然都存在,那为什么会报错“表不存在呢”,边思考。边检查,google了一番,有类似情况。可是解决的方法不通用。
冷静,回头细致看错误提示,有新的发现,错误提示中的表名是大写的,实际库中的表名是小写的。好吧,动手验证一下,
select * from 库名.表名。 表名相同大写,运行完成。报错信息图2和 图1 的报错信息相同“表不存在”。
select * from 库名.表名; 表名小写,运行完成,输出正确结果,如图2。
图2
找到原因就好解决这个问题了。
解决:
stop slave;
show slavestatus \G;
从新克隆一个secureCRT连接。编辑my.cnf配置文件,
在[mysqld]节点下,增加一行:lower_case_table_names=1
保存退出。
/etc/init.d/mysqldrestart
回到数据库操作命令行。运行 start slave;show slave status\G;开启同步。发现报错信息消失,同步恢复。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
登陆master端,发现master 的my.cnf配置中有lower_case_table_names=1
最后总结原因:slave端my.cnf配置缺少lower_case_table_names=1导致。
Master: Dell R720 Intel(R)Xeon(R) CPU E5-2640 v2 @ 2.00GHz
MEM 64G。disk 4*2.5 SAS 网络4* 千兆
Slave: Dell R720 Intel(R)Xeon(R) CPU E5-2640 v2 @ 2.00GHz
MEM 64G,disk 4*2.5 SAS 网络4* 千兆
二、 软件环境
系统软件:
Master: cento5.8
Slave: cento5.8
数据库软件:mysql-5.5.10
三、 问题现象
3.1收到报警,发现问题
2014年XX月XX日收到mysql主从同步监控报警。登陆Slave,用show slavestatus \G; 查看结果例如以下。错误代码为1146,错误描写叙述为 “库名.表名不存在。插入语句”
图1
3.2 分析解决这个问题
有上述slave截图中的错误描写叙述,表不存在。我们须要进一步验证。在slave上运行show databases; 查看发现库存在,如图2,继续输入命令,
use 库名。
show tables;
发现表也存在,既然都存在,那为什么会报错“表不存在呢”,边思考。边检查,google了一番,有类似情况。可是解决的方法不通用。
冷静,回头细致看错误提示,有新的发现,错误提示中的表名是大写的,实际库中的表名是小写的。好吧,动手验证一下,
select * from 库名.表名。 表名相同大写,运行完成。报错信息图2和 图1 的报错信息相同“表不存在”。
select * from 库名.表名; 表名小写,运行完成,输出正确结果,如图2。
图2
找到原因就好解决这个问题了。
解决:
stop slave;
show slavestatus \G;
从新克隆一个secureCRT连接。编辑my.cnf配置文件,
在[mysqld]节点下,增加一行:lower_case_table_names=1
保存退出。
/etc/init.d/mysqldrestart
回到数据库操作命令行。运行 start slave;show slave status\G;开启同步。发现报错信息消失,同步恢复。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
登陆master端,发现master 的my.cnf配置中有lower_case_table_names=1
最后总结原因:slave端my.cnf配置缺少lower_case_table_names=1导致。
相关文章推荐
- mysql生产环境___主从同步修复案例
- mysql生产环境____主从同步修复案例
- 生产环境 MySQL主从复制(同步)
- 生产环境mysql主主同步主键冲突处理
- Linux(Ubuntu)环境MYSQL->master/slave主从同步设置以及注意事项
- mysql 主从同步出问题,重新修复从库(转)
- MySQL 主从同步失败,数据表修复
- MySQL 系列(一) 生产标准线上环境安装配置案例及棘手问题解决
- MySQL生产库主从重新同步操作注意事项
- 企业案例 【故障修复】mysql主从故障解决过程
- MySQL主从延迟复制实践及生产故障案例恢复实践
- MySQL 系列(四)主从复制、备份恢复方案生产环境实战
- 马老师 生产环境mysql主从复制、架构优化方案
- 生产环境主从数据同步不了?
- mysql 主从同步出问题,重新修复从库 - web架构研究
- 屌炸天实战 Mysql 系列教程(一) 生产标准线上环境安装配置案例及棘手问题解决
- 生产环境MySQL快速备份工具XtraBackup使用案例
- MySQL 系列教程(四)【秒杀七年经验 LowB工程师】 主从复制、备份恢复方案生产环境实战
- shell脚本监控mysql主从同步状态并自动修复
- 生产环境下的MySQL数据库主从同步总结