Algumas horas atrás, tivemos uma interrupção em um servidor que estava executando uma mongos
instância. Depois de resolver o problema subjacente, mongos
não foi possível inicializar com o seguinte erro:
"ctx":"ReplicaSetMonitor-TaskExecutor","msg":"Invariant failure","attr":{"expr":"!groupAndId.groupData","file":"src/mongo/s/sharding_task_executor_pool_controller.cpp","line":134}
"ctx":"ReplicaSetMonitor-TaskExecutor","msg":"\n\n***aborting after invariant() failure\n\n"
"ctx":"ReplicaSetMonitor-TaskExecutor","msg":"Writing fatal message","attr":{"message":"Got signal: 6 (Aborted).\n"}
E agora, outras mongos
instâncias mongod
que exigiram reinicializações também não conseguem inicializar com o mesmo erro - portanto, com o tempo, todas podem falhar uma a uma e não conseguir inicializar novamente.
Nosso cluster MongoDB contém 5 fragmentos de dados e 1 fragmento de configuração, cada um consistindo em um conjunto de réplicas de 3 membros. Vamos rotular cada fragmento de dados A,B,C,D,E e cada instância A1,A2,A3,B1,B2,etc...
Após uma inspeção mais detalhada da mongos
instância com falha, notei algumas coisas estranhas nos logs de alteração de topologia do RSM. Os hosts parecem estar misturados entre o replset. Observe a mudança de topologia para replset-B, contendo 1 host de seu conjunto, mas os hosts para outros conjuntos, mas ao mesmo tempo, a propriedade "setName" mostrando replset-A.
"ctx":"ReplicaSetMonitor-TaskExecutor",
"msg":"RSM Topology Change",
"attr":{
"replicaSet":"replset-B",
"newTopologyDescription":"{
id: \"bfcaaf31-9ead-497b-85b9-1e98dbf97805\",
topologyType: \"ReplicaSetNoPrimary\",
servers: {
server-B1:27017: {
address: \"server-B1:27017\", type: \"Unknown\",
minWireVersion: 0, maxWireVersion: 0,
lastUpdateTime: new Date(-9223372036854775808),
hosts: {}, arbiters: {}, passives: {}
},
server-A1:27017: {
address: \"server-A1:27017\", type: \"Unknown\",
minWireVersion: 0, maxWireVersion: 0,
lastUpdateTime: new Date(-9223372036854775808),
hosts: {}, arbiters: {}, passives: {}
},
server-A2:27017: {
address: \"server-A2:27017\", type: \"Unknown\",
minWireVersion: 0, maxWireVersion: 0,
lastUpdateTime: new Date(-9223372036854775808),
hosts: {}, arbiters: {}, passives: {}
},
server-A3:27017: {
address: \"server-A3:27017\", type: \"Unknown\",
minWireVersion: 0, maxWireVersion: 0,
lastUpdateTime: new Date(-9223372036854775808),
hosts: {}, arbiters: {}, passives: {}
}
},
logicalSessionTimeoutMinutes: 30,
setName: \"replset-A\",
compatible: true
}",
"previousTopologyDescription":"{
id: \"2e9451c0-f13e-4d77-b9f9-6900ee5754ab\",
topologyType: \"Unknown\",
servers: {
server-B2:27017: {
address: \"server-B2:27017\", type: \"Unknown\",
minWireVersion: 0, maxWireVersion: 0,
lastUpdateTime: new Date(-9223372036854775808),
hosts: {}, arbiters: {}, passives: {}
},
server-B3:27017: {
address: \"server-B3:37017\", type: \"Unknown\",
minWireVersion: 0, maxWireVersion: 0,
lastUpdateTime: new Date(-9223372036854775808),
hosts: {}, arbiters: {}, passives: {}
}
},
compatible: true
}"
}
Eu corri sh.status()
em uma mongos
instância em funcionamento e eis que shard-B
estava aparecendo como replset-B/server-A1:27017,server-A2:27017,server-A3:27017
. Não tenho ideia de como isso aconteceu. Este cluster está em execução há alguns anos, e a última alteração na topologia foi adicionar shard-E algumas semanas atrás. Todos mongod.conf
têm os nomes replSet corretos neles, fazendo rs.conf()
e rs.status()
nas primárias de cada conjunto de réplicas não mostra inconsistências.
Eu até tentei atualizar a config.shards
coleção diretamente e $set
tingir os hosts corretos para os shards problemáticos, tanto por meio mongos
da configuração primária, mas não apenas não funcionou (as outras mongos
instâncias continuaram falhando com o mesmo erro), mas reverteu para a string de conexão antiga (errada) depois de um tempo (o que eu suspeito que tenha a ver com o ShardRegistry
mecanismo que atualiza o config.shards
também).
Correr db.runCommand({getShardMap: 1})
me dá o seguinte resultado (que eu suspeito ser outro sintoma de algum conflito em algum lugar):
"connStrings" : {
...all good until...
"replset-B/server-A1:27017,server-A2:27017,server-A3:27017" : "shard-B",
}
Estou quase perdendo o juízo. O tempo de inatividade não é realmente uma opção, e eu queria saber se alguém mais experiente no funcionamento interno do MongoDB teria alguma ideia para compartilhar sobre isso.
Problema encontrado. O problema era uma configuração de DNS - o mapeamento do nome do host para um dos servidores B estava apontando para o endereço IP de um servidor A. De alguma forma, isso demorou um pouco para se manifestar.