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

Alterar um cluster fragmentado autogerenciado para WiredTiger

Observação

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 cluster fragmentado para usar WiredTiger.

Se você alterar o host ou a porta de qualquer fragmento, também deverá atualizar a configuração do fragmento.

A referência de leitura "majority", disponível para o WiredTiger, está habilitado por padrão. No entanto, se você tiver um conjunto de réplicas de fragmentos de três membros com uma arquitetura PSA (primary-secondary-árbitro), poderá desativar a referência de leitura do "majority" para esse conjunto de réplicas de fragmentos. A desativação do "majority" para uma arquitetura PSA de três membros evita o possível aumento da pressão de cache.

Observação

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

A desativação da "majority" referência de leitura impede que collMod os comandos que modificam um índice sejam revertidos. Se essa operação precisar ser revertida, você deverá ressincronizar os nós afetados com o nó primário .

A desativação da referência de leitura "majority" do afeta o suporte para transação em clusters fragmentados. Especificamente:

  • Uma transação não poderá usar a read concern "snapshot" se a transação envolver um fragmento que desativou a read concern "maioria".

  • Uma transação que grava em vários erros de fragmentos se alguma das operações de leitura ou gravação da transação envolver um fragmento que desativou a referência de leitura "majority".

No entanto, isso não afeta a transação em conjuntos de réplicas. Para transações em conjuntos de réplicas, você pode especificar a preocupação de leitura "majority" (ou "snapshot" ou "local" ) para transações distribuídas, mesmo que a preocupação de leitura "majority" esteja desativada.

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.

Servidores de configuração devem ser implantados como conjuntos de réplica (CSRS). Dessa forma, os servidores de configuração já usam o mecanismo de armazenamento WiredTiger.

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.

A partir do MongoDB 8.0, você pode usar a função directShardOperations para realizar operações de manutenção que exigem que você execute comandos diretamente em um shard.

Aviso

Executar comandos utilizando a função directShardOperations pode fazer com que seu cluster pare de funcionar corretamente e pode causar corrupção de dados. Use a função directShardOperations apenas para fins de manutenção ou sob a orientação do suporte do MongoDB . Quando terminar de executar as operações de manutenção, pare de usar a função directShardOperations .

Para cada conjunto de réplicas , para alterar o storage engine para WiredTiger:

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

1

Em mongosh, desligue 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 Lista de verificação de segurança para implantações autogerenciadas. No mínimo, considere 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 preocupação de leitura 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.

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 Lista de verificação de segurança para implantações autogerenciadas. No mínimo, considere 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 preocupação de leitura 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 o procedimento para os outros fragmentos.

Voltar

Alterar um conjunto de réplicas autogerenciadas para WiredTiger