Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / / /

Alterar um conjunto de réplicas autogerenciadas para WiredTiger

Observação

  • As opções noPadding e usePowerOf2Sizes MMAPv1 para o comando collMod são removidas.

  • Você deve atualizar para o WiredTiger. O MongoDB removeu o storage engine obsoleto MMAPv1 na versão 4.2.

Use este tutorial para atualizar um conjunto de réplicas para usar o WiredTiger. O procedimento atualiza o conjunto de réplicas de forma contínua para evitar tempo de inatividade.

Os conjuntos de réplicas podem ter membros com diferentes mecanismos de armazenamento. Dessa forma, você pode atualizar os membros para usar o mecanismo de armazenamento WiredTiger de forma contínua.

A referência de leitura "majority", disponível para o WiredTiger, está habilitada por padrão. No entanto, em conjuntos de réplicas de três nós com uma arquitetura primário-secundário-árbitro (PSA), você pode desabilitar a referência de leitura "majority". A desativação da referência de leitura "majority" para uma arquitetura PSA de três nós evita o possível aumento da pressão de cache.

Oprocedimento abaixo desativa a read concern "majority" para a arquitetura PSA ao incluir --enableMajorityReadConcern false.

Observação

A desativação da referência de leitura do "majority" não tem efeito na disponibilidade de fluxos de alterações.

Para obter mais informações sobre a arquitetura PSA e a referência de leitura "majority", consulte Conjuntos de réplicas primário-secundário-árbitro.

Binários do MongoDB, mongod e mongos, ligam-se ao localhost por padrão.

Com o mecanismo de armazenamento WiredTiger, é recomendado usar XFS para nós que contêm dados no Linux. Para obter mais informações, consulte Kernel e sistemas de arquivos.

Após a atualização para o WiredTiger, seu sistema do WiredTiger não estará sujeita às seguintes restrições somente do MMAPv1:

Restrições do MMAPv1
Descrição curta
Número de spacenames
Para MMAPv1, o número de spacenames é limitado ao tamanho do arquivo de spacenames dividido por 628.
Tamanho do arquivo de namespace
Para MMAPv1, os arquivos namespace não podem ser maiores que 2047 megabytes.
Tamanho do Banco de Dados
O mecanismo de armazenamento MMAPv1 limita cada banco de dados a no máximo 16000 arquivos de dados.
tamanho de dados
Para MMAPv1, uma única instância do mongod não pode gerenciar um conjunto de dados que exceda o espaço de endereço de memória virtual máximo fornecido pelo sistema operacional subjacente.
Número de Coleções em um Banco de Dados
Para o mecanismo de armazenamento MMAPv1, o número máximo de coleções em um banco de dados é uma função do tamanho do arquivo namespace e o número de índices de coleções no banco de dados.

O procedimento a seguir atualiza o conjunto de réplicas de forma contínua. O procedimento atualiza primeiro os nós secundários, depois reduz o primário e atualiza o nó desativado.

Para atualizar um nó para o WiredTiger, o procedimento remove os dados de um nó, inicia mongod com o WiredTiger e executa uma sincronização inicial.

Atualize os nós secundários um de cada vez:

1

Em mongosh, encerre o secundário.

use admin
db.shutdownServer()
2

Prepare um diretório de dados para a nova instância do mongod que será executada com o storage engine do WiredTiger. mongod deve ter permissões de leitura e gravação para esse diretório. Você pode excluir o conteúdo do diretório de dados atual do membro secundário interrompido ou criar um diretório de dados totalmente novo.

mongod com WiredTiger não iniciará com arquivos de dados criados com um mecanismo de armazenamento diferente.

3

Remova todas as opções de configuração do MMAPv1 da configuração da instância mongod.

4

Inicie o mongod especificando wiredTiger como --storageEngine e o diretório de dados preparado para WiredTiger como --dbpath.

Especifique opções adicionais conforme apropriado, como --bind_ip.

Aviso

Antes de vincular sua instância a um endereço IP acessível publicamente, você deve proteger 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 --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --replSet <replSetName> --bind_ip localhost,<hostname(s)|ip address(es)>

Importante

Se você estiver executando uma arquitetura PSA de três membros, inclua --enableMajorityReadConcern false para desativar a read concern majority. Consulte PSA 3-Arquitetura de membros.

mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --replSet <replSetName> --bind_ip localhost,<hostname(s)|ip address(es)> --enableMajorityReadConcern false

Como não existem dados no --dbpath, o mongod executará uma sincronização inicial. O comprimento do processo de sincronização inicial depende do tamanho do banco de dados e da conexão de rede entre os nós do conjunto de réplica.

Você também pode especificar as opções em um arquivo de configuração. Para especificar o mecanismo de armazenamento, utilize a configuração do storage.engine.

Repita as etapas para os membros secundários restantes, atualizando-os um de cada vez.

Importante

Se atualizar todos os nós do conjunto de réplicas para usar o WiredTiger, certifique-se de que todos os nós secundários tenham sido atualizados primeiro antes de atualizar o primário.

Depois que todos os nós secundários tiverem sido atualizados para o WiredTiger, conecte mongosh ao primário e use rs.stepDown() para reduzir o primário e forçar a eleição de um novo primário.

rs.stepDown()

Quando o primário tiver sido retirado e se tornar secundário, atualize o secundário para usar o WiredTiger como antes:

1

Em mongosh, encerre o secundário.

use admin
db.shutdownServer()
2

Prepare um diretório de dados para a nova instância do mongod que será executada com o storage engine do WiredTiger. mongod deve ter permissões de leitura e gravação para esse diretório. Você pode excluir o conteúdo do diretório de dados atual do membro secundário interrompido ou criar um diretório de dados totalmente novo.

mongod com WiredTiger não iniciará com arquivos de dados criados com um mecanismo de armazenamento diferente.

3

Remova todas as opções de configuração do MMAPv1 da configuração da instância mongod.

4

Inicie o mongod especificando wiredTiger como --storageEngine e o diretório de dados preparado para WiredTiger como --dbpath.

Especifique opções adicionais conforme apropriado, como --bind_ip.

Aviso

Antes de vincular sua instância a um endereço IP acessível publicamente, você deve proteger 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 --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --replSet <replSetName> --bind_ip localhost,<hostname(s)|ip address(es)>

Importante

Se você estiver executando uma arquitetura PSA de três membros, inclua --enableMajorityReadConcern false para desativar a read concern majority. Consulte PSA 3-Arquitetura de membros.

mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --replSet <replSetName> --bind_ip localhost,<hostname(s)|ip address(es)> --enableMajorityReadConcern false

Como não existem dados no --dbpath, o mongod executará uma sincronização inicial. O comprimento do processo de sincronização inicial depende do tamanho do banco de dados e da conexão de rede entre os nós do conjunto de réplica.

Você também pode especificar as opções em um arquivo de configuração. Para especificar o mecanismo de armazenamento, utilize a configuração do storage.engine.

Voltar

Alterar um Standalone autogerenciado para WiredTiger