Uma lista de verificação de desenvolvimento e operações para MongoDB

As listas de verificação de operação e desenvolvimento do MongoDB destinam-se a ajudar os administradores de banco de dados a evitar problemas no ambiente de produção do MongoDB. Uma lista de verificação de desenvolvimento deve abordar questões como...

1. Design de esquema
2. Durabilidade dos dados
3. Replicação
4. Drives 
5. Fragmentação 

Uma lista de verificação de operação, por outro lado, aborda...

1. Replicação
2. Sistema de arquivos 
3. Fragmentação
4. Hardware
5. Journaling (WiredTiger Storage Engine) 
6. Configurações do sistema operacional 
7. Implantação em hardware de nuvem 
8. Monitoramento
9. Backups e balanceamento de carga

Antes de iniciar um projeto, é aconselhável trabalhar na lista de verificação de operação e desenvolvimento para permitir o bom funcionamento do MongoDB em produção. Este artigo explica a lista de verificação de operação e desenvolvimento antes de implantar o MongoDB.

Lista de verificação de operações do MongoDB

Replicação

Todos os conjuntos de membros de réplica que não estão ocultos devem ser provisionados de forma idêntica em relação ao disco, RAM, configuração de rede e CPU.

O tamanho do oplog deve ser configurado adequadamente para atender às necessidades operacionais, como:

• Para evitar a necessidade de uma ressincronização completa, a janela do aplicativo de oplog de réplica deve cobrir o tempo de inatividade regular e a janela de manutenção.
• Para restaurar um membro do conjunto de replicação, a janela de oplog de réplica deve sempre cobrir o tempo necessário.

O conjunto de produção no mínimo deve incorporar três nós portadores de dados que são executados com o journaling ativado. Além disso, as gravações devem ser emitidas com w:"majority" write concern com o objetivo de garantir a disponibilidade e a durabilidade dos dados.

A implantação deve conter um número ímpar de membros votantes para facilitar o processo de votação sempre que o nó principal do cluster falhar.

Em vez de usar endereços IP que podem exigir a alteração de configurações devido à alteração de IP, é recomendado o uso de nomes de host DNS lógicos.

Certifique-se de que as instâncias do mongod tenham 0 ou 1 votos.

Todas as instâncias do Mongod devem ser totalmente e bidirecionalmente conectadas de forma que haja facilidade de comunicação de dados entre os nós envolvidos.

Diário

Esta é uma estratégia de gravação antecipada de arquivos de diário em disco empregada para garantir a durabilidade dos dados em caso de falha. Todas as instâncias devem ter o registro no diário habilitado por esse motivo, especialmente ao lidar com cargas de trabalho com uso intenso de gravação.

No entanto, leve em consideração que isso afeta os reforços de estilo instantâneo, pois os registros que constituem o estado do banco de dados residirão em volumes particionados.

Sistema de arquivos

Não use unidades do News File System (NFS) para dbPath. As unidades NFS podem resultar em um desempenho desestabilizado. As unidades virtuais VMware são recomendadas para uso por usuários VMware.

Certifique-se de que suas partições de disco estejam alinhadas com suas configurações RAIDON.

Para usuários Linux/Unix, o uso de XFS é recomendado. O XFS é conhecido por ter um desempenho melhor com o MongoDB.

Para usuários do sistema operacional Windows, o sistema de arquivos NTFS é recomendado. Você deve evitar usar qualquer sistema de arquivos FAT.

Implantação para hardware de nuvem

Windows Azure:altere o keepalive do TCP (tcp_keepalive_time) para 100-120. O tempo limite do TCP fora do equipamento no balanceador de pilha do Azure também é moderado para o comportamento de pool de associação do MongoDB

Use o MongoDB 2.6.4 ou versões mais recentes em estruturas com armazenamento de alta latência, como o Windows Azure, pois essas versões incorporam aprimoramentos de execução para essas estruturas.

Fragmentação

Coloque seus servidores de configuração em hardware dedicado para execução ideal em clusters expansivos.

Certifique-se de que o hardware tenha RAM suficiente para manter os registros de informações inteiramente na memória e tenha armazenamento dedicado.

