一淘模板发明在企业情况中的停机老本敏捷增加。在一项考察中，40%的受访者示意，仅仅一个小时的停机就使患上他们的构造丢失了100万美金以上。确保数据库效劳连续可用明显是值患上的。
它为你的构造节减了少量资金，更不用说与各种形式以及范围的长处相干者的瓜葛。
那末你怎样确保连续可用性？连续可用性劈面的不雅点被称为 高可用性 。在本文中，咱们将概述甚么是高可用性以及怎样为你的 MySQL 集群实现高可用。
咱们还指出高可用性的光明一壁，即使系统治理员同伴地依靠高可用性来实行保护事件-并注释为甚么这么做会毁坏高可用性的宗旨，使你的企业经营面临危险。
让咱们先来谈谈可用性。如果一个效劳（如数据库）在年夜少数时日内对于用户是不可用的，那末运行它就没甚么意思了。因而当咱们议论可用性时，咱们是指效劳的可访问水平。
对于任何失常运行的效劳，人们有来由期待它总是在被需要时是可用的-然而也会有一些停机时日，一年中有一两天，或者每一个月有多少个小时。
一个广泛的可用的效劳对于患上多用例场景来说能够是很好的，然而如果效劳实质上是相当主要的，或者少量用户依靠与一个效劳，仅仅依靠「可用性」是不足的。
这便是高可用性的意思所在。在最基础的条件下，高可用性确保比一般预期的水平更高的可用性，更细致的说，在许可保护、修补以及失常同伴以及故障的状况下，也能到达约定的水平。
对于甚么是高可用性尚无杀青对于抗的界说，只是为了满足特定的（更高的）可用性需要，它一般高出被护接受的「可用性」。事实上，你的构造能够会依据经营的需要来界说所需的可用性-掂量高可用性的老本与停机相干的丢失的老本。
你需要的可用性水平能够通过百分最近示意。比方99.99%或者「4个9」的可用性象征着一年中至多有52.06分钟的停机时日，而「6个9」或者99.9999%的可用性则限制一年有31.56分钟的停机时日。
从实质上来说，抉择权在你手上-然而，异样，这也是一种掂量。保持高可用性的老本将是低廉的-需要分外的物理资本以及软件许可，并消耗你的人力资本。然而，你能够会发明这是一个值患上支付的价钱，为了阻挠中断带来的连锁老本，或者因客户不骄傲而丢失支出的危险。
你的高可用性基础架构确实切性子取决于你的事件负载。然而，从狭义上来讲，当有容错性时，就能够实现高可用性，如许即使一个效劳或者设施浮现故障，事件负载也不会中断。一般状况下，这意为着不单点故障-所有效劳以及设施都在收集以及应用级别是齐全冗余的。
依据效劳的分比方，这一般能够涉及到一些节点-比方，你的MySQL集群将多蕴含多少个节点，数据存储在这下面。而后将多个节点以及负载平衡工具联合，如许如果一个节点失利，申请将被疏导发送到另一个节点。用户依然能够访问可用的效劳，即使性能细微下降。
固然，你通往高可用MySQL数据库的路径将取决于你对于MySQL的实现。归纳综合的说，你需要建立拥有多个节点的某种范例的MySQL集群-换句话说，你的数据必须是存储在多个MySQL效劳器上。
接下来，你需要一个能够在这些节点上复制数据的效劳，确保每一个节点都有你的数据库中蕴含的数据的准确备份。最后，你需要一个负载平衡器，确保任何数据库申请被均匀地疏导到数据库节点-是的，一个平衡负载-然而请确保即使有一个节点离线，申请也能失去满足。
比方，MySQL供应了一个面向高可用的商业产物- TeMySQLInnoDBCluster.。它基于MySQL群组复制，这是确保MySQL数据库情况中高可用性的一种流行的形式。
另一个代替的抉择是Galera，它多年来一直供应MySQL高可用性。如果你应用的是MySQL的MariaDB分支，你能够通过你用Galera集群运行多个节点来配置MariaDB情况的高可用性 -同时依靠HAProxy停止负载平衡。此外，你也能够钻研一下MariaDB自身的
MaxScale 产物。
企业范围的事件负载越来越多地应用高可用性准则，因为从长远来看，它供应了最佳的效果。下面是你应当思考在你的操纵中配置高可用性的多少个好的来由：
极其主要的应用.一些应用基础无奈经受任何停机时日，想一想军事应用或者能源收集。在这些状况下，高可用性是必须的，你不甚么抉择，只能确保极高的可用性-只管你能够做危险评估，并抉择你究竟需要多年夜的高可用性保障。
连锁效应.如果系统是一个事件负载的外围，即使长久的停机也会以致宽泛的问题，因为连接以及同步的系统将会连带失利。值患上思考在多少个外围的畛域投入高可用性-如数据库-因为思考到能够很难复原的更年夜连带问题的老本，这能够是值患上的。
支出丢失.高可用性，即使是数目未多少的9，也能够防范支出丢失。对于一个主要的在线批发商来说，仅仅多少个小时的销售丢失，加之相干威望丢失，就会对于底线发生非常主要的影响。
客户的希望以及效劳水平协定.你的营业操纵能够会受到效劳水平协定的束缚，保障你的客户端有一定的失常运行时日。如果是这种状况，你需要确保你的客户端事件负载的效劳拥有失常运行时日的水平-你将通过高可用性来实现。如果做不到这一点会以致条约的停止，或者依据你的条约停止抵偿惩罚。
这是高可用性的多少个好的实用来由-而且，这今天这个技术至上的天下里，有患上多事件负载在不高可用性平台的状况下基础无奈运行。
可怜的是，高可用的日益流行以致了它的滥用。因为高可用性使患上系统变患上异样健壮，技术团队在实行系统治理事件的时刻（如打补钉）能够会偏偏向走捷径，因为那些团队认为高可用性基础设施将会轻易负担一台机器脱机的累赘。
实践上，它很快就会变患上更加简单。以MySQL集群为例。是的，如果你重启一台机器给它打补钉，因为高可用性，你的MySQL集群将连续运行。然而，请记着，当你为了打补钉而敞开一个节点，而后从新启动它时，会以致需要输入的数据积累。这个进程能够需要生产永劫日能力实现。
不用说，每一台数据库主机都需要看到相同的数据。危险来自于从新同步的进程：如果在你已经敞开的一个节点并对于其打补钉的状况下，另一个节点浮现故障，这能够以致失去终究实用的法定人数。换句话说，生存对于于数据「真相」的效劳器数目能够低于可接受的水平。从这种状态下复原能够是困难以及简单的，以至能够以致数据丢失。
高可用性是为了在浮现故障时保障系统的失常运行。这种针对于故障的固有保卫并非一个收费通畅证，能够依靠高可用性的健壮，以不卖命的形式实行的系统保护，并无人会细致到它。
相同，技术团队应当依靠其余解决心划-比方，为正在打补钉的系统配置齐全的冗余，而不是轻易地希望高可用性基础设施能够来反抗压力。或者，在能够的状况下，依靠实时打补钉的形式来代替，通过如许的做来消除了需要重启效劳来布置补钉的效果。
只管云云，依靠高可用性停止保护事件的显示出使人担忧的迹象。仔细考察一下，你以至会发明供应商的民间批示，批示用户依靠高可用性来实行打补钉的事件，用户只要希望在一个节点离线打补钉时，其余节点不要浮现任何问题。
高可用性对于患上多应用来说都相当主要-对于患上多其余应用来说也是非常无利。配置准确，MySQL数据库能够供应多少乎完美的可用性，但这并不料味着技术团队能够把可用性视为天经地义。
滥用高可用性架构来保护走捷径是不可取的-危险比乍看之下更年夜。
本文链接：https://addon.ciliseo.com/wei-shen-me-bu-yao-yi-lai-mysql-gao-ke-yong-xing-jin-xing-wei-hu.html
网友评论
xnxisv
回复不依赖MySQL高可用性进行维护，因单独依靠其难以确保数据安全与系统稳定性的长期保障。