189 8069 5689
如何理解MongoDB高可用，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
服务器容灾一直是云服务运维过程中无法避开的问题，我们常常会讨论如何对出现故障的机器进行数据库方面的恢复，却很少考虑到在机器出现故障后，是用一套怎样的处理流程将三节点副本集恢复如初的。
MongoDB采用的是什么方法，得以做到在有机器故障的情况下依旧能保证用户业务的高可用？
对于MongoDB数据库来说，MongoDB内核就像汽车发动机，是整个数据库运转的核心部分，而管控就像拼装汽车的过程。车子怎么跑，跑起来的效能如何，运转是否安全，出现故障如何维修，诸如此类的任务都由管控部门负责处理。而保证用户的业务能够达到高可用，则是运维任务的重中之重：
那么，什么是高可用？
MongoDB服务采用三节点副本集架构，三个数据节点位于不同的物理服务器上，分别自动同步数据。副本集提供三种角色，Primary节点（支持读写请求），Secondary节点（支持只读请求），Hidden节点（提供备节点的角色，默认不支持访问）。
而高可用，就是针对这一服务的容灾切换和故障转移的过程。这一过程有很高的自动化程度，通过Primary，Secondary和更多备用节点形成容灾，当Primary节点出现故障，系统会自动选举新的Primary节点。Secondary节点不可用，由备用节点接管并恢复服务，从多个方面保障服务的可用性。这便是MongoDB自身带来的高可用。
高可用的最高境界就是：“容灾故障关我何事？我只要业务ok”——从而做到将最稳定的服务提供给用户。对用户来说，能够看到的是Primary和Secondary两个节点和暴露出的相关访问链接。但在服务器上，同时还存在着另外一个Secondary节点处于Hidden状态，这个节点通常用于数据备份以及性能优化，在主节点出现故障时顶到前方，切换成Secondary节点继续承担用户的工作。
天有不测风云，服务器总会出现各式各样难以排查的硬件故障，极端情况下甚至出现罢工：例如内存ECC异常无法自动修复，硬盘IO异常读写失败，RAID卡状态有问题，电池断电，网卡网络满载等。面对这些形形色色的故障类型，阿里对所有对外服务的服务器都提供了监控，采用监控系统对这些点进行实时采集，一旦发现问题便会及时的进行报警。
此外，诸如服务器到达质保期的换新或者延保，系统升级OS，服务程序漏洞的修复，很多原因都可能导致服务器需要下线。
服务器下线了，用户服务还要接着用，怎样在拿掉机器进行线下升级的同时不影响用户在跑的业务，这就需要交给MongoDB管控团队去应对。
MongoDB用什么策略应对：
MongoDB高可用的实现流程分为以下三个部分：
故障检测：使用多种检测系统针对各种项目进行检测，各个系统中存在联动效应。
故障转移：发生故障后怎样将故障机器上的业务从该机器转移出来。
主机下线：故障机器下线维修以及相应的后续过程。
故障检测：
MongoDB服务集群里有大量不同型号的机器，例如D13、H43。每个服务器上都有与之对应的检测程序，通过大量的Monitor进行监控从而获取信息：无论是内部属于阿里云自己的部分，还是在用户的业务中由用户实现的部分，都存在着与之对应的接口。阿里云会通过推送或自取的方式获取实例并了解服务器的状态，如果获悉某台机器存在下线的必要，资源管理器就会对这台机器进行打标，确认异常后进入下一个阶段。检测和故障转移两个步骤之间并不是直来直去一步到位，其间实际上存在众多细化的检查过程。
故障转移：
对阿里云提供的三节点副本集架构而言，类似机器达到保修期，浪潮D13 RAID卡故障等许多情况下，都需要对任务的Primary节点机器进行下线维护。面对这些情况，资源管理器会对需要下线的机器进行打标，打标后的机器会进行实际的下线。而这些需要下线的机器往往还有业务正在运转。为了保证业务不受影响，MongoDB会借用自身机制，把Secondary节点替换为Primary节点，从而使打标的节点变成Secondary状态，之后会把打标节点从Secondary变成Hidden，即隐藏服务节点。原有的Hidden节点则作为容灾节点被替换上去。
此时的Hidden（打标）节点上依旧存留着实例的数据，不能轻易下掉机器，这里会进入节点重搭的步骤——从资源池里额外再选一台机器生产一个Hidden节点，等新的节点加入副本集后，并且完成三节点同步的情况下，被打标的机器才会被摘下，从而正式进入下线流程，这个过程往往需要一段时间才能完成。况且被打标的机器上面很可能存在多个实例，这台机器上可能不只是某个实例的Primary节点，可能还存在其他实例的Secondary或者Hidden节点，但主体流程是类似的，打标机器上的所有节点最终都会替换成Hidden状态，直到这台机器达到没有任何用户访问请求的效果。
为了不影响用户对云服务的正常使用，整个切换过程都会在用户提供的运维时间窗口里进行。
主机下线：
面对被下线的机器，系统并不会直接草率的将其置于主机资源池中，而是会有24H的滞留期，在滞留期内，监测系统会检测滞留机器上是否还有其它访问请求或IO读写操作。检测结束，确定机器可以下线时才会将其放入主机资源池。资源池里的机器将进入另外一套系统进行后续操作，此时和MongoDB业务已经关联不大。会通过专用的IDCfree系统对机器进行恢复，待到确定机器没问题后，我们才会重新将其放入资源池内，通过自动上线系统重新加入MongoDB集群，这部分内容由自动资源控制平台来负责。接下来，我们就以实际的故障转移业务场景为例子，阐释关于高可用实现更具体的过程。
故障转移业务场景：
一台副本集出现问题：
故障机器打标确认进入转移流程后，名为Robot的自动运维系统会先获取机器上的实例信息，然后在用户设定的可运维时间内开始正式转移（即使不在用户设定的使用时间内，依旧会通过短信对用户进行告知）。在判定Role是Primary节点的情况下，先把Primary和Secondary节点进行置换，如果发现已经是Secondary节点，那就进行Secondary和Hidden节点之间的的角色切换。这一步骤通过下发任务流的方式完成，后端完成置换的速度很快，对用户的影响可以忽略不计。当确定故障机器全部变成Hidden节点时，开始触发重搭Hidden流程，将新建的节点加入副本集。此时，有故障的节点已经没有任何实例存在，自动运维平台会将这一空闲的问题机器置于可下线列表中，不再继续进行即时的实例检查。
故障迁移的时候存在一种独特的说法：防风暴，波澜不惊。
关于如何理解MongoDB高可用问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联成都网站设计公司行业资讯频道了解更多相关知识。
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。