[大数据] MySQL主从同步

-> 大数据 -> MySQL主从同步 -> 正文阅读

前言：面试中，经常被问到MySQL中主从同步的原理是什么？什么是主从延迟？如何解决主从同步延迟问题？

主从同步优势

随着业务量的增长，高并发，数据库服务器宕机等问题频繁出现，单台MySQL服务器将会成为系统瓶颈。

为了解决此问题，通常会使用集群主从同步模式（Master-Slave）来同步数据，通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力。

总结主从同步模式优势：

数据库中间件.jpg

MySQL主从之间数据同步主要通过 binlog 日志实现。

主要用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中，可以简单理解为记录的就是sql语句；

在实际应用中， binlog 的主要使用场景有两个：

用于主从复制，在主从结构中，binlog 作为操作记录从 master 被发送到 slave，slave 服务器从 master 接收到的日志保存到 relay log 中；
用于数据备份，在数据库备份文件生成后，binlog 保存了数据库备份后的详细信息，以便下一次备份能从备份点开始；

binlog 日志有三种格式，分别为 Statement 、 Row 和 Mixed；

在 MySQL 5.7.7 之前，默认的格式是 Statement ， MySQL 5.7.7 之后，默认值是 Row；

Statement格式 -- 基于SQL语句的复制，每一条会修改数据的sql都会记录在binlog中

优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能；

缺点：由于记录的只是执行语句，但由于sql的执行是有上下文的,因此在保存的时候需要保存相关的信息,同时还有一些使用了函数(比如 uuid() 函数)之类的语句无法被记录复制;

Row格式 -- 基于行的复制，记录单元为每一行的改动,基本是可以全部记下来

优点：会记录每次操作的源数据与修改后的目标数据,绝对精准的还原，从而保证了数据的安全与可靠，并且复制和数据恢复过程可以是并发进行的;

缺点：可能会导致大量行的改动(比如alter table),这种模式的文件保存的信息太多,日志量太大；

Mixed格式* *-- 一种折中的方案,普通操作使用Statement记录，当无法使用Statement的时候使用Row

数据库中间件 (1).jpg

MySQL主从复制需要三个线程：master（binlog dump thread）、slave（I/O thread 、SQL thread）

binlog dump线程： ?主库中有数据更新时，根据设置的binlog格式，将更新的事件类型写入到主库的binlog文件中。当I/O线程请求日志内容时，master创建dump线程，将此时的binlog名称和当前更新的位置同时传给slave的I/O线程。
I/O线程： ?该线程会连接到master，向dump线程请求一份指定binlog文件位置的副本，并将请求回来的binlog存到本地的relay log中。
SQL线程： ?该线程检测到relay log有更新后，会读取并在本地做redo操作，将发生在主库的事件在本地重新执行一遍，来保证主从数据同步。

基本过程总结

master库上的数据发生改变时，则将其改变写入binlog中；
slave库在一定时间间隔内对master进行binlog探测是否发生改变，如发生改变，则开启I/O线程连接Master事件，请求从执行binlog日志文件中的指定位置，开始读取binlog至slave库；
master库接收到从库的IO线程请求后，其上复制的dump线程会根据Slave的请求信息分批读取binlog文件然后返回给从库的IO线程；
slave库的I/O线程获取到master库上IO线程发送的日志内容后，会将binlog日志内容依次写到slave库的relay Log（即中继日志）文件的最末端,并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master库binlog日志时能告诉master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容；
slave库服务器的SQL线程会实时监测到本地relay log中新增了日志内容，然后把relay log中的日志翻译成SQL并且按照顺序执行SQL来更新从库的数据。