佛山新网站建设渠道,天津工程网站建设,智联网最新招聘官网,自己网上做超市小程序MySQL 中的集群部署方案 前言 这里来聊聊#xff0c;MySQL 中常用的部署方案。 MySQL Replication MySQL Replication 是官方提供的主从同步方案#xff0c;用于将一个 MySQL 的实例同步到另一个实例中。Replication 为保证数据安全做了重要的保证#xff0c;是目前运用…MySQL 中的集群部署方案 前言 这里来聊聊MySQL 中常用的部署方案。 MySQL Replication MySQL Replication 是官方提供的主从同步方案用于将一个 MySQL 的实例同步到另一个实例中。Replication 为保证数据安全做了重要的保证是目前运用最广的 MySQL 容灾方案。Replication 用两个或以上的实例搭建了 MySQL 主从复制集群提供单点写入多点读取的服务实现了读的 scale out。 上面的栗子一个主库(M)三个从库(S)通过 replicationMaster 生成 event 的 binlog然后发给 slaveSlave 将 event 写入 relaylog然后将其提交到自身数据库中实现主从数据同步。 对于数据库之上的业务层来说基于 MySQL 的主从复制集群单点写入 Master ,在 event 同步到 Slave 后读逻辑可以从任何一个 Slave 读取数据以读写分离的方式大大降低 Master 的运行负载同时提升了 Slave 的资源利用。 优点 1、通过读写分离实现横向扩展的能力写入和更新操作在源服务器上进行从服务器中进行数据的读取操作通过增大从服务器的个数能够极大的增强数据库的读取能力 2、数据安全因为副本可以暂停复制过程所以可以在副本上运行备份服务而不会破坏相应的源数据 3、方便进行数据分析可以在写库中创建实时数据数据的分析操作在从库中进行不会影响到源数据库的性能 实现原理 在主从复制中从库利用主库上的 binlog 进行重播实现主从同步复制的过程中蛀主要使用到了 dump threadI/O threadsql thread 这三个线程。 IO thread: 在从库执行 start slave 语句时创建负责连接主库请求 binlog接收 binlog 并写入 relay-log dump thread用于主库同步 binlog 给从库负责响应从 IO thread 的请求。主库会给每个从库的连接创建一个 dump thread然后同步 binlog 给从库 sql thread读取 relay log 执行命令实现从库数据的更新。 来看下复制的流程 1、主库收到更新命令执行更新操作生成 binlog; 2、从库在主从之间建立长连接 3、主库 dump_thread 从本地读取 binlog 传送刚给从库 4、从库从主库获取到 binlog 后存储到本地成为 relay log中继日志 5、sql_thread 线程读取 relay log 解析、执行命令更新数据。 不过 MySQL Replication 有个严重的缺点就是主从同步延迟。 因为数据是进行主从同步的那么就会遇到主从同步延迟的情况。 为什么会出现主从延迟 1、从库机器的性能比主库差 2、从库的压力大 大量查询放在从库上可能会导致从库上耗费了大量的 CPU 资源进而影响了同步速度造成主从延迟。 3、大事务的执行 有事务产生的时候主库必须要等待事务完成之后才能写入到 binlog假定执行的事务是一个非常大的数据插入这些数据传输到从库从库同步这些数据也需要一定的时间就会导致从节点出现数据延迟。 4、从库的复制能力较差 如果从库的复制能力低于主库那么在主库写入压力很大的情况下就会造成从库长时间数据延迟的情况出现。 如何解决 1、优化业务逻辑避免出现多线程大事务的并发场景 2、提高从库的机器性能减少主库写 binlog 和从库读 binlog 的效率差 3、保证主库和从库的网络连接避免出现网络延迟导致的 binlog 传输延迟 4、强行读主库 5、配合 semi-sync 半同步复制 semi-sync 半同步复制 MySQL 有三种同步模式分别是 1、异步复制MySQL 中默认的复制是异步的主库在执行完客户端提交的事务后会立即将结果返回给客户端并不关心从库是否已经接收并且处理。存在问题就是如果主库的日志没有及时同步到从库然后主库宕机了这时候执行故障转移在从库冲选主可能会存在选出的主库中数据不完整 2、全同步复制指当主库执行完一个事务并且等到所有从库也执行完成这个事务的时候主库在提交事务并且返回数据给客户端。因为要等待所有从库都同步到主库中的数据才返回数据所以能够保证主从数据的一致性但是数据库的性能必然受到影响 3、半同步复制是介于全同步和全异步同步的一种主库至少需要等待一个从库接收并写入到 Relay Log 文件即可主库不需要等待所有从库给主库返回 ACK。主库收到 ACK 标识这个事务完成返回数据给客户端。 MySQL 中默认的复制是异步的所以主库和从库的同步会存在一定的延迟更重要的是异步复制还可能引起数据的丢失。全同步复制的性能又太差了所以从 MySQL 5.5 开始MySQL 以插件的形式支持 semi-sync 半同步复制。 半同步复制潜在的问题 在传统的半同步复制中主库写数据到 binlog并且执行 commit 提交事务后会一直等待一个从库的 ACK。从库会在写入 Relay Log 后将数据落盘然后回复给主库 ACK主库收到这个 ACK 才能给客户端事务完成的确认。 这样会存在问题就是主库已经将该事务的 commit 存储到了引擎层应用已经可以看到数据的变化了只是在等待从库的返回如果此时主库宕机可能从库还没有写入 Relay Log就会发生主从库数据不一致。 为了解决这个问题MySQL 5.7 引入了增强半同步复制。主库写入数据到 binlog 后就开始等待从库的应答 ACK直到至少一个从库写入 Relay Log 后并将数据落盘然后返回给主库 ACK通知主库可以进行 commit 操作然后主库再将事务提交到事务引擎应用此时才能看到数据的变化。 不过看下来增强半同步复制在同步给从库之后因为自己的数据还没有提交然后宕机了主库中也是会存在数据的丢失不过应该想到的是这时候主库宕机了是会重新在从库中选主的这样新选出的主库数据是没有发生丢失的。 MySQL Group Replication MySQL Group Replication 组复制又称为 MGR。是 Oracle MySQL 于 2016 年 12 月发布 MySQL 5.7.17 推出的一个全新高可用和高扩展的解决方案。 引入复制组主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。 MGR 由若干个节点共同组成一个复制组一个事务的提交必须经过组内大多数节点 (N / 2 1) 决议并通过才能得以提交。 当客户端发起一个更新事务时该事务先在本地执行执行完成之后就要发起对事务的提交操作。在还没有真正提交之前需要将产生的复制写集广播出去复制到其它成员。因为事务是通过原子广播发送的所以组中的成员要么都接收事务要么都不接收事务。如果组中的所有成员收到了该广播消息(事务)那么他们会按照之前发送事务的相同顺序收到该广播消息。因此所有组成员都以相同的顺序接收事务的写集并为事务建立全局顺序。因此所有组成员都以相同的顺序接收事务的写集并为事务建立全局顺序。 在不同组成员并发执行的事务可能存在冲突。冲突是通过检查和比较两个不同并发事务的 write set 来验证的这个过程称为认证。在认证期间冲突检测在行级别执行的如果在不同组成员上执行的两个并发事务更新了同一行数据则存在冲突。根据冲突认证检测机制判断按照顺序第一次提交的会正常执行第二次提交的事务会在事务发起的原始组成员上执行回滚,组中的其他成员对该事务执行删除。如果两个事务经常发生冲突那么最好将这两个事务放在同一个组成员中执行这样它们在本地锁管理器的协调下将都有机会提交成功而不至于因为处在两个不同的组成员中由于冲突认证而导致其中一个事务被频繁回滚。 最终所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改保证组内数据强一致性。 有下面的几种特性 1、避免脑裂MGR 中不会出现脑裂的现象 2、数据一致性保障MGR 的冗余能力很好能够保证 Binlog Event 至少被复制到超过一半的成员上只要同时宕机的成员不超过半数便不会导致数据丢失。MGR还保证只要 Binlog Event 没有被传输到半数以上的成员本地成员不会将事务的 Binlog Event 写入 Binlog 文件和提交事务从而保证宕机的服务器上不会有组内在线成员上不存在的数据。因此宕机的服务器重启后不再需要特殊的处理就可以加入组 3、多节点写入支持多写模式下支持集群中的所有节点都可以写入。 组复制的应用场景 1、弹性复制需要非常灵活的复制基础设施的环境其中MySQL Server的数量必须动态增加或减少并且在增加或减少Server的过程中对业务的副作用尽可能少。例如云数据库服务 2、高可用分片分片是实现写扩展的一种流行方法。基于 组复制 实现的高可用分片其中每个分片都会映射到一个复制组上逻辑上需要一一对应但在物理上一个复制组可以承载多个分片 3、替代主从复制在某些情况下使用一个主库会造成单点争用。在某些情况下向整个组内的多个成员同时写入数据对应用来说可能伸缩性更强 4、自治系统可以利用组复制内置的自动故障转移、数据在不同组成员之间的原子广播和最终数据一致性的特性来实现一些运维自动化。 InnoDB Cluster InnoDB Cluster 是官方提供的高可用方案,是 MySQL 的一种高可用性(HA)解决方案它通过使用 MySQL Group Replication 来实现数据的自动复制和高可用性InnoDB Cluster 通常包含下面三个关键组件 1、MySQL Shell: 它是 MySQL 的高级管理客户端; 2、MySQL Server 和 MGR使得一组 MySQL 实例能够提供高可用性对于 MGRInnodb Cluster 提供了一种更加易于编程的方式来处理 MGR; 3、MySQL Router一种轻量级中间件主要进行路由请求将客户端发送过来的请求路由到不同的 MySQL 服务器节点。 MySQL Server 基于 MySQL Group Replication 构建提供自动成员管理容错自动故障转移动能等。InnoDB Cluster 通常以单主模式运行一个读写实例和多个只读实例。不过也可以选用多主模式。 优点 1、高可用性通过 MySQL Group ReplicationInnoDB Cluster 能够实现数据在集群中的自动复制从而保证数据的可用性 2、简单易用InnoDB Cluster 提供了一个简单易用的管理界面使得管理员可以快速部署和管理集群 3、全自动故障转移: InnoDB Cluster 能够自动检测和诊断故障并进行必要的故障转移使得数据可以继续可用。 缺点 1、复杂性InnoDB Cluster 的部署和管理比较复杂需要对 MySQL 的工作原理有一定的了解 2、性能影响由于自动复制和高可用性的要求InnoDB Cluster 可能对 MySQL 的性能造成一定的影响 3、限制InnoDB Cluster 的功能对于一些特殊的应用场景可能不够灵活需要更多的定制。 InnoDB ClusterSet MySQL InnoDB ClusterSet 通过将主 InnoDB Cluster 与其在备用位置例如不同数据中心的一个或多个副本链接起来为 InnoDB Cluster 部署提供容灾能力。 InnoDB ClusterSet 使用专用的 ClusterSet 复制通道自动管理从主集群到副本集群的复制。如果主集群由于数据中心损坏或网络连接丢失而变得无法使用用户可以激活副本集群以恢复服务的可用性。 InnoDB ClusterSet 的特点 1、主集群和副本集群之间的紧急故障转移可以由管理员通过 MySQL Shell使用 AdminAPI 进行操作 2、InnoDB ClusterSet 部署中可以拥有的副本集群的数量没有定义的限制 3、异步复制通道将事务从主集群复制到副本集群。clusterset_replication 在 InnoDB ClusterSet 创建过程中在每个集群上都设置了名为 ClusterSet 的复制通道当集群是副本时它使用该通道从主集群复制事务。底层组复制技术管理通道并确保复制始终在主集群的主服务器作为发送方和副本集群的主服务器作为接收方之间进行 4、每个 InnoDB ClusterSet 集群只有主集群能够接收写请求大多数的读请求流量也会被路由到主集群不过也可以指定读请求到其他的集群 InnoDB ClusterSet 的限制 1、InnoDB ClusterSet 只支持异步复制不能使用半同步复制无法避免异步复制的缺陷数据延迟、数据一致性等 2、InnoDB ClusterSet 仅支持Cluster实例的单主模式,不支持多主模式。 即只能包含一个读写主集群, 所有副本集群都是只读的, 不允许具有多个主集群的双活设置因为在集群发生故障时无法保证数据一致性 3、已有的 InnoDB Cluster 不能用作 InnoDB ClusterSet 部署中的副本集群。副本集群必须从单个服务器实例启动作为新的 InnoDB 集群 4、只支持 MySQL 8.0。 InnoDB ReplicaSet InnoDB ReplicaSet 是 MySQL 团队在 2020 年推出的一款产品用来帮助用户快速部署和管理主从复制在数据库层仍然使用的是主从复制技术。 InnoDB ReplicaSet由单个主节点和多个辅助节点传统上称为 MySQL 复制源和副本组成。 与InnoDB cluster 类似, MySQL Router 支持针对 InnoDB ReplicaSet 的引导, 这意味着可以自动配置 MySQL Router 以使用 InnoDB ReplicaSet, 而无需手动配置文件. 这使得 InnoDB ReplicaSet 成为一种快速简便的方法, 可以启动和运行 MySQL 复制和 MySQL Router, 非常适合扩展读取, 并在不需要 InnoDB 集群提供高可用性的用例中提供手动故障转移功能。 InnoDB ReplicaSet 的限制 1、没有自动故障转移在主节点不可用的情况下需要使用 AdminAPI 手动触发故障转移然后才能再次进行任何更改。但是辅助实例仍可用于读取 2、由于意外停止或不可用无法防止部分数据丢失在意外停止时未完成的事务可能会丢失 3、在意外退出或不可用后无法防止不一致。如果手动故障转移提升了一个辅助实例而前一个主实例仍然可用例如由于网络分区裂脑情况可能会导致数据不一致 4、InnoDB ReplicaSet 不支持多主模式。允许写入所有成员的经典复制拓扑无法保证数据一致性 5、读取横向扩展是有限的。InnoDB ReplicaSet 基于异步复制因此无法像 Group Replication 那样调整流量控制 6、一个 ReplicaSet 最多由一个主实例组成。支持一个或多个辅助。尽管可以添加到 ReplicaSet 的辅助节点的数量没有限制但是连接到 ReplicaSet 的每个 MySQL Router 都必须监视每个实例。因此一个 ReplicaSet 中加入的实例越多监控就越多。 使用 InnoDB ReplicaSets 的主要原因是你有更好的写性能。使用 InnoDB ReplicaSets 的另一个原因是它们允许在不稳定或慢速网络上部署而 InnoDB Cluster 则不允许。 MMM MMMMaster-Master replication manager for MySQL是一套支持双主故障切换和双主日常管理的脚本程序。MMM 使用 Perl 语言开发主要用来监控和管理 MySQL Master-Master双主复制可以说是 MySQL 主主复制管理器。 双主模式业务上同一时刻只能一个主库进行数据的写入。另一个主备库会在主服务器失效时进行主备切换和故障转移。 MMM 中是通过一个 VIP(虚拟 IP) 的机制来保证集群的高可用的。整个集群中在主节点会提供一个 VIP 地址来提供数据读写服务当出现故障的时候VIP 就会从原来的主节点便宜到其他节点由其他节点提供服务。 MMM无法完全的保证数据一致性所以适用于对数据的一致性要求不是很高的场景。因为主备上的数据不一定是最新的可能还没从库的新。解决方法开启半同步。 MMM 的优缺点 优点高可用性扩展性好出现故障自动切换对于主主同步在同一时间只提供一台数据库写操作保证数据的一致性。 缺点无法完全保数据的一致性建议采用半同步复制方式减少失败的概率目前 MMM 社区已经缺少维护不支持基于 GTID 的复制。 适用场景 MMM的适用场景为数据库访问量大业务增长快并且能实现读写分离的场景。 MHA Master High Availability Manager and Tools for MySQL简称 MHA 。是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。 这个工具专门用于监控主库的状态当发现 master 节点故障的时候会自动提升其中拥有新数据的 slave 节点成为新的 master 节点在此期间,MHA 会通过其他从节点获取额外的信息来避免数据一致性问题。MHA 还提供了 mater 节点的在线切换功能即按需切换 master-slave 节点。MHA 能够在30秒内实现故障切换并能在故障切换过程中最大程度的保证数据一致性。 MHA 由两部分组成 MHA Manager管理节点和MHA Node数据节点。 MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群也可以部署在一台 slave节点上。MHA Node 运行在每台 MySQL 服务器上MHA Manager 会定时探测集群中的 master 节点当 master 出现故障时它可以自动将最新数据的 slave 提升为新的 master然后将所有其他的 slave 重新指向新的 master。 整个故障转移过程对应用程序完全透明。 在 MHA 自动故障切换过程中MHA 试图从宕机的主服务器上最大限度的保存二进制日志最大程度的保证数据的不丢失但这并不总是可行的。例如主服务器硬件故障或无法通过 ssh 访问MHA 没法保存二进制日志只进行故障转移而丢失了最新的数据。 使用 MySQL 5.5 开始找支持的半同步复制可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个 slave 已经收到了最新的二进制日志MHA 可以将最新的二进制日志应用于其他所有的 slave 服务器上因此可以保证所有节点的数据一致性。 目前 MHA 主要支持一主多从的架构要搭建 MHA,要求一个复制集群中必须最少有三台数据库服务器 一主二从即一台 master一台充当备用 master另外一台充当从库因为至少需要三台服务器。 MHA 工作原理总结如下 1、从宕机崩溃的 master 保存二进制日志事件binlog events 2、识别最新更新的 slave 3、应用差异的中继日志(relay log) 到其他slave 4、应用从master保存的二进制日志事件(binlog events) 5、提升一个 slave 为新master 6、使用其他的 slave 连接新的 master 进行复制。 优点 1、可以支持基于 GTID 的复制模式 2、MHA 在进行故障转移时更不易产生数据丢失 3、同一个监控节点可以监控多个集群。 缺点 1、需要编写脚本或利用第三方工具来实现 Vip 的配置 2、MHA 启动后只会对主数据库进行监控 3、需要基于 SSH 免认证配置存在一定的安全隐患。 Galera Cluster Galera Cluster 是由 Codership 开发的MySQL多主集群包含在 MariaDB 中同时支持 Percona xtradb、MySQL是一个易于使用的高可用解决方案在数据完整性、可扩展性及高性能方面都有可接受的表现。 其本身具有 multi-master 特性支持多点写入Galera Cluster 中每个实例都是对等的互为主从。当客户端读写数据的时候可以选择任一 MySQL 实例对于读操作每个实例读取到的数据都是相同的。对于写操作当数据写入某一节点后集群会将其同步到其它节点。这种架构不共享任何数据是一种高冗余架构。 主要功能 1、同步复制 2、真正的 multi-master即所有节点可以同时读写数据库 3、自动的节点成员控制失效节点自动被清除 4、新节点加入数据自动复制 5、真正的并行复制行级 6、用户可以直接连接集群使用感受上与 MySQL 完全一致。 优势 1、数据一致同步复制保证了整个集群的数据一致性无论何时在任何节点执行相同的select查询结果都一样 2、高可用性由于所有节点数据一致单个节点崩溃不需要执行复杂耗时的故障切换也不会造成丢失数据或停止服务 3、性能改进同步复制允许在集群中的所有节点上并行执行事务从而提高读写性能 4、更小的客户端延迟 5、同时具有读和写的扩展能力。 分析下原理 Galera Cluster 中主要用到了同步复制主库中的单个更新事务需要在所有从库中同步更新当主库提交事务集群中的所有节点数据保持一致。 异步复制主库将数据更新传播给从库后立即提交事务而不论从库是否成功读取或重放数据变化所以异步复制会存在短暂的主从数据同步不一致的情况出现。 不过同步复制的缺点也是很明显的同步复制协议通常使用两阶段提交或分布式锁协调不同节点的操作也及时说节点越多需要协调的节点也就越多那么事务冲突和死锁的概率也就会随之增加。 我们知道 MGR 组复制的引入也是为了解决传统异步复制和半同步复制可能产生数据不一致的问题MGR 中的组复制基于 Paxos 协议原则上事务的提交主要大多数节点 ACK 就可以提交了。 Galera Cluster 中的同步需要同步数据到所有节点保证所有节点都成功。基于专有通信组系统 GCommon ,所有节点都必须有 ACK。 Galera 复制是一种基于验证的复制基于验证的复制使用通信和排序技术实现同步复制通过广播并发事务之间建立的全局总序来协调事务提交。简单的讲就是事务必须以相同的顺序应用于所有实例。 事务现在本地执行然后发送的其他节点做冲突验证没有冲突的时候所有节点提交事务否则在所有节点回滚。 当客户端发出 commit 命令时在实际提交之前对数据所做的更改都会收集到一个写集合中写集合中包含事务信息和所更改行的主键数据库将写集发送到其它节点。 节点用写集中的主键与当前节点中未完成事务的所有写集的主键比较确定节点是否可以提交事务同时满足下面三个条件会被任务存在冲突验证失败 1、两个事务来源于不同节点 2、两个事务包含相同的主键 3、老事务对新事务不可见即老事务未提交完成。新老事务的划定依赖于全局事务总序即 GTID。 验证失败节点将删除写集集群将回滚原始事务对于所有的节点都是如此每个节点单独进行验证。因为所有节点都以相同的顺序接收事务它们对事务的结果都会做出相同的决定要么全成功要么都失败。成功后自然就提交了所有的节点又会重新达到数据一致的状态。节点之间不交换“是否冲突”的信息各个节点独立异步处理事务。 MySQL Cluster MySQL Cluster 是一个高度可扩展的兼容 ACID 事务的实时数据库基于分布式架构不存在单点故障MySQL Cluster 支持自动水平扩容并能做自动的读写负载均衡。 MySQL Cluster 使用了一个叫 NDB 的内存存储引擎来整合多个 MySQL 实例提供一个统一的服务集群。 NDB 是一种内存性的存储引擎,使用 Sarding-Nothing 的无共享的架构。Sarding-Nothing 指的是每个节点有独立的处理器磁盘和内存节点之间没有共享资源完全独立互不干扰节点之间通过告诉网络组在一起每个节点相当于是一个小型的数据库存储部分数据。这种架构的好处是可以利用节点的分布性并行处理数据调高整体的性能还有就是有很高的水平扩展性能只需要增加节点就能增加数据的处理能力。 MySql Cluster 中包含三种节点分别是管理节点(NDB Management Server)、数据节点(Data Nodes)和 SQL查询节点(SQL Nodes) 。 SQL Nodes 是应用程序的接口像普通的 mysqld 服务一样接受用户的 SQL 输入执行并返回结果。Data Nodes 是数据存储节点NDB Management Server 用来管理集群中的每个 node。 其中数据节点会存储集群中的数据分区和分区的副本来看下 MySql Cluster 是如何对数据进行分片的操作的首先来了解下下面几个概念 节点组Node Group 一组数据节点的集合。节点组的个数节点数 / 副本数 比如有集群中 4 个节点副本数为 2对应 NoOfReplicas 的设置那么节点组个数为2。 另外在可用性方面数据的副本在组内交叉分配一个节点组内只有要一台机器可用就可以保证整个集群的数据完整性实现服务的整体可用。 分区PartitionMySql Cluster 是一个分布式的存储系统数据按照 分区 划分成多份存储在各数据节点中分区个数由系统自动计算分区数 数据节点数 / LDM 线程数 副本Replica分区数据的备份有几个分区就有几个副本为了避免单点保证 MySql Cluster 集群的高可用原始数据对应的分区和副本通常会保存在不同的主机上在一个节点组内进行交叉备份。 栗如上面的例子有四个数据节点使用ndbd副本数为2的集群节点组被分为2组4/2数据被分为4个分区数据分配情况如下: 分区0Partition 0保存在节点组 0Node Group 0中分区数据(主副本 — Primary Replica)保存在节点1(node 1) 中备份数据(备份副本Backup Replica)保存在节点2(node 2) 中 分区1Partition 1保存在节点组 1Node Group 1中分区数据(主副本 — Primary Replica)保存在节点3(node 3) 中备份数据(备份副本Backup Replica)保存在节点4(node 4) 中 分区2Partition 2保存在节点组 0Node Group 0中分区数据(主副本 — Primary Replica)保存在节点2(node 2) 中备份数据(备份副本Backup Replica)保存在节点1(node 1) 中 分区3Partition 2保存在节点组 1Node Group 1中分区数据(主副本 — Primary Replica)保存在节点4(node 4) 中备份数据(备份副本Backup Replica)保存在节点3(node 3) 中 这样对于一张表的一个 Partition 来说在整个集群有两份数据并分布在两个独立的 Node 上实现了数据容灾。同时每次对一个 Partition 的写操作都会在两个 Replica 上呈现如果 Primary Replica 异常那么 Backup Replica 可以立即提供服务实现数据的高可用。 mysql cluster 的优点 1、99.999的高可用性 2、快速的自动失效切换 3、灵活的分布式体系结构没有单点故障 4、高吞吐量和低延迟 5、可扩展性强支持在线扩容。 mysql cluster 的缺点 1、存在很多限制比如不支持外键数据行不能超过8K不包括BLOB和text中的数据 2、部署、管理、配置很复杂 3、占用磁盘空间大内存大 4、备份和恢复不方便 5、重启的时候数据节点将数据 load 到内存需要很长时间。 MySQL Fabric MySQL Fabric 会组织多个 MySQL 数据库将大的数据分散到多个数据库中即数据分片(Data Shard),同时同一个分片数据库中又是一个主从结构Fabric 会挑选合适的库作为主库当主库挂掉的时候又会重新在从库中选出一个主库。 MySQL Fabric 的特点 1、高可用 2、使用数据分片的横向功能。 MySQL Fabric-aware 连接器把从 MySQL Fabric 获取的路由信息存储到缓存中然后凭借该信息将事务或查询发送给正确的 MySQL 服务器。 同时每一个分片组可以又多个一个服务器组成构成主从结构当主库挂掉的时候又会重新在从库中选出一个主库。保证节点的高可用。 HA Group 保证访问指定 HA Group 的数据总是可用的同时其基础的数据复制是基于 MySQL Replication 实现的。 缺点 事务及查询只支持在同一个分片内事务中更新的数据不能跨分片查询语句返回的数据也不能跨分片。 总结 1、MySQL Replication 是官方提供的主从同步方案用于将一个 MySQL 的实例同步到另一个实例中在主从复制中从库利用主库上的 binlog 进行重播实现主从同步默认是异步同步针对其在不同场景下的一些缺陷衍生出了半同步复制强同步复制等数据高可用的方案 2、MySQL Group Replication 组复制又称为 MGR,引入复制组主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题, MGR 由若干个节点共同组成一个复制组一个事务的提交必须经过组内大多数节点 (N / 2 1) 决议并通过才能得以提交; 3、InnoDB Cluster 是官方提供的高可用方案,是 MySQL 的一种高可用性(HA)解决方案它通过使用MySQL Group Replication 来实现数据的自动复制和高可用性 4、InnoDB ClusterSet 通过将主 InnoDB Cluster 与其在备用位置例如不同数据中心的一个或多个副本链接起来为 InnoDB Cluster 部署提供容灾能力每个节点就是一个 InnoDB Cluster 5、InnoDB ReplicaSet 与InnoDB cluster 类似, MySQL Router 支持针对 InnoDB ReplicaSet 的引导, 这意味着可以自动配置 MySQL Router 以使用 InnoDB ReplicaSet, 而无需手动配置文件. 这使得 InnoDB ReplicaSet 成为一种快速简便的方法, 可以启动和运行 MySQL 复制和 MySQL Router, 非常适合扩展读取, 并在不需要 InnoDB 集群提供高可用性的用例中提供手动故障转移功能 6、MMMMaster-Master replication manager for MySQL是一套支持双主故障切换和双主日常管理的脚本程序。MMM 使用 Perl 语言开发主要用来监控和管理 MySQL Master-Master双主复制可以说是 MySQL 主主复制管理器; 7、Master High Availability Manager and Tools for MySQL简称 MHA 。是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件这个工具专门用于监控主库的状态当发现 master 节点故障的时候会自动提升其中拥有新数据的 slave 节点成为新的 master 节点在此期间,MHA 会通过其他从节点获取额外的信息来避免数据一致性问题。MHA 还提供了 mater 节点的在线切换功能即按需切换 master-slave 节点。MHA 能够在30秒内实现故障切换并能在故障切换过程中最大程度的保证数据一致性 8、Galera Cluster 是由 Codership 开发的MySQL多主集群包含在 MariaDB 中同时支持 Percona xtradb、MySQL是一个易于使用的高可用解决方案在数据完整性、可扩展性及高性能方面都有可接受的表现本身具有 multi-master 特性支持多点写入Galera Cluster 中每个实例都是对等的互为主从。当客户端读写数据的时候可以选择任一 MySQL 实例对于读操作每个实例读取到的数据都是相同的。对于写操作当数据写入某一节点后集群会将其同步到其它节点。这种架构不共享任何数据是一种高冗余架构 9、MySQL Cluster 是一个高度可扩展的兼容 ACID 事务的实时数据库基于分布式架构不存在单点故障MySQL Cluster 支持自动水平扩容并能做自动的读写负载均衡MySQL Cluster 使用了一个叫 NDB 的内存存储引擎来整合多个 MySQL 实例提供一个统一的服务集群 10、MySQL Fabric 会组织多个 MySQL 数据库将大的数据分散到多个数据库中即数据分片(Data Shard),同时同一个分片数据库中又是一个主从结构Fabric 会挑选合适的库作为主库当主库挂掉的时候又会重新在从库中选出一个主库。