mongodb集群shard状态异常:RECOVERING

报错信息

2018-11-28T06:46:55.783+0000 I REPL     [replication-0] We are too stale to use 172.19.9.12:27003 as a sync source. Blacklisting this sync source because our last fetched timestamp: Timestamp(1542344943, 1) is before their earliest timestamp: Timestamp(1543387334, 5197) for 1min until: 2018-11-28T06:47:55.783+0000
2018-11-28T06:46:55.783+0000 I REPL     [replication-0] sync source candidate: 172.19.9.11:27003
2018-11-28T06:46:55.783+0000 I REPL     [replication-0] We are too stale to use 172.19.9.11:27003 as a sync source. Blacklisting this sync source because our last fetched timestamp: Timestamp(1542344943, 1) is before their earliest timestamp: Timestamp(1543387334, 5953) for 1min until: 2018-11-28T06:47:55.783+0000

错误原因分析:

报错节点数据太”陈旧:stale”了;网络异常或者节点异常,太久没有进行同步数据操作,而导致其他节点的数据操作日志已经覆盖,所以本节点被认为 stale,无法从其他节点同步数据。

恢复方案

1:停掉数据库,直接删除异常节点(shard)本地数据,然后启动mongo数据库,启动之后存在一个同步的过程,根据数据量、网络、磁盘性能等因素所需时间不同。

2:停掉数据库,直接拷贝主节点上的数据,然后再启动mongo,这样就不存在数据同步的过程了.问题,就是数据时刻在变化,拷贝过程中难免会漏掉一些数据。

处理办法:

我们的mongodb集群是使用docker拉起的,使用方案 1;

首先确定异常分片节点==》然后确定映射目录==》删除异常分片实例数据目录==》docker 服务会自动拉起服务==》集群开始数据恢复;

确认异常信息:

/mongo localhost:27017/admin

:PRIMARY> rs.status();

                {
                        "_id" : 2,
                        "name" : "172.19.9.13:27003",   《== 节点信息
                        "health" : 1,
                        "state" : 5,
                        "stateStr" : "RECOVERING",      《== 异常状态
                        "uptime" : 64,
                        "optime" : {
                                "ts" : Timestamp(0, 0),
                                "t" : NumberLong(-1)
                        },

具体操作:

数据目录:/data/shard3     

ssh $HOSTNAME
cd /data/
rm -rf shard3       

删除数据目录后,容器异常,集群会自动拉起新的一个docker 实例运行 shard 3实例;

查看恢复状态:

STARTUP2表示正在初始化并同步数据,会看到数据目录文件在不停增加文件。

/mongo localhost:27017/admin

:PRIMARY> rs.status();

                {
                        "_id" : 2,
                        "name" : "172.19.9.13:27003",
                        "health" : 1,
                        "state" : 5,
                        "stateStr" : "STARTUP2",    《===表示正在初始化并同步数据。
                        "uptime" : 64,
                        "optime" : {
                                "ts" : Timestamp(0, 0),
                                "t" : NumberLong(-1)
                        },

查看恢复结果

/mongo localhost:27017/admin

:PRIMARY> rs.status();
                        "_id" : 2,
                        "name" : "172.19.9.13:27003",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",     <== 一段时间后状态恢复正常
                        "uptime" : 945196,
                        "optime" : {
                                "ts" : Timestamp(1543401694, 1),
                                "t" : NumberLong(1)
                        },

注意事项:

同步数据时候比较耗费资源,推荐在系统访问量最低的时间段进行。防止数据大量更新滞后,降低集群数据恢复风险。

原文地址:http://blog.51cto.com/michaelkang/2323388

时间: 2024-10-18 09:49:12

mongodb集群shard状态异常:RECOVERING的相关文章

搭建高可用mongodb集群—— 分片

从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!“分片”就用这个来解决这个问题. 传统数据库怎么做海量数据读写?其实一句话概括:分而治之.上图看看就清楚了,如下 taobao岳旭强在infoq中提到的 架构图: 上图中有个TDDL,是taobao的一

搭建高可用mongodb集群(四)—— 分片(经典)

转自:http://www.lanceyan.com/tech/arch/mongodb_shard1.html 按照上一节中<搭建高可用mongodb集群(三)-- 深入副本集>搭建后还有两个问题没有解决: 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么

搭建高可用mongodb集群(二)—— 副本集

http://www.lanceyan.com/tech/mongodb/mongodb_repset1.html 在上一篇文章<搭建高可用MongoDB集群(一)——配置MongoDB> 提到了几个问题还没有解决. 主节点挂了能否自动切换连接?目前需要手工切换. 主节点的读写压力过大如何解决? 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 这篇文章看完这些问题就可以搞定了.NoSQL的产生就是为了解决大数据量.高扩展性.高

搭建高可用mongodb集群(四)—— 分片

转载自LANCEYAN.COM 按照上一节中<搭建高可用mongodb集群(三)—— 深入副本集>搭建后还有两个问题没有解决: 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!“分片”就用这个来解决这个问题. 传统数据库怎么做海量数据读写?其实一句

MongoDB集群解决方案-分片技术

MongoDB,NoSQL技术的实现,基于分布式文件存储的数据库,由C++语言编写.主要是解决海量数据的访问效率问题,为web应用提供可扩展的高性能数据库存储解决方案 MongoDB集群的实现方式: 1.Replica Set:也叫作副本集,简单来说就是集群中的服务器包含了多分数据,保证主节点挂掉了.备节点能够继续的提供服务,但是提供的前提就是数据必须要和主节点的一致,如下图: MongoDB(M)表示主节点,MongoDB(S)表示从节点,MongoDB(A)表示仲裁节点: M节点存储数据并提

mongodb集群搭建

mongodb集群有三种方式 1,主从模式,类似mysql master slave方式. 2,副本集模式,其实是一主多从,如果主节点挂掉,会重新在从节点选取一台为主节点. 3,分片模式,针对大数据量,高负载情况. 从图中可以看到有四个组件:mongos.config server.shard.replica set. mongos,数据库集群请求的入口,所有的请求都通过mongos进行协调,不需要在应用程序添加一个路由选择器,mongos自己就是一个请求分发中心,它负责把对应的数据请求请求转发

mongodb集群安装及到现在遇到的一些问题

集群搭建 只有3台服务器,开始搭建mongodb集群里主要参照的是http://www.lanceyan.com/tech/arch/mongodb_shard1.html,端口的设置也是mongos为 20000, config server 为 21000, shard1为 22001 , shard2为22002, shard3为22003.其大体思路为: 在每台服务器上启动config服务 在每台服务器上启动mongos服务,并指定每个mongos服务包含的config服务地址(前一步启

搭建高可用MongoDB集群(四):分片

按照上一节中<搭建高可用mongodb集群(三)-- 深入副本集>搭建后还有两个问题没有解决: 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!"分片"就用这个来解决这个问题. 传统数据库怎么做海量数据读写?其实一句话概括:分而

【转】搭建高可用mongodb集群(二)—— 副本集

在上一篇文章<搭建高可用MongoDB集群(一)——配置MongoDB> 提到了几个问题还没有解决. 主节点挂了能否自动切换连接?目前需要手工切换. 主节点的读写压力过大如何解决? 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 这篇文章看完这些问题就可以搞定了.NoSQL的产生就是为了解决大数据量.高扩展性.高性能.灵活数据模型.高可用性.但是光通过主从模式的架构远远达不到上面几点,由此MongoDB设计了副本集和分片的功能