Solucionando problemas de um cluster fragmentado do MongoDB

Selecionar chaves de fragmentação e disponibilidade de cluster

Sharding envolve a divisão de dados em pequenos grupos chamados shards para reduzir a carga de trabalho geral para uma determinada taxa de transferência Operação. Esse agrupamento é obtido através da seleção de uma chave ideal que é principalmente a parte mais importante antes do sharding. Uma chave ideal deve garantir:

1. Os Mongos podem isolar a maioria das consultas a um mongod específico. Se, por exemplo, mais operações estiverem sujeitas a um único shard, a falha desse shard renderizará apenas os dados associados a ele ausentes naquele momento. É aconselhável selecionar uma chave de fragmentação que forneça mais fragmentos para reduzir a quantidade de indisponibilidade de dados caso o fragmento falhe.
2. O MongoDB poderá dividir os dados igualmente entre os pedaços. Isso garante que as operações de taxa de transferência também sejam distribuídas uniformemente, reduzindo as chances de qualquer falha devido ao maior estresse da carga de trabalho.
3. Grave escalabilidade em todo o cluster para garantir alta disponibilidade. Cada fragmento deve ser um conjunto de réplicas, pois, se uma determinada instância do mongod falhar, os membros restantes do conjunto de réplicas serão capazes de eleger outro membro como primário, garantindo assim a continuidade operacional.

Se, em qualquer caso, um determinado fragmento tiver a tendência de falhar, comece verificando quantas operações de taxa de transferência está sujeito e considere selecionar uma chave de fragmentação melhor para ter mais fragmentos.

E se? A instância do Mongos fica ausente

Primeiro verifique se você está se conectando à porta correta, pois você pode ter mudado sem saber. Por exemplo, na implantação com a plataforma AWS, há uma probabilidade desse problema devido aos grupos de segurança que podem não permitir conexões nessa porta. Para um teste imediato, tente especificar o host:port completo para ter certeza de que está usando uma interface de loopback. O bom é que, se cada servidor de aplicativos tiver sua própria instância do mongos, os servidores de aplicativos poderão continuar acessando o banco de dados. Além disso, instâncias mongos têm seus estados alterados com o tempo e podem reiniciar sem necessariamente perder dados. Quando a instância for reconectada, ela recuperará uma cópia do banco de dados de configuração e iniciará as consultas de roteamento.

Certifique-se de que a porta na qual você está tentando se reconectar também não esteja ocupada por outro processo.

E se? Um membro fica ausente do conjunto de réplicas de fragmentos

Comece verificando o status do shard executando o comando sh.status(). Se o resultado retornado não tiver o clusterId, o estilhaço estará realmente indisponível. Sempre investigue interrupções e falhas de disponibilidade e se você não conseguir recuperá-lo no menor tempo possível, crie um novo membro para substituí-lo o mais rápido possível para evitar mais perda de dados.

Se um membro secundário ficar indisponível, mas com entradas de oplog atuais, quando reconectado, ele poderá alcançar o estado definido mais recente lendo os dados atuais do oplog como processo de replicação normal. Se não conseguir replicar os dados, você precisa fazer uma sincronização inicial usando uma dessas duas opções...

1. Reinicie o mongod com um diretório de dados vazio e deixe o recurso de sincronização inicial normal do MongoDB restaurar os dados. No entanto, essa abordagem leva muito tempo para copiar os dados, mas é bastante simples.
2. Reinicie a máquina host com uma cópia de um diretório de dados recente de outro membro do conjunto de réplicas. Processo rápido, mas com etapas complicadas

A sincronização inicial permitirá que o MongoDB...

1. Clone todos os bancos de dados disponíveis, exceto o banco de dados locais. Certifique-se de que o membro de destino tenha espaço em disco suficiente no banco de dados local para armazenar temporariamente os registros de oplog durante o período em que os dados estiverem sendo copiados.
2. Aplicar  todas as alterações ao conjunto de dados usando o oplog da fonte. O processo será concluído somente se o status da réplica mudar de STARTUP2 para SECONDARY.

E se? Todos os membros de um conjunto de réplicas estão ausentes

Os dados mantidos em um fragmento ficarão indisponíveis se todos os membros de um fragmento do conjunto de réplicas ficarem ausentes. Como os outros shards permanecem disponíveis, as operações de leitura e gravação ainda são possíveis, exceto que o aplicativo será servido com dados parciais. Você precisará investigar a causa das interrupções e tentar reativar o fragmento o mais rápido possível. Verifique qual criador de perfil de consulta ou o método de explicação pode ter levado a esse problema.

E se? Dados de configuração obsoletos levam a falhas no cursor

Às vezes, uma instância do mongos pode demorar muito para atualizar o cache de metadados do banco de dados de configuração, levando a uma consulta retornando O aviso:

could not initialize cursor across all shards because : stale config detected

Este erro sempre será apresentado até que as instâncias do mongos atualizem seus caches. Isso não deve se propagar de volta para o aplicativo. Para corrigir isso, você precisa forçar a atualização da instância executando fluRouterConfig.

Para liberar o cache para uma coleção específica, execute

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

Para liberar o cache para uma execução de banco de dados específica

db.adminCommand({ flushRouterConfig: "<db>" } )

Para liberar o cache de todos os bancos de dados e suas coleções, execute:

db.adminCommand("flushRouterConfig")

db.adminCommand( { flushRouterConfig: 1 } )

E se? Servidor de configuração fica indisponível

O servidor de configuração neste caso pode ser considerado como o membro primário a partir do qual os nós secundários replicam seus dados. Se ele se tornar ausente, os nós secundários disponíveis terão que eleger um entre seus membros para se tornar o principal. Para evitar uma situação em que talvez você não tenha um servidor de configuração, considere distribuir os membros do conjunto de réplicas em dois data centers desde...

• Se um data center ficar inativo, os dados ainda estarão disponíveis para leituras em vez de nenhuma operação se você tiver usado um único data center .
• Se o data center que envolve membros minoritários ficar inativo, o conjunto de réplicas ainda poderá atender a operações de gravação e leitura.
l>

É aconselhável distribuir os membros em pelo menos três data centers.

Outra possibilidade de distribuição é distribuir uniformemente os membros portadores de dados pelos dois centros de dados e membros restantes em a nuvem.

Corrigindo erro de string de banco de dados

A partir do MongoDB 3.4, os servidores de configuração SCCC não são suportados para instâncias mongod espelhadas. Se você precisar atualizar seu cluster fragmentado para a versão 3.4, precisará converter os servidores de configuração de SCCC para CSRS.

Evitando tempo de inatividade ao mover servidores de configuração

O tempo de inatividade pode ocorrer como resultado de alguns fatores, como falta de energia ou frequências de rede, resultando no falha de um servidor de configuração para o cluster. Use CNAME para identificar esse servidor para renomear ou renumerar durante a reconexão. Se o comando moveChunk commit falhar durante o processo de migração, o MongoDB reportará o erro:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of

<N>|<NN>" and "ERROR: TERMINATING"

Isso significa que o shard também não foi conectado ao banco de dados de configuração, portanto, o primário encerrará este membro para evitar inconsistência de dados. Você precisa resolver a falha de migração do fragmento de forma independente, consultando o suporte do MongoDB. Certifique-se também de fornecer alguns recursos estáveis, como rede e energia, para o cluster.

Conclusão

Um cluster fragmentado do MongoDB reduz a carga de trabalho sobre a qual um único servidor teria sido submetido, melhorando assim o desempenho das operações de rendimento. No entanto, a falha em configurar alguns parâmetros corretamente, como selecionar uma chave de fragmentação ideal, pode criar um desequilíbrio de carga, portanto, alguns fragmentos acabam falhando.

Supondo que a configuração seja feita corretamente, alguns contratempos inevitáveis, como falta de energia, também podem ocorrer. Para continuar dando suporte ao seu aplicativo com o mínimo de tempo de inatividade, considere usar pelo menos 3 data centers. Se um falhar, os outros estarão disponíveis para dar suporte a operações de leitura se o primário estiver entre os membros afetados. Atualize também seu sistema para pelo menos a versão 3.4, pois ele suporta mais recursos.