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.
Considerações
Tempo de inatividade
Se você alterar o host ou a porta de qualquer fragmento, também deverá atualizar a configuração do fragmento.
Arquitetura de 3 nós do PSA
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.
Vinculação padrão ao localhost
Binários do MongoDB, mongod e mongos, ligam-se ao localhost por padrão.
Servidores de configuraçã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.
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
Para cada conjunto de réplicas , para alterar o storage engine para WiredTiger:
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, 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 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 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.
B. Desative 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 antigo.
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 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 o procedimento para os outros fragmentos.