Alterar nomes de host em um conjunto de réplicas autogerenciado
Nesta página
Para a maioria dosconjuntos de réplicas , os nomes de host no campo members[n].host
nunca mudam. No entanto, se as necessidades organizacionais mudarem, talvez seja necessário migrar alguns ou todos os nomes de host.
Observação
Sempre use nomes de host resolvíveis para o valor do campo members[n].host
na configuração do conjunto de réplicas para evitar confusão e complexidade.
Importante
Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.
Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.
Visão geral
Este documento fornece dois procedimentos separados para alterar os nomes de host no campo members[n].host
. Use uma das seguintes abordagens:
Altere os nomes de host sem interromper a disponibilidade. Essa abordagem garante que seus aplicativos sempre poderão ler e gravar dados no conjunto de réplicas, mas ela pode levar muito tempo e pode gerar tempo de inatividade na camada de aplicativos.
Se você utilizar o primeiro procedimento, você deverá configurar seus aplicativos para se conectar ao conjunto de réplicas definido nos locais antigos e novos, o que muitas vezes exige uma reinicialização e reconfiguração na camada do aplicativo e que pode afetar a disponibilidade de seus aplicativos. A reconfiguração de aplicativos está além do escopo deste documento.
Impeça que todos os membros usem os nomes de host antigos de uma só vez. Esta abordagem tem uma janela de manutenção mais curta, mas o conjunto de réplicas ficará indisponível durante a operação.
Suposições
Dado um conjunto de réplica com três nós:
database0.example.com:27017
(o primário)database1.example.com:27017
database2.example.com:27017
E com a seguinte saída de rs.conf()
:
{ "_id" : "rs", "version" : 3, "members" : [ { "_id" : 0, "host" : "database0.example.com:27017" }, { "_id" : 1, "host" : "database1.example.com:27017" }, { "_id" : 2, "host" : "database2.example.com:27017" } ] }
Os procedimentos a seguir alteram os nomes de host dos membros da seguinte maneira:
mongodb0.example.net:27017
(o primário)mongodb1.example.net:27017
mongodb2.example.net:27017
Use o procedimento mais apropriado para sua implantação.
Altere Nomes de Host enquanto Mantém a Disponibilidade do Conjunto de Réplicas
Esse procedimento usa as suposiçõesacima.
Para cada secundário no conjunto de réplicas, execute a seguinte sequência de operações:
Interrompa o secundário.
Reinicie o secundário no novo local.
Conecte
mongosh
ao primário do conjunto de réplicas. Em nosso exemplo, o primário executa na porta27017
para que você emita o seguinte comando:mongosh --port 27017 Utilize o
rs.reconfig()
para atualizar o documento de configuração do conjunto de réplica com o novo nome de host.Por exemplo, a seguinte sequência de comandos atualiza o nome de host para o secundário no índice de array
1
da arraymembers
(ou seja,members[1]
) no documento de configuração do conjunto de réplicas:cfg = rs.conf() cfg.members[1].host = "mongodb1.example.net:27017" rs.reconfig(cfg) Para obter mais informações sobre atualizações do documento de configuração, consulte Exemplos.
Certifique-se de que os aplicativos clientes consigam acessar o conjunto no novo local e que o secundário tenha a chance de se comunicar com os outros nós do conjunto.
Repita as etapas acima para cada nó não primário do conjunto.
Conecte
mongosh
ao primário e reduza o primário utilizando o métodors.stepDown()
:rs.stepDown() O conjunto de réplicas elege outro nó para se tornar primário.
Quando a redução for bem-sucedida, encerre o primário antigo.
Inicie a instância do
mongod
que se tornará o novo primário no novo local.Conecte-se ao primário atual, que acabou de ser eleito, e atualize o documento de configuração do conjunto de réplicas com o nome de host do nó que deve se tornar o novo primário.
Por exemplo, se o primário antigo estivesse na posição
0
e o nome do host do novo primário fossemongodb0.example.net:27017
, você executaria:cfg = rs.conf() cfg.members[0].host = "mongodb0.example.net:27017" rs.reconfig(cfg) Conecte o
mongosh
ao novo primário.Para confirmar a nova configuração, chame
rs.conf()
emmongosh
.Seu resultado deve ser semelhante:
{ "_id" : "rs", "version" : 4, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017" }, { "_id" : 1, "host" : "mongodb1.example.net:27017" }, { "_id" : 2, "host" : "mongodb2.example.net:27017" } ] }
Alterar todos os nomes de host ao mesmo tempo
Esse procedimento usa as suposiçõesacima.
Pré-requisitos
O procedimento a seguir lê e atualiza a coleção system.replset
no banco de dados local
.
Se a sua implementação impõe controle de acesso, o usuário que executa o procedimento deve ter ações de privilégio find
e update
na coleção system.replset
.
Para criar uma função que forneça os privilégios necessários:
Faça login como um usuário com privilégios para gerenciar usuários e funções, como um usuário com a função
userAdminAnyDatabase
. O procedimento a seguir usa omyUserAdmin
criado em Habilitar controle de acesso em implementações autogerenciadas.mongosh --port 27017 -u myUserAdmin --authenticationDatabase 'admin' -p Crie uma função de usuário que forneça os privilégios necessários na coleção do
system.replset
no banco de dados dolocal
:db.adminCommand( { createRole: "systemreplsetRole", privileges: [ { resource: { db: "local", collection: "system.replset" }, actions: ["find","update"] } ], roles: [] } ); Conceda a função ao usuário que executará o procedimento de renomeação. Por exemplo, o seguinte pressupõe um usuário existente
"userPerformingRename"
no banco de dadosadmin
.use admin db.grantRolesToUser( "userPerformingRename", [ { role: "systemreplsetRole", db: "admin" } ] );
Procedimento
Pare todos os nós no conjunto de réplicas.
Reinicie cada nó em uma porta diferente e sem utilizar a opção de tempo de execução do
--replSet
. Alterar o número da porta durante a manutenção impede que os clientes se conectem a esse host enquanto você executa a manutenção. Utilize o--dbpath
usual do nó, que neste exemplo é/data/db1
. Use um comando semelhante ao seguinte:Aviso
Antes de vincular a um não localhost (por exemplo, acessível IP ), certifique-se de ter protegido seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte a Lista de verificação de segurança para implementações autogerenciadas. No mínimo, procure habilitar a autenticação e fortalecer a infraestrutura de rede.
mongod --dbpath /data/db1/ --port 37017 --bind_ip localhost,<hostname(s)|ip address(es)> Importante
Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.
Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.
Para cada nó do conjunto de réplicas, execute a seguinte sequência de operações:
Conecte o
mongosh
aomongod
executando na nova porta temporária. Por exemplo, para um nó executando em uma porta temporária do37017
, você iria emitir este comando:mongosh --port 37017 Se estiver executando com controle de acesso, conecte-se como um usuário com privilégios apropriados. Consulte Pré-requisitos.
mongosh --port 37017 -u userPerformingRename --authenticationDatabase=admin -p Edite a configuração do conjunto de réplicas manualmente. A configuração do conjunto de réplicas é o único documento na coleção
system.replset
no banco de dadoslocal
.Para alterar os nomes de host, edite a configuração do conjunto de réplicas para fornecer os novos nomes de host e portas para todos os membros do conjunto de réplicas.
Mudar para o banco de dados
local
.use local Crie uma variável JavaScript para o documento de configuração. Modifique o valor do campo
_id
para corresponder ao seu conjunto de réplicas.cfg = db.system.replset.findOne( { "_id": "rs0" } ) Forneça novos nomes de host e portas para cada membro do conjunto de réplicas. Modifique os nomes de host e as portas para que correspondam ao seu conjunto de réplicas.
cfg.members[0].host = "mongodb0.example.net:27017" cfg.members[1].host = "mongodb1.example.net:27017" cfg.members[2].host = "mongodb2.example.net:27017" Atualize os nomes de host e portas na coleção
system.replset
:db.system.replset.updateOne( { "_id": "rs0" }, { $set: cfg } ) Verifique as alterações:
db.system.replset.find( {}, { "members.host": 1 } )
Pare o processo
mongod
no nó.
Depois de reconfigurar todos os nós do conjunto, inicie cada instância
mongod
da maneira normal: use o número de porta usual e a opção--replSet
. Por exemplo:Aviso
Antes de vincular a um não localhost (por exemplo, acessível IP ), certifique-se de ter protegido seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte a Lista de verificação de segurança para implementações autogerenciadas. No mínimo, procure habilitar a autenticação e fortalecer a infraestrutura de rede.
mongod --dbpath /data/db1/ --port 27017 --replSet rs0 --bind_ip localhost,<hostname(s)|ip address(es)> Conecte-se a uma das instâncias do
mongod
utilizando omongosh
. Por exemplo:mongosh --port 27017 Para confirmar a nova configuração, chame
rs.conf()
emmongosh
.Seu resultado deve ser semelhante:
{ "_id" : "rs0", "version" : 4, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017" }, { "_id" : 1, "host" : "mongodb1.example.net:27017" }, { "_id" : 2, "host" : "mongodb2.example.net:27017" } ] }