MongoDB 双机热备那篇文章是 “毒”

5faf2e4a7d450c535729a731ed2c8b3f.png

开头还是介绍一下群,如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis ,Oracle ,Oceanbase 等有问题,有需求都可以加群群内有各大数据库行业大咖,CTO,可以解决你的问题。加群请加微信号 liuaustin3 (共1200人左右 1 + 2 + 3)新人会进入3群

如果没有法律,我可能真想做了这个事情,群里最近有人问MongoDB 双机热备,我非常愤怒的告诉他们,不可以,不应该,不要,NO NO NO 。

这个底气我是有的,为什么?官方 official 问答,解释了这个问题,我还真好笑,还真有人提出这个问题。哎,使用MongoDB 7年了,从3.2 到了现在的4.4 (惭愧,我们准备5.0) , 没有想到MongoDB 的知识普及率还那么低,还有人问出 MongoDB  双机热备,还有人写出这样的文章。

212ff454f21df8582ecc2b5320264c3a.png

先看完官方的回复 MongoDB Developer Community 

ae5c380a0201935daf3e7ccdb4d53581.png

757ede361cbfb523b84d8fa9b29f9c95.png

0f1202349ca50dafcdd7743efc566920.png

这里普及一个基本的概念,MongoDB 本身在生产环境中,从来不存在单机使用方式(不抬杠,如果你的业务随时可以DOWN机,那你不在讨论的范围),同时必须要注意,MongoDB 本身是一款历史和传统相比,很新的数据库他本身在设计之初就融入了分布式的概念,网络数据传输的概念,自动切换的概念,以及服务程序和程序员至上的方式,最终是不能用传统数据库的理念去使用MongoDB 的。

在MongoDB 的生产环境中,有最小化成本投入和标准成本投入,以及特殊成本投入。

举例如果你的项目需要成本较低,那么你在搭建MongoDB 的时候可以加入 Arbiter节点, 但在标准的应用里面,官方也不建议你使用Arbiter ,而是标准的三节点的MongoDB Replicaset.

MongoDB 具有完善的复制集的协议,也就是我们知道的 protocol version1 简称 PV1 , 这个协议是从MongoDB 3.2后开始的,他详细的定义了如下的一些概念

1  写入数据的概念:在写入数据的时候  w:1 是MongoDB 特有的概念,其中可以标定到底需要几个节点写入后,才可以算是数据写入,比如你有3个节点,你在一条插入数据的语句执行后,MongoDB 会根据你语句中的数字来判断你的写入的操作是否完成,给与数据安全写,和性能之间的平衡的权利交给你来抉择。当然你可以使用默认的设置 majority ,大多数写的概念,完全能Hold 95%以上的应用场景。

在早期的PV0中(版本为  MongoDB 3.4.1 之前的版本)与PV1 版本的不同在于PV1 在4.0 后不会在支持具有副本集W:1 回滚的可能性。

3  投票权和否决权,在MongoDB 中为什么必须是三个节点,我想在MySQL  使用MHA 的那些同学也深知这个道理,脑裂,也就是如果你是两个节点的情况下,你网络出现问题,如何判断你当时那个节点应该是主,那个节点应该从,两个节点,自说自话各自为政,导致数据不一致,这点MySQL 的同学应该是深知的,那么为什么到了 MongoDB 这样一个使用 raft like 协议的数据库,提出双机热备这样,上世纪早期数据库提出的一个算不算高可用的理念。请别把Oracle 的 DG 放到这里。

这里在MongoDB PV1 协议中明确指出,各个成员可以在特性选举的情况下,对候选人投赞成或不赞成,但单方面不能停止选举,这在两个节点是无法实现这个功能的,因为,因为,因为 在两个节点的情况下,瞬间两个节点都认为他们是主节点,需要有第三个节点来进行仲裁,到底谁是真正的主节点。PV1 中使用了 term的概念,允许快速检测到同时存在主节点并在短时间进行多次的成功的选举,这更是在两个节点的情况下无法完成。

在MongoDB 中4.0以上的版本PV1,防止一个成员对于选举重复发起投票,通过term修改副本集协议中的版本,在MongoDB 副本集中每个成员都会维护一个term计数器,计数器会递增标识每次选举中状态是否进行了切换,这里在任意一个member接受到选票时他会检查当前自己的term和选票上的term 谁大谁小,如果自己小则更新自己,并接受该选票,同时也会验证选票中候选人的信息来确保自己有没有重复投票,通过这样的方式每个成员对每个 Term 发送一次选票,避免重复投票和选择冲突,而这一切都建议在至少3个节点的基础上。

所以我不知道提出MongoDB 双机热备的文章的作者是否了解MongoDB的基本原理。

f3288f2b3bf74e5cb0847133268df3a5.png

同时这里也建议,不在使用MongoDB 3.x ,目前在用MongoDB 应该在4.X 起步,也是基于3.x 在使用PV0 协议时的一些可能的问题的基础上。

如果你还在使用3.x 的Mongodb 3.2 3.4 可以通过如下的命令来修改你当前的使用的版本信息

cfg = rs.conf();
cfg.protocolVersion=1;
rs.reconfig(cfg);

看似简单的MongoDB ,一点都不简单,如果你觉得他简单,那是你还没有深入。

参考文章链接

https://www.mongodb.com/community/forums/t/setup-a-2-node-mongodb-replica-set/3323

