Menu Docs

Página inicial do DocsDesenvolver aplicaçõesManual do MongoDB

Checklist de operações

Nesta página

  • Sistema de arquivos
  • Replicação
  • Fragmentação
  • Registro em diário: Mecanismo de armazenamento WiredTiger
  • Hardware
  • Sistemas em hardware de nuvem
  • Configuração do sistema operacional
  • Backups
  • Monitoramento
  • Balanceamento de carga
  • Segurança

A lista de verificação a seguir, juntamente com a lista de verificação de desenvolvimento , fornece recomendações para ajudá-lo a evitar problemas na implantação de produção do MongoDB.

  • Verifique se todos os membros do conjunto de réplicas não ocultos estão provisionados de forma idêntica em termos de RAM, CPU, disco, configuração de rede etc.

  • Configure o tamanho do registro para se adequar ao seu caso de uso:

    • A janela de oplog de replicação deve cobrir as janelas normais de manutenção e tempo de inatividade para evitar a necessidade de uma ressincronização completa.

    • A janela do registro de replicação deve cobrir o tempo necessário para restaurar um membro do conjunto de réplicas a partir do último backup.

      Alterado na versão 3.4: a janela de registro de replicação não precisa mais cobrir o tempo necessário para restaurar um membro do conjunto de réplicas por meio da sincronização, pois os registros oplog são extraídos durante a cópia de dados. No entanto, o membro que está sendo restaurado deve ter espaço em disco suficiente no banco de dados local para armazenar temporariamente esses registros oplog durante esse estágio de cópia de dados.

      Com versões anteriores do MongoDB, a janela de oplog de replicação deve cobrir o tempo necessário para restaurar um membro do conjunto de réplicas por initial sync.

  • O conjunto de réplicas deve incluir pelo menos três membros votantes com dados que sejam executados com registro em diário e que você emita escritas com a write concern w: majority para garantir a disponibilidade e a durabilidade.

  • Use nomes de host ao configurar membros do conjunto de réplicas, em vez de endereços IP.

  • Garanta conectividade de rede bidirecional completa entre todas as instâncias de mongod.

  • Certifique-se de que cada host possa se resolver sozinho.

  • Garanta que o conjunto de réplicas contenha um número ímpar de membros votantes.

  • Garanta que as instâncias do mongod tenham 0 ou 1 votos.

  • Para alta disponibilidade, implemente sua réplica configurada em no mínimo três centro de dados.

  • Coloque seus servidores de configuração em hardware dedicado para obter o desempenho ideal em clusters grandes. Verifique se o hardware tem RAM suficiente para manter os arquivos de dados inteiramente na memória e se tem armazenamento dedicado.

  • Implemente roteadores do mongos de acordo com as diretrizes de Configuração da Produção.

  • Use o NTP para sincronizar os relógios em todos os componentes do seu cluster fragmentado.

  • Garanta a conectividade de rede bidirecional completa entre mongod, mongos e os servidores de configuração.

  • Use CNAMEs para identificar seus servidores de configuração no cluster. Dessa forma, é possível renomear e renumerar seus servidores de configuração sem tempo de inatividade.

  • Certifique-se de que todas as instâncias usem o registro no diário.

  • Coloque o diário em seu próprio disco de baixa latência para cargas de trabalho de escrita intensiva. Observe que isso afetará os backups do tipo snapshot, pois os arquivos que constituem o estado do banco de dados residirão em volumes separados.

  • Use drives RAID10 e SSD para ter o desempenho ideal.

  • SAN e virtualização:

    • Garanta que cada mongod tenha IOPS provisionado para seu dbPath ou tenha seu próprio drive físico ou LUN.

    • Evite recursos dinâmicos de memória, como memory ballooning, ao executar em ambientes virtuais.

    • Evite colocar todos os membros do conjunto de réplicas no mesmo SAN, pois o SAN pode ser um ponto único de falha.

  • Windows Azure: ajuste a manutenção de atividade do TCP (tcp_keepalive_time) para 100-120. O tempo limite de inatividade do TCP no balanceador de carga do Azure é muito lento para o comportamento de pool de conexões do MongoDB. Consulte: Notas de produção do Azure para obter mais informações.

  • Use o MongoDB versão 2.6.4 ou posterior em sistemas com armazenamento de alta latência, como o Windows Azure, pois essas versões incluem melhorias de desempenho para esses sistemas.

  • Desative hugepages transparentes. Consulte Configurações de hugepages transparentes para obter mais informações.

  • Ajuste as configurações de readahead nos dispositivos que armazenam seus arquivos do banco de dados.

    • Para o mecanismo de armazenamento WiredTiger, defina o readahead entre 8 e 32, independentemente do tipo de mídia de armazenamento (disco giratório, SSD, etc.), a menos que o teste mostre um benefício mensurável, repetível e confiável com um valor de readahead maior.

      O suporte comercial do MongoDB pode fornecer conselhos e orientações sobre configurações alternativas de leitura antecipada.

  • Se estiver usando tuned no RHEL /CentOS, você deve personalizar seu perfil tuned. Muitos dos perfis tuned fornecidos com o RHEL /CentOS podem impactar negativamente o desempenho com suas configurações padrão. Personalize o perfil tuned escolhido para:

  • Use os agendadores de disco cfq ou deadline para SSDs.

  • Use o agendador de discos cfq para drives virtualizados em VMs guest.

  • Desative o NUMA ou defina vm.zone_reclaim_mode como 0 e execute instâncias mongod com intercalação de nós. Consulte Hardware do MongoDB e NUMA para obter mais informações.

  • Ajuste os valores ulimit no hardware de acordo com seu caso de uso. Se várias instâncias mongod ou mongos estiverem sendo executadas sob o mesmo usuário, escale os valores ulimit adequadamente. Consulte: Configurações ulimit do UNIX para saber mais.

  • Use noatime como ponto de montagem dbPath.

  • Configure identificadores de arquivo suficientes (fs.file-max), limite de pid do kernel (kernel.pid_max), máximo de threads por processo (kernel.threads-max) e número máximo de áreas de mapa de memória por processo (vm.max_map_count) para sua implantação. Para sistemas grandes, os seguintes valores fornecem um bom ponto de partida:

    • fs.file-max valor de 98000,

    • kernel.pid_max valor de 64000,

    • kernel.threads-max valor de 64000 e

    • vm.max_map_count valor de 102400

  • Certifique-se de que seu sistema tenha espaço de troca configurado. Consulte a documentação do seu sistema operacional para obter detalhes sobre o tamanho apropriado.

  • Certifique-se de que o keepalive TCP padrão do sistema esteja configurado corretamente. Um valor de 120 geralmente oferece melhor desempenho para conjuntos de réplicas e clusters fragmentados. Consulte: O tempo TCP keepalive afeta as implantações do MongoDB? nas Perguntas Frequentes para obter mais informações.

  • Agende testes periódicos do seu processo de backup e restauração para ter estimativas de tempo em mãos e verificar sua funcionalidade.

  • Use o MongoDB Cloud Manager ou o Ops Manager, uma solução local disponível no MongoDB Enterprise Advanced ou outro sistema de monitoramento para monitorar as principais métricas do banco de dados e configurar alertas para elas. Incluir alertas para as seguintes métricas:

    • atraso de replicação

    • janela de replicação de registro

    • afirmações

    • filas

    • Falhas na Página

  • Monitore as estatísticas de hardware de seus servidores. Em particular, preste atenção ao uso do disco, à CPU e ao espaço disponível em disco.

    Na ausência de monitoramento do espaço em disco ou como precaução:

    • Crie um arquivo dummy de 4 GB no drive storage.dbPath para garantir que haja espaço disponível se o disco ficar cheio.

    • Uma combinação de cron+df pode alertar quando o espaço em disco atinge uma marca de água alta, se nenhuma outra ferramenta de monitoramento estiver disponível.

  • Configure os balanceadores de carga para ativar as "sessões fixas" ou afinidade do cliente, com um tempo limite suficiente para as conexões existentes.

  • Evite colocar balanceadores de carga entre o cluster MongoDB ou componentes de conjunto de réplicas.

Para obter uma lista de medidas de segurança para proteger sua instalação do MongoDB, consulte a Lista de verificação de segurança do MongoDB.

← Notas de produção