MySQL的复制原理以及流程

MySQL的复制原理以及流程

主从复制：将主数据库中的DDL和DML操作通过二进制日志（BINLOG）传输到从数据库上，然后将这

些日志重新执行（重做）；从而使得从数据库的数据与主数据库保持一致。

主从复制的作用

1. 主数据库出现问题，可以切换到从数据库。

2. 可以进行数据库层面的读写分离。

3. 可以在从数据库上进行日常备份。

MySQL主从复制解决的问题

数据分布：随意开始或停止复制，并在不同地理位置分布数据备份负载均衡：降低单个服务器的压

力高可用和故障切换：帮助应用程序避免单点失败升级测试：可以用更高版本的MySQL作为从库

MySQL主从复制工作原理

在主库上把数据更高记录到二进制日志从库将主库的日志复制到自己的中继日志

从库读取中继日志的事件，将其重放到从库数据中基本原理流程，3个线程以及之间的关联

主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的 binlog中；从：io线程——

在使用start slave 之后，负责从master上拉取 binlog 内容，放进自己的relay log中；

从：sql执行线程——执行relay log中的语句；Binary log：主数据库的二进制日志

Relay log：从服务器的中继日志

第一步：master在每个事务更新数据完成之前，将该操作记录串行地写入到 binlog文件中。

第二步：salve开启一个I/O Thread，该线程在master打开一个普通连接，主要工作是binlog dump

process。如果读取的进度已经跟上了master，就进入睡眠状态并等待master产生新的事件。I/O线程

终的目的是将这些事件写入到中继日志中。

第三步：SQL Thread会读取中继日志，并顺序执行该日志中的SQL事件，从而与主数据库中的数据保持

一致。

读写分离有哪些解决方案？

读写分离是依赖于主从复制，而主从复制又是为读写分离服务的。因为主从复制要求slave不能写只能读

（如果对slave执行写操作，那么show slave status将会呈现Slave_SQL_Running=NO，此时你需要按

照前面提到的手动同步一下slave）。

方案一

使用mysql-proxy代理

优点：直接实现读写分离和负载均衡，不用修改代码，master和slave用一样的帐号，mysql官方不建议

实际生产中使用缺点：降低性能， 不支持事务方案二

使用AbstractRoutingDataSource+aop+annotation在dao层决定数据源。如果采用了mybatis， 可以

将读写分离放在ORM层，比如mybatis可以通过

mybatis plugin拦截sql语句，所有的insert/update/delete都访问master库，所有的select 都访问salve

库，这样对于dao层都是透明。 plugin实现时可以通过注解或者分析语句是读写方法来选定主从库。不

过这样依然有一个问题， 也就是不支持事务， 所以我们还需要重写一下

DataSourceTransactionManager， 将read-only的事务扔进读库， 其余的有读有写的扔进写库。

方案三使用AbstractRoutingDataSource+aop+annotation在service层决定数据源，可以支持事务. 缺点：类

内部方法通过this.xx()方式相互调用时，aop不会进行拦截，需进行特殊处理

备份计划，mysqldump以及xtranbackup的实现原理

(1)备份计划视库的大小来定，一般来说 100G 内的库，可以考虑使用 mysqldump 来做，因为

mysqldump更加轻巧灵活，备份时间选在业务低峰期，可以每天进行都进行全量备份(mysqldump 备

份出来的文件比较小，压缩之后更小)。

100G 以上的库，可以考虑用 xtranbackup 来做，备份速度明显要比

mysqldump 要快。一般是选择一周一个全备，其余每天进行增量备份，备份时间为业务低峰期。

(2)备份恢复时间

物理备份恢复快，逻辑备份恢复慢

这里跟机器，尤其是硬盘的速率有关系，以下列举几个仅供参考

20G的2分钟（mysqldump）

80G的30分钟(mysqldump)

111G的30分钟（mysqldump)

288G的3小时（xtra)

3T的4小时（xtra)

逻辑导入时间一般是备份时间的5倍以上

(3)备份恢复失败如何处理首先在恢复之前就应该做足准备工作，避免恢复的时候出错。比如说备份之后

的有效性检查、权限检查、空间检查等。如果万一报错，再根据报错的提示来进行相应的调整。

(4)mysqldump和xtrabackup实现原理 mysqldump mysqldump 属于逻辑备份。加入–single

transaction 选项可以进行一致性备份。后台进程会先设置 session 的事务隔离级别为 RR(SET SESSION

TRANSACTION ISOLATION LEVELREPEATABLE READ)，之后显式开启一个

事务(START TRANSACTION /*!40100 WITH CONSISTENTSNAPSHOT */)，这样就保证了该事务里读到

的数据都是事务事务时候的快照。之后再把表的数据读取出来。如果加上–master-data=1 的话，在刚开

始的时候还会加一个数据库的读锁(FLUSH TABLES WITH READ LOCK),等开启事务后，再记录下数据库

此时 binlog 的位置(showmaster status)，马上解锁，再读取表的数据。等所有的数据都已经导完，就

可以结束事务

Xtrabackup:

xtrabackup 属于物理备份，直接拷贝表空间文件，同时不断扫描产生的 redo 日志并保存下来。 后完

成 innodb 的备份后，会做一个 flush engine logs 的

操作(老版本在有 bug，在5.6 上不做此操作会丢数据)，确保所有的 redo log 都已经落盘(涉及到事务的

两阶段提交

概念，因为 xtrabackup 并不拷贝 binlog，所以必须保证所有的 redo log 都落盘，否则可能会丢 后一组

提交事务的数据)。这个时间点就是 innodb 完成备份的时间点，数据文件虽然不是一致性的，但是有这

段时间的 redo 就可以让数据文件达到一致性(恢复的时候做的事

情)。然后还需要 flush tables with read lock，把 myisam 等其他引擎的表给备份出来，备份完后解

锁。这样就做到了完美的热备。