mongodb的副本集成员状态state解析

 

 

 综述：

# 停掉数据库，直接删除本地数据，然后启动mongo数据库，启动之后存在一个同步的过程，会非常耗时。

# startup2：表示正在初始化并同步数据。

 副本集的每个成员都有一个状态，反映了它在集合中的配置情况。

 

数字	名称	状态描述
0	STARTUP	还不是任何集合的活动成员。所有的成员启动在该状态。在STARTUP状态mongod解析副本集配置文档。
1	PRIMARY	处于PRIMARY状态的成员是唯一能接受写操作的成员。
2	SECONDARY	处于SECONDARY状态的成员复制数据存储。数据可用于读，尽管可能比较旧。
3	RECOVERING	可以选举。成员要么实施启动自检测，或完成回滚或重新同步的转换。处于维修模式时：db.adminCommand({"replSetMaintenance":true})
5	STARTUP2	成员加入了集合，正运行初始化同步。
6	UNKNOWN	成员的状态，正如从集合的另一个成员中所看到的，未知。
7	ARBITER	仲裁不复制数据，而仅仅参与选举。
8	DOWN	该成员，正如从集合的立即你跟一个成员所见，不可达。(not reachable/healthy)，执行： db.shutdownServer()
9	ROLLBACK	该成员正在实施回滚。数据不可读。
10	REMOVED	成员曾今在副本集但随后被移除。

 

 举例：

glc-test:SECONDARY> use admin
switched to db admin
glc-test:SECONDARY> db.shutdownServer()
server should be down...
2020-11-26T15:57:35.265+0800 I NETWORK  [js] trying reconnect to xxx:28042 failed
2020-11-26T15:57:35.267+0800 I NETWORK  [js] reconnect xxx:28042 failed failed 
2020-11-26T15:57:35.270+0800 I NETWORK  [js] trying reconnect to xxx:28042 failed
2020-11-26T15:57:35.271+0800 I NETWORK  [js] reconnect xxx:28042 failed failed 
> ^C
2020-11-26T15:57:45.250+0800 I NETWORK  [js] trying reconnect to xxx:28042 failed
2020-11-26T15:57:45.251+0800 I NETWORK  [js] reconnect xxx:28042 failed failed 
2020-11-26T15:57:45.252+0800 I QUERY    [js] Failed to end session { id: UUID("0dbe7d46-7f64-4af4-9a82-346be3b0d8fe") }
 due to SocketException: socket exception [CONNECT_ERROR] server [couldn't connect to server xxx:28042,
 connection attempt failed: SocketException: Error connecting to xxx:28042 (ip:28042) :: caused by :: Connection refused]



{
"_id" : 4,
"name" : "xxx:28042",
"health" : 0,
"state" : 8,
"stateStr" : "(not reachable/healthy)",
"uptime" : 0,
"optime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDurable" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2020-11-26T07:58:56.535Z"),
"lastHeartbeatRecv" : ISODate("2020-11-26T07:57:32.974Z"),
"pingMs" : NumberLong(1),
"lastHeartbeatMessage" : "Error connecting to xxx:28042 (ip:28042) :: caused by :: Connection refused",
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"configVersion" : -1
}

 

 

PRIMARY：

处于PRIMARY状态的成员接受写操作。
一个副本集每次最多只有一个主成员。在一次选举后，一个SECONDARY状态成员成为主成员。处于PRIMARY状态的成员有资格选举。

SECONDARY：

处于SECONDARY状态的成员复制主成员的数据集合，并可以被配置为接受读操作。辅助成员有资格在选举中投票，如果主成员不可用，会被选举为PRIMARY状态。
ARBITER

处于ARBITER状态的成员不复制数据，也不接受写操作。它们有资格选举，仅仅存在于选举中决胜负。如果集合要么有大量的成员，并能够参与决胜选举，否则副本集应该只有一个成员处于ARBITER状态。在任何副本集中最多只有一个仲裁被配置。
其他状态

STARTUP：

副本集的每个成员以STARTUP状态启动。Mongod然后加载成员的副本集配置，成员的状态转化为STARTUP2。在STARTUP状态的成员没有资格选举，因为它们不被人为是任何副本集的成员。
STARTUP2

一旦mongod加载成员配置完成，副本集的每个成员就进入STARTUP2状态，在此时它开始成员副本集的一个活动成员。成员然后决定是否需要初始化同步。如果一个成员开始初始化同步，成员保持STARTUP2状态直到所有数据拷贝完成所有索引创建完成。之后，成员转换为RECOVERING状态。

RECOVERING：

当副本集成员不准备接受读取时，它进入RECOVERING状态。RECOVERING状态发生在正常操作期间，不必显示一个错误条件。处于RECOVERING状态的成员有资格在选举中投票，但是没有资格进入PRIMARY状态。

在复制足够的数据给客户端所需读取数据的一致性视图，成员便从RECOVERING状态转为SECONDARY状态。在RECOVERING和SECONDARY状态之间的唯一区别是，RECOVERING阻止客户端读取，SECONDARY运行读取。SECONDARY状态并不保证主成员数据陈旧化。

注：关于负载，一个辅助成员可能会远远落后于副本集的其他成员，以至于它可能需要重新同步数据到副本集。当这种情况发生时，成员进入RECOVERING状态，并需要手工干预。
错误状态

处于错误状态的成员不能选举。

UNKNOWN：

从没交流状态信息到副本集的成员会处于UNKNOWN状态。

 

DOWN：

丢失到副本集连接的成员被集合的剩余成员看作为DOWN状态。

REMOVED：

从副本集移除的成员进入REMOVED状态。当成员进入REMOVED状态，日志将会标记replset REMOVED消息事件。

 

ROLLBACK：

当副本集在选举中替换掉主成员，旧的主成员可能包含不会复制到辅助成员的文档。在这种情况下，旧的主成员反转这些写操作。在回滚期间，成员将保持ROLLBACK状态。

FATAL：

处于FATAL状态的成员触发了一个不可恢复错误。成员必需关闭并重启，可能还需要重新同步。

 

 

 

###################################################