MySQL主从复制中从库SQL线程故障案例分析

1. SQL线程故障：

SLQ线程故障一般有：无法读写relay-log.info；relay-log损坏，断节，找不到；接收到的SQL无法执行：要创建的数据对象；要删除或修改的对象不存在；DML语句不符合表定义及约束时。

根本原因时由于从库发生了写入操作。

案例：模拟SQL故障：

（1）误操作：在从库中新建了个数据库“db”

 mysql> create database db;

mysql> show databases;

myslq> show slave status \G;  # 从库增加数据库，从库状态信息显示从库还能正常与主库进行连接。

（2）切换主库，与刚才从库一模一样的数据库

mysql> create database db;
mysql> show databases;

mysql> use db;
mysql> create table t1(ti int);
mysql> show tables;

（3）切换到从库，对从库之前建的db数据库进行查询出现主库新建的数据库，从库没有同步过来。

mysql> use db;
mysql> show tables;
Empty set(0.00 sec) 	#发现表t1是空的
mysql> show slave status \G;

发现Slave_SQL_Running:No；

Last_Error:Last SQL Error: Error 'Can't create database 'db'; database exists' on query. Default database:'db'. Query:'create database db'

有报错新建的db库在从库中已经存在。

有报错新建的db库在从库中已经存在。

（4）解决方案一：直接把从库的数据库db删除掉：mysql> drop database db;

（5） 解决方案二：以从库为核心的处理方案

步骤一： mysql> stop slave; #先停从库进程

步骤二： mysql> set global sql_slave_skip_counter =1 ; # 将同步指针向下移动一个，如果多个次不同步，可以重复操作

步骤三： mysql> start slave;

（6）解决方案三： 在配置文件配置从库跳过错误，这方法是以前流行用法，但限制用的比较少。

vim /etc/my.cnf

slave-skip-errors=1032,1062,1007

但是，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则，一切以主库为主。

1. 根本原因时由于从库发生了写入操作。解决办法：将从库设定为只读库。

临时设置： mysql> set global read_only=1;

永久生效：在从库配置文件设置“read_only=1”，但这个参数设置只对普通用进行只读限定权限，不能对管理员进行限定。

vim /etc/my.cnf

read_only=1

要对管理员设置权限为只读权限，在从库中配置文件my.cnf增加如下命令：

innodb_read_only=1;