Estou tendo problemas para entender como o replicaSet funciona usando 2 nós e um árbitro, usando a comunidade MongoDB 6 em 3 servidores com ubuntu 22.04.
Meu cenário atual é que tenho 2 servidores em um replicaSet onde o primeiro é primário (prioridade 1) e um secundário com prioridade 0,5 (eu configurei assim, então sempre poderia ter o primário como servidor principal). Um terceiro servidor não armazena nenhum dado funcionando como árbitro.
Testei desligar meu primário, então meu secundário foi eleito como primário sem nenhum problema. Mas se eu tentar gravar qualquer dado nele, ele não salva até que meu primário volte.
A ideia é ter meu secundário como um servidor sobressalente caso meu principal falhe por qualquer motivo, para que meus aplicativos possam continuar salvando e lendo.
Eu sei que poderia usar 3 nós de servidor, então eu teria 2 servidores graváveis para votar, mas considerando que esse banco de dados terá cerca de 1 TB de dados, não posso ter um terceiro servidor salvando a mesma quantidade de dados por enquanto.
Eu tentei alguns comandos sobre a preocupação de gravação, mas tive dois comportamentos diferentes:
1 - Usando este comando, usando mongodb Compass, parece gravar novos dados, mas não é listado até que o primário volte:
db.adminCommand({ "setDefaultRWConcern": 1, "defaultWriteConcern": { "w": 1 } })
2 - Usando mongodb Compass, mostre "Iinserting Document", mas nunca termine, até que o primário volte:
db.adminCommand({ "setDefaultRWConcern": 1, "defaultWriteConcern": { "w": "majority" } })
Atualização de como conectado: Por meio de um aplicativo PHP, usando ssh com mongosh
MongoDB Compass com string de conexão (com ajuda de Wernfried):
mongodb://rootuser:rootpasswd@primaryip:27017,secondaryip:27017/?replicaSet=myRepl&authSource=admin&readPreference=primaryPreferred
Se eu desligar meu servidor primário, o secundário é eleito como primário, mas não posso escrever até que ambos os nós estejam online.
É assim que meu rs.conf() está agora
{
_id: 'rspd01',
version: 13,
term: 51,
members: [
{
_id: 0,
host: 'primaryIP:27017',
arbiterOnly: false,
buildIndexes: true,
hidden: false,
priority: 1,
tags: {},
secondaryDelaySecs: Long("0"),
votes: 1
},
{
_id: 1,
host: 'secondaryIP:27017',
arbiterOnly: false,
buildIndexes: true,
hidden: false,
priority: 0.5,
tags: {},
secondaryDelaySecs: Long("0"),
votes: 1
},
{
_id: 2,
host: 'arbiterIP:27017',
arbiterOnly: true,
buildIndexes: true,
hidden: false,
priority: 0,
tags: {},
secondaryDelaySecs: Long("0"),
votes: 1
}
],
protocolVersion: Long("1"),
writeConcernMajorityJournalDefault: true,
settings: {
chainingAllowed: true,
heartbeatIntervalMillis: 2000,
heartbeatTimeoutSecs: 10,
electionTimeoutMillis: 10000,
catchUpTimeoutMillis: -1,
catchUpTakeoverDelayMillis: 30000,
getLastErrorModes: {},
getLastErrorDefaults: { w: 1, wtimeout: 0 },
replicaSetId: ObjectId("64863fd09a9b54d4cd0da913")
}
}
Existe algum comando que eu possa fazer para trabalhar com essa estrutura?
Atenciosamente.
Observe que no MongoDB você tem duas maiorias diferentes.
Uma maioria se aplica para eleger um PRIMÁRIO, no seu caso todos os três membros são contados, ou seja, se um membro não estiver disponível, você ainda terá a maioria disponível.
A outra maioria aplica-se a escrever dados, no seu caso, apenas as duas notas com dados são contadas. Se um deles cair, a maioria não estará mais disponível - apesar do fato de você ter um ÁRBITRO.
Portanto, para um conjunto de réplicas PSA de 3 membros, a única preocupação RW significativa é
Normalmente, você executa esse comando apenas uma vez ao configurar seu MongoDB.
Esteja ciente de que alguns comandos (por exemplo, renomear uma coleção) reforçam a preocupação de gravação
{ w: "majority" }
, você não pode alterá-lo. Portanto, a maioria deve estar disponível quando você quiser executar esses comandos. Caso contrário, você precisa rebaixar o membro que não está disponível para um membro sem direito a voto, ou seja, alterar as configurações da réplica para{ votes: 0, priority: 0}
.