Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Alterar conjunto de réplicas para WiredTiger
Observação
Começando no MongoDB 4.2
As opções
noPadding
eusePowerOf2Sizes
MMAPv1 para o comandocollMod
são removidas. Não use essas opções porque a atualização do MongoDB 4.0 para o 4.2 faz com que os membros secundários do 4.2 parem imediatamente.O MongoDB remove o mecanismo de armazenamento MMAPv1 obsoleto. Se você estiver atualizando para o MongoDB 4.2 de um MongoDB 4.0 sistema que usa MMAPv1, é necessário atualizar para o WiredTiger.
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 o tempo de inatividade.
Considerações
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.
Arquitetura de membros do PSA 3
O read concern "majority"
, disponível para WiredTiger, está habilitado por padrão. No entanto, em conjuntos de réplicas de três membros com uma arquitetura primary-secondary-arbiter (PSA), você pode desabilitar a read concern "majority"
. Desativar a preocupação de leitura "majority"
para uma arquitetura PSA de três membros evita um possível aumento da pressão no cache.
Oprocedimento abaixo desativa a read concern "majority"
para a arquitetura PSA ao incluir --enableMajorityReadConcern false
.
Observação
A desativação da read concern "majority"
não afeta a disponibilidade dos change streams.
Para obter mais informações sobre a arquitetura do PSA e a read concern "majority"
, consulte Conjuntos de réplicas do Primary-Secondary-Arbiter.
Vinculação padrão ao localhost
Binários do MongoDB, mongod
e mongos
, ligam-se ao localhost
por padrão.
XFS e 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.
Restrições somente do MMAPv1
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. |
Procedimento
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ó suspenso.
Para atualizar um membro para WiredTiger, o procedimento remove os dados de um membro, inicia o mongod
com WiredTiger e executa uma sincronização inicial.
A. Atualizar os membros secundários para WiredTiger.
Atualize os membros secundários um de cada vez:
Desligue o nó secundário.
Em mongosh
, desligue o secundário.
use admin db.shutdownServer()
Prepare um diretório de dados para o novo mongod
executando com WiredTiger.
Prepare um diretório de dados para a nova instância do mongod
que será executada com o mecanismo de armazenamento WiredTiger. mongod
deve ter permissões de leitura e gravação para este diretório. Você pode excluir o conteúdo do diretório de dados atual do membro secundário interrompido ou criar um novo diretório completamente.
mongod
com WiredTiger não iniciará com arquivos de dados criados com um mecanismo de armazenamento diferente.
Atualize a configuração do WiredTiger.
Remova todas as opções de configuração MMAPv1 da configuração da instância mongod
.
Iniciar mongod
com WiredTiger.
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 acessos não autorizados. Para obter uma lista completa das recomendações de segurança, consulte Lista de verificação de segurança. No mínimo, considere habilitar a autenticação e fortalecer a infraestrutura de rede.
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 membros 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.
B. Reduza o primário.
Importante
Se atualizar todos os membros do conjunto de réplicas para usar o WiredTiger, certifique-se de que todos os membros secundários tenham sido atualizados primeiro antes de atualizar o principal.
Depois que todos os membros 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 uma nova primária.
rs.stepDown()
C. Atualizar o primário desativado.
Quando o primário tiver saído e se tornar secundário, atualize o secundário para usar o WiredTiger como antes:
Desligue o nó secundário.
Em mongosh
, desligue o secundário.
use admin db.shutdownServer()
Prepare um diretório de dados para o novo mongod
executando com WiredTiger.
Prepare um diretório de dados para a nova instância do mongod
que será executada com o mecanismo de armazenamento WiredTiger. mongod
deve ter permissões de leitura e gravação para este diretório. Você pode excluir o conteúdo do diretório de dados atual do membro secundário interrompido ou criar um novo diretório completamente.
mongod
com WiredTiger não iniciará com arquivos de dados criados com um mecanismo de armazenamento diferente.
Atualize a configuração do WiredTiger.
Remova todas as opções de configuração MMAPv1 da configuração da instância mongod
.
Iniciar mongod
com WiredTiger.
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 acessos não autorizados. Para obter uma lista completa das recomendações de segurança, consulte Lista de verificação de segurança. No mínimo, considere habilitar a autenticação e fortalecer a infraestrutura de rede.
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 membros 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
.