在企业环境中的停机成本迅速增加。在一项调查中,40% 的受访者表示,仅仅一个小时的停机就使得他们的组织损失了 100 万美金以上。确保数据库服务持续可用显然是值得的。
它为你的组织节省了大量资金,更不用说与各种形式和规模的利益相关者的关系。
那么你如何确保持续可用性?持续可用性背后的概念被称为 高可用性 。在本文中,我们将概述什么是高可用性以及如何为你的 MySQL 集群实现高可用。
我们还指出高可用性的黑暗一面,即使系统管理员错误地依赖高可用性来执行维护任务 - 并解释为什么这么做会破坏高可用性的目标,使你的企业运营面临风险。
1. 高可用性介绍
让我们先来谈谈可用性。如果一个服务(如数据库)在大多数时间内对用户是不可用的,那么运行它就没什么意义了。因此当我们谈论可用性时,我们是指服务的可访问程度。
对于任何正常运行的服务,人们有理由期待它总是在被需要时是可用的 - 但是也会有一些停机时间,一年中有一两天,或者每月有几个小时。
一个普遍的可用的服务对于许多用例场景来说可能是很好的,但是如果服务本质上是至关重要的,或者大量用户依赖与一个服务,仅仅依靠「可用性」是不够的。
这就是高可用性的意义所在。在最基本的条件下,高可用性确保比通常预期的水平更高的可用性,更具体的说,在允许维护、修补和一般错误以及故障的情况下,也能达到约定的水平。
2. 什么级别的可用性是高可用性?
对于什么是高可用性还没有达成一致的定义,只是为了满足特定的(更高的)可用性需求,它通常超过被护接受的「可用性」。事实上,你的组织可能会根据运营的需求来定义所需的可用性 - 权衡高可用性的成本与停机相关的损失的成本。
你需要的可用性水平可以通过百分比来表示。例如 99.99% 或者「4 个 9」的可用性意味着一年中最多有 52.06 分钟的停机时间,而「6 个 9」或者 99.9999% 的可用性则限制一年有 31.56 分钟的停机时间。
从本质上来说,选择权在你手上 - 但是,同样,这也是一种权衡。维持高可用性的成本将是昂贵的 - 需要额外的物理资源和软件许可,并耗费你的人力资源。但是,你可能会发现这是一个值得付出的代价,为了避免中断带来的连锁成本,或者因客户不满意而损失收入的风险。
3. 高可用性在实践中是如何工作的?
你的高可用性基础架构的确切性质取决于你的工作负载。然而,从广义上来讲,当有容错性时,就可以实现高可用性,这样即使一个服务或者设备出现故障,工作负载也不会中断。通常情况下,这意为着没有单点故障 - 所有服务和设备都在网络和应用级别是完全冗余的。
根据服务的不同,这通常可能涉及到一些节点 - 例如,你的 MySQL 集群将多包含几个节点,数据存储在这上面。然后将多个节点和负载平衡工具结合,这样如果一个节点失败,请求将被引导发送到另一个节点。用户仍然可以访问可用的服务,即使性能稍微下降。
4. 在 MySQL 中配置高可用性
当然,你通往高可用 MySQL 数据库的途径将取决于你对 MySQL 的实现。概括的说,你需要创建具有多个节点的某种类型的 MySQL 集群 - 换句话说,你的数据必须是存储在多个 MySQL 服务器上。
接下来,你需要一个可以在这些节点上复制数据的服务,确保每一个节点都有你的数据库中包含的数据的精确备份。最后,你需要一个负载平衡器,确保任何数据库请求被均匀地引导到数据库节点 - 是的, 一个平衡负载 - 但是请确保即使有一个节点离线,请求也能得到满足。
例如, MySQL 提供了一个面向高可用的商业产品 - Te MySQL InnoDB Cluster. 。它基于 MySQL 群组复制,这是确保 MySQL 数据库环境中高可用性的一种流行的方式。
另一个替代的选择是 Galera ,它多年来一直提供 MySQL 高可用性。如果你使用的是 MySQL 的 MariaDB 分支,你可以通过你用 Galera 集群运行多个节点来配置 MariaDB 环境的高可用性 - 同时依靠 HAProxy 进行负载平衡。另外,你也可以研究一下 MariaDB 自己的
MaxScale 产品。
5. 依赖高可用性好的理由…
企业规模的工作负载越来越多地使用高可用性原则,因为从长远来看,它提供了最好的结果。下面是你应该考虑在你的操作中设置高可用性的几个好的理由:
- 极其重要的应用. 一些应用根本无法承受任何停机时间,想一想军事应用或者能源网络。在这些情况下,高可用性是必须的,你没有什么选择,只能确保极高的可用性 - 尽管你可以做风险评估,并决定你到底需要多大的高可用性保证。
- 连锁效应. 如果系统是一个工作负载的核心,即使短暂的停机也会导致广泛的问题,因为连接和同步的系统将会连带失败。值得考虑在几个核心的领域投入高可用性 - 如数据库 - 因为考虑到可能很难恢复的更大连带问题的成本,这可能是值得的。
- 收入损失. 高可用性,即使是数量不多的 9 ,也可以防止收入损失。对于一个主要的在线零售商来说,仅仅几个小时的销售损失,加上相关名誉损失,就会对底线产生非常重要的影响。
- 客户的期望和服务水平协议. 你的业务操作可能会受到服务水平协议的约束,保证你的客户端有一定的正常运行时间。如果是这种情况,你需要确保你的客户端工作负载的服务具有正常运行时间的水平 - 你将通过高可用性来实现。如果做不到这一点会导致合同的终止,或者根据你的合同进行赔偿惩罚。
这是高可用性的几个好的有效理由 - 而且,这今天这个技术至上的世界里,有许多工作负载在没有高可用性平台的情况下根本无法运行。
6. … 和依赖高可用性错误的理由
不幸的是,高可用的日益盛行导致了它的滥用。因为高可用性使得系统变得异常健壮,技术团队在执行系统管理任务的时候(如打补丁)可能会倾向走捷径,因为那些团队认为高可用性基础设施将会简单承担一台机器脱机的负担。
实际上,它很快就会变得更加复杂。以 MySQL 集群为例。是的,如果你重启一台机器给它打补丁,由于高可用性,你的 MySQL 集群将继续运行。但是,请记住,当你为了打补丁而关闭一个节点,然后重新启动它时,会导致需要输入的数据积压。这个过程可能需要花费长时间才能完成。
不用说,每一台数据库主机都需要看到相同的数据。危险来自于重新同步的过程:如果在你已经关闭的一个节点并对其打补丁的情况下,另一个节点出现故障,这可能导致失去最终有效的法定人数。换句话说,保存关于数据「真相」的服务器数量可能低于可接受的水平。从这种状态下恢复可能是困难和复杂的,甚至可能导致数据丢失。
7. 不要依赖高可用性进行维护
高可用性是为了在出现故障时保证系统的正常运行。这种针对故障的固有保护并不是一个免费通行证,可以依赖高可用性的健壮,以不负责的方式执行的系统维护,并没有人会注意到它。
相反,技术团队应该依靠其他解决方案 - 例如,为正在打补丁的系统设置完全的冗余,而不是简单地希望高可用性基础设施能够来抵挡压力。或者,在可能的情况下,依靠实时打补丁的方式来替代,通过这样的做来消除需要重启服务来安装补丁的效果。
尽管如此,依赖高可用性进行维护工作的显示出令人担忧的迹象。仔细观察一下,你甚至会发现供应商的官方指导,指示用户依靠高可用性来执行打补丁的任务,用户只需希望在一个节点离线打补丁时,其他节点不要出现任何问题。
8. 结束
高可用性对于许多应用来说都至关重要 - 对于许多其他应用来说也是十分有益。配置正确, MySQL 数据库可以提供几乎完美的可用性,但这并不意味着技术团队可以把可用性视为理所当然。
滥用高可用性架构来维护走捷径是不可取的 - 风险比乍看之下更大。
相反,系统管理员应该寻找可以久经考验的替代方案 - 包括冗余和实时补丁 - 来执行维护操作,而不伤害高可用性解决方案的能力。
原文地址:https://tuxcare.com/understanding-mysql-high-availability-good-and-bad-reasons-to-use-it/
译文地址:https://learnku.com/mysql/t/71681
【相关推荐:mysql视频教程】
以上是聊聊为什么不要依赖MySQL高可用性进行维护的详细内容。更多信息请关注PHP中文网其他相关文章!

