Eu configurei um cluster de fragmentos do MongoDB. Ele tem três réplicas de estilhaços, cada réplica tem três instâncias do mongo. E tem uma réplica de 3 servidores de configuração do mongo. E um mongo. Funciona bem no início, mas a conexão da réplica de configuração falhou após alguns dias de execução. Quando eu faço login em cada instância mongo do servidor de configuração, abaixo está a rs.status()saída do comando:
Configurar servidor1:
OTHER> rs.status()
{
"state" : 10,
"stateStr" : "REMOVED",
"uptime" : 121353,
"optime" : {
"ts" : Timestamp(1504367995, 1),
"t" : NumberLong(3)
},
"optimeDate" : ISODate("2017-09-02T15:59:55Z"),
"ok" : 0,
"errmsg" : "Our replica set config is invalid or we are not a member of it",
"code" : 93,
"codeName" : "InvalidReplicaSetConfig"
}
Configure o Servidor 2:
OTHER> rs.status()
{
"state" : 10,
"stateStr" : "REMOVED",
"uptime" : 121421,
"optime" : {
"ts" : Timestamp(1504367995, 1),
"t" : NumberLong(3)
},
"optimeDate" : ISODate("2017-09-02T15:59:55Z"),
"ok" : 0,
"errmsg" : "Our replica set config is invalid or we are not a member of it",
"code" : 93,
"codeName" : "InvalidReplicaSetConfig"
}
Configure o servidor 3:
SECONDARY> rs.status()
{
"set" : "cnf-serv",
"date" : ISODate("2017-09-04T01:45:05.842Z"),
"myState" : 2,
"term" : NumberLong(3),
"configsvr" : true,
"heartbeatIntervalMillis" : NumberLong(2000),
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"appliedOpTime" : {
"ts" : Timestamp(1504367995, 1),
"t" : NumberLong(3)
},
"durableOpTime" : {
"ts" : Timestamp(1504367995, 1),
"t" : NumberLong(3)
}
},
"members" : [
{
"_id" : 0,
"name" : "172.19.0.10:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 121454,
"optime" : {
"ts" : Timestamp(1504367995, 1),
"t" : NumberLong(3)
},
"optimeDate" : ISODate("2017-09-02T15:59:55Z"),
"configVersion" : 403866,
"self" : true
},
{
"_id" : 1,
"name" : "172.19.0.7:27017",
"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("2017-09-04T01:45:02.312Z"),
"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "Connection refused",
"configVersion" : -1
},
{
"_id" : 2,
"name" : "172.19.0.4:27017",
"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("2017-09-04T01:45:02.310Z"),
"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "Connection refused",
"configVersion" : -1
}
],
"ok" : 1
}
Parece que as duas primeiras instâncias foram removidas e o terceiro servidor de configuração é secundário. Com base no meu entendimento, se houver um desligamento de instância em uma réplica, outra instância íntegra deverá ser selecionada para se tornar primária. Por que a terceira instância não se tornou primária em minha réplica?
Todas as instâncias do mongo estão usando a versão 3.4.4.
Abaixo está o comando que usei para iniciar o servidor de configuração do mongod:
mongod --replSet cnf-serv --rest --configsvr --port 27017 --oplogSize 16 --noprealloc --smallfiles
FYI, no primeiro log de duas instâncias, vejo a mensagem de erro abaixo:
2017-09-04T01:39:23.006+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed :: caused by :: 134 could not get updated shard list from config server due to Read concern majority reads are currently not possible.; will retry after 30s
2017-09-04T01:39:53.006+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed :: caused by :: 134 could not get updated shard list from config server due to Read concern majority reads are currently not possible.; will retry after 30s
2017-09-04T01:40:23.006+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed :: caused by :: 134 could not get updated shard list from config server due to Read concern majority reads are currently not possible.; will retry after 30s
2017-09-04T01:40:53.006+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed :: caused by :: 134 could not get updated shard list from config server due to Read concern majority reads are currently not possible.; will retry after 30s
OK .. A razão pela qual esse terceiro servidor é secundário e não primário, é "majoritário". Quando há apenas um dos três servidores "up", esse não é a maioria. Então, se você "perder" um dos três servidores, o resto dos dois está bom porque 2/3 é a maioria.
E então de volta ao problema básico. Parece que esses dois servidores que estão no estado "OUTRO" agora têm endereço/nome diferente do que era quando você os adicionou ao conjunto de réplicas. Verifique se esses dois servidores ainda resolvem o mesmo endereço IP (ou nome DNS) usado na configuração do conjunto de réplicas.
Você pode tentar usar force:true enquanto reconfigura a partir de um membro secundário disponível, fornecendo o IP correto para os outros dois membros.