MySQL主从复制和Redis主从复制有点像, 可以相互对照一下. Redis主从复制
Binary Log日志格式
- STATEMENT
记录每一条会修改数据的SQL语句. 相比ROW来说日志量少, 性能更高, 但在某些特殊情况下会丢失数据, 比如使用sleep()函数等. - ROW
如果是表结构变更, 仍然以STATEMENT格式记录SQL, 对于其他增删改SQL语句, 会将其分解为基于行更改的SQL语句. ROW格式相比STATEMENT格式来说日志量更大, 性能会低一些, 但数据不会丢失. - MIXED
这是STATEMENT和ROW两种格式的结合, 它根据每一条具体的SQL语句来选择使用STATEMENT或ROW.
MySQL主从复制的原理
异步复制
MySQL主从复制默认是异步复制.
- 主库修改数据会记录Binary Log日志, 只有记录Binary Log日志成功后, 事务才能提交.
- 从库接入后会开启一个IO线程, 根据position偏移量从主库的Binary Log日志中拷贝数据.
- 将拷贝过来的数据写入Relay Log中.
- 开启一个SQL线程从Relay Log日志中读取SQL, 然后再执行.
半同步复制
半同步复制是在异步复制的基础上进行优化, 即主库写入binlog日志之后, 会立即将数据同步到从库, 从库将binlog日志写入自己本地的Relay Log之后, 会返回一个ack命令给主库, 主库只有接收到至少一个从库的ack命令之后, 才会认为写操作完成.
半同步复制插件: semisync_master.so
并行复制
并行复制是对异步复制导致的主从同步延时问题的解决方案.
(1) 为什么会产生主从同步延时呢?
主库写入binlog日志是多线程并发执行的, 而从库执行Relay Log日志中的SQL是单线程执行的, 所以当主库的写并发太大时, 就会导致主从同步延时. 解决这个问题的方向就是让从库多线程并发地执行Relay Log日志中的SQL.
并行复制可以基本解决主从同步延迟的问题, 但当主库的写并发太大时, 还是会有延迟, 这时就只能拆分主库了, 降低单库的写并发.
(2) 并行复制的原理
MySQL5.6是基于库的并行复制, 即不同数据库的SQL可以并发地执行, 而MySQL5.7是基于组提交的并行复制, 即同一组的事务可以并发地执行, 我们来看下具体实现.
- SQL层有一个全局的logical clock: commit_clock
- 当事务进入prepare阶段时(执行SQL, 但还未提交), 从commit_clock获取一个逻辑时间保存在binlog中.(last_committed)
- 当事务准备commit之前, 从commit_clock再获取一个逻辑时间保存在binlog中.(sequence_number)
- last_committed - sequence_number能覆盖地就属于同一组(能同时执行说明没有锁冲突)
- 从节点对属于同一组事务的binlog会并发地执行.
如何解决MySQL主库宕机导致的数据丢失情况？
使用半同步复制来解决这个问题.
如何解决主从同步延时的问题?
(1) 主从同步延时的原因
主库写入binlog日志是多线程并发执行的, 而从库执行Relay Log日志中的SQL是单线程执行的, 所以当主库的写并发太大时, 就会导致主从同步延时.
(2) 解决办法
- 并行复制
MySQL5.7开启并行复制后, 主从同步延时问题基本就解决了. - 分库
主从同步延时的根本原因还是主库写并发太高, 我们可以通过分库来降低单库的写并发. - 优化代码
较短时间的主从同步延时是可以接受的, 我们不要写那种insert+select+update式的语句, 即插入一条数据后立即查询, 然后再修改.