深入了解MySQL主从复制的原理

欢迎微信关注「SH的全栈笔记」

0. 主从复制

首先主从复制是什么？简单来说是让一台MySQL服务器去复制另一台MySQL的数据，使两个服务器的数据保持一致。

这种方式与Redis的主从复制的思路没有太大的出入。如果你对Redis的主从复制感兴趣可以去看看《Redis的主从复制》。那既然Redis和MySQL都采用了复制这种方式，主从复制所带来的意义是什么呢？

通过复制功能，构建一个或者多个从库，可以提高数据库的高可用性、可扩展性，同时实现负载均衡。当主库发生故障时，可以快速的切到其某一个从库，并将该从库提升为主库，因为数据都一样，所以不会影响系统的运行；当MySQL服务器需要扛住更多的读请求时，可以把读请求的流量分流到各个从库上去，写请求则转发给主库，形成读写分离的架构，来提供更好的读扩展和请求的负载均衡。

读写分离的架构应用的其实非常广泛，就比如MySQL，还有Redis，以及我们熟悉的Zookeeper，Zookeeper的Follower收到读请求不会自己处理，而是会将读请求转发给Leader，感兴趣的可以自己下来了解一下，这里就不偏题了。

1. 复制原理

MySQL的主从复制支持两种方式：

基于行

基于语句

基于语句的复制在MySQL3.23中就已经有了，而基于语句的方式则在5.1中才实现。其本质都是基于主库的binlog来实现的，主库记录binlog，然后从库将binlog在自己的服务器上重放，从而保证了主、从的数据一致性。

1.1 binlog

MySQL中日志分为两个维度，一个是MySQL服务器的，一个是底层存储引擎的。而上文提到的binlog就是属于MySQL服务器的日志，binlog也叫二进制日志，记录了所有对MySQL所做的更改。

基于行、语句的复制方式跟binlog的存储方式有关系。 binlog有三种存储格式，分别是Statement、Row和Mixed。

Statement 基于语句，只记录对数据做了修改的SQL语句，能够有效的减少binlog的数据量，提高读取、基于binlog重放的性能

Row 只记录被修改的行，所以Row记录的binlog日志量一般来说会比Statement格式要多。基于Row的binlog日志非常完整、清晰，记录了所有数据的变动，但是缺点是可能会非常多，例如一条update语句，有可能是所有的数据都有修改；再例如alter table之类的，修改了某个字段，同样的每条记录都有改动。

Mixed Statement和Row的结合，怎么个结合法呢。例如像update或者alter table之类的语句修改，采用Statement格式。其余的对数据的修改例如update和delete采用Row格式进行记录。

为什么会有这么多方式呢？因为Statement只会记录SQL语句，但是并不能保证所有情况下这些语句在从库上能够正确的被重放出来。因为可能顺序不对。

MySQL什么时候会记录binlog呢？是在事务提交的时候，并不是按照语句的执行顺序来记录，当记录完binlog之后，就会通知底层的存储引擎提交事务，所以有可能因为语句顺序错误导致语句出错。

1.2 查看binlog

这里拿MySQL 5.6举例子，binlog默认是处于关闭状态的。我们可以通过命令show variables like '%log_bin%' 来查看关于binlog的配置。

默认配置

log_bin代表是否开启了binlog，其默认值为OFF。

log_bin 代表是否开启了binlog，其默认值为OFF

log_bin_basename binlog存储文件的完整名称，会在默认的文件名后面添加上递增的序号，就例如mysql-bin.000001

log_bin_index binlog索引文件名称，例如mysql-bin.index

sql_log_bin 在binlog开启的时候，可以禁用当前session的binlog

你可以在MySQL中通过命令show binary logs查看所有的binlog文件

查看binlog

知道了有哪些文件之后我们可以来看看binlog文件中的内容，可以在MySQL通过show binlog events命令来查看。