As implantações de cluster são de grande importância para garantir a alta disponibilidade dos dados e protegê-los. O MongoDB aprimora isso por meio de replicação e fragmentação, em que a replicação garante o dimensionamento vertical por meio da redundância de levantamento, enquanto o fragmento infla o dimensionamento horizontal.
Em geral, ambas as abordagens tentam distribuir a carga de trabalho entre os membros e, assim, reduzir a carga de trabalho à qual um único nó pode estar sujeito. O desempenho do banco de dados pode ser visto como rápido no atendimento aos usuários com operações de taxa de transferência. No entanto, sem uma arquitetura de cluster principal, você pode não ver o mesmo nível de resultados, mesmo se tentar fragmentação e replicação.
Se os membros do conjunto de réplicas forem pares, será difícil para os membros votar e eleger um novo primário se o existente falhar em algum momento. Neste blog, discutiremos a arquitetura de implantação padrão que pode ser usada, mas isso pode variar de acordo com os requisitos do aplicativo.
Estratégias de implantação do MongoDB
A arquitetura dos conjuntos de réplicas é muito determinante da capacidade e capacidade do MongoDB.
Um conjunto de réplicas de três nós é a implantação de cluster padrão para MongoDB em qualquer ambiente de produção, pois fornece redundância de dados e tolerância a falhas. A redundância é importante especialmente na recuperação de banco de dados após um desastre. Um conjunto de réplicas de três nós pode ser a arquitetura de implantação básica, mas isso pode variar de acordo com as especificações e os requisitos do aplicativo. No entanto, não o torne muito complexo, pois pode levar a alguns problemas de configuração maiores.
Estratégias de fragmentação do MongoDB
O sharding reduz a carga de trabalho sobre a qual o banco de dados deve trabalhar para uma determinada consulta, reduzindo o número de documentos que precisam ser executados. Portanto, eleva o dimensionamento horizontal, permitindo que o banco de dados cresça além dos limites de hardware de um único servidor. Dependendo da demanda da carga de trabalho, os nós podem ser adicionados ou removidos do cluster e o MongoDB reequilibrará os dados de maneira ideal sem intervenção da operação.
Algumas das melhores estratégias de implantação para um cluster fragmentado incluem:
Garantir que as chaves de fragmentação sejam distribuídas uniformemente
A razão por trás da fragmentação é dimensionar o banco de dados horizontalmente e reduzir o número de operações de taxa de transferência às quais uma única instância pode estar sujeita. Se você não distribuir as chaves de fragmentação de maneira uniforme, poderá acabar com um pequeno número de fragmentos. Com poucos shards, as operações podem ser limitadas pela capacidade de um único shard, tornando as operações de leitura e gravação lentas.
Os pedaços devem ser pré-divididos e distribuídos primeiro
Os fragmentos têm blocos de dados que são agrupados de acordo com alguns critérios de chave de fragmento. Ao criar uma nova coleção de fragmentos, antes de carregá-la com dados, você deve criar pedaços vazios e distribuí-los uniformemente em todos os fragmentos. Quando você estiver preenchendo o MongoDB com dados, será fácil equilibrar a carga entre os shards envolvidos. A opção numInitialChunks pode ser usada para fazer isso automaticamente se você estiver usando fragmentação baseada em hash. O valor inteiro, no entanto, deve ser menor que 8192 por estilhaço.
Número de fragmentos
Dois shards geralmente são necessários como o número mínimo para que a significância do sharding seja alcançada. Um único estilhaço só é útil se você quiser estabelecer a base para habilitar a fragmentação no futuro e sem necessidade durante o tempo de implantação.
Prefira fragmentação baseada em intervalo em vez de fragmentação baseada em hash
A fragmentação baseada em intervalo é benéfica, pois fornece mais fragmentos, portanto, as operações podem ser roteadas para o menor número de fragmentos necessários e, com mais frequência, para um único fragmento. Na prática, isso pode ser difícil, a menos que você tenha uma boa compreensão dos dados e dos padrões de consulta envolvidos. A fragmentação com hash melhora a distribuição uniforme da operação de taxa de transferência às custas de fornecer operações baseadas em intervalo inferiores.
Usar consultas Scatter-Gather apenas para grandes consultas de agregação
Consultas que não podem ser roteadas com base em uma chave de estilhaço devem ser transmitidas para todos os estilhaços para avaliação e, como envolvem vários estilhaços para cada solicitação, elas não são dimensionadas linearmente à medida que mais estilhaços são adicionados, incorrendo em uma sobrecarga que degrada o desempenho do banco de dados. Essa operação é conhecida como scatter-gather e só pode ser evitada se você incluir a chave de fragmentação em sua consulta.
A abordagem só é útil ao lidar com grandes consultas de agregação em que cada consulta pode ser executada em paralelo em todos os shards.
Estratégias de replicação do MongoDB
A replicação aprimora o dimensionamento vertical no MongoDB de forma que a carga de trabalho seja distribuída entre os membros envolvidos. No ambiente de produção, essas são algumas das considerações que devem ser feitas para uma arquitetura de cluster ideal.
Número de nós
O número máximo de nós que um conjunto de réplicas pode ter é 50 com 7 membros votantes. Qualquer membro após o dia 7 é considerado sem direito a voto. Um bom cluster deve, portanto, ter 7 membros votantes para tornar o processo eleitoral conveniente.
Implante um número ímpar de membros votantes e se você tiver apenas menos de 7, mas um número par de membros, você precisará implantar um árbitro como outro membro votante. Os árbitros não armazenam uma cópia dos dados, portanto, exigirão menos recursos para gerenciar. Além disso, pode-se submetê-los a um ambiente que não poderia submeter os outros membros.
Considerações sobre tolerância a falhas
Às vezes, alguns membros podem ficar indisponíveis como resultado de fatores como falta de energia ou transientes e desconexões da rede. O número de membros que permanecem no conjunto e capazes de eleger um primário cria uma situação conhecida como tolerância a falhas. É, portanto, a diferença entre o número total de membros do conjunto de réplicas e a maioria dos membros votantes necessários para eleger um primário. A ausência de um primário determina que as operações de gravação não podem ser executadas.
A tabela abaixo mostra um exemplo de relacionamento entre os três.
| Total de membros do conjunto de réplicas | Maioria necessária para eleger novo primário | Tolerância a falhas |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
O relacionamento não é tão direto, pois se você adicionar mais membros ao conjunto, não é dado que a tolerância a falhas aumentará conforme visto na tabela. Membros adicionais fornecem suporte para funções dedicadas, como backups e relatórios.
Planejamento de capacidade e balanceamento de carga para leituras pesadas
Você precisa ter uma capacidade sobressalente para sua implantação adicionando novos membros antes que a demanda atual sature a capacidade do conjunto existente.
Para tráfego de leitura muito alto, distribua as leituras de taxa de transferência para os membros secundários e sempre que o cluster crescer, adicione ou mova membros para data centers alternativos para obter redundância e aumentar a disponibilidade de dados.
Você também pode usar operações de destino com conjuntos de tags para direcionar operações de leitura para membros específicos ou modificar a preocupação de gravação para solicitar confirmação de membros específicos.
Os nós devem ser distribuídos geograficamente
Os data centers também podem falhar devido a alguma catástrofe . Portanto, é aconselhável manter pelo menos um ou dois membros em um data center separado para fins de proteção de dados. Se possível, use um número ímpar de datacenters e selecione uma distribuição que maximize a probabilidade de que, mesmo com a perda de um datacenter, os membros restantes do conjunto de réplicas possam formar a maioria ou, no mínimo, fornecer uma cópia dos dados.
Empregar registro no diário para falhas inesperadas
Por padrão, isso está habilitado no MongoDB. Você deve garantir que essa opção esteja habilitada para proteger a perda de dados em caso de interrupções de serviço, como reinicializações repentinas e falhas de energia.
Padrões de implantação
Existem principalmente duas abordagens de implantação:
- Três conjuntos de réplicas de membros que fornecem a arquitetura mínima recomendada para um conjunto de réplicas.
- Conjunto de réplicas distribuído em dois ou mais data centers para proteção contra falhas específicas da instalação, como falta de energia.
Os padrões, no entanto, dependem dos requisitos do aplicativo, mas, se possível, você pode combinar os recursos desses dois em sua arquitetura de implantação.
Nomes de host e nomes de conjuntos de réplicas
Use o nome de host DNS lógico em vez do endereço IP ao configurar membros do conjunto de réplicas ou membros do cluster fragmentado. Isso é para evitar a dor envolvida com as alterações de configuração que você precisará fazer como resultado de endereços IP alterados.
No caso de nomenclatura de conjuntos de réplicas, use nomes distintos para os conjuntos, pois alguns drivers agrupam conexões de conjuntos de réplicas por nome de conjunto de réplicas.
Conclusão
O layout de arquitetura para um conjunto de réplicas determina a capacidade e a capacidade de sua implantação. A proteção de dados e o desempenho do sistema são as principais considerações ao configurar a arquitetura. Deve-se considerar fatores vitais, como tolerância a falhas, número de membros do conjunto de réplicas, chave de fragmentação ideal e padrões de implantação para alta disponibilidade e proteção de dados. A distribuição geográfica dos nós do conjunto de réplicas pode abordar muitos desses fatores, garantindo redundância e fornecendo tolerância a falhas se um dos data centers estiver ausente.
