Timeout de Balancer de MongoDB com réplica atrasada

Question

Temos uma configuração de dois fragmentos de MongoDB. Cada fragmento contém um mestre, um escravo, um escravo de 24 horas de escravo e um árbitro. No entanto, o balanceador falha em migrar qualquer fragmento que aguarde o tardio do escravo migrar. Eu tentei definir _secondarythrottle como false na configuração Balancer, mas ainda tenho o problema.

Parece que a migração continua por um dia e depois falha (uma tonelada de mensagens de escravos de espera nos logs). Eventualmente, desiste e inicia uma nova migração. A mensagem diz esperar por 3 escravos, mas o escravo de atraso está oculto e o PRIO 0, para que deve esperar por isso. E se o _Secondarythrottle funcionou, não deve esperar por nenhum escravo, certo?

Tem sido assim há alguns meses, então a configuração deveria ter sido recarregada em todos os moscas. Alguns dos mostras de mosca que administram o balanceamento foram restauradores recentemente.

Alguém tem alguma idéia de como resolver o problema, não tivemos esses problemas antes de iniciar o escravo atrasado, mas é apenas a nossa teoria.

Config:

{ "_id" : "balancer", "_secondaryThrottle" : false, "stopped" : false }

Log do processo SHARD1 Master:

migrateThread] warning: migrate commit waiting for 3 slaves for 'xxx.xxx' { shardkey: ObjectId('4fd2025ae087c37d32039a9e') } -> {shardkey: ObjectId('4fd2035ae087c37f04014a79') } waiting for: 529dc9d9:7a [migrateThread] Waiting for Replicação para recuperar o atraso antes de entrar na seção crítica

Log do processo mestre Shard2:

Ter 3 de dezembro de 14: 52: 25.302 [Conn1369472] MOVECHUNK Data Transfer Progress: {Active: true, ns: "xxx.xxx", de: "shard2/mongo2: 27018, mongob2: 27018", min: {shardkey: objectId (ObjectId ( '4fd2025ae087c37d32039a9e') }, max: { shardkey: ObjectId('4fd2035ae087c37f04014a79') }, shardKeyPattern: { shardkey: 1.0 }, state: "catchup", counts: { cloned: 22773, clonedBytes: 36323458, catchup: 0, steady: 0}, ok: 1.0} meu mem usado: 0

ATUALIZAÇÃO: Confirmei que a remoção do Slavedelay fez o balanceador funcionar novamente. Assim que eles se submetem a speed pedaços se moveram. Portanto, o problema parece estar relacionado ao Slavedelay. Eu também confirmei que o balanceador corre com "secundário": false. Parece esperar os escravos de qualquer maneira.

Shard2:

Tue Dec 10 11: 44: 25.423 [MigrateThread] Aviso: Migre Commit, esperando por 3 escravos para 'xxx.xxx' {shardKey: objectId ('4ff1213ee087c3516b2f703f')} -> {shardKey: objectId ('442222f703f')} -> {shardDidid ('4 4 52A6F089: 81

Ter 10 de dezembro 11: 44: 26.423 [MigrateThread] Aguardando a replicação para recuperar o atraso antes de entrar na seção crítica

Ter 10 de dezembro 11: 44: 27.423 [MigrateThread] Aguardando a replicação para recuperar o atraso antes de entrar na seção crítica

Ter 10 de dezembro 11: 44: 28.423 [MigrateThread] Aguardando a replicação para recuperar o atraso antes de entrar na seção crítica

Ter 10 de dezembro 11: 44: 29.424 [MigrateThread] Aguardando a replicação para recuperar o atraso antes de entrar na seção crítica

Ter 10 de dezembro 11: 44: 30.424 [MigrateThread] Aguardando a replicação para recuperar o atraso antes de entrar na seção crítica

Ter 10 de dezembro 11: 44: 31.424 [MigrateThread] Aguardando a replicação para recuperar o atraso antes de entrar na seção crítica

Tue Dec 10 11:44:31.424 [migrateThread] migrate commit succeeded flushing to secondaries for 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }

TUE DEC 10 11: 44: 31.425 [MigrateThread] Migre CommitiEn Lanke to Journal for 'xxx.xxx' {shardKey: objectId ('4ff1213ee087c3516b2f703f')} -> {shardKey: objectId ('4ff12A5Eddf2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B.

Tue Dec 10 11:44:31.647 [migrateThread] migrate commit succeeded flushing to secondaries for 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }

TUE DEC 10 11: 44: 31.667 [MigrateThread] Migre CommitiE Lanke to Journal para 'xxx.xxx' {shardKey: objectId ('4ff1213ee087c3516b2f703f')} -> {shardKey: objectId ('4ff12A5Eddf2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B.

Answer 1

O balanceador está aguardando adequadamente a maioria do conjunto de réplicas do Shard de destino para que os documentos fossem migrados antes de iniciar a exclusão desses documentos no fragmento de origem.

A questão é que você tem quatro membros em seu conjunto de réplicas (mestre, escravo, escravo de atraso de 24 horas e um árbitro). Isso significa que três são a maioria. Não sei por que você adicionou um árbitro, mas se você o remover, dois serão a maioria e o balanceador não terá que esperar pelo escravo atrasado.

A maneira alternativa de alcançar o mesmo resultado é configurar o escravo atrasado com votes:0 propriedade e deixe o árbitro como o terceiro nó de votação.

Answer 2

Qual versão você está executando? Há um bug conhecido em 2.4.2 e abaixo, bem como 2.2.4 e abaixo que causa uma contagem incorreta do número de secundários no conjunto (e, portanto, torna impossível satisfazer o padrão W: Maioria Escreva para a migração). Este é o bug (corrigido em 2.4.3+ e 2.2.5+):

https://jira.mongodb.org/browse/server-8420

Desligar o acelerador secundário deve ser uma solução alternativa válida, mas você pode querer fazer um flushRouterConfig em qualquer mongos processos (ou apenas reinicie todos os mongos processos) para garantir que a configuração esteja entrando em vigor para suas migrações, especialmente se elas estiverem levando um dia a tempo. Como outra correção em potencial antes da atualização, você também pode soltar a coleção Local.Slaves (será recriado).