mysqldiffersfromothersqldialectsinsyntaxforlimit,自动启动,弦乐范围,子征服和表面上分析。1)MySqluessLipslimit,whilesqlserverusestopopandoraclesrontersrontsrontsrontsronnum.2)

MySQL分区能提升性能和简化维护。1)通过按特定标准(如日期范围)将大表分成小块,2)物理上将数据分成独立文件,3)查询时MySQL可专注于相关分区,4)查询优化器可跳过不相关分区,5)选择合适的分区策略并定期维护是关键。

在MySQL中,如何授予和撤销权限?1.使用GRANT语句授予权限,如GRANTALLPRIVILEGESONdatabase_name.TO'username'@'host';2.使用REVOKE语句撤销权限,如REVOKEALLPRIVILEGESONdatabase_name.FROM'username'@'host',确保及时沟通权限变更。

InnoDB适合需要事务支持和高并发性的应用,MyISAM适合读多写少的应用。1.InnoDB支持事务和行级锁,适用于电商和银行系统。2.MyISAM提供快速读取和索引,适合博客和内容管理系统。

MySQL中有四种主要的JOIN类型:INNERJOIN、LEFTJOIN、RIGHTJOIN和FULLOUTERJOIN。1.INNERJOIN返回两个表中符合JOIN条件的所有行。2.LEFTJOIN返回左表中的所有行,即使右表中没有匹配的行。3.RIGHTJOIN与LEFTJOIN相反,返回右表中的所有行。4.FULLOUTERJOIN返回两个表中所有符合或不符合JOIN条件的行。

