Restaurar um cluster fragmentado autogerenciado
Nesta página
Esse procedimento restaura um cluster fragmentado a partir de um snapshot de backup existente, como snapshots LVM. O cluster fragmentado de origem e destino deve ter o mesmo número de shards. Para obter informações sobre como criar snapshots LVM para todos os componentes de um cluster fragmentado, consulte Fazer backup de um cluster fragmentado autogerenciado com snapshots do sistema de arquivos.
Observação
Para usar mongodump
e mongorestore
como uma estratégia de backup para clusters fragmentados, consulte Fazer backup de um cluster fragmentado autogerenciado com um despejo de banco de dados.
Os clusters fragmentados também podem usar um dos seguintes processos coordenados de backup e restauração, que mantêm as garantias de atomicidade das transações entre shards:
Considerações
Para mecanismos de armazenamento criptografado que usam o modo de criptografia AES256-GCM
, AES256-GCM
exige que cada processo use um valor de bloco de contador exclusivo com a chave.
Para mecanismo de armazenamento criptografado configurado com cifra AES256-GCM
:
- Restauração a partir de um hot backup
- A partir da versão 4.2, se você restaurar a partir de arquivos obtidos via backup "quente" (ou seja, o
mongod
está em execução), o MongoDB pode detectar chaves "sujas" na inicialização e rolar automaticamente a chave do banco de dados para evitar a reutilização IV (Initialization Vector).
- Restaurando a partir do Cold Backup
No entanto, se você restaurar a partir de arquivos obtidos via backup "frio" (ou seja, o
mongod
não está em execução), o MongoDB não poderá detectar chaves "sujas" na inicialização, e a reutilização do IV anulará as garantias de confidencialidade e integridade.A partir do 4,2, para evitar a reutilização das chaves após restaurar de um snapshot de sistema de arquivos frio, o MongoDB adiciona uma nova opção de linha de comando
--eseDatabaseKeyRollover
. Quando iniciada com a opção--eseDatabaseKeyRollover
, a instânciamongod
rola as chaves de banco de dados configuradas comAES256-GCM
cifra e sai.
A. (Opcional) Revise as configurações do conjunto de réplicas
Este procedimento inicia um novo conjunto de réplicas para o Config Server Replica Set (CSRS) e cada conjunto de réplicas de shard usando a configuração padrão. Para usar uma configuração de conjunto de réplicas diferente para seus CSRS e shards restaurados, você deve reconfigurar o (s) conjunto (s) de réplicas.
Se o cluster de origem estiver íntegro e acessível, conecte um shell mongo
ao membro do conjunto de réplicas primário em cada conjunto de réplicas e execute rs.conf()
para exibir o documento de configuração da réplica.
Se você não conseguir acessar um ou mais componentes do cluster fragmentado de origem, consulte qualquer documentação interna existente para reconstruir os requisitos de configuração para cada conjunto de réplicas de shard e o conjunto de réplicas do servidor de configuração.
B. Prepare o host alvo para restauração
- Requisitos de espaço de armazenamento
- Garanta que o hardware do host de destino tenha espaço de armazenamento aberto suficiente para os dados restaurados. Se o host de destino contiver dados de cluster fragmentados existentes que você deseja manter, verifique se você tem espaço de armazenamento suficiente para os dados existentes e os dados restaurados.
- Requisitos do LVM
- Para snapshots LVM, você deve ter pelo menos um grupo de volumes gerenciados LVM e um volume lógico com espaço livre suficiente para os dados extraídos do snapshot.
- Requisitos da versão do MongoDB
Certifique-se de que o host de destino e o host de origem tenham a mesma versão do MongoDB Server. Para verificar a versão do MongoDB disponível em uma máquina host, execute o
mongod --version
a partir do terminal ou shell.Para obter a documentação completa sobre a instalação, consulte Instalar MongoDB.
- Encerrar os processos do MongoDB em execução
Se estiver restaurando em um cluster existente, desligue o processo
mongod
oumongos
no host de destino.Para hosts que executam o
mongos
, conecte um shellmongo
aomongos
e executedb.shutdownServer()
a partir do banco de dadosadmin
:use admin db.shutdownServer() Para hosts executando um
mongod
, conecte uma shell domongo
nomongod
e executedb.hello()
:Se
isWritablePrimary
for falso, omongod
será um membro secundário de um conjunto de réplica. Você pode encerrá-lo executandodb.shutdownServer()
no banco de dadosadmin
.Se
isWritablePrimary
for verdadeiro, omongod
será o nó primary de um conjunto de réplicas. Encerre primeiro os nós secundários do conjunto de réplicas. Utilize ors.status()
para identificar os outros nós do conjunto de réplicas.O primário desiste automaticamente após detectar que a maioria dos membros está offline. Depois que ele descer(
db.hello()
retornaisWritablePrimary: false
), você pode fechar omongod
com segurança.
- Preparar diretório de dados
Crie um diretório no host de destino para os arquivos do banco de dados restaurados. Verifique se o usuário que executa o
mongod
tem permissões de leitura, gravação e execução para todos os arquivos e subpastas neste diretório:sudo mkdir /path/to/mongodb sudo chown -R mongodb:mongodb /path/to/mongodb sudo chmod -R 770 /path/to/mongodb Substitua o
/path/to/mongodb
pelo caminho para o diretório de dados que você criou. No RHEL / CentOS, Amazon Linux e SUSE, o nome de usuário padrão émongod
.- Preparar diretório de registro
Crie um diretório no host de destino para os arquivos de registro do
mongod
. Certifique-se de que o usuário que executa omongod
tenha permissões de leitura, gravação e execução para todos os arquivos e subpastas desse diretório:sudo mkdir /path/to/mongodb/logs sudo chown -R mongodb:mongodb /path/to/mongodb/logs sudo chmod -R 770 /path/to/mongodb/logs Substitua
/path/to/mongodb/logs
pelo caminho para o diretório de registro que você criou. Em RHEL / CentOS, Amazon Linux e SUSE, o nome de usuário padrão émongod
.- Criar arquivo de configuração
Este procedimento pressupõe iniciar um
mongod
com um arquivo de configuração.Crie o arquivo de configuração no local de sua preferência. Certifique-se de que o usuário que executa o
mongod
tenha permissões de leitura e gravação no arquivo de configuração:sudo touch /path/to/mongod.conf sudo chown mongodb:mongodb /path/to/mongodb/mongod.conf sudo chmod 644 /path/to/mongodb/mongod.conf Em RHEL / CentOS, Amazon Linux e SUSE, o nome de usuário padrão é
mongod
.Abra o arquivo de configuração no editor de texto de sua preferência e modifique-o conforme exigido pelo seu sistema. Como alternativa, se você tiver acesso ao arquivo de configuração original do
mongod
, copie-o para o local de sua preferência no host de destino.Importante
Valide que seu arquivo de configuração inclui as seguintes configurações:
storage.dbPath
deve ser definido para o caminho para o diretório de dados de sua preferência.systemLog.path
deve ser definido como o caminho para seu diretório de registro preferidonet.bindIp
deve incluir o endereço IP da máquina host.replication.replSetName
tem o mesmo valor em cada membro em qualquer conjunto de réplicas.sharding.clusterRole
tem o mesmo valor em cada membro em qualquer conjunto de réplicas.Você também deve especificar as mesmas opções de inicialização para sua nova implantação que foram especificadas no snapshot.
C. Restaurar conjunto de réplicas do servidor de configuração
Restaure os mongod
arquivos de dados primary do CSRS.
Selecione a guia que corresponde ao seu método de backup preferido:
Monte o snapshot LVM na máquina host de destino. As etapas específicas para montar um snapshot LVM dependem da sua configuração de LVM.
O exemplo abaixo pressupõe um snapshot LVM criado usando a etapa Criar um snapshot no procedimento Backup e restaurar um sistema autogerenciado com snapshots de sistemas de arquivos .
lvcreate --size 250GB --name mongod-datafiles-snapshot vg0 gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb Este exemplo pode não ser aplicado a todas as possíveis configurações de LVM. Consulte a documentação de LVM do seu sistema para obter mais orientações sobre a restauração de LVM.
Copie os arquivos de dados
mongod
da montagem do snapshot para o diretório de dados criado em B. Prepare the Target Host for Restoration:cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb A opção
-a
copia recursivamente o conteúdo do caminho de origem para o caminho de destino enquanto preserva as permissões de pasta e arquivo.Comente ou omita as seguintes definições do arquivo de configuração:
#replication # replSetName: myCSRSName #sharding # clusterRole: configsvr Para iniciar o
mongod
usando um arquivo de configuração, especifique a opção--config
na linha de comando, indicando o caminho completo do arquivo de configuração.mongod --config /path/to/mongodb/mongod.conf Se estiver restaurando de um snapshot filtrado por namespace, especifique a opção
--restore
.mongod --config /path/to/mongod/mongod.conf --restore Se
mongod
estiver configurado para ser executado como um serviço do sistema, inicie-o usando o processo recomendado para o gerenciador de serviços do sistema.Após o
mongod
iniciar, conecte-se a ele utilizando a shellmongo
.
Torne os arquivos de dados armazenados na mídia de backup selecionada acessíveis no host. Isso pode exigir a montagem do volume de backup, a abertura do backup em um utilitário de software ou o uso de outra ferramenta para extrair os dados para o disco. Consulte a documentação da ferramenta de backup de sua preferência para obter instruções sobre como acessar os dados contidos no backup.
Copie os arquivos de dados
mongod
do local dos dados da cópia de segurança para o diretório de dados de dados criado em B. Prepare the Target Host for Restoration:cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb A opção
-a
copia recursivamente o conteúdo do caminho de origem para o caminho de destino enquanto preserva as permissões de pasta e arquivo.Comente ou omita as seguintes definições do arquivo de configuração:
#replication # replSetName: myCSRSName #sharding # clusterRole: configsvr Para iniciar o
mongod
usando um arquivo de configuração, especifique a opção--config
na linha de comando, indicando o caminho completo do arquivo de configuração.mongod --config /path/to/mongodb/mongod.conf Se estiver restaurando de um snapshot filtrado por namespace , especifique também a opção
--restore
.mongod --config /path/to/mongod/mongod.conf --restore Observação
Somente Cloud Manager ou MongoDB Ops Manager
Se estiver executando uma restauração manual de um backup do Cloud Manager ou MongoDB Ops Manager , você deverá especificar o parâmetro de servidor
disableLogicalSessionCacheRefresh
antes da inicialização.mongod --config /path/to/mongodb/mongod.conf \ --setParameter disableLogicalSessionCacheRefresh=true Se
mongod
estiver configurado para ser executado como um serviço do sistema, inicie-o usando o processo recomendado para o gerenciador de serviços do sistema.Após o
mongod
iniciar, conecte-se a ele utilizando a shellmongo
.
Solte o local
banco de banco de dados .
Utilize o db.dropDatabase()
para soltar o banco de dados do local
:
use local db.dropDatabase()
Insira a lista de arquivos filtrados no banco de dados local.
Essa etapa só é necessária se você estiver restaurando a partir de um snapshot filtrado por namespace.
Para cada shard, localize a lista de arquivos filtrados com o seguinte formato de nome: <shardRsID>-filteredFileList.txt
. Este arquivo contém uma lista de objetos JSON com o seguinte formato:
{ "filename":"file1", "ns":"sampleDb1.sampleCollection1", "uuid": "3b241101-e2bb-4255-8caf-4136c566a962" }
Adicione cada objeto JSON de cada arquivo fragmentado a uma nova coleção db.systems.collections_to_restore
no seu banco de dados local
. Você pode ignorar entradas com campos ns
ou uuid
vazios. Ao inserir entradas, o campo uuid
deve ser inserido como tipo UUID()
.
Para qualquer alteração planejada ou concluída do nome do hostname do shard ou do nome do conjunto de réplicas, atualize os metadados em config.shards
.
Você pode pular esta etapa se todos os itens a seguir forem verdadeiros:
Nenhum nome de host da máquina host membro do shard foi ou será alterado durante este procedimento.
Nenhum nome de conjunto de réplicas de shards foi ou será alterado durante este procedimento.
Emita o seguinte método find()
na collection shards
no banco de dados de configuração. Substitua <shardName>
pelo nome do shard. Por padrão, o nome do shard é o nome do conjunto de réplicas. Se você adicionou o shard utilizando o comando addShard
e especificou um name
personalizado, você deverá especificar name
a <shardName>
.
use config db.shards.find( { "_id" : "<shardName>" } )
Esta operação retorna um documento semelhante ao seguinte:
{ "_id" : "shard1", "host" : "myShardName/alpha.example.net:27018,beta.example.net:27018,charlie.example.net:27018", "state" : 1 }
Importante
O valor _id
deve corresponder ao valor shardName
no documento _id : "shardIdentity"
no shard correspondente. Ao restaurar os shards mais tarde neste procedimento, valide que o campo _id
em shards
corresponde ao valor shardName
no shard.
Utilize o método updateOne()
para atualizar a string hosts
para refletir o nome do conjunto de réplicas planejado e lista de nome do host para o shard. Por exemplo, a seguinte operação atualiza a connection string do host
para o shard com "_id" : "shard1"
:
db.shards.updateOne( { "_id" : "shard1" }, { $set : { "host" : "myNewShardName/repl1.example.net:27018,repl2.example.net:27018,repl3.example.net:27018" } } )
Repita o processo até que todos os metadados do shard representam com precisão o nome do conjunto de réplicas planejado e a lista de nomes de host para cada shard no cluster.
Observação
Se você não souber o nome do shard, emita o método find()
na coleção shards
com um documento de filtro vazio {}
:
use config db.shards.find({})
Cada documento no conjunto de resultados representa um shard no cluster. Para cada documento, verifique no campo host
uma connection string que corresponda ao shard em questão, ou seja, um nome de conjunto de réplicas correspondente e uma lista de nomes de host de membros. Use o _id
desse documento no lugar de <shardName>
.
Reinicie o como um novo conjunto de réplicas de nó mongod
único.
Desligue o mongod
. Descomente ou adicione as seguintes opções de arquivo de configuração:
replication replSetName: myNewCSRSName sharding clusterRole: configsvr
Se você deseja alterar o nome do conjunto de réplica, você deverá atualizar o campo replSetName
com o novo nome antes de continuar.
Inicie o mongod
com o arquivo de configuração atualizado:
mongod --config /path/to/mongodb/mongod.conf
Se mongod
estiver configurado para ser executado como um serviço do sistema, inicie-o usando o processo recomendado para o gerenciador de serviços do sistema.
Após o mongod
iniciar, conecte-se a ele utilizando a shell mongo
.
Inicie o novo conjunto de réplicas.
Inicie o conjunto de réplicas utilizando rs.initiate()
com as configurações padrão.
rs.initiate()
Quando a operação for concluída, use rs.status()
para verificar se o membro se tornou o principal.
Adicione mais nós de conjuntos de réplicas.
Para cada nó do conjunto de réplicas no CSRS, inicie o mongod
em sua máquina host. Depois de iniciar todos os nós restantes do cluster, conecte um shell mongo
ao nó primary do conjunto de réplicas. A partir do primary, utilize o método rs.add()
para adicionar cada nó do conjunto de réplicas. Inclua o nome do conjunto de réplicas como prefixo, seguido pelo nome do host e pela porta do processo mongod
do nó:
rs.add("config2.example.net:27019") rs.add("config3.example.net:27019")
Se quiser adicionar o membro com definições específicas de configuração de réplica member
, você pode passar um documento para rs.add()
que defina o nome de host do membro e quaisquer configurações members
que seu sistema exija.
rs.add( { "host" : "config2.example.net:27019", priority: <int>, votes: <int>, tags: <int> } )
Cada novo nó executa uma sincronização inicial para alcançar o primary. Dependendo de fatores como a quantidade de dados a serem sincronizados, a topologia e saúde de sua rede e o poder de cada máquina host, a sincronização inicial pode levar bastante tempo para ser concluída.
O conjunto de réplicas pode eleger um novo primário enquanto você adiciona membros adicionais. Utilize o rs.status()
para identificar qual membro é o principal atual. Você só pode executar rs.add()
no primário.
Defina todas as configurações adicionais de replicação necessárias.
O método rs.reconfig()
atualiza a configuração do conjunto de réplicas baseado em um documento de configuração passado como um parâmetro. Você deve executar reconfig()
em relação ao membro principal do conjunto de réplicas.
Consulte a saída do arquivo de configuração original do conjunto de réplicas conforme identificado na etapa A. Review Replica Set Configurations e aplique as configurações conforme necessário.
D. Restaurar cada conjunto de réplicas de shard
Restaure os arquivos de mongod
dados primários do shard.
Selecione a guia que corresponde ao seu método de backup preferido:
Monte o snapshot LVM na máquina host de destino. As etapas específicas para montar um snapshot LVM dependem da sua configuração de LVM.
O exemplo abaixo pressupõe um snapshot LVM criado usando a etapa Criar um snapshot no procedimento Backup e restaurar um sistema autogerenciado com snapshots de sistemas de arquivos .
lvcreate --size 250GB --name mongod-datafiles-snapshot vg0 gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb Este exemplo pode não ser aplicado a todas as possíveis configurações de LVM. Consulte a documentação de LVM do seu sistema para obter mais orientações sobre a restauração de LVM.
Copie os ficheiros de dados
mongod
da montagem do snapshot para o diretório de dados criado em B. Prepare the Target Host for Restoration:cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb A opção
-a
copia recursivamente o conteúdo do caminho de origem para o caminho de destino enquanto preserva as permissões de pasta e arquivo.Comente ou omita as seguintes definições do arquivo de configuração:
#replication # replSetName: myShardName #sharding # clusterRole: shardsvr Para iniciar o
mongod
usando um arquivo de configuração, especifique a opção--config
na linha de comando, indicando o caminho completo do arquivo de configuração:mongod --config /path/to/mongodb/mongod.conf Se
mongod
estiver configurado para ser executado como um serviço do sistema, inicie-o usando o processo recomendado para o gerenciador de serviços do sistema.Após o
mongod
iniciar, conecte-se a ele utilizando a shellmongo
.
Torne os arquivos de dados armazenados na mídia de backup selecionada acessíveis no host. Isso pode exigir a montagem do volume de backup, a abertura do backup em um utilitário de software ou o uso de outra ferramenta para extrair os dados para o disco. Consulte a documentação da ferramenta de backup de sua preferência para obter instruções sobre como acessar os dados contidos no backup.
Copie os arquivos de dados
mongod
do local dos dados da cópia de segurança para o diretório de dados de dados criado em B. Prepare the Target Host for Restoration:cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb A opção
-a
copia recursivamente o conteúdo do caminho de origem para o caminho de destino enquanto preserva as permissões de pasta e arquivo.Comente ou omita as seguintes definições do arquivo de configuração:
#replication # replSetName: myShardName #sharding # clusterRole: shardsvr Para iniciar o
mongod
usando um arquivo de configuração, especifique a opção--config
na linha de comando, indicando o caminho completo do arquivo de configuração:mongod --config /path/to/mongodb/mongod.conf Observação
Somente Cloud Manager ou MongoDB Ops Manager
Se estiver executando uma restauração manual de um backup do Cloud Manager ou MongoDB Ops Manager , você deverá especificar o parâmetro de servidor
disableLogicalSessionCacheRefresh
antes da inicialização:mongod --config /path/to/mongodb/mongod.conf \ --setParameter disableLogicalSessionCacheRefresh=true Se
mongod
estiver configurado para ser executado como um serviço do sistema, inicie-o usando o processo recomendado para o gerenciador de serviços do sistema.Após o
mongod
iniciar, conecte-se a ele utilizando a shellmongo
.
Crie um usuário temporário com a __system
função .
Durante este procedimento você modificará documentos na coleção admin.system.version
. Para clusters que impõem autenticação, somente o papel __system
concede permissão para modificar esta coleção. Você poderá pular esta etapa se o cluster não impor a autenticação.
Aviso
O papel do __system
dá ao seu titular o direito de tomar qualquer ação contra qualquer objeto do banco de dados. Este procedimento inclui instruções para remover o usuário criado nesta etapa. Não mantenha este usuário ativo além do escopo deste procedimento.
Considere criar este usuário com a restrição de autenticação do clientSource
configurada de forma que somente os hosts especificados possam autenticar como o usuário privilegiado.
Autentique-se como um usuário com a função
userAdmin
no banco de dadosadmin
ou a funçãouserAdminAnyDatabase
:use admin db.auth("myUserAdmin","mySecurePassword") Crie um usuário com a role
__system
:db.createUser( { user: "mySystemUser", pwd: "<replaceMeWithAStrongPassword>", roles: [ "__system" ] } ) As senhas devem ser aleatórias, longas e complexas para garantir a segurança do sistema e evitar ou atrasar o acesso malicioso.
Autenticar como usuário privilegiado:
db.auth("mySystemUser","<replaceMeWithAStrongPassword>")
Solte o local
banco de banco de dados .
Utilize o db.dropDatabase()
para soltar o banco de dados do local
:
use local db.dropDatabase()
Remova o minOpTimeRecovery
documento da admin.system.versions
collection .
Para atualizar os componentes internos de sharding, execute o seguinte método deleteOne()
na coleção system.version
do banco de dados admin
:
use admin db.system.version.deleteOne( { _id: "minOpTimeRecovery" } )
Observação
A coleção system.version
é uma coleção interna do sistema. Você só deve modificá-lo quando receber instruções específicas como essas.
Opcional: para qualquer alteração no nome do host CSRS ou no nome do conjunto de réplicas, atualize os metadados do shard no documento de identidade de cada shard.
Você pode pular esta etapa se todos os itens a seguir forem verdadeiros:
Os nomes de host de qualquer host CSRS não foram alterados durante este procedimento.
O nome do conjunto de réplicas CSRS não foi alterado durante este procedimento.
A coleção system.version
no banco de dados do admin
contém metadados relacionados ao shard, incluindo a connection string CSRS. Se o nome do CSRS ou qualquer nome de host do membro for alterado durante a restauração do CSRS, você deverá atualizar esses metadados.
Emita o seguinte método find()
na coleção system.version
no banco de dados admin
:
use admin db.system.version.find( {"_id" : "shardIdentity" } )
O método find()
retorna um documento semelhante ao seguinte:
{ "_id" : "shardIdentity", "clusterId" : ObjectId("2bba123c6eeedcd192b19024"), "shardName" : "shard1", "configsvrConnectionString" : "myCSRSName/alpha.example.net:27019,beta.example.net:27019,charlie.example.net:27019" }
O seguinte método do updateOne()
atualiza o documento de forma que a string do host
represente a connection string CSRS mais atual:
db.system.version.updateOne( { "_id" : "shardIdentity" }, { $set : { "configsvrConnectionString" : "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"} } )
Importante
O valor shardName
deve corresponder ao valor _id
na coleção shards
no CSRS. Valide que os metadados no CSRS correspondem aos metadados do shard. Consulte a subetapa 3 na parte C. Restore Config Server Replica Set deste procedimento para obter instruções sobre como visualizar os metadados do CSRS.
Reinicie o como um novo conjunto de réplicas de nó mongod
único.
Desligue o mongod
. Descomente ou adicione as seguintes opções de arquivo de configuração:
replication replSetName: myNewShardName sharding clusterRole: shardsvr
Se você deseja alterar o nome do conjunto de réplica, você deverá atualizar o campo replSetName
com o novo nome antes de continuar.
Inicie o mongod
com o arquivo de configuração atualizado:
mongod --config /path/to/mongodb/mongod.conf
Se mongod
estiver configurado para ser executado como um serviço do sistema, inicie-o usando o processo recomendado para o gerenciador de serviços do sistema.
Após o mongod
iniciar, conecte-se a ele utilizando a shell mongo
.
Inicie o novo conjunto de réplicas.
Inicie o conjunto de réplicas utilizando rs.initiate()
com as configurações padrão.
rs.initiate()
Quando a operação for concluída, use rs.status()
para verificar se o membro se tornou o principal.
Adicione mais nós de conjuntos de réplicas.
Para cada membro do conjunto de réplicas no conjunto de réplicas fragmentadas, inicie o mongod
em sua máquina host. Depois de iniciar todos os membros restantes do cluster com sucesso, conecte um shell mongo
ao membro primário do conjunto de réplicas. No primário, use o método rs.add()
para adicionar cada membro do conjunto de réplicas. Inclua o nome do conjunto de réplicas como prefixo, seguido pelo nome do host e pela porta do processo de mongod
do membro:
rs.add("repl2.example.net:27018") rs.add("repl3.example.net:27018")
Se quiser adicionar o membro com definições específicas de configuração de réplica member
, você pode passar um documento para rs.add()
que defina o nome de host do membro e quaisquer configurações members
que seu sistema exija.
rs.add( { "host" : "repl2.example.net:27018", priority: <int>, votes: <int>, tags: <int> } )
Cada novo nó executa uma sincronização inicial para alcançar o primary. Dependendo de fatores como a quantidade de dados a serem sincronizados, a topologia e saúde de sua rede e o poder de cada máquina host, a sincronização inicial pode levar bastante tempo para ser concluída.
O conjunto de réplicas pode eleger um novo primário enquanto você adiciona membros adicionais. Utilize o rs.status()
para identificar qual membro é o principal atual. Você só pode executar rs.add()
no primário.
Defina todas as configurações adicionais de replicação necessárias.
O método rs.reconfig()
atualiza a configuração do conjunto de réplicas baseado em um documento de configuração passado como um parâmetro. Você deve executar reconfig()
em relação ao membro principal do conjunto de réplicas.
Consulte a saída do arquivo de configuração original do conjunto de réplicas conforme identificado na etapa A. Review Replica Set Configurations e aplique as configurações conforme necessário.
Remova o usuário privilegiado temporário.
Para clusters que aplicam autenticação, remova o usuário privilegiado criado anteriormente neste procedimento:
Autentique-se como um usuário com a função
userAdmin
no banco de dadosadmin
ou a funçãouserAdminAnyDatabase
:use admin db.auth("myUserAdmin","mySecurePassword") Excluir o usuário privilegiado:
db.removeUser("mySystemUser")
E. Reiniciar cada mongos
Reinicie cada mongos
no cluster.
mongos --config /path/to/config/mongos.conf
Inclua todas as outras opções de linha de comando conforme exigido pelo seu sistema.
Se o nome do conjunto de réplicas CSRS ou qualquer nome de host membro for alterado, atualize a mongos
de definição do arquivo de configuração com sharding.configDB
a connection string atualizada do servidor de configuração:
sharding: configDB: "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"
F. Validar acessibilidade do cluster
Conecte uma shell do mongo
a um dos processos do mongos
para o cluster. Utilize o sh.status()
para verificar o status geral do cluster. Se sh.status()
indicar que o balancer não está em execução, use sh.startBalancer()
para reiniciá-lo. [1]
Para confirmar que todos os shards estão acessíveis e comunicados, insira os dados de teste em uma coleção fragmentada temporária. Confirme se os dados estão sendo divididos e migrados entre cada shard em seu cluster. Você pode conectar uma shell mongo
a cada shard primário e usar db.collection.find()
para validar se os dados foram fragmentados como esperado.
[1] | A partir do MongoDB 6.0.3, a divisão automática de chunks não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação. Nas versões do MongoDB anteriores a 6.0.3, sh.startBalancer() também permite a divisão automática para o cluster fragmentado. |