16、mysql主从复制问题总结

16.1、主库"show master status"没有结果：

1、原因：

主库binlog功能开关没有改或没有生效；

2、解决办法：

（1）[root@backup ~]#egrep "server-id|log-bin" /data/3306/my.cnf

log-bin = /data/3306/mysql-bin

server-id = 1

（2）mysql> show variables like 'server_id';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| server_id | 1 |

+---------------+-------+

1 row in set (0.00 sec)

mysql> show variables like 'log_bin';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| log_bin | ON |

+---------------+-------+

1 row in set (0.00 sec)

（3）提示：

配置文件my.cnf中的参数和show variables里的参数不一样；

my.cnf配置文件中的是log-bin，show variables中的是log_bin;

16.2、CHANGE MASTER时多了空格：

1、错误：

mysql > show slave stauts\G;

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log:

'Could not find first log file name in binary log index file'

2、解决办法：

重新CHANGE MASTER;

或找到最近的没有数据的pos点重新chang master;

16.3、使用mysql启动时显示已经启动了，但是mysql没有启动：

1、原因：

mysql 没有正常关闭导致的问题：

2、解决办法

删除mysql的mysql.pid和mysql.sock文件

rm -f /data/3306/mysql.sock /data/3306/*.pid

16.4、由于切换binlog导致show master status 位置变化无影响；

16.5、mysql_InnoDB独立表空间物理文件被误删的解决方法：

1、因为InnoDB格式的表索引都保存在ibdata1这个文件中，虽然物理文件*.ibd,*.frm被删除，但是ibdata1中的索引没有删除，所以

数据库认为该表已经存在，导致创建失败。

2、解决方案是： 比如test表的.frm文件误删了首先新建一个文件名字叫test.frm(cp -a other.frm test.frm)，然后使用drop命令

删除该数据库drop table test，删除之后会发现该数据库的物理文件夹中还存在test.ibd文件；

删除该文件 然后再次建表就ok了；

16.6、mysql从库数据冲突导致同步停止的解决方案：

1、报错：

2、解决方法：

（1）方法一：

stop slave;

set global sql_slave_skip_counter = 1;

start slave;

提示：sql_slave_skip_counter=n #n取值大于0，忽略执行n个更新；

对于普通的互联网业务，忽略问题不是很大，当然在不影响公司业务的前提下；

企业场景解决主从同步，比主从不一致当前更重要，主从同步数据一致很重要，需

要中找个时间恢复下这个从库；

缺点：容易造成数据丢失；

（2）方法二：

根据错误号跳过指定的错误：

slave-skip-errors = 1032,1062,1007 #一般由于入库重复导致的失败问题就可以进行忽略；

提示：你也可以使用不推荐的all值忽略所有的错误消息，不考虑所发生的错误。如果使用改制，

我们不能保证数据的完整性。

（3）其他可能引起同步的问题：

1）mysql自身的原因；

2）不同的数据库版本会引起不同步，低版本到高版本可以，但是高版本不能往低版本同步；

3）mysql的错误；

16.7、主库master宕机的解决方案：

1、登陆各个从服务器分别查看master.info文件；

cat /data/3307/data/master.info

cat /data/3308/data/master.info

18

mysql-bin.000035 #mysql-bin文件

331 #pos点

172.16.1.41

lc

123456

3306

60

0

0

1800.000

0

选择mysql-bin文件和pos值最大的点作为主库；

2、确保选择从库的relay_log全部都更新完毕：

stop slave io_thread;

show processlist\G;

直到看到sql线程已经是：Has read all relay log; waiting for the slave I/O thread to update it为止；

表示从库更新都执行完成；

提示：如果主库还能够启动，需要把主库的binlog日志拉到选定的主库并导入；

3、把选定的从库切换成主库：

stop slave;

reset master;

quit;

4、进到选定从库目录，删除master-info和relay-log.info文件：

cd /data/3307/data

rm -f master.info relay-log.*

5、提升选择的从库为主库：

vim /data/3306/my.cnf

开启：log-bin = /data/3307/mysql-bin

#如果存在log-slave-updates,read-only等一定要注释掉；

/data/3307/mysql restart

授权同步的用户和主库一致；

到此为止主库提升完毕；

6、分别登陆其他的从库：

stop slave;

change master to master_host = '172.168.1.41'; #如果不同步需要获取master的为止点并指定；

start slave；

show slave status\G; #查看状态，从库切换成功；

补充：

CHANGE MASTER TO

MASTER_HOST='172.16.1.41',

MASTER_PORT=3306,

MASTER_USER='lc',

MASTER_PASSWORD='123456',

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=331;

7、修理损坏的主库，完成后作为从库进行使用；

8、如果是有计划的主从库切换的做法为：

（1）主库锁表；

flush table with read lock;

unlock tables;

（2）登陆所有的库查看同步状态，是否同步完成；

（3）然后按照前面的3-7步骤完成操作；

16.8、从库slave宕机的解决方案：

从做slave：

stop slave；

gzip -d /tmp/mysql_bal.sql.gz #该文件是前天凌晨备份好的，库是inoodb引擎，使用

了--mstart-data=1参数备份的库；

mysql -uroot -p123456 -S /data/3306/mysql.sock </tmp/mysql_bak.sql

CHANGE MASTER TO

MASTER_HOST='172.16.1.41',

MASTER_PORT=3306,

MASTER_USER='lc',

MASTER_PASSWORD='123456';

start slave;

show slave status\G;

16.9、binglog查看时报错：

[root@db01 data]# mysqlbinlog mysql-bin.000013

mysqlbinlog: unknown variable 'default-character-set=utf8'

#出现这种情况的原因是my.cnf中[client] default-character-set=utf8,解决的办法是，去掉此参数,在

#在/etc/sysconfig/i18n中设置zh_CN.UTF8即可解决乱码的问题，而这种方法不会影响mysql客户端

#和库的编码一致性；