Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Sistemas autogerenciados
/
Administração
/
Métodos de backup
/
Restaurar clusters fragmentados

Restaurar um cluster fragmentado autogerenciado

Nesta página

Esse procedimento restaura um cluster fragmentado a partir de um snapshot de backup existente, como snapshots do Logical Volume Manager (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ância mongod rola as chaves de banco de dados configuradas com AES256-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 sendo executado corretamente e estiver acessível, conecte um mongo shell ao membro do conjunto de réplicas primário em cada conjunto de réplicas. Em seguida, execute para visualizar o documento de configuração da rs.conf() 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 ou mongos no host de destino.

Para hosts que executam omongos, conecte um shell mongo ao mongos e execute db.shutdownServer() a partir do banco de dados admin:

use admin
db.shutdownServer()

Para hosts executando um mongod, conecte uma shell do mongo no mongod e execute db.hello():

  • Se isWritablePrimary for falso, o mongod será um membro secundário de um conjunto de réplica. Você pode encerrá-lo executando db.shutdownServer() no banco de dados admin .

  • Se isWritablePrimary for verdadeiro, o mongod será o nó primary de um conjunto de réplicas. Encerre primeiro os nós secundários do conjunto de réplicas. Utilize o rs.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() retorna isWritablePrimary: false), você pode fechar o mongod 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 o mongod 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 preferido

  • net.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

1

Restaure os mongod arquivos de dados primary do CSRS.

Selecione a guia que corresponde ao seu método de backup preferido:

  1. 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.

  2. 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.

  3. 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 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.

  1. 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.

  2. 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.

  3. Comente ou omita as seguintes definições do arquivo de configuração:

    #replication
    #  replSetName: myCSRSName
    #sharding
    #  clusterRole: configsvr

  4. 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 shell mongo.

2

Solte o local banco de dados.

Utilize o db.dropDatabase() para soltar o banco de dados do local:

use local
db.dropDatabase()
3

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>.

4

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.

5

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.

6

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.

7

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

1

Restaure os arquivos de mongod dados primários do shard.

Selecione a guia que corresponde ao seu método de backup preferido:

  1. 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.

  2. 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.

  3. 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 shell mongo.

  1. 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.

  2. 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.

  3. Comente ou omita as seguintes definições do arquivo de configuração:

    #replication
    #  replSetName: myShardName
    #sharding
    #  clusterRole: shardsvr

  4. 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 shell mongo.

2

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.

  1. Autentique-se como um usuário com a função userAdmin no banco de dados admin ou a função userAdminAnyDatabase:

    use admin
    db.auth("myUserAdmin","mySecurePassword")

  2. 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.

  3. Autenticar como usuário privilegiado:

    db.auth("mySystemUser","<replaceMeWithAStrongPassword>")
3

Solte o local banco de dados.

Utilize o db.dropDatabase() para soltar o banco de dados do local:

use local
db.dropDatabase()
4

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.

5

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.

6

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.

7

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.

8

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.

9

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.

10

Remova o usuário privilegiado temporário.

Para clusters que aplicam autenticação, remova o usuário privilegiado criado anteriormente neste procedimento:

  1. Autentique-se como um usuário com a função userAdmin no banco de dados admin ou a função userAdminAnyDatabase:

    use admin
    db.auth("myUserAdmin","mySecurePassword")

  2. 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 partes não é executada. Isso se deve às melhorias no balanceamento das políticas. Os comandos de divisão automática ainda existem, mas não executam uma operação. Para obter detalhes, consulte Alterações na política de balanceamento.Nas versões do MongoDB anteriores à 6.0.3, sh.startBalancer() também ativa a divisão automática do cluster fragmentado.

Voltar

Agendamento de backups

Próximo

Recuperar standalone