Tiempo de espera del equilibrador MongoDB con réplica retrasada

Question

Tenemos una configuración de dos fragmentos MongoDB. Cada fragmento contiene un maestro, un esclavo, un esclavo de retraso de esclavos de 24 h y un árbitro. Sin embargo, el equilibrador no migra los fragmentos que esperan que el esclavo retrasado migre. He intentado configurar _secundarythrottle en falso en la configuración del equilibrador, pero todavía tengo el problema.

Parece que la migración continúa por un día y luego falla (una tonelada de mensajes de esclavos en los registros). Finalmente se da por vencido y comienza una nueva migración. El mensaje dice que esperar a 3 esclavos, pero el esclavo de retraso está oculto y Prio 0, por lo que debe esperar a ese. Y si el _secundariothottle funcionó, no debería esperar a ningún esclavo, ¿verdad?

Ha sido así durante unos meses, por lo que la configuración debería haber sido recargada en todas las mongosis. Algunos de los Mongosis que ejecutan el Balancer han sido recientemente.

¿Alguien tiene alguna idea de cómo resolver el problema? No tuvimos estos problemas antes de comenzar el esclavo retrasado, pero es solo nuestra teoría.

Configuración:

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

Registre desde el proceso maestro Shard1:

migrateThread] warning: migrate commit waiting for 3 slaves for 'xxx.xxx' { shardkey: ObjectId('4fd2025ae087c37d32039a9e') } -> {shardkey: ObjectId('4fd2035ae087c37f04014a79') } waiting for: 529dc9d9:7a [migrateThread] Waiting for Replicación para ponerse al día antes de ingresar a la sección crítica

Registre desde el proceso maestro de Shard2:

Martes 3 14: 52: 25.302 [Conn1369472] Movechunk Data Transfer Progress: {Active: True, NS: "xxx.xxx", de: "Shard2/Mongo2: 27018, Mongob2: 27018", Min: {Shardkey: ObjectID (ObjectID (ObjectId ( '4fd2025ae087c37d32039a9e')}, max: {shardkey: objectId ('4fd2035eAe087c37f04014a79')}, shardKeyPattern: {shardkey: 1.0}, estado: "CACKUNT", cuenta: {Cloneded: CLONEDBYY 0}, OK: 1.0} Mi mem usó: 0

ACTUALIZACIÓN: Confirmé que eliminar Slavedelay hizo que el equilibrador funcionara nuevamente. Tan pronto como se pusieron para acelerar los trozos. Entonces, el problema parece estar relacionado con SlaVedelay. También confirmé que el Balancer corre con "SecondarioThrottle": False. Parece esperar a los esclavos de todos modos.

Fragmento2:

Martes 10 de diciembre 11: 44: 25.423 [migratethread] advertencia: migrar compromiso esperando 3 esclavos para 'xxx.xxx' {shardkey: objectId ('4ff1213ee087c3516b2f703f')} -> {shardkey: objectId ('4ff12a5eddf2b32dff1e7' ') 52A6F089: 81

Martes 10 de diciembre 11: 44: 26.423 [migratethread] esperando que la replicación se ponga al día antes de ingresar a la sección crítica

Martes 10 de diciembre 11: 44: 27.423 [migratethread] esperando que la replicación se ponga al día antes de ingresar a la sección crítica

Martes 10 de diciembre 11: 44: 28.423 [migratethread] esperando que la replicación se ponga al día antes de ingresar a la sección crítica

Martes 10 de diciembre 11: 44: 29.424 [migratethread] esperando que la replicación se ponga al día antes de ingresar a la sección crítica

Martes 10 de diciembre 11: 44: 30.424 [migratethread] esperando que la replicación se ponga al día antes de ingresar a la sección crítica

Martes 10 de diciembre 11: 44: 31.424 [migratethread] esperando que la replicación se ponga al día antes de ingresar a la sección crítica

Martes 10 de diciembre 11: 44: 31.424 [migratethread] Migrate Commit Succesed Flushing a secundarios para 'xxx.xxx' {shardkey: objectId ('4ff1213ee087c3516b2f703f')} -> {shardkey: objectId ('4ff12a5eddf2b32dff1e7e7')

Martes 10 de diciembre 11: 44: 31.425 [migratethread] migrate Commit Flushed a Journal para 'xxx.xxx' {ShardKey: ObjectId ('4ff1213ee087c3516b2f703f')} -> {ShardKey: ObjectId ('4ff12a5eddf2b32dff1e7Bea')})})

Martes 10 de diciembre 11: 44: 31.647 [migratethread] Migrate Commit Succesed Flushing a secundarios para 'xxx.xxx' {shardkey: objectId ('4ff1213ee087c3516b2f703f')} -{shardkey: objectId ('4ff12a5eddf2b32dff1e7e7')

Martes 10 de diciembre 11: 44: 31.667 [migratethread] migrate Commit Flushed a Journal para 'xxx.xxx' {ShardKey: ObjectID ('4ff1213ee087c3516b2f703f')} -> {ShardKey: ObjectID ('4FF12A5EDF2B32DFF1E7Bea')})})

Answer 1

El equilibrador está esperando adecuadamente que la mayoría del conjunto de réplicas del fragmento de destino haga que los documentos se migren antes de iniciar la eliminación de esos documentos en el fragmento de origen.

El problema es que tiene cuatro miembros en su conjunto de réplicas (maestro, un esclavo, un esclavo de retraso de esclavos de 24 h y un árbitro). Eso significa que tres es la mayoría. No estoy seguro de por qué agregó un árbitro, pero si lo elimina, dos serán la mayoría y el equilibrador no tendrá que esperar al esclavo retrasado.

La forma alternativa de lograr el mismo resultado es configurar el esclavo retrasado con votes:0 propiedad y dejar el árbitro como el tercer nodo de votación.

Answer 2

¿Qué versión estás ejecutando? Hay un error conocido en 2.4.2 y debajo, así como 2.2.4 y por debajo de eso provoca un recuento incorrecto del número de secundarios en el conjunto (y por lo tanto hace que sea imposible satisfacer el valor predeterminado W: mayoría escribir para la migración). Este es el error (corregido en 2.4.3+ y 2.2.5+):

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

Apagar el acelerador secundario debe ser una solución válida, pero es posible que desee hacer un flushrouterconfig en cualquier mongos procesos (o simplemente reinicie todos los mongos Procesos) para asegurarse de que la configuración esté en vigencia para sus migraciones, especialmente si están tomando un día a tiempo. Como otra solución potencial antes de la actualización, también puede Deja caer la colección local. Slaves (Será recreado).