¿Cuál es la preocupación de escritura predeterminada de mongod en qué versión?

La preocupación de escritura predeterminada en MongoDB ha sido w:1 desde MongoDB 2.2 en 2012.

Hay tres configuraciones diferentes que puede usar para configurar el problema de escritura en las versiones actuales de MongoDB (versión 3.2.6 y posteriores):

• w ajuste :cuántos nodos deben reconocer la escritura antes de declararla exitosa. El valor predeterminado es 1, lo que significa que el reconocimiento del nodo principal es suficiente.
• j ajuste :¿las escrituras deben ser registradas antes de ser reconocidas? El valor predeterminado depende de writeConcernMajorityJournalDefault .
• writeConcernMajorityJournalDefault :si especifica w:majority escriba la configuración de preocupación para sus escrituras sin configurar j , cuál es el j implícito ¿valor? El valor predeterminado es true (las escrituras deben registrarse en la mayoría de los nodos de votación antes de que se reconozcan).

También hay un wtimeout ajuste para configurar cuánto tiempo debe esperar MongoDB para que se satisfaga el problema de escritura antes de informar al cliente que no se ha reconocido la escritura. De lo contrario, las escrituras que esperan que se satisfaga el problema de escritura pueden esperar para siempre en lugar de fallar.

La configuración especial aquí es w:majority . Esto significa que las escrituras deben propagarse a la mayoría de los nodos de votación (y también a sus diarios) en un conjunto de réplicas para ser reconocido. Podría decirse que esta es la configuración más segura a la vez que proporciona un buen rendimiento, porque:

• Evita que las escrituras reconocidas se reviertan en caso de fallas.
• Regula el rendimiento de la aplicación para que no envíe escrituras más rápido de lo que puede manejar el conjunto de réplicas (debido a restricciones de hardware, situación de la red, etc.).

Como ha imaginado, los nodos de votación incluyen el árbitro . Por lo tanto, en un conjunto de réplicas con configuración de árbitro primario-secundario, w:majority podría fallar en un escenario donde:

• Uno de los nodos que contienen datos está fuera de línea por algún motivo.
• El conjunto de réplicas todavía está en línea con un principal grabable, ya que la topología ahora es un árbitro principal sin conexión.
• Escribe con w:1 tendrá éxito como de costumbre, pero esas escrituras podrían revertirse (ya que no se escribió en la mayoría de los nodos que contienen datos de votación).
• Dado que el árbitro no lleva datos, w:majority las escrituras fallarán (o esperarán indefinidamente) ya que el árbitro se cuenta como un nodo de votación.

Por esta razón, no se recomienda usar un árbitro si planea usar w:majority en su aplicación.

Tenga en cuenta que tampoco se recomienda usar un árbitro en un conjunto de réplicas de 3 nodos que forma un fragmento en un clúster fragmentado, ya que los movimientos de fragmentos requieren w:majority . Tener una falla en un nodo portador de datos en un fragmento será perjudicial para las operaciones de migración de fragmentos.