深入MySQL实战.pdf

MySQL电子书深入MySQL实战快速理解MySQL核心技术业内资深大咖联合出品，详细解读AliSQL在双11等高并发场景下的应用与实践1MySQL电子书3123049688291MySQL高可用MGR8.0 最佳实践MySQL高并发场景实战RDS MySQL Java 开发实战MySQL查询优化MySQL 开发规约实战RDS for MySQL 表和索引优化实战从研发角度深入了解RDS AliSQL内核2020新特性深入MySQL实战微信关注公众号：阿里云数据库第一时间，获取更多技术干货阿里云开发者“藏经阁”海量免费电子书下载34MySQL电子书MySQL高可用MGR8.0 最佳实践（一）MGR是什么（一）MGR插件组成（二）单主模式（二）示例1.MGR的定义MGR是具备强大的分布式协调能力，可用于创建弹性、高可用性、高容错的复制拓扑的一个MySQL插件。2.通讯协议基于Paxos算法的GCS原子广播协议，保证了一条事务在集群内要么在全部节点上提交，要么全部回滚。3.组成员资格MGR内部提供一个视图服务，集群节点之间相互交换各自的视图信息，从而且实现集群整体的稳态。4.数据一致性MGR内部实现了一套不同事务之间修改数据的冲突认证检测机制。在集群的所有节点当中进行一个冲突认证检测，反之，通过冲突认证检测的事务即可提交成功。当一个事务发起提交后，它会通过原子广播协议分发到集群其他Secondary节点。集群的Secondary节点通过冲突检测之后，事务提交成功。在大多数的Secondary节点提交成功之后，会在Primary节点进行提交。反之，如果在冲突认证检测失败，Secondary节点会丢弃这段事务对应的Binlog，Primary节点回滚该事务。上图是一个三节点的MGR实例集群，Member1代表Primary节点，Member2、Member3代表Secondary节点。如上图所示，MGR插件使用 MySQL Server 与 API 接口层以及若干组件，最后由GCS（Group Communication System）协议封装而成。MySQL Server调用MGR插件是基于MySQL现有的主从复制，利用Row格式的Binlog和Gtid等功能实现的集群架构。API接口层复制基于MySQL Server交互的接口集，在逻辑上将MySQL内核与MGR插件隔绝开来。其他组件例如Capture组件，它是负责事务状态在集群内提交或是回滚，以及通过Binlog event广播到其他节点上进行的冲突认证检测进行到哪个阶段。Apply组件代表MGR集群Secondary节点Binlog回放，Recovery组件代表进行崩溃恢复或集群扩容时增量数据的应用。ON表示单主模式，也是默认模式，OFF表示多主模式。如下图所示，在单主模式下（group_replication_single_primary_mode=ON）:1该变量在所有组成员中必须设置为相同的值，同一个组中，不能将成员部署在不同模式中。例如，一个成员配置为单主模式，另一个成员配置为多主模式。2该集群具有一个设置为读写模式的主节点，组中的所有其他成员都设置为只读模式（superread-only=ON）；MGR架构分为单主模式和多主模式。MGR特性集群架构作者：张彦东Member 1Member 2Member 3executecertifybinlogbinlogcommitcommitcertifyrelay logapplybinlogcommitcertifyrelay logapplyConsensusMySQL ServerAPIs：Capture/Apply/LifecycleApplierCaptureRecoveryReplication Protocol LogicsGroup Communication System APIMySQL Group Replication PluginGroupGroup Communication Engine(Paxos variant)56MySQL电子书3.读写节点通常是引导该组的第一个节点，加入该集群的所有其他只读节点均需要从读写节点同步数据，并自动设置为只读模式。单主模式集群原理流程图多主模式集群原理流程图同步原理示例冲突检测原理Write ClientsServer S1 is the primary.Read ClientsS1S2S3S4S5Write Clients?Server S1 fails.Read ClientsS1S2S3S4S5Write ClientsServer S2 is the new primary.Read ClientsS2S3S4S5（三）多主模式在多主模式下（group_replication_single_primary_mode=OFF）:1.所有节点不会区分Primary和Standby角色；2.加入该集群时，与其他组成员兼容的任何节点都被设置为读写模式，并且可以处理写请求，即使它们在集群内是并发执行的；3.如果组复制中的某个节点停止接受写事务，例如，在某个节点意外宕机的情况下，可以将与其连接的客户端重定向或故障转移到处于读写模式的任何其他健康的节点；4.组复制本身不处理客户端故障转移，因此需要使用中间件框架（例如MySQL Router 8.0代理，连接器或应用程序本身）来实现。如上图所示，以一个三节点的MGR集群为例。在单主模式下，当一个事务发起提交，它会通过原子广播协议将事务伴随着Binlog Event广播到其他Secondary节点上。在获得集群大多数节点同意之后，它会进行一个提交。如果通过冲突认证检测，那么该事务最终会在集群当中提交。如果在Secondary节点上面没有通过冲突认证检测，那么Secondary节点丢弃该事务对应的Binlog，Primary节点回滚该事务。如上图所示，在冲突检测时：1.每个事务的Gtid Set和对应的主键Hash值组成事务认证列表，在每个节点的内存当中都维护这样一个冲突检测库。2.Gtid set：标记数据库的快照版本，事务提交前从gtid_execute变量中获取该值；Write ClientsAll server are primaries.Read ClientsS1S2S3S4S5Write Clients?Server S1 fails.Read ClientsS1S2S3S4S5Write ClientsS1s client connects to S3.Read ClientsS2S3S4S5（一）同步原理示例（二）冲突检测原理数据同步原理PrepareBinlogCommitCOMMITDB1DB3TXTXSucceedsERROROKFallsCertifyRollbackPaxosDB2Relay logApplyTXSucceedsFallsCertifyDropPaxosDB2DB1DB3PK HASHdb1.tb1.pk=1db1.tb1.pk=2GTID SETgroup_name:1-10group_name:1-1578MySQL电子书3.事务提交前，数据库中执行了的Gtid集合，随着Binlog中的Event通过原子广播的方式分发到集群的所有节点上进行事务冲突检测。如上图所示，以T1与T2这两条Update语句为例。若T2修改的数据在冲突检测数据库中无匹配记录，则判定为通过冲突检测认证；若T2中的GTID SET包含了冲突检测数据库中相同主键值的GTID SET，则冲突认证检测通过；冲突认证检测通过后，每个节点的冲突检测数据库按照如下规则变更：1.若在冲突检测数据库中无匹配记录，则向其中插入一条新的记录。2.如果有记录，则更新冲突检测数据库中的GTID SET值。若T1修改的数据在冲突检测数据库中有匹配到记录，且T1的GTID SET不包括冲突检测数据库中的GTID SET，则判定为冲突检测不通过。注意：冲突检测不通过时，不会更新认证数据库里的GTID SET。目前业内存在以下问题：1.MGR可确保仅在集群中的大多数节点都已收到事务，并就并发发送的所有事务之间的相对顺序达成一致后才提交事务。相对顺序意味着，在分发到Secondary节点之后，可以不按照Primary节点提交的顺序进行提交，只需保证和集群的一致性即可。2.在流量小的时候不存在任何的性能问题。当流量突增时，如果集群中某些节点的写入吞吐量比其他节点少，尤其是小于Primary节点，则这些节点的数据和Primary节点的数据存在偏差。例如说在集群当中，一个3节点的集群，如果节点之间服务性能存在差异的话，则会存在性能问题。3.在单主模式的集群中，如果发生故障转移，在新的Primary节点可以立刻接受写入请求的情况下，则存在集群内事务一致性的问题。举例说明，当集群扩容时，例如由3节点集群扩容到5节点集群：1.无论采用Clone的方式还是用Xtrabackup做全量数据恢复后，都避免不了在集群扩容期间产生的增量数据以二进制日志的方式来追平；2.若新扩容的节点配置较低，写入吞吐差，则新加入的节点很有可能一直处于Recover的状态，该节点很难达到Online的状态。在进行高可用切换之后，存在事务一致性保证，这是由于Secondary节点和Primary节点存在追数据的过程，如果数据没有追平，那么业务数据可能会读到旧的数据，用户可以根据group_replication_consistency参数对应的可选值进行调整，总共有5个值如下：1.EVENTUAL（三）冲突检测示例DB2DB1DB3PK HASHT1update tb1set xid=2where PK=1gtid_executed:group_name:1-100gtid_executed:group_name:1-100T2update tb1set xid=3where PK=1T1:update tb1 set xid=1 wherepk=1(snapshot:group_name:1-100)T2:update tb1 set xid=2 wherepk=1(snapshot:group_name:1-100)certifydb1.tb1.pk=1GTID SETupdategroup_name:1-50PK HASHdb1.tb1.pk=1GTID SETgroup_name:1-101PK HASHT1:update tb1 set xid=1 wherepk=1(snapshot:group_name:1-100)certifydb1.tb1.pk=1GTID SETNo need to updategroup_name:1-101（一）存在的问题（二）事务一致性保证性能分析910MySQL电子书开启该级别的事务（T2），事务执行前不会等待先序事务（T1）的回放完成，也不会影响后序事务等待该事务回放完成。2.BEFORE开启了该级别的事务（T2），在开始前首先要等待先序事务（T1）的回放完成，确保此事务将在最新的数据上执行。3.AFTER开启该级别的事务（T1），只有等该事务回放完成。其他后序事务（T2）才开始执行，这样所有后序事务都会读取包含其更改的数据库状态，而不管它们在哪个节点上执行。4.BEFORE_AND_AFTER开启该级别等事务（T2），需要等待前序事务的回放完成（T1）；同时后序事务（T3）等待该事务的回放完成。5.BEFORE_ON_PRIMARY_FAILOVER在发生切换时，连到新主的事务会被阻塞，等待先序提交的事务回放完成；这样确保在故障切换时客户端都能读取到主服务器上的最新数据，保证了一致性。用户根据不同的级别，根据业务上是读多写少，还是写多读少，或者是读写均衡的请求，不同的场景选择不同的值即可。1.流控机制的功能性能的问题对应着解决方案，MGR的流控机制试图解决以下问题：1）集群内节点之间不会相差太多的事务；2）快速适