Abaixo está um trecho do nosso whitepaper “MongoDB Management and Automation with ClusterControl” que pode ser baixado gratuitamente.
Considerações para administrar o MongoDB
Redundância incorporada
Um recurso importante do MongoDB é sua redundância integrada, na forma de Replicação. Se você tiver dois ou mais nós de dados, eles podem ser configurados como um conjunto de réplicas, no qual todos os dados gravados no nó primário são replicados quase em tempo real para os nós secundários,
Conjunto de réplicas do MongoDB garantindo várias cópias dos dados. No caso de failover primário, os nós restantes no conjunto de réplicas realizam uma eleição e promovem o vencedor a primário, um processo que normalmente leva de 2 a 3 segundos e as gravações no conjunto de réplicas podem ser retomadas. O MongoDB também usa um diário para gravações mais rápidas e seguras no servidor ou conjunto de réplicas, e também emprega um método de “preocupação de gravação” através do qual o nível de redundância de gravação é
configurado.
Para implantar manualmente um conjunto de réplicas, as etapas de alto nível são as seguintes:
- Aloque um único host físico ou virtual para cada nó de banco de dados e instale o cliente de linha de comando MongoDB em seu desktop. Para uma configuração de conjunto de réplicas redundantes, são necessários no mínimo três nós, dos quais pelo menos dois serão nós de dados. Um nó no conjunto de réplicas pode ser configurado como um árbitro:este é um processo mongod configurado apenas para formar um quorum fornecendo um voto na eleição de um Primário quando necessário. Os dados não são replicados para processos de arbitragem.
- Instale o MongoDB em cada nó. Algumas distribuições Linux incluem o MongoDB Community Edition, mas esteja ciente de que elas podem não incluir as versões mais recentes. O MongoDB Enterprise está disponível apenas para download no site do MongoDB. Funcionalidade semelhante ao MongoDB Enterprise também está disponível por meio do Percona Server for MongoDB, um substituto imediato para o MongoDB Enterprise ou Community Edition.
- Configure os arquivos de configuração individuais do mongod.conf para seu conjunto de réplicas, usando o “parâmetro de replicação”. Se você for usar um arquivo de chave para segurança, configure-o agora também. Observe que o uso da segurança de arquivo de chave também habilita a autenticação baseada em função, portanto, você também precisará adicionar usuários e funções para usar os servidores. Reinicie o processo mongod em cada servidor.
- Garantir a conectividade entre os nós. Você deve garantir que os nós do conjunto de réplicas do MongoDB possam se comunicar entre si na porta 27017 e também que seus clientes possam se conectar a cada um dos nós do conjunto de réplicas na mesma porta.
- Usando o cliente de linha de comando MongoDB, conecte-se a um dos servidores e execute rs.initiate() para inicializar seu conjunto de réplicas, seguido de rs.add() para cada nó adicional. rs.conf() pode ser usado para visualizar a configuração.
Embora essas etapas não sejam tão complexas quanto implantar e configurar um cluster fragmentado do MongoDB ou fragmentar um banco de dados relacional, elas podem ser onerosas e propensas a erros, especialmente em ambientes maiores.
Escalabilidade
O MongoDB é frequentemente chamado de software de banco de dados de “escala da web”, devido à sua capacidade de escalar horizontalmente. Assim como os bancos de dados relacionais, é possível dimensionar o MongoDB verticalmente, simplesmente atualizando o host físico no qual reside com mais núcleos de CPU, mais RAM, discos mais rápidos ou até mesmo maior velocidade de barramento. O escalonamento vertical tem seus limites, no entanto, tanto em termos de relação custo-benefício e retornos decrescentes, quanto de limitação técnica. Para resolver isso, o MongoDB possui um recurso de “auto-sharding”, que permite que os bancos de dados sejam divididos em vários hosts (ou conjuntos de réplicas, para redundância). Embora o sharding também seja possível em plataformas relacionais, a menos que projetado para o início do banco de dados, isso requer um grande redesenho do esquema e do aplicativo, bem como o redesenho do aplicativo cliente, tornando esse processo tedioso, demorado e propenso a erros.
O sharding do MongoDB funciona introduzindo um processo de roteador, por meio do qual os clientes se conectam ao cluster fragmentado, e servidores de configuração, que armazenam os metadados do cluster, a localização no cluster de cada documento. Quando um cliente envia uma consulta ao processo do roteador, ele primeiro se refere aos servidores de configuração para obter os locais dos documentos e, em seguida, obtém os resultados da consulta diretamente dos servidores individuais ou
conjuntos de réplicas (shards). A fragmentação é realizada por coleta.
Um parâmetro extremamente importante aqui, para fins de desempenho, é a “chave de fragmentação”, um campo indexado ou campo composto que existe em cada documento em uma coleção. É isso que define a distribuição de gravação entre os fragmentos de uma coleção. Como tal, uma chave de fragmentação mal escolhida pode ter um efeito muito prejudicial no desempenho. Por exemplo, uma chave de fragmentação baseada puramente em séries temporais pode resultar em todas as gravações indo para um único nó por longos períodos de tempo. No entanto, uma chave de fragmento com hash, enquanto distribui as gravações uniformemente entre os fragmentos, pode afetar o desempenho de leitura, pois um conjunto de resultados é recuperado de muitos nós.
MongoDB Sharded ClusterSeveralnines Torne-se um DBA do MongoDB - Trazendo o MongoDB para a produçãoSaiba mais sobre o que você precisa saber para implantar, monitorar, gerencie e dimensione o MongoDBBaixe gratuitamente Árbitros
Um árbitro MongoDB é um processo mongod que foi configurado para não atuar como um nó de dados, mas para fornecer apenas a função de votação quando um conjunto de réplicas Primário deve ser eleito, para desempate e proteger contra uma votação dividida. Um árbitro não pode se tornar Primário, pois não mantém uma cópia dos dados nem aceita gravações. Embora seja possível ter mais de um árbitro em um conjunto de réplicas, geralmente não é recomendado.
Eleições do MongoDB e o processo de arbitragem Membros do conjunto de réplicas atrasados
Os membros do conjunto de réplicas com atraso adicionam um nível adicional de redundância, mantendo um estado que é um número fixo de segundos atrás do Primário. Como os membros atrasados são um “backup contínuo” ou um instantâneo “histórico” em execução do conjunto de dados, eles podem ajudar na recuperação de vários tipos de erro humano.
Membros atrasados são membros do conjunto de réplicas “ocultos”, invisíveis para aplicativos cliente e, portanto, não podem ser consultados diretamente. Eles também podem não se tornar Primários durante as operações normais e devem ser reconfigurados manualmente no caso de serem usados para recuperação de erros.
Nó secundário atrasado do MongoDB Backups
O backup de um conjunto de réplicas ou cluster fragmentado é realizado por meio do utilitário de linha de comando “mongodump”. Quando usado com o parâmetro --oplog, isso cria um dump do banco de dados que inclui um oplog, para criar um instantâneo point-in-time do estado de uma instância do mongod. Usando o mongorestore com o parâmetro --replayOplog, você pode restaurar completamente o estado dos dados no momento em que o backup foi concluído, evitando inconsistências.
Para requisitos de backup mais avançados, está disponível uma ferramenta de terceiros chamada “mongodbconsistent-backup” - também baseada em linha de comando - que fornece backups totalmente consistentes de clusters fragmentados, um procedimento complexo, uma vez que os bancos de dados fragmentados são distribuídos em vários hosts.
Monitoramento
Existem várias ferramentas comerciais, oficiais e não oficiais, disponíveis no mercado para monitorar o MongoDB. Essas ferramentas, em geral, são utilitários de gerenciamento de produto único, focando exclusivamente no MongoDB. Muitos se concentram apenas em certos aspectos específicos, como gerenciamento de coleção em uma arquitetura MongoDB existente, ou em backups ou em implantação. Sem planejamento adequado, isso pode levar a uma situação em que uma proliferação de ferramentas adicionais deve ser implantada e gerenciada em seu ambiente.
As ferramentas de linha de comando fornecidas com o MongoDB, “mongotop” e “mongostat” podem fornecer uma visão detalhada do desempenho de seus ambientes e podem ser usadas para diagnosticar problemas. Além disso, o cliente de linha de comando "mongo" do MongoDB também pode executar "rs.status()" - ou em um cluster fragmentado "sh.status() - para visualizar o status de conjuntos de réplicas ou clusters e seus hosts membros. O comando “db.stats()” retorna um documento que aborda o uso de armazenamento e volumes de dados, e seus equivalentes para coleções, bem como outras chamadas para acessar muitas métricas internas.
Resumo
Esta foi uma breve sinopse das considerações para administrar o MongoDB. Mesmo em um nível tão alto, deve ser imediatamente óbvio que, embora seja possível administrar um conjunto de réplicas ou cluster fragmentado a partir da linha de comando usando as ferramentas disponíveis, isso não é dimensionado em um ambiente com muitos conjuntos de réplicas ou com uma grande produção cluster fragmentado. Em ambientes de médio a grande porte com muitos hosts
e bancos de dados, torna-se rapidamente inviável gerenciar tudo com ferramentas de linha de comando e scripts. Embora ferramentas e scripts internos possam ser desenvolvidos para implantar e manter o ambiente, isso adiciona a carga de gerenciamento de novos desenvolvimentos, sistemas de controle de revisão e processos. Uma simples atualização de um servidor de banco de dados pode se tornar um processo complexo se forem necessárias alterações de ferramentas para suportar novas versões de servidor de banco de dados.
Mas sem ferramentas e scripts internos, como automatizamos e gerenciamos clusters do MongoDB? Baixe o whitepaper para saber como!
