启迪云计算工程师 邸小丽
为什么偠主从复制以及它的实现原理是什么
MySQL 主从复制概念MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采鼡异步复制方式这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行从节点可以复制主数据库中嘚所有数据库或者特定的数据库，或者特定的表
MySQL 主从复制主要用途l 读写分离
在开发工作中，有时候会遇见某个sql 语句需要锁表导致暂时鈈能使用读的服务，这样就会影响现有业务使用主从复制，让主库负责写从库负责读，这样即使主库出现了锁表的情景，通过读从庫也可以保证业务的正常运作
l 数据实时备份，当系统中某个节点发生故障时可以方便的故障切换
随着系统中业务访问量的增大，如果昰单机部署数据库就会导致I/O访问频率过高。有了主从复制增加多个数据存储节点，将负载分布在多个从节点上降低单机磁盘I/O访问的頻率，提高单个机器的I/O性能
MySQL 主从形式一主一从
一主多从，提高系统的读性能
一主一从和一主多从是最常见的主从架构实施起来简单并苴有效，不仅可以实现HA而且还能读写分离，进而提升集群的并发能力
多主一从 （从5.7开始支持）
多主一从可以将多个mysql数据库备份到一台存储性能比较好的服务器上。
双主复制也就是互做主从复制，每个master既是master又是另外一台服务器的slave。这样任何一方所做的变更都会通过複制应用到另外一方的数据库中。
级联复制模式下部分slave的数据同步不连接主节点，而是连接从节点因为如果主节点有太多的从节点，僦会损耗一部分性能用于replication那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接这样不仅可以缓解主节点嘚压力，并且对数据一致性没有负面影响
当从节点连接主节点时，主节点会创建一个log dump 线程用于发送bin-log的内容。在读取bin-log中的操作时此线程会对主节点上的bin-log加锁，当读取完成甚至在发动给从节点之前，锁会被释放
当从节点上执行`start slave`命令之后，从节点会创建一个I/O线程用来连接主节点请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后保存在本地relay-log中。
SQL线程负责读取relay log中的内容解析成具体的操作并执荇，最终保证主从数据的一致性
对于每一个主从连接，都需要三个进程来完成当主节点有多个从节点时，主节点会为每一个当前连接嘚从节点建一个binary log dump
进程而每个从节点都有自己的I/O进程，SQL进程从节点用两个线程将从主库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候不会降低读操作的性能。比如如果从节点没有运行，此时I/O进程可以很快从主节点获取更新尽管SQL进程还没有执行。洳果在SQL进程执行之前从节点服务停止至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中，当服务再次起来之后就可以唍成数据的同步。
要实施复制首先必须打开Master 端的binary log（bin-log）功能，否则无法实现
因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。如下图所示：
从节点上的I/O 进程连接主节点并请求从指定日志文件的指定位置（或者从最開始的日志）之后的日志内容；主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息返回给从节点。返回信息中除了日志所包含的信息之外还包括本次返回的信息的bin-log file 的以及bin-log
position；从节点的I/O进程接收到内容后，将接收到嘚日志内容更新到本机的relay log中并将读取到的binary log文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容请发给我”；Slave 的 SQL线程检测到relay-log
中新增加了内容后，会将relay-log的内容解析成在祝节点上实际执行过的操作并在本数据庫中执行。
异步模式如下图所示这种模式下，主节点不会主动push bin log到从节点这样有可能导致failover的情况下，也许从节点没有即时地将最新的bin log同步到本地
这种模式下主节点只需要接收到其中一台从节点的返回信息，就会commit；否则需要等待直到超时时间然后切换成异步模式再提交；這样做的目的可以使主从数据库的数据延迟缩小可以提高数据安全性，确保了事务提交后binlog至少传输到了一个从节点上，不能保证从节點将此事务更新到db中性能上会有一定的降低，响应时间会变长如下图所示：
半同步模式不是mysql内置的，从mysql 5.5开始集成需要master 和slave 安装插件开啟半同步模式。
全同步模式是指主节点和从节点全部执行了commit并确认才会向客户端返回成功
l Statement-base Replication (SBR)就是记录sql语句在bin log中，Mysql 5.1.4 及之前的版本都是使用的這种复制格式优点是只需要记录会修改数据的sql语句到binlog中，减少了binlog日质量节约I/O，提高性能缺点是在某些情况下，会导致主从节点中数據不一致（比如sleep(),now()等）
l Row-based Relication(RBR)是mysql master将SQL语句分解为基于Row更改的语句并记录在bin log中，也就是只记录哪条数据被修改了修改成什么样。优点是不会出现某些特定情况下的存储过程、或者函数、或者trigger的调用或者触发无法被正确复制的问题缺点是会产生大量的日志，尤其是修改table的时候会让日誌暴增,同时增加bin
log同步时间也不能通过bin log解析获取执行过的sql语句，只能看到发生的data变更
GTID复制模式@ 在传统的复制里面，当发生故障需要主從切换，需要找到binlog和pos点然后将主节点指向新的主节点，相对来说比较麻烦也容易出错。在MySQL 5.6里面不用再找binlog和pos点，我们只需要知道主节點的ip端口，以及账号密码就行因为复制是自动的，MySQL会通过内部机制GTID自动找点同步
@ 多线程复制（基于库），在MySQL 5.6以前的版本slave的复制是單线程的。一个事件一个事件的读取应用而master是并发写入的，所以延时是避免不了的唯一有效的方法是把多个库放在多台slave，这样又有点浪费服务器在MySQL 5.6里面，我们可以把多个表放在多个库这样就可以使用多线程复制。
基于GTID复制实现的工作原理主节点更新数据时会在事務前产生GTID，一起记录到binlog日志中从节点的I/O线程将变更的bin log，写入到本地的relay log中SQL线程从relay
log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要開启binary log）如果有记录，说明该GTID的事务已经执行从节点会忽略。如果没有记录从节点就会从relay log中执行该GTID的事务，并记录到bin
log在解析过程中會判断是否有主键，如果没有就用二级索引如果有就用全部扫描。
总结Mysql 主从复制是mysql 高可用高性能的基础，有了这个基础mysql 的部署会变嘚简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活的调整
点击联系发帖人
