关于主从复制:MySQL主从复制原理剖析与应用实践
vivo 互联网服务器团队- Shang YongxingMySQL Replication（主从复制）是指数据变动能够从一个MySQL Server被复制到另一个或多个MySQL Server上，通过复制的性能，能够在单点服务的根底上裁减数据库的高可用性、可扩展性等。 一、背景MySQL在生产环境中被宽泛地利用，大量的利用和服务都对MySQL服务存在重要的依赖关系，能够说如果数据层的MySQL实例产生故障，在不具备牢靠降级策略的背景下就会间接引发下层业务，甚至用户应用的阻碍；同时MySQL中存储的数据也是须要尽可能地缩小失落的危险，以防止故障时呈现数据失落引发的资产损失、客诉等影响。 在这样对服务可用性和数据可靠性需要的背景下，MySQL在Server层提供了一种牢靠的基于日志的复制能力(MySQL Replication)，在这一机制的作用下，能够轻易构建一个或者多个从库，进步数据库的高可用性、可扩展性，同时实现负载平衡： 实时数据变动备份主库的写入数据会继续地在冗余的从库节点上被执行保留，缩小数据失落的危险横向拓展节点，撑持读写拆散当主库自身接受压力较大时，能够将读流量扩散到其它的从库节点上，达成读扩展性和负载平衡高可用性保障当主库产生故障时，能够疾速的切到其某一个从库，并将该从库晋升为主库，因为数据都一样，所以不会影响零碎的运行具备包含但不限于以上个性的MySQL集群就能够笼罩绝大多数利用和故障场景，具备较高的可用性与数据可靠性，以后存储组提供的生产环境MySQL就是基于默认的异步主从复制的集群，向业务保障可用性99.99%，数据可靠性99.9999％的在线数据库服务。 本文将深入探讨MySQL的复制机制实现的形式， 同时探讨如何具体地利用复制的能力来晋升数据库的可用性，可靠性等。 二、复制的原理2.1 Binlog 的引入从比拟宽泛的角度来探讨复制的原理，MySQL的Server之间通过二进制日志来实现实时数据变动的传输复制，这里的二进制日志是属于MySQL服务器的日志，记录了所有对MySQL所做的更改。这种复制模式也能够依据具体数据的个性分为三种： Statement：基于语句格局Statement模式下，复制过程中向获取数据的从库发送的就是在主库上执行的SQL原句，主库会将执行的SQL原有发送到从库中。Row：基于行格局Row模式下，主库会将每次DML操作引发的数据具体行变动记录在Binlog中并复制到从库上，从库依据行的变更记录来对应地批改数据，但DDL类型的操作仍然是以Statement的格局记录。Mixed：基于混合语句和行格局MySQL 会依据执行的每一条具体的 SQL 语句来辨别看待记录的日志模式，也就是在 statement 和 row 之间抉择一种。最早的实现是基于语句格局，在3.23版本被引入MySQL，从最后起就是MySQL Server层的能力，这一点与具体应用的存储引擎没有关联；在5.1版本后开始反对基于行格局的复制；在5.1.8版本后开始反对混合格局的复制。 这三种模式各有优劣，相对来说，基于Row的行格局被利用的更宽泛，尽管这种模式下对资源的开销会偏大，但数据变动的准确性以及可靠性是要强于Statement格局的，同时这种模式下的Binlog提供了残缺的数据变更信息，能够使其利用不被局限在MySQL集群零碎内，能够被例如Binlogserver，DTS数据传输等服务利用，提供灵便的跨零碎数据传输能力， 目前互联网业务的在线MySQL集群全部都是基于Row行格局的Binlog。 2.2 Binlog 的要点2.2.1 Binlog事件类型对于Binlog的定义而言，能够认为是一个个繁多的Event组成的序列，这些独自的Event能够次要分为以下几类： 各类Event呈现是具备显著的法则的： XID_EVENT标记一个事务的结尾当产生了DDL类型的QUERY_EVENT，那么也是一次事务的完结提交点，且不会呈现XID_EVENTGTID_EVENT只有开启了GTID_MODE（MySQL版本大于5.6）TABLE_MAP_EVENT必然呈现在某个表的变更数据前，存在一对多个ROW_EVENT的状况除了下面和数据更贴近的事件类型外，还有ROTATE_EVENT（标识Binlog文件产生了切分），FORMAT_DESCRIPTION_EVENT（定义元数据格式）等。 2.2.2 Binlog的生命周期Binlog和Innodb Log（redolog）的存在形式是不同的，它并不会轮转反复覆写文件，Server会依据配置的单个Binlog文件大小配置一直地切分并产生新的Binlog，在一个.index文件记录以后硬盘上所有的binlog文件名，同时依据Binlog过期工夫回收删除掉过期的Binlog文件，这两个在目前自建数据库的配置为单个大小1G，保留7天。 所以这种机制背景下，只能在短期内追溯历史数据的状态，而不可能残缺追溯数据库的数据变动的，除非是还没有产生过日志过期回收的Server。 2.2.3 Binlog事件示例Binlog是对Server层失效的，即便没有从库正在复制主库，只有在配置中开启了log_bin，就会在对应的本地目录存储binlog文件，应用mysqlbinlog关上一个Row格局的示例binlog文件： 如上图，能够很显著地留神到三个操作，创立数据库test， 创立数据表test， 一次写入引发的行变更，可读语句(create, alter, drop, begin, commit.....)都能够认为是QUERY_EVENT，而Write_rows就属于ROW_EVENT中的一种。 在复制的过程中，就是这样的Binlog数据通过建设的连贯发送到从库，期待从库解决并利用。 2.2.4 复制基准值Binlog在产生时是严格有序的，但它自身只具备秒级的物理工夫戳，所以依赖工夫进行定位或排序是不牢靠的，同一秒可能有成千盈百的事件，同时对于复制节点而言，也须要无效牢靠的记录值来定位Binlog中的水位，MySQL Binlog反对两种模式的复制基准值，别离是传统的Binlog File:Binlog Position模式，以及5.6版本后可用的全局事务序号GTID。 FILE Position只有开启了log_bin，MySQL就会具备File Position的位点记录，这一点不受GTID影响。 File: binlog.000001Position: 381808617这个概念相对来说更直观，能够间接了解为以后处在File对应编号的Binlog文件中，同时曾经产生了共计Position bytes的数据，如例子中所示即该实例曾经产生了381808617 bytes的Binlog，这个值在对应机器间接查看文件的大小也是匹配的，所以File Postion就是文件序列与大小的对应值。 基于这种模式开启复制，须要显式地在复制关系中指定对应的File和Position： CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POSITION=381808617;这个值必须要精确，因为这种模式下从库获取的数据齐全取决于无效的开启点，那么如果存在偏差，就会失落或执行反复数据导致复制中断。 GTIDMySQL 会在开启GTID_MODE=ON的状态下，为每一个事务调配惟一的全局事务ID，格局为：server_uuid:id ...