Instalação de sharded cluster MongoDB (config servers + shards + mongos)

Sharded cluster montado quando os dados ou a carga de escrita excedem um único replica set: config server replica set de três membros, dois ou três shard replica sets e dois roteadores mongos; autenticação interna com keyfile, autorização, sh.addShard, escolha da shard key, sharding da collection, balancer e verificação da distribuição. Ao final, você tem um cluster que cresce horizontalmente, em que as aplicações se conectam somente aos mongos. Se os dados cabem em um único servidor, a instalação de um replica set é mais simples e suficiente.

Topologia: 3 config servers + 2×3 membros de shard + 2 mongos (no mínimo 11 servidores; menos para teste)

Antes de começar

• Todos os servidores com o mesmo sistema operacional, atualizados; relógio sincronizado por NTP (chrony). Diferença de horário entre os membros causa problemas de sessão e de oplog.
• RAM e CPU iguais aos valores do formulário (o cache do WiredTiger é calculado a partir desse valor). Swap definido, mas pequeno.
• Diretório de dados (…) em disco/LV separado, formatado com XFS, montado com noatime e persistente no fstab. Com WiredTiger, ext4 pode causar problemas de desempenho.
• O nome de cada servidor resolve a partir de todos os servidores e dos servidores de aplicação (DNS ou /etc/hosts). Na configuração do replica set usa-se o nome, não o IP.
• As portas …, … e … estão abertas entre os servidores; a rede de aplicação alcança essas portas. Elas não estão em uso por outro serviço.
• Os servidores acessam repo.mongodb.org e pgp.mongodb.com por HTTPS, ou há um mirror interno configurado.
• Não há o pacote mongodb do próprio sistema operacional nem uma instalação antiga do MongoDB.
• A partir do primeiro servidor, é possível fazer scp para os demais como root (ou usuário com sudo) (para copiar o keyfile). Caso contrário, transfira o arquivo manualmente por um meio seguro.
• Você entrou com root ou com privilégio sudo; a janela de manutenção e o plano de snapshot dos servidores (rollback) estão prontos.
• A decisão sobre a shard key foi tomada com a equipe da aplicação: campo do filtro das consultas mais frequentes, alta cardinalidade, distribuição equilibrada dos valores. A shard key pode ser alterada depois com reshardCollection, mas isso é custoso.

Fases do guia

• Preparação do sistema operacional (todos os servidores) — Hostname: … · Hostname: … · Hostname: … · Hostname: … · Hostname: … · Atualização do sistema e ferramentas necessárias …
• Instalação do software MongoDB — Adicionar o repo do MongoDB … · Adicionar o repo do MongoDB … · Instalar o software de servidor do MongoDB (config servers e shards) · Instalar o mongos e o mongosh (roteadores) · Preparar o diretório de dados · Política SELinux, rótulos e portas …
• Keyfile (autenticação interna do cluster) — Criar o keyfile · Copiar o keyfile para todos os servidores · Permissões do keyfile
• Config server replica set — mongod.conf (config server): … · Iniciar o mongod · rs.initiate (config server)
• Shard A (replica set shardA) — mongod.conf (shard A): … · Iniciar o mongod · rs.initiate (shard A) · Usuário administrador shard-local (shard A)
• Shard B (replica set shardB) — mongod.conf (shard B): … · Iniciar o mongod · rs.initiate (shard B) · Usuário administrador shard-local (shard B)
• Shard C (replica set shardC) — mongod.conf (shard C): … · Iniciar o mongod · rs.initiate (shard C) · Usuário administrador shard-local (shard C)
• mongos (roteador) — mongos.conf: … · Serviço systemd do mongos · Iniciar o mongos · Criar o administrador do cluster · Adicionar os shards (sh.addShard) · Criar o usuário da aplicação
• Shard key e sharding da collection — Escolha da shard key (passo de decisão) · Fazer o sharding da collection · Status do balancer · Janela de tempo do balancer
• Verificação — Status do cluster · Teste de distribuição · Status do config server replica set · String de conexão da aplicação
• Pós-instalação — Rotação de logs · Estratégia de backup · Monitoramento