Alterar um conjunto de réplicas autogerenciadas para WiredTiger
Observação
As opções
noPaddingeusePowerOf2SizesMMAPv1 para o comandocollModsã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.
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 3 nós do PSA
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.
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 |
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ó 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.
A. Atualize os nós secundários para WiredTiger.
Atualize os nós secundários um de cada vez:
Desligue o membro secundário.
Em mongosh, encerre 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 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.
Atualize a configuração do WiredTiger.
Remova todas as opções de configuração do 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 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.
B. Desative o primário.
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()
C. Atualize o primário desativado.
Quando o primário tiver sido retirado e se tornar secundário, atualize o secundário para usar o WiredTiger como antes:
Desligue o membro secundário.
Em mongosh, encerre 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 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.
Atualize a configuração do WiredTiger.
Remova todas as opções de configuração do 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 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.