Implante roteadores mongos de acordo com as diretrizes de configuração de geração.

Sincronize os relógios em todos os componentes do cluster fragmentado usando NTP.

Garantir uma rede bidirecional completa entre mongos, mongod e servidores de configuração.

Use CNAMEs para reconhecer seus servidores de configuração no cluster para que você possa renomear e renumerar seus servidores de configuração sem tempo de inatividade.

Monitoramento

Você pode utilizar ferramentas como MongoDB Cloud Manager, ClusterControl ou outra estrutura de monitoramento para rastrear as principais métricas do banco de dados e configurar alarmes. Incorpore alertas para as métricas:

• Filas
• Janela de oplog de replicação
• Afirmações
• Falhas de página
• Atraso de replicação

Monitore as métricas de hardware de seus servidores. Preste atenção especialmente ao espaço em disco disponível, uso do disco, CPU

Hardware

Utilize unidades RAID10 e SSD para desempenho ideal.

SAN e virtualização:

Certifique-se de que cada uma das instâncias do mongod tenha provisionado IOPS para seu dbPath ou tenha sua unidade física ou LUN de declaração.

Evite destaques de memória dinâmica, como o aumento de memória, ao executar em ambientes virtuais.

Evite definir todos os indivíduos do conjunto de cópias na mesma SAN, pois a SAN pode ser um único ponto de decepção.

Balanceamento de carga

Projete balanceadores de carga para habilitar "sessões fixas" ou "afinidade de cliente" com um tempo limite adequado para conexões existentes.

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

Backups

Planeje testes intermitentes de seu processo de backup e restauração para ter medidores de tempo à mão e confirmar sua utilidade.

Configuração do sistema operacional

Janelas

Considere desativar as atualizações de “último acesso” do NTFS.

Formatar discos NTFS usando o tamanho da unidade de alocação padrão de 4096 bytes.

Linux

Desligue as enormes páginas transparentes.

Faça ajustes nas configurações do cabeçote de leitura dos dados onde seus arquivos de banco de dados estão armazenados. O readahead do mecanismo de armazenamento WiredTiger deve ser definido entre 8 e 32.

Se estiver usando sintonizado no RHEL / CentOS, você deve personalizar seu perfil ajustado. Vários dos perfis ajustados que acompanham o RHEL / CentOS podem afetar negativamente a execução com suas configurações padrão. Personalize o perfil ajustado escolhido para:

Desabilite páginas enormes diretas.

Defina readahead entre 8 e 32 em qualquer caso de classificação de mídia de capacidade.

Utilize os agendadores de disco noop ou deadline para unidades SSD.

Use o agendador de disco noop para unidades virtualizadas em VMs convidadas.

Desative NUMA ou defina vm.zone_reclaim_mode como 0 e execute as ocorrências do mongod com intercalação de nós.

Ajuste os valores ulimit em seu hardware para corresponder ao seu caso de uso. Caso diferentes ocorrências de mongod ou mongos estejam sendo executadas no mesmo cliente, dimensione os valores ulimit da mesma maneira.

Projetar identificadores de registro adequados (fs.file-max), restrição de pid de parte (kernel.pid_max), thread máximo por processo (kernel.threads-max) e número máximo de áreas de contorno de memória por processo (vm.max_map_count) para seu envio. Para estruturas expansivas, os valores a seguir fornecem um ótimo ponto de partida:

fs.file-max value of 98000,

kernel.pid_max value of 64000,

kernel.threads-max value of 64000, and vm.max_map_count value of 128000

Certifique-se de que sua estrutura tenha o espaço de troca configurado.

Faça referência à documentação do seu sistema operacional para pontos de interesse sobre o dimensionamento correto.

 Certifique-se de que a manutenção de atividade TCP padrão do sistema esteja definida com precisão. Um valor de 300 geralmente oferece desempenho superior para conjuntos de réplicas e clusters fragmentados.

Lista de verificação de desenvolvimento do MongoDB

Replicação

Utilize um número ímpar de indivíduos votantes para garantir que as eleições continuem efetivamente. Você terá até 7 indivíduos votantes. Caso você tenha um número par de pessoas votantes e restrições, como custo, não permitam incluir outro secundário para ser membro votante, você poderá incluir um árbitro para garantir um número ímpar de votos.

