如何理解MongoDB高可用

如何理解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高可用问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注行业资讯频道了解更多相关知识。