Nossa versão mais recente do ClusterControl transforma algumas das tarefas mais problemáticas do MongoDB em meros 15 segundos de trabalho. Novos recursos foram adicionados para dar a você mais controle sobre seu cluster e realizar alterações de topologia:
- Converter um replicaSet do MongoDB em um cluster do MongoDB fragmentado
- Adicionar e remover fragmentos
- Adicionar roteadores de fragmentos a um cluster do MongoDB fragmentado
- Reduzir ou congelar um nó
- Novos conselheiros do MongoDB
Descreveremos esses recursos adicionais em profundidade abaixo.
Converter um MongoDB ReplicaSet em um cluster do MongoDB fragmentado
Como a maioria dos usuários do MongoDB começará com um replicaSet para armazenar seu banco de dados, esse é o tipo de cluster mais usado. Se você tiver problemas de dimensionamento, poderá dimensionar este replicaSet adicionando mais secundários ou dimensionando horizontalmente por fragmentação. Você pode converter um replicaSet existente em um cluster fragmentado, mas esse é um processo longo em que você pode cometer erros facilmente. No ClusterControl automatizamos esse processo, onde adicionamos automaticamente os Configservers, shard routers e habilitamos o sharding.
Para converter um replicaSet em um cluster fragmentado, você pode simplesmente acioná-lo por meio do menu suspenso de ações:
Isso abrirá um diálogo de duas etapas sobre como converter isso em um fragmento. A primeira etapa é definir onde implantar o Configserver e os roteadores de fragmentos para:
A segunda etapa é onde armazenar os dados e quais arquivos de configuração devem ser usados para o Configserver e o roteador de fragmentos.
Após a conclusão do trabalho de migração de fragmentos, a visão geral do cluster agora exibe fragmentos em vez de instâncias de replicaSet:
Após a conversão em um cluster fragmentado, novos fragmentos podem ser adicionados.
Adicionar ou remover fragmentos de um cluster do MongoDB fragmentado
Adicionando fragmentos
Como um shard do MongoDB é tecnicamente um replicaSet, adicionar um novo shard também envolve a implantação de um novo replicaSet. No ClusterControl, primeiro implantamos um novo replicaSet e o adicionamos ao cluster fragmentado.
Na interface do usuário do ClusterControl, você pode adicionar facilmente novos fragmentos com um assistente de duas etapas, aberto na lista suspensa de ações:
Aqui você pode definir a topologia do novo shard.
Depois que o novo fragmento for adicionado ao cluster, o roteador de fragmentos do MongoDB começará a atribuir novos fragmentos a ele, e o balanceador balanceará automaticamente todos os fragmentos em todos os fragmentos.
Removendo fragmentos
Remover shards é um pouco mais difícil do que adicionar um shard, pois isso envolve mover os dados para os outros shards antes de remover o próprio shard. Para todos os dados que foram fragmentados em todos os fragmentos, esse será um trabalho executado pelo balanceador do MongoDB.
No entanto, qualquer banco de dados/coleção não fragmentado, que foi atribuído a esse fragmento como seu fragmento principal, precisa ser movido para outro fragmento e transformado em seu novo fragmento principal. Para esse processo, o MongoDB precisa saber para onde mover esses bancos de dados/coleções não fragmentados.
No ClusterControl, você pode simplesmente removê-los através do menu suspenso de ações:
Isso permitirá que você selecione o fragmento que deseja remover e o fragmento para o qual deseja migrar quaisquer bancos de dados primários:
O trabalho que remove o estilhaço executará ações semelhantes conforme descrito anteriormente:ele moverá todos os bancos de dados primários para o estilhaço designado, habilitará o balanceador e aguardará que ele mova todos os dados do estilhaço.
Depois que todos os dados forem removidos, ele removerá o fragmento da interface do usuário.
Adicionando roteadores de fragmentos MongoDB adicionais
Depois de começar a dimensionar seu aplicativo usando um cluster de fragmentos do MongoDB, você pode descobrir que precisa de roteadores de fragmentos adicionais.
Adicionar roteadores de fragmentos MongoDB adicionais é um processo muito simples com o ClusterControl, basta abrir a caixa de diálogo Adicionar nó na lista suspensa de ações:
Isso adicionará um novo roteador de estilhaço ao cluster. Não se esqueça de definir a porta padrão adequada (27017) no roteador.
Servidor abaixado
Caso você deseje realizar manutenção no nó primário em um replicaSet, é melhor fazer com que ele primeiro “desacelere” de maneira graciosa antes de colocá-lo offline. Rebaixar um primário basicamente significa que o host deixa de ser primário e se torna secundário e não é elegível para se tornar primário por um determinado número de segundos. Os nós no replicaSet do MongoDB com poder de votação, elegerão um novo primário com o primário reduzido excluído pelo número de segundos definido.
No ClusterControl adicionamos a funcionalidade step down como uma ação na página Nodes. Para descer, basta selecionar isso como uma ação no menu suspenso:
Depois de definir o número de segundos para a redução e a confirmação, a primária será demitida e uma nova primária será eleita.
Congelar um nó
Essa funcionalidade é semelhante ao comando step down:isso torna um determinado nó inelegível para se tornar um primário por um determinado número de segundos. Isso significa que você pode impedir que um ou mais nós secundários se tornem primários ao reduzir o primário e forçar um determinado nó a se tornar o novo primário dessa maneira.
No ClusterControl, adicionamos a funcionalidade de congelamento do nó como uma ação na página Nós. Para congelar um nó, basta selecionar isso como uma ação no menu suspenso:
Após definir o número de segundos e confirmar, o nó não será elegível como primário pelo número de segundos definido.
Novos conselheiros do MongoDB
Advisors são miniprogramas que fornecem conselhos sobre questões específicas de banco de dados. Adicionamos três novos consultores para o MongoDB. O primeiro calcula a janela de replicação, o segundo observa a janela de replicação e o terceiro verifica bancos de dados/coleções não fragmentados.
MongoDB Replication Lag Advisor
É muito importante ficar de olho no atraso de replicação, se você estiver dimensionando as leituras adicionando mais secundários. O MongoDB só usará esses secundários se eles não ficarem muito para trás. Se o secundário tiver atraso de replicação, você corre o risco de fornecer dados obsoletos que já foram substituídos no primário.
Para verificar o atraso de replicação, basta conectar-se ao primário e recuperar esses dados usando o comando replSetGetStatus. Ao contrário do MySQL, o primário acompanha o status de replicação de seus secundários.
Implementamos essa verificação em um orientador no ClusterControl, para garantir que seu atraso de replicação seja sempre vigiado.
MongoDB Replication Window Advisor
Assim como o atraso de replicação, a janela de replicação é uma métrica igualmente importante a ser observada. O lag advisor já nos informa o número de segundos que um nó secundário está atrás do primário/mestre. Como o oplog é limitado em tamanho, ter lag escravo impõe os seguintes riscos:
- Se um nó ficar muito atrasado, talvez ele não consiga mais recuperar o atraso, pois as transações necessárias para recuperar o atraso não estão mais no oplog do primário.
- Um nó secundário atrasado é menos favorecido em uma eleição do MongoDB para um novo primário. Se todos os secundários estiverem atrasados na replicação, você terá um problema e um com o menor atraso se tornará o primário.
- Secundários atrasados são menos favorecidos pelo driver MongoDB ao dimensionar leituras com o MongoDB, ele também adiciona uma carga de trabalho maior nos secundários restantes.
Se tivéssemos um nó secundário atrasado por alguns minutos (ou horas), seria útil ter um orientador que nos informasse quanto tempo resta antes que nossa próxima transação seja descartada do oplog. A diferença de tempo entre a primeira e a última entrada no oplog é chamada de Janela de Replicação. Essa métrica pode ser criada buscando o primeiro e o último item do oplog e calculando a diferença de seus timestamps.
No shell do MongoDB, já existe uma função disponível que calcula a janela de replicação para você. No entanto, essa função é incorporada ao shell da linha de comando, portanto, qualquer conexão externa que não use o shell da linha de comando não terá essa função interna. Portanto, criamos um consultor que vigiará a janela de replicação e o alertará se você exceder um limite predefinido.
MongoDB banco de dados não fragmentado e consultor de coleções
Bancos de dados e coleções não fragmentados serão atribuídos a um fragmento primário padrão pelo roteador de fragmentos MongoDB. Isso significa que o banco de dados ou a coleção está limitado ao tamanho desse shard primário e, se gravado em grandes volumes, pode usar todo o espaço em disco restante de um shard. Quando isso acontecer, o shard obviamente não funcionará mais. Portanto, é importante observar todos os bancos de dados e coleções existentes e verificar o banco de dados de configuração para validar se eles foram habilitados para fragmentação.
Para evitar que isso aconteça, criamos um banco de dados não fragmentado e um consultor de coleta. Esse orientador verificará cada banco de dados e coleção e avisará se não tiver sido fragmentado.
ClusterControl melhorou a capacidade de manutenção do MongoDB
Demos um grande passo ao adicionar todas as melhorias aos replicaSets e clusters fragmentados do ClusterControl for MongoDB. Isso melhora muito a usabilidade do MongoDB e permite que DBAs, sysops e devops mantenham seus clusters ainda melhor!