0718efa9835a5bb9616416a88dae52eb.png

<think>嗯,用户想知道如何通过分布式部署或双机热备来提高Windows服务器的高可用性。首先,我需要回忆一下双机热备和分布式部署的基本概念。双机热备通常是指两个服务器互为备份,一个作为主节点,另一个作为备用节点,当主节点故障时,备用节点自动接管。而分布式部署可能涉及多个节点共同工作,通过负载均衡和数据冗余来提高可用性。 根据引用里的内容,双机热备有两种模式:磁盘阵列备份方式和镜像模式。磁盘阵列方式需要共享存储,可能成本较高,但稳定性好。镜像模式可能不需要共享存储,但需要数据同步机制。另外,数据库双机热备的例子中提到使用SQL Server的镜像功能,连接字符串可以自动故障转移,这应该适用于Windows环境。 分布式部署方面,引用提到高可用性的核心是冗余和自动故障转移。可能需要考虑负载均衡、数据分片、多主节点等问题。但引用也提到多主节点在数据一致性上的挑战,所以可能需要权衡。例如,使用Nginx或HAProxy做负载均衡,结合Redis集群或数据库分片来分散压力。 用户可能还关心具体实施步骤,比如如何配置故障转移集群,如何设置存储复制,或者如何选择适合的分布式架构。需要结合Windows服务器的特点,比如使用Windows Server Failover Clustering(WSFC)或者Hyper-V的冗余配置。 另外,用户提到的热冗余可能涉及实时数据同步,比如Storage Replica或第三方工具。需要确保数据在多个节点间的一致性,同时处理故障切换时的连接问题,比如ADO.NET的连接字符串配置。 可能还需要比较双机热备和分布式部署的优缺点。双机热备适合对成本有一定承受能力且需要高可靠性的场景,而分布式部署更适合需要横向扩展和高并发处理的场景。不过,分布式系统复杂度更高,维护成本也更大。 最后,要确保回答结构清晰,分点说明双机热备和分布式部署的具体方法,并结合引用中的例子,比如SQL Server镜像和故障转移集群的配置。同时,生成的相关问题要引导用户进一步了解实施细节、优缺点比较和实际案例。</think>### Windows服务器实现高可用性的方法 为提升Windows服务器的高可用性,主要可通过**双机热备**和**分布式部署**两种方式实现,其核心思想是**冗余设计**和**自动故障转移**。以下是具体方法: --- #### 一、双机热备(Active/Standby) 1. **基础架构模式** - **磁盘阵列备份方式**: 两台服务器通过共享磁盘阵列(如SAN/NAS)连接,主服务器负责业务处理,备用服务器实时同步数据。若主服务器故障,备用服务器自动接管存储和IP资源[^2]。 - **镜像模式**: 通过软件(如Windows Server Failover Clustering, WSFC)实现数据实时镜像,无需共享存储。例如SQL Server数据库镜像,可配置自动故障转移[^5]。 2. **关键技术实现** - **故障转移集群(WSFC)**: 将多台服务器组成集群,共享存储或通过存储复制(如Storage Replica)同步数据。支持服务、应用程序和虚拟机的自动迁移。 - **网络负载均衡(NLB)**: 适用于无状态服务(如Web服务器),通过流量分发实现冗余。 3. **配置示例(SQL Server镜像)** 在连接字符串中指定主备服务器地址,客户端可自动切换: ```plaintext ConnectionString="Data Source=主服务器;Failover Partner=备用服务器;Initial Catalog=数据库名;..." ``` --- #### 二、分布式部署 1. **核心原则** - **横向扩展**:通过多节点分担负载,避免单点故障。 - **数据分片与副本**:将数据分散到多个节点,并为每个分片创建副本(如Redis Cluster、HDFS)。 2. **实现方法** - **微服务架构**: 将应用拆分为独立服务,部署在多个服务器上,结合API网关实现动态路由。 - **容器化部署(如Kubernetes)**: 使用容器编排工具自动管理Pod副本和故障恢复,例如在Azure Kubernetes Service(AKS)中部署Windows容器。 - **数据库分布式集群**: 如MySQL Cluster或MongoDB分片集群,通过多主节点实现读写分离和数据同步[^4]。 3. **关键技术组件** - **负载均衡器**:如Nginx、HAProxy,分配请求至健康节点。 - **一致性协议**:如Raft或Paxos,解决分布式系统数据一致性问题。 --- #### 三、热冗余(实时冗余) 1. **存储级冗余** - **Storage Replica**:Windows Server原生功能,支持跨服务器块级同步复制,可实现零数据丢失[^3]。 - **Hyper-V实时迁移**:虚拟机在物理主机间无缝迁移,保障服务连续性。 2. **应用层冗余** - **Session复制**:如ASP.NET会话状态存储在SQL Server或Redis,确保用户请求可路由至任意节点。 --- #### 四、方案对比与选型建议 | 方案 | 适用场景 | 优点 | 缺点 | |---------------|---------------------------|---------------------------|---------------------------| | 双机热备 | 数据库、关键业务系统 | 切换快(秒级),配置简单 | 硬件成本高,扩展性有限 | | 分布式部署 | 高并发、大规模服务 | 弹性扩展,容灾能力强 | 复杂度高,需解决一致性问题| | 热冗余 | 实时性要求高的场景 | 数据零丢失 | 对网络带宽要求高 | ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值