Solucionar problemas de clusters fragmentados

Servidores de aplicativos ou As instâncias ficam mongos 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 oferecem alta disponibilidade para os servidores de configuração. Se um servidor de configuração indisponível for o primário, o conjunto de réplicas elegerá um novo primário.

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.

Metadados de fragmentação inconsistentes

A partir do MongoDB 7.0, o comando checkMetadataConsistency está disponível para verificar se há inconsistências e corrupções nos metadados devido a bugs em versões anteriores do MongoDB.

Inconsistências no compartilhamento de metadados podem se originar em casos como:

• clusters atualizados de uma versão pré-5.0 do MongoDB que podem ter corrompido dados de operações de DDL anteriores.

• Intervenções manuais, como manipular o Config Database ou ignorar o mongos para escrever diretamente em um shard.

• Operações de manutenção, como procedimentos de upgrade ou downgrade.

Essas inconsistências podem gerar resultados de query incorretos ou perda de dados.

Para verificar se há inconsistências nos metadados de sharding, execute o comando checkMetadataConsistency:

db.runCommand( { checkMetadataConsistency: 1 } )

{
   cursor: {
      id: Long("0"),
      ns: "test.$cmd.aggregate",
      firstBatch: [
         {
            type: "MisplacedCollection",
            description: "Unsharded collection found on shard different from database primary shard",
            details: {
               namespace: "test.authors",
               shard: "shard02",
               localUUID: new UUID("1ad56770-61e2-48e9-83c6-8ecefe73cfc4")
            }
         }
      ],
   },
   ok: 1
}

Os documentos retornados pelo comando checkMetadataConsistency indicam as inconsistências identificadas pelo MongoDB nos metadados de compartilhamento do cluster.

Para informações sobre documentos de inconsistência retornados pelo comando checkMetadataConsistency, consulte Tipos de inconsistência.