Solucionar problemas de clusters fragmentados

Servidores de aplicativos ou mongos As instâncias ficam indisponíveis

Se cada servidor de aplicativo tiver sua própria instância do mongos, outros servidores de aplicativo poderão continuar a acessar o banco de dados. Além disso, as instâncias do mongos não mantêm o estado persistente e podem reiniciar e se tornar indisponíveis sem perder qualquer estado ou dados. Quando uma instância do mongos inicia, ela recupera uma cópia do banco de dados de configuração e pode iniciar queries de roteamento.

Um único membro se torna indisponível em um conjunto de réplicas de shard

Conjuntos de réplicas fornecem alta disponibilidade para shards. Se o mongod indisponível for um primário, o conjunto de réplicas elegerá um novo primário. Se o mongod indisponível for um secundário e ele se desconectar, o primário e o secundário continuarão a manter todos os dados. Em um conjunto de réplicas de três membros, mesmo que um único membro do conjunto sofra uma falha catastrófica, dois outros membros terão cópias completas dos dados. [1]

Sempre investigue interrupções e falhas de disponibilidade. Se um sistema não for recuperável, substitua-o e crie um novo membro do conjunto de réplicas assim que possível para substituir a redundância perdida.

Todos os membros de um shard ficam indisponíveis

Em um cluster fragmentado, as instâncias mongod e mongos monitoram os conjuntos de réplicas no cluster fragmentado (por exemplo, conjunto de réplicas de shards, conjunto de réplicas de servidores de configuração).

Se todos os membros de um shard do conjunto de réplicas não estiverem disponíveis, todos os dados mantidos nesse shard não estarão disponíveis. No entanto, os dados em todos os outros shards permanecerão disponíveis, e é possível ler e gravar dados nos outros shards. No entanto, seu aplicativo deve ser capaz de lidar com resultados parciais, e você deve investigar a causa da interrupção e tentar recuperar o shard o mais rápido possível.

Um membro do conjunto de réplicas do servidor de configuração fica indisponível

Os conjuntos de réplicas fornecem alta disponibilidade para os servidores de configuração. Se um servidor de configuração indisponível for um primary, o conjunto de réplicas escolherá um novo primary.

Se o servidor de configuração do conjunto de réplicas perder seu primário e não puder eleger um principal, os metadados do cluster se tornarão somente leitura. Você ainda pode ler e gravar dados dos shards, mas nenhuma migração de bloco ou divisões de blocos ocorrerá até que um primário esteja disponível.

Falha do cursor devido a dados de configuração desatualizados

Uma query gera o seguinte aviso quando uma ou mais instâncias do mongos ainda não atualizou seu cache dos metadados do cluster a partir do banco de dados de configuração:

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

Este aviso não deve ser propagado de volta ao seu aplicativo. O aviso será repetido até que todas as instâncias do mongos atualizem seus caches. Para forçar uma instância para atualizar seu cache, execute o comando flushRouterConfig.

Chaves de fragmentação

Para solucionar problemas de uma chave shard, consulte Solução de problemas de chaves shard.

Disponibilidade do cluster

Para garantir a disponibilidade do cluster:

• Cada shard deve ser um conjunto de réplicas; se uma instância mongod específica falhar, os membros do conjunto de réplicas elegerão outra para ser a principal e continuar a operação. No entanto, se um shard inteiro não puder ser acessado ou falhar por algum motivo, esses dados ficarão indisponíveis.

• A chave de shard deve permitir que mongos isole a maioria das operações em um único shard. Se as operações puderem ser processadas por um único shard, a falha de um único shard tornará apenas alguns dados indisponíveis. Se as operações precisarem acessar todos os shards para queries, a falha de um único shard tornará o cluster inteiro indisponível.

Config Database String Error

Os servidores de configuração devem ser implantados como conjuntos de réplicas. As instâncias mongos do cluster devem especificar o mesmo nome de conjunto de réplicas do servidor de configuração, mas podem especificar o nome do host e a porta de diferentes membros do conjunto de réplicas.

Com versões anteriores de clusters fragmentados do MongoDB que utilizam a topologia de três instâncias do mongod espelhadas para servidores de configuração, as instâncias do mongos em um cluster fragmentado devem especificar uma string configDB idêntica.

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

Use CNAMEs para identificar seus servidores de configuração no cluster. Dessa forma, é possível renomear e renumerar seus servidores de configuração sem tempo de inatividade.

moveChunk commit failed Erro

Ao final de uma migração de chunk, o shard deve se conectar ao banco de dados de configuração para atualizar o registro do chunk nos metadados do cluster. Se o shard não conseguir se conectar ao banco de dados de configuração, o MongoDB reportará o seguinte erro:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of
<N>|<NN>" and "ERROR: TERMINATING"

Quando isso acontece, o membro principal do conjunto de réplicas do shard é encerrado para proteger a consistência dos dados. Se um membro secundário puder acessar o banco de dados de configuração, os dados no shard poderão ser acessados novamente após uma eleição.

O usuário precisará resolver a falha de migração de parte de forma independente. Se você encontrar esse problema, peça à MongoDB Community ou ao Suporte do MongoDB para resolver esse problema.