mysqloffersvariousStorageengines,每个suitedfordferentusecases:1)InnodBisidealForapplicationsNeedingingAcidComplianCeanDhighConcurncurnency,supportingtransactionsancions and foreignkeys.2)myisamisbestforread-Heavy-Heavywyworks,lackingtransactionsactionsacupport.3)记忆

MySQL中常见的安全漏洞包括SQL注入、弱密码、权限配置不当和未更新的软件。1.SQL注入可以通过使用预处理语句防止。2.弱密码可以通过强制使用强密码策略避免。3.权限配置不当可以通过定期审查和调整用户权限解决。4.未更新的软件可以通过定期检查和更新MySQL版本来修补。

在MySQL中识别慢查询可以通过启用慢查询日志并设置阈值来实现。1.启用慢查询日志并设置阈值。2.查看和分析慢查询日志文件,使用工具如mysqldumpslow或pt-query-digest进行深入分析。3.优化慢查询可以通过索引优化、查询重写和避免使用SELECT*来实现。


热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

Video Face Swap
使用我们完全免费的人工智能换脸工具轻松在任何视频中换脸!

热门文章

热工具

SublimeText3 Mac版
神级代码编辑软件(SublimeText3)

DVWA
Damn Vulnerable Web App (DVWA) 是一个PHP/MySQL的Web应用程序,非常容易受到攻击。它的主要目标是成为安全专业人员在合法环境中测试自己的技能和工具的辅助工具,帮助Web开发人员更好地理解保护Web应用程序的过程,并帮助教师/学生在课堂环境中教授/学习Web应用程序安全。DVWA的目标是通过简单直接的界面练习一些最常见的Web漏洞,难度各不相同。请注意,该软件中

EditPlus 中文破解版
体积小,语法高亮,不支持代码提示功能

SecLists
SecLists是最终安全测试人员的伙伴。它是一个包含各种类型列表的集合,这些列表在安全评估过程中经常使用,都在一个地方。SecLists通过方便地提供安全测试人员可能需要的所有列表,帮助提高安全测试的效率和生产力。列表类型包括用户名、密码、URL、模糊测试有效载荷、敏感数据模式、Web shell等等。测试人员只需将此存储库拉到新的测试机上,他就可以访问到所需的每种类型的列表。

WebStorm Mac版
好用的JavaScript开发工具