【Mongodb】 Replica set 的 选举策略之二

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
简介:
对于Replica Set中的选择策略:
We use a consensus protocol to pick a primary. Exact details will be spared here but that basic process is:
1 get maxLocalOpOrdinal from each server.
2 if a majority of servers are not up (from this server's POV), remain in Secondary mode and stop.
3 if the last op time seems very old, stop and await human intervention.
4 else, using a consensus protocol, pick the server with the highest maxLocalOpOrdinal as the Primary.

对于策略2:当集群里的大多数服务器发生down 机了,剩余的节点就会保持在secondary模式并停止服务。
做了实验结果是对于4节点的 Replica Set,当两个secondary节点down了的时候,主节点变为secondary。整个集群相当于挂了,因为secondary 不提供读写操作。。
在一个集群中关闭两个secondary 节点:rac4:27019和rac3:27017 
[mongodb@rac4 bin]$ ./mongo 127.0.0.1:27019
MongoDB shell version: 2.0.1
connecting to: 127.0.0.1:27019/test
SECONDARY> 
SECONDARY> use admin
switched to db admin
SECONDARY> db.shutdownServer();
Wed Nov  2 11:02:29 DBClientCursor::init call() failed
Wed Nov  2 11:02:29 query failed : admin.$cmd { shutdown: 1.0 } to: 127.0.0.1:27019
server should be down...

[mongodb@rac3 bin]$ ./mongo  10.250.7.241:27017
MongoDB shell version: 2.0.1
connecting to: 127.0.0.1:27017/test
SECONDARY> 
SECONDARY> use admin
switched to db admin
SECONDARY> db.shutdownServer();
Tue Nov  1 22:02:46 DBClientCursor::init call() failed
Tue Nov  1 22:02:46 query failed : admin.$cmd { shutdown: 1.0 } to: 127.0.0.1:27017
server should be down...
Tue Nov  1 22:02:46 trying reconnect to 127.0.0.1:27017
Tue Nov  1 22:02:46 reconnect 127.0.0.1:27017 failed couldn't connect to server 127.0.0.1:27017
Tue Nov  1 22:02:46 Error: error doing query: unknown shell/collection.js:150
从主库的客户端退出以后,再次进入提示符发生变化:由PRIMARY--->SECONDARY ,查看Replica Set的状态信息:
[mongodb@rac4 bin]$ ./mongo 127.0.0.1:27020       
MongoDB shell version: 2.0.1
connecting to: 127.0.0.1:27020/test
SECONDARY
SECONDARY> rs.status();
{
        "set" : "myset",
        "date" : ISODate("2011-11-01T13:56:05Z"),
        "myState" : 2,
        "members" : [
                {
                        "_id" : 0,
                        "name" : "10.250.7.220:27018",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 101,
                        "optime" : {
                                "t" : 1320154033000,
                                "i" : 1
                        },
                        "optimeDate" : ISODate("2011-11-01T13:27:13Z"),
                        "lastHeartbeat" : ISODate("2011-11-01T13:56:04Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 1,
                        "name" : "10.250.7.220:27019",
                        "health" : 0,  --已经关闭
                        "state" : 8,
                        "stateStr" : "(not reachable/healthy)",
                        "uptime" : 0,
                        "optime" : {
                                "t" : 1320154033000,
                                "i" : 1
                        },
                        "optimeDate" : ISODate("2011-11-01T13:27:13Z"),
                        "lastHeartbeat" : ISODate("2011-11-01T13:53:50Z"),
                        "pingMs" : 0,
                        "errmsg" : "socket exception"
                },
                {
                        "_id" : 2,
                        "name" : "10.250.7.220:27020",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY", ---由主库变为从库
                        "optime" : {
                                "t" : 1320154033000,
                                "i" : 1
                        },
                        "optimeDate" : ISODate("2011-11-01T13:27:13Z"),
                        "self" : true
                },
                {
                        "_id" : 3,
                        "name" : "10.250.7.241:27017",
                        "health" : 0,
                        "state" : 8,
                        "stateStr" : "(not reachable/healthy)",
                        "uptime" : 0,
                        "optime" : {
                                "t" : 1320154033000,
                                "i" : 1
                        },
                        "optimeDate" : ISODate("2011-11-01T13:27:13Z"),
                        "lastHeartbeat" : ISODate("2011-11-01T13:53:54Z"),
                        "pingMs" : 0,
                        "errmsg" : "socket exception"
                }
        ],
        "ok" : 1
}
SECONDARY> exut
Wed Nov  2 15:23:02 ReferenceError: exut is not defined (shell):1
Wed Nov  2 15:23:02 DBClientCursor::init call() failed
> exit
bye
未完 待续。。。。
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。   相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
相关文章
|
9月前
|
存储 NoSQL MongoDB
掌握MongoDB索引优化策略:提升查询效率的关键
在数据库性能调优中,索引是提升查询效率的利器。本文将带你深入了解MongoDB索引的内部工作原理,探讨索引对查询性能的影响,并通过实际案例指导如何针对不同的查询模式建立有效的索引。不仅将涵盖单一字段索引,还会探讨复合索引的使用,以及如何通过分析查询模式和执行计划来优化索引,最终实现查询性能的最大化。
|
存储 监控 NoSQL
MongoDB索引解析:工作原理、类型选择及优化策略
MongoDB索引解析:工作原理、类型选择及优化策略
|
NoSQL 定位技术 MongoDB
深入探索 MongoDB:高级索引解析与优化策略
深入探索 MongoDB:高级索引解析与优化策略
287 1
|
NoSQL 定位技术 MongoDB
解锁MongoDB索引的秘密:优化查询效率与应对限制的策略
解锁MongoDB索引的秘密:优化查询效率与应对限制的策略
202 0
|
11月前
|
Kubernetes 容器 Perl
在K8S中,Replica Set和Replication Controller之间有什么区别?
在K8S中,Replica Set和Replication Controller之间有什么区别?
|
NoSQL MongoDB 数据库
国内唯一 阿里云荣膺MongoDB“2024年度DBaaS认证合作伙伴奖”
阿里云连续第五年斩获MongoDB合作伙伴奖项,也是唯一获此殊荣的中国云厂商。一起学习MongoDB副本集的选举机制以及可能会出现的特殊情况。
国内唯一 阿里云荣膺MongoDB“2024年度DBaaS认证合作伙伴奖”
|
存储 监控 NoSQL
【MongoDB 专栏】MongoDB 分片策略与最佳实践
【5月更文挑战第10天】MongoDB 分片是应对大数据量的扩展策略,涉及哈希和范围分片两种策略。分片架构包含分片服务器、配置服务器和路由服务器。最佳实践包括选择合适分片键、监控调整、避免热点数据等。注意数据分布不均和跨分片查询的挑战。通过实例展示了如何在电商场景中应用分片。文章旨在帮助理解并优化 MongoDB 分片使用。
416 3
【MongoDB 专栏】MongoDB 分片策略与最佳实践
|
存储 NoSQL 安全
【MongoDB 专栏】MongoDB 的备份与恢复策略
【5月更文挑战第11天】MongoDB的备份与恢复至关重要,确保数据安全、完整和可用。数据库提供文件级和逻辑备份,前者简单直接但可能需短暂停机,后者灵活可选特定数据。备份策略要考虑频率和存储位置,恢复时要验证数据完整性,选择合适恢复点。增量和差异备份可提升效率,监控管理备份是必要环节。案例显示,有效策略能降低意外损失。随着技术发展,应持续优化策略,强化人员培训,以责任和使命对待备份恢复,保障企业数据环境的安全稳定。
192 1
【MongoDB 专栏】MongoDB 的备份与恢复策略
|
监控 NoSQL MongoDB
MongoDB索引机制与优化策略详解
【4月更文挑战第30天】本文深入解析MongoDB的索引机制,包括单字段、复合、地理空间、全文及哈希索引。介绍了创建与查看索引的方法,并提出了优化策略:选择性创建、使用复合索引、定期审查优化、避免不必要的索引扫描、利用索引前缀与覆盖索引,以及监控索引使用。通过这些策略,可提升MongoDB查询性能。
MongoDB-复制集选举规则
选举规则 • 一旦发现主节点没有响应 / 发送心跳请求, 那么副节点就会认为主节点挂了 • 一旦发现主节点挂了, 任意一个副节点都可以发起选举 • (发起选举的节点我们称之为 候选节点, 每一个节点内部都有一个 选举计数器) • 发起选举的节点会给自己先投一票, 然后将自己的票数依次发送给其它节点
210 0

推荐镜像

更多
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问