本文小编为大家详细介绍“为什么不要依赖MySQL高可用性进行维护”，内容详细，步骤清晰，细节处理妥当，希望这篇“为什么不要依赖MySQL高可用性进行维护”文章能帮助大家解决疑惑，下面跟着小编的思路慢慢深入，一起来学习新知识吧。
让我们先来谈谈可用性。如果一个服务（如数据库）在大多数时间内对用户是不可用的，那么运行它就没什么意义了。因此当我们谈论可用性时，我们是指服务的可访问程度。
对于任何正常运行的服务，人们有理由期待它总是在被需要时是可用的 - 但是也会有一些停机时间，一年中有一两天，或者每月有几个小时。
一个普遍的可用的服务对于许多用例场景来说可能是很好的，但是如果服务本质上是至关重要的，或者大量用户依赖与一个服务，仅仅依靠「可用性」是不够的。
这就是高可用性的意义所在。在最基本的条件下，高可用性确保比通常预期的水平更高的可用性，更具体的说，在允许维护、修补和一般错误以及故障的情况下，也能达到约定的水平。
对于什么是高可用性还没有达成一致的定义，只是为了满足特定的（更高的）可用性需求，它通常超过被护接受的「可用性」。事实上，你的组织可能会根据运营的需求来定义所需的可用性 - 权衡高可用性的成本与停机相关的损失的成本。
你需要的可用性水平可以通过百分比来表示。例如 99.99% 或者「4 个 9」的可用性意味着一年中最多有 52.06 分钟的停机时间，而「6 个 9」或者 99.9999% 的可用性则限制一年有 31.56 分钟的停机时间。
从本质上来说，选择权在你手上 - 但是，同样，这也是一种权衡。维持高可用性的成本将是昂贵的 - 需要额外的物理资源和软件许可，并耗费你的人力资源。但是，你可能会发现这是一个值得付出的代价，为了避免中断带来的连锁成本，或者因客户不满意而损失收入的风险。
你的高可用性基础架构的确切性质取决于你的工作负载。然而，从广义上来讲，当有容错性时，就可以实现高可用性，这样即使一个服务或者设备出现故障，工作负载也不会中断。通常情况下，这意为着没有单点故障 - 所有服务和设备都在网络和应用级别是完全冗余的。
根据服务的不同，这通常可能涉及到一些节点 - 例如，你的 MySQL 集群将多包含几个节点，数据存储在这上面。然后将多个节点和负载平衡工具结合，这样如果一个节点失败，请求将被引导发送到另一个节点。用户仍然可以访问可用的服务，即使性能稍微下降。
当然，你通往高可用 MySQL 数据库的途径将取决于你对 MySQL 的实现。概括的说，你需要创建具有多个节点的某种类型的 MySQL 集群 - 换句话说，你的数据必须是存储在多个 MySQL 服务器上。
接下来，你需要一个可以在这些节点上复制数据的服务，确保每一个节点都有你的数据库中包含的数据的精确备份。最后，你需要一个负载平衡器，确保任何数据库请求被均匀地引导到数据库节点 - 是的， 一个平衡负载 - 但是请确保即使有一个节点离线，请求也能得到满足。
例如， MySQL 提供了一个面向高可用的商业产品 - Te MySQL InnoDB Cluster. 。它基于 MySQL 群组复制，这是确保 MySQL 数据库环境中高可用性的一种流行的方式。
另一个替代的选择是 Galera ，它多年来一直提供 MySQL 高可用性。如果你使用的是 MySQL 的 MariaDB 分支，你可以通过你用 Galera 集群运行多个节点来配置 MariaDB 环境的高可用性 - 同时依靠 HAProxy 进行负载平衡。另外，你也可以研究一下 MariaDB 自己的
MaxScale 产品。
企业规模的工作负载越来越多地使用高可用性原则，因为从长远来看，它提供了最好的结果。下面是你应该考虑在你的操作中设置高可用性的几个好的理由：
极其重要的应用. 一些应用根本无法承受任何停机时间，想一想军事应用或者能源网络。在这些情况下，高可用性是必须的，你没有什么选择，只能确保极高的可用性 - 尽管你可以做风险评估，并决定你到底需要多大的高可用性保证。
连锁效应. 如果系统是一个工作负载的核心，即使短暂的停机也会导致广泛的问题，因为连接和同步的系统将会连带失败。值得考虑在几个核心的领域投入高可用性 - 如数据库 - 因为考虑到可能很难恢复的更大连带问题的成本，这可能是值得的。
收入损失. 高可用性，即使是数量不多的 9 ，也可以防止收入损失。对于一个主要的在线零售商来说，仅仅几个小时的销售损失，加上相关名誉损失，就会对底线产生非常重要的影响。
客户的期望和服务水平协议. 你的业务操作可能会受到服务水平协议的约束，保证你的客户端有一定的正常运行时间。如果是这种情况，你需要确保你的客户端工作负载的服务具有正常运行时间的水平 - 你将通过高可用性来实现。如果做不到这一点会导致合同的终止，或者根据你的合同进行赔偿惩罚。
这是高可用性的几个好的有效理由 - 而且，这今天这个技术至上的世界里，有许多工作负载在没有高可用性平台的情况下根本无法运行。
不幸的是，高可用的日益盛行导致了它的滥用。因为高可用性使得系统变得异常健壮，技术团队在执行系统管理任务的时候（如打补丁）可能会倾向走捷径，因为那些团队认为高可用性基础设施将会简单承担一台机器脱机的负担。
实际上，它很快就会变得更加复杂。以 MySQL 集群为例。是的，如果你重启一台机器给它打补丁，由于高可用性，你的 MySQL 集群将继续运行。但是，请记住，当你为了打补丁而关闭一个节点，然后重新启动它时，会导致需要输入的数据积压。这个过程可能需要花费长时间才能完成。
不用说，每一台数据库主机都需要看到相同的数据。危险来自于重新同步的过程：如果在你已经关闭的一个节点并对其打补丁的情况下，另一个节点出现故障，这可能导致失去最终有效的法定人数。换句话说，保存关于数据「真相」的服务器数量可能低于可接受的水平。从这种状态下恢复可能是困难和复杂的，甚至可能导致数据丢失。
高可用性是为了在出现故障时保证系统的正常运行。这种针对故障的固有保护并不是一个免费通行证，可以依赖高可用性的健壮，以不负责的方式执行的系统维护，并没有人会注意到它。
相反，技术团队应该依靠其他解决方案 - 例如，为正在打补丁的系统设置完全的冗余，而不是简单地希望高可用性基础设施能够来抵挡压力。或者，在可能的情况下，依靠实时打补丁的方式来替代，通过这样的做来消除需要重启服务来安装补丁的效果。
尽管如此，依赖高可用性进行维护工作的显示出令人担忧的迹象。仔细观察一下，你甚至会发现供应商的官方指导，指示用户依靠高可用性来执行打补丁的任务，用户只需希望在一个节点离线打补丁时，其他节点不要出现任何问题。
读到这里，这篇“为什么不要依赖MySQL高可用性进行维护”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