Garantir que seus secundários permaneçam atualizados utilizando ferramentas de monitoramento e indicando problemas de gravação adequados.

Não utilize leituras auxiliares para dimensionar a taxa de transferência geral de leitura.

Design de esquema

Os dados no MongoDB contêm um padrão dinâmico. As coleções não mantêm a estrutura do relatório. Isso incentiva a melhoria iterativa e o polimorfismo. De qualquer forma, as coleções frequentemente guardam registros com estruturas extremamente homogêneas.

Decida o conjunto de coleções que você precisará e os índices necessários para apoiar suas consultas. Com o caso especial do índice _id, você deve fazer todos os índices expressamente:MongoDB naturalmente não faz nenhum índice diferente de _id.

Garantir que seu plano de esquema seja compatível com sua classificação de implantação:caso você esteja planejando utilizar clusters fragmentados para dimensionamento horizontal, planeje seu esquema para incorporar uma chave de fragmentação forte. A chave de fragmentação influencia a execução de leitura e gravação ao decidir como o MongoDB segmenta os dados. Você não pode alterar a chave de fragmentação depois de definida.

Certifique-se de que seu plano de esquema não dependa de clusters indexados que crescem em comprimento sem limites. Normalmente, a melhor execução pode ser alcançada quando esses clusters indexados têm menos de 1.000 componentes.

Considere os limites de estimativa do documento ao projetar seu esquema. A restrição de estimativa de documento BSON é de 16 MB por documento. Caso você precise de relatórios maiores, use o GridFS.

Drivers

Faça uso do pool de associações. A maioria dos drivers do MongoDB oferece suporte ao pool de associações. Altere o tamanho do pool de associações para se adequar ao seu caso de uso, começando em 110-115% do número normal de demandas de banco de dados simultâneas.

Certifique-se de que seus aplicativos lidem com erros temporais de gravação e leitura em meio a eleições de conjuntos de réplicas.

Garantir que seus aplicativos lidem com solicitações com falha e tente novamente, se apropriado. Os motoristas não

tente novamente solicitações com falha.

Utilize a lógica de retirada exponencial para novas tentativas de solicitação de banco de dados.

Utilize cursor.maxTimeMS() para leituras e wtimeout para gravações caso você queira limitar o período de execução das operações do banco de dados.

Durabilidade dos dados

Certifique-se de que seu conjunto de réplicas incorpore pelo menos três hubs de suporte de dados com preocupação de composição w:majority. Três hubs portadores de dados são necessários para a solidez dos dados em todo o conjunto de réplicas.

Garantir que todas as instâncias utilizam journaling.

Fragmentação

Garantir que sua chave de fragmentação transmita a carga igualmente em seus fragmentos.

Utilize operações direcionadas para cargas de trabalho que foram dimensionadas com o número de estilhaços.

Para o MongoDB 3.6 e posteriores, os secundários não retornam mais dados órfãos, a menos que utilizem a preocupação de leitura "disponível" (que é a preocupação de leitura padrão para leituras contra secundárias quando não relacionadas a sessões causalmente confiáveis).

A partir do MongoDB 3.6, todos os membros do conjunto de réplicas de fragmentos mantêm metadados de fragmentos, permitindo que eles filtrem órfãos quando não estiverem utilizando "disponível". Como tal, consultas não direcionadas ou de transmissão que não estão utilizando "disponível" podem ser executadas com segurança em qualquer membro e não retornarão informações órfãs.

O problema de leitura "acessível" pode retornar documentos órfãos de membros auxiliares, pois não verifica metadados de partes revisados. De qualquer forma, caso o retorno de documentos órfãos seja insignificante para um aplicativo, a preocupação de leitura "disponível" fornece a menor inatividade possível de leituras entre as diferentes preocupações de leitura.

Pré-dividir e ajustar manualmente os fragmentos ao incorporar conjuntos de dados expansivos em uma nova coleção fragmentada sem hash. A pré-divisão e o ajuste físico permitem que a pilha incorporada seja dispersa entre os fragmentos, expandindo a execução para a carga inicial.

Conclusão