MySQL复制常见问题处理

MYSQL复制配置起来非常的简单,而且想其复制链路中断呢,同样十分简单,有很多种因素呢,可能会造成主从复制的

中断,我们就来看看下面的主要因素,如何恢复中断后的复制链路,那么第一类我们经常需要面对的问题呢,是由于

数据损坏或数据丢失引起的主从复制的错误,这种错误大部分都是由于非正常的关机所引起的,当数据库服务器突然

宕机,这个时候呢就会经常出现部分数据没有及时的刷新到磁盘的情况,在这种情况下,重启主从服务器之后,再次进行

同步,可能就会产生中断的错误,这种错误主要有以下几种,首先第一种是由于主库或者从库意外宕机所引起的,从我们前面

讲解的内容中呢,大家可以知道,当参数没有设置为1时,那么在主库发生奔溃意外时呢,有可能没有将最后的二进制日志刷新

到磁盘上存储,当主库重新启动后,并尝试再次去读取二进制事件,但是主库可以告诉从库,在主库二进制日志中呢,没有二进制

所在的事件,因为在主库宕机时呢,并没有把这个事件保存到二进制日志中,这就会出现从库读取不到主库的二进制日志的错误,

而造成主从链路中断,根据我们所使用的模式,可以使用跳过二进制日志事件的方式,注入空事务的方式呢,先恢复中断的复制

链路,然后再使用其他方法,对比主从服务器上的数据,与修改从库,重新同步从库丢失主库的数据

另外除了主库的意外宕机,会引起从库的错误外,从库的意外宕机呢,也有可能会引起主从复制的链路中断,由于从库的

意外宕机呢,会引起master-info文件,没有及时的同步到磁盘上,在这个文件中记录了从库已经同步了二进制的日志信息,

这可能会引起从库的从主库获取二进制日志,这在基于日志点的复制下呢,会出现主键冲突这样的问题,当然呢,基于SQL段

的日志下呢,还有可能会对数据进行更新,所以如果出现了这些问题,我们通过可以通过这种方式呢,来进行恢复主从链路,

但是同步恢复后呢,我们同样要验证,主从的数据是否一致,关于如何检验主从数据库的数据是否一致呢,我们会放到本课程的最后,

也就是服务器性能监控,来给大家讲解,另外主从以外重启的故障呢,就是主库上的二进制日志损坏了,主库每次重启以后呢,

都会重新生成一个二进制日志文件,可能由于意外的关闭,甚至我们只能从从库中,通过change master命令,来重新指定从库从

主库的同步的二进制日志,来进行同步,但是会丢失主库上的一些更新,是主从数据库上出现一些差异,因此我们接下来还是要

对丢失的数据进行修复,以及修复后还要对主从数据库的数据进行检验,看是否恢复了主从数据库的一致性,和主库的意外重启,

可能会和主库二进制的日志一样,从库的意外重启呢,他也可能引起中继日志的损坏,不过只要主库的二进制日志没有删除,中继

日志的损坏呢,很好处理了,我们可以通过change master命令,指定从库的IO线程,从损坏的位置,再次同步主库的二进制日志,

这样就可以安全的恢复同步的链路了,无论是意外宕机,引起主从复制错误之外,还有一些可能会造成主从复制的意外的时间

主要包括下面这些,首先由于从库上进行了数据修改,而造成了主从复制的这种错误,前面讲解如何主从复制,

以及主从复制需要注意的问题的时候呢,设置read_only参数,使从库只读,但是在实际的工作中呢,我们经常发现,

很少有人会记得,在从库上来设置这个参数,另外即使是设置了这个参数,在MYSQL5.7之前呢,用于SQL权限的用户呢,

还是在从库上进行修改,而主从库的正常运行呢,非常依赖于主从数据库的一致性,如果出现了从备份服务器修改数据

的情况,主从的链路就会轻易地会更变,另外如果是业务应用在从服务器上进行了数据修改,很可能会出现事务丢失的

问题,是保留主库上的数据还是保留从库上的数据,在多数的情况下,一旦出现这种问题,我们只能更新从主库差异的数据,

这样从库修改就会丢失,另一种情况呢,在多个从服务器上,可能会存在不同的server_id,或者server_uuid,在主服务器

之间,如果出现了相同的server_id,启动复制时呢就会出现错误,所以这种错误很容易被发现,而如果是在从服务器之间,

存在相同的server_id,或者uuid时呢,就不是那么容易被发现了,server_id的情况,如果我们使用的是复制目录的方式来

初始化服务器的数据,那么这种情况下,是非常容易发生,因为server_uuid是记录在数据库目录中的auto.cnf文件中,那这个文件

一旦存在呢,mysql是不会重新生成uuid的,所以如果我们不注意呢,多个从服务器使用同一个server_uuid的情况,这种错误

很隐蔽,所以也很难被发现,具有相同server_id可能会丢失,也有可能会重新执行,使用了相同server_id的从服务器,

而造成了主从切换的失败,最后呢运行最大包不一致,也会可能造成主从复制的失败,在这种情况下呢,主库可能会记录从库的包,

当从库获得这个二进制事件时呢,可能会碰到很多问题,如无限制的报错,或者日志的损坏,下面我们就来介绍如何配置主从复制,

以及如何处理常见的主从复制的错误,MYSQL复制确实非常简单,功能也相当强大,可以为我们解决很多问题

但是有些问题单纯使用主从复制是无法解决的,比如前面多次提到的,主从复制是无法分担主数据库的写负载,

由于在主从复制中,写入主数据库的二进制事件,最终会在所有的从上存放,所以说,写负载并不会减少,如果要

解决写负载的问题,只能通过分库分表的方式,来处理,这个我们后面会有一个专门的章节来讲解,另外单纯的主从

复制呢,还无法进行自动的故障转移,和主从切换,我们在上面介绍中,可以看到,主从复制所解决的问题中呢,是为了

高可用架构,架构基础,之后主从复制虽然提供了多个从服务器,我们可以利用多个从服务器来分担你读的负载,但是主从

复制不提供读写分离的功能,这实现读写分离,也需要额外的一些主键