在本文中，我们将看一个内部部署，跨地理位置分布式MySQL高可用性解决方案的示例。它是跨地域分布区域上一些高可用性参考架构解决方案的更长系列的一部分。 **[第1部分：跨地域分布式场景中的高可用解决方案的体系结构参考：我为什么在关注？](http://www.itopers.com/article/204)** Percona咨询公司的主要目标是将复杂的问题找出简单的解决方案。我们致力于确定正确的工具，更有效的解决方案，以及如何使客户的生活更轻松。我们相信做一次工作，做得好，并有更多的时间用于生活的其他方面。 在我们的旅程中，我们经常收到帮助请求 - 有些简单，有些复杂。 ###概要### “ACME Inc.”公司正在将其整个业务从单机应用程序转移到分布式应用程序，切分为服务。每个不同的服务彼此独立地处理请求。 有些服务遵循紧密限制的事务模型，而其他服务则异步工作/回答。 每个服务都可以独立访问数据存储层。 在此背景下，ACME公司确定了在广泛的地理区域分发应用服务的需求，重点关注每个区域独立实现规模。 **确定的地区是：** 北美 欧洲 中国 ACME Inc.也意识到适用于每个地区的不同的法律。因此，每个地区都需要有关销售政策，销售活动，客户，订单，账单和本地化目录的独立信息处理，但将共享全局目录和一些历史汇总数据。 虽然大多数应用程序服务都可以处理和读取本地分布式缓存，但与目录，销售和计费相关的基本数据基于RDBMS。 而是将历史数据迁移到“大数据”平台，并详细说明聚合数据并推送到总部的DWH解决方案。 应用程序组件使用多种编程语言开发，具体取决于服务。 ACME公司与当地政府合作确定的RDBMS是面向MySQL的。有几个解决方案，如： PostgreSQL Oracle DB MSSQL Server 鉴于某些国家/地区实施了特定的审计插件，我们排除了封闭源RDBMS。此插件仅适用于上述平台。在RDBMS多样化的情况下，并行开发和后续维护的成本太高。因此，所有区域必须使用相同的主要RDBMS组件。 我们排除了PostgreSQL，因为与采用MySQL相比，利用案例更高，MySQL有一个现成的代码开发者。 最后，ACME Inc.的业务连续性团队定义了一个ITSC（信息技术服务连续性）计划，该计划定义了RPO（恢复点目标），RTO（恢复时间目标）和系统冗余。 然而。为了实现ITSCP，每个区域必须使关键系统在同一区域内冗余复制，而不是在邻近区域。 ##浅谈组件## 这是一个不那么罕见的场景，如果您尝试使用一个解决方案来解决它，它也会带来很多复杂性。但让我们分析一下，看看我们如何在满足ACME公司的需求和要求的同时简化方法。 使用基于MySQL的解决方案时，“我们应该使用什么？”的答案是使用最适合您业务需求的解决方案。 MySQL世界（大多数RDBMS）的“几个9”可用性参考表可以总结如下： 9 0. 0 0 0％（36天）MySQL Replication 9 9. 9 0 0％（8小时）带有DRBD的Linux心跳（已淘汰DRBD） 9 9. 9 0 0％（8小时）带共享存储的RHCS（活动/被动） 9 9. 9 9 0％（52分钟）MHA / Orchestrator至少有三个节点 9 9. 9 9 0％（52分钟）DRBD和复制（已淘汰DRBD） 9 9 .9 9 5％（26分钟） Multi-Master（Galera复制）3节点最小 9 9. 9 9 9％（5分钟）MySQL Cluster 专家会告诉你，在列表中选择最多的“9”是没有意义的。这是因为每个解决方案都需要权衡：您获得的可用性（HA）越高，解决方案的复杂性和管理解决方案的复杂性就越高。 例如，MySQL Cluster（NDB）中使用的方法使得此解决方案不适用于通用场景。它需要在选择之前正确分析应用程序需求，数据的使用和归档。它还需要深入的知识来正确管理集群，因为它比其他类似的解决方案更复杂。 这间接使得基于MySQL + Galera复制的解决方案具有最高HA级别的解决方案是更好的选择，因为它更通用些。 这就是为什么MySQL + Galera复制在过去六年中成为寻求非常高HA的平台最常用的解决方案，而不需要偏离标准的MySQL / InnoDB方法。您可以阅读有关Galera复制的更多信息：http://galeracluster.com/products/ 了解有关Percona XtraDB Cluster的更多信息。 **有几个实现Galera复制的发行版：** - Codership（Galera软件生产商/所有者）：http://galeracluster.com/downloads/#downloads - * MariaDB https://mariadb.com/kb/en/library/what-is-mariadb-galera-cluster/ - Percona XtraDB Cluster：https://www.percona.com/downloads/Percona-XtraDB-Cluster-LATEST/ *请注意，来自MariaDB的MariaDB Cluster / Server和所有相关解决方案与MySQL主流有很大不同。这通常意味着一旦迁移到MariaDB; 您的数据库将与其他MySQL解决方案不兼容。简而言之，您被锁定在MariaDB中。建议您在进行此移动之前仔细评估迁移到MariaDB。 ##选择组件## ###RDBMS### 我们的建议是使用Percona XtraDB Cluster（PXC），因为目前它是最灵活，最可靠和兼容的解决方案之一。 PXC由三个主要组成部分组成： Percona Server for MySQL Percona XtraBackup Galera Replication library 群集通常由三个或更多节点组成。每个节点都可以用作Master，但首选和推荐的方法是将一个节点用作Writer，将另一个节点用作Readers。 应用程序方面，访问正确的节点可能具有挑战性，因为这意味着您需要知道Master是哪个节点，哪个节点是读节点，并且必要时能够从一个节点转移到另一个节点。 ##代理## 为了简化此过程，有一个额外的组件可以作为将应用程序层连接到所需节点的“代理”。 最受欢迎的解决方案是： HAProxy ProxySQL 两者之间有几个重要的区别。但总的来说，ProxySQL是一个7级代理，并且可识别MySQL协议。因此，虽然HAProxy只是将连接作为转发代理（4层）传递，但ProxySQL知道它正在执行过程是什么，并充当反向代理。 使用ProxySQL可以根据几个参数决定，发送流量到哪个节点（读/写分离等），必要时可以下线，或者是否应该改写传入的SQL命令。ProxySQL网站https://github.com/sysown/proxysql/wiki和Percona数据库性能博客上 提供了大量信息。 ##备份/恢复## 没有经过充分测试的备份和恢复程序，没有RDBMS平台是安全的。Percona XtraDB Cluster软件包分发随Percona XtraBackup一起提供，作为节点配置的默认方法。 良好的备份和恢复（B / R）策略从考虑ACME的ITSCP开始，具有完整和增量备份，完美覆盖RPO，以及良好的恢复过程，以尽可能在RTO内保持恢复时间。 有几种工具可以让您规划和执行备份/恢复过程，其中一些来自开源以外的供应商和面向社区的供应商。 关于完全开源和面向社区，我们咨询通常建议使用：https://github.com/dotmanila/pyxbackup。 Pyxbackup是XtraBackup的包装器，它有助于简化B / R操作，包括准备完整和增量集。这有助于显着缩短恢复时间。 ##灾难恢复## ITSC计划的另一个非常重要的方面是系统能够在重大灾难中生存。 灾难和恢复（DR）解决方案必须能够充当主要生产环境。 因此，必须将其设计和扩展为资源的主要生产基地。 它必须在地理上分开，通常为数百公里或更长。 它必须完全独立于主站点。 它必须尽可能与主要生产站点同步。 虽然前三个“必须”很容易理解，但第四个通常是误解的对象。 尽可能与生产站点同步 的概念在设计涉及Galera复制的HA解决方案时会造成混乱。 最常见的误解是滥用Galera复制层。 主要是紧密耦合的数据库集群与松散耦合的数据库集群之间的概念混淆。 任何基于Galera复制的解决方案都是一个紧密耦合的数据库集群，因为整个想法是以数据为中心、同步分布和一致的。代价是这个解决方案不能在跨地域上进行分布。 像标准MySQL复制这样的解决方案是松散耦合的数据库集群，它们被设计为异步的。鉴于此，由它连接的节点在处理/应用事务时完全独立，并且该解决方案完全适合任何地理分布的复制解决方案。代价是接收方面的数据可能与该特定时刻的来源中的数据不一致。 关键是对于DR站点，唯一有效的解决方案是异步链路（松散耦合数据库集群），因为根据设计和要求，两个站点必须相隔很多公里。 为了更好地了解同步复制在跨地理位置分散的方案中无法工作的原因，请参阅下一篇“ 使用基于Galera的复制滥用跨地理节点分发 ”。 在我们的场景中，使用Percona XtraDB Cluster有助于创建最强大的异步解决方案。这是因为每个紧密耦合的数据库集群，无论是源还是目的地，都将被另一个紧密耦合的数据库集群视为单个实体。 这意味着我们可以在两个集群内从一个节点转移到另一个节点，仍然相信我们将拥有相同的可用数据和相同的异步流从一个源传递到另一个源。 为确保此过程完全自动化，我们在架构中添加了最后一个块： Percona XtraDB Cluster的复制管理器 （https://github.com/y-trudeau/Mysql-tools/tree/master/PXC）。RMfP是另一个开源工具，它简化并自动化每个PXC集群内的故障转移，这样，如果节点当前充当Master失败，我们的异步解决方案就不会受到影响。 ##如何组合组件## 总结我们解决方案的所有不同组件： - 应用程序栈 - 负载均衡器 - 应用节点即服务 - 分布式缓存 - 数据访问服务 - 数据库堆栈 - Percona XtraDB集群的Replication Manager - Xtrabackup - Pyxbackup - 自定义脚本 - 数据代理（ProxySQL） - RDBMS（Percona XtraDB集群） - 备份/恢复 - DR - 监控 - PMM（这里没有介绍<link>获取详细信息）  在上面的解决方案中，我们有两个相隔几公里的位置。 在它们之上，负载均衡器/ DNS解析将传入流量重定向到活动站点。 每个站点都托管一个完整的应用程序堆栈，应用程序连接到本地ProxySQL。 ProxySQL已启用读/写分离以优化平台利用率，并配置为在节点发生故障时将写入从一个PXC节点转移到另一个PXC节点。 异步复制连接两个位置并将数据从主设备传输到从设备。 请注意，使用此解决方案，可以拥有多个地理位置分散的站点。 每个站点独立进行备份，并执行恢复测试。 在节点发生故障的情况下，RMfP会监视并修改复制通道。 最后，Percona监控和管理（PMM）已经到位，可以对整个数据库平台进行深入监控。 ##结论## 我们一直在寻找最高效，易于管理，用户友好的产品组合，因为我们相信通过简单而有效的解决方案为社区提供和支持。 我们在这里介绍的是MySQL领域中最强大，最稳定的高可用性解决方案（除了我们已经排除的MySQL NDB）。 它被概念化以提供最大的服务连续性，平台/站点之间的绑定有限。 它也是一个经过良好测试的解决方案，已经在许多不同的场景中得到采用和调整，其中性能和真正的HA是必须的。 考虑到其他地方已经讨论过实施的细节，我更倾向于将这个题外话保持在较高水平（有关更多阅读，请参阅参考部分）。 尽管如此，Percona XtraDB Cluster（与实施Galera复制的任何其他解决方案一样）可能不适合最终用途。鉴于此，重要的是要了解它的作用和不适合。本文是一个很好的总结示例： 同步复制是否适合您的应用？。 ##参考## https://www.percona.com/blog/2016/06/07/choosing-mysql-high-availability-solutions/ https://dev.mysql.com/doc/mysql-ha-scalability/en/ha-overview.html https://www.percona.com/blog/2014/11/17/typical-misconceptions-on-galera-for-mysql/ http://galeracluster.com/documentation-webpages/limitations.html http://tusacentral.net/joomla/index.php/mysql-blogs/170-geographic-replication-and-quorum-calculation-in-mysqlgalera.html http://tusacentral.net/joomla/index.php/mysql-blogs/167-geographic-replication-with-mysql-and-galera.html http://tusacentral.net/joomla/index.php/mysql-blogs/164-effective-way-to-check-the-network-connection-when-in-need-of-a-geographic-distribution-replication- html的 http://tusacentral.net/joomla/index.php/mysql-blogs/183-proxysql-percona-cluster-galera-integration.html https://github.com/sysown/proxysql/wiki 源文来自：https://www.percona.com/blog/2018/11/15/mysql-high-availability-on-premises-a-geographically-distributed-scenario/