学习笔记(一）MySQL复制原理及应用场景

一、为什么需要主从复制

1. 使用主从复制，让主库负责写，从库负责读，这样即使主库出现了锁表的情景(暂时不能使用读)，通过读从库也可以保证业务的正常运作。
2. 架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
3. 主从多台服务器，同样也可以当作数据备份的。

二、复制架构

MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库或者特定的表。

1. 复制原理

1. 首先从库启动I/O线程，跟主库建立客户端连接
2. 主库启动binlog dump线程，读取主库上的binlog event发送给从库的I/O线程，I/O线程获取到binlog event之后将其写入到自己的RelayLog中。
3. 从库启动SQL线程，将等待Relay中的数据进行重放，完成从库的数据更新

注意：

• Mysql复制最好确保master和slave服务器上的Mysql版本相同（如果不能满足版本一致，那么要保证master主节点的版本低于slave从节点的版本）
• master和slave两节点间时间需同步。
• master将操作语句记录到binlog日志中，然后授予slave远程连接的权限（master一定要开启binlog二进制日志功能；通常为了数据安全考虑，slave也开启binlog功能）。

relay log的意义

• 在MySQL 4.0 之前是没有Relay Log这部分的，整个过程中只有两个线程。但是这样也带来一个问题，那就是复制的过程需要同步的进行，很容易被影响，而且效率不高。例如主库必须要等待从库读取完了才能发送下个binlog事件。这就有点类似于一个阻塞的信道和非阻塞的信道。
• 在流程中新增Relay Log中继日志后，让原本同步的获取事件、重放事件解耦了，两个步骤可以异步的进行，Relay Log充当了缓冲区的作用。
• Relay Log包含一个relay-log.info的文件，用于记录当前复制的进度，下个事件从什么Pos开始写入，该文件由SQL线程负责更新。

2. binlog

(1) 格式

• Statement：基于语句

  statement模式下，复制过程中向slave发送的就是在master上执行的SQL原句，master会将执行的SQL原有发送到slave中

• Row：基于行✨

  row模式下，master会将每次DML操作引发的数据具体行变化记录在binlog中并复制到slave上，slave根据行的变更记录来对应的修改数据，但DDL类型的操作依然是statement的格式记录。

• Mixed：基于混合语句和行格式

  MySQL会根据执行的每一条具体的SQL语句来区别对待记录的日志形式，也就是在statement和row之间选择一种。

  这三种模式各有优劣，相对来说，基于Row的行格式被应用的更广泛，虽然这种模式下对资源的开销会偏大，但数据变化的准确性以及可靠性是要强于Statement格式的，同时这种模式下的Binlog提供了完整的数据变更信息，可以使其应用不被局限在MySQL集群系统内，可以被例如Binlogserver，DTS数据传输等服务应用，提供灵