Lea la inconsistencia de los datos inmediatamente después de escribir con Mongo DB Replication durante el desarrollo real del servicio

Encontré un problema al usar MongoDB mientras desarrollaba un servicio real. El problema era que si los mismos datos se leían inmediatamente después de escribirlos, no se confirmaban. En ese momento no sabía mucho sobre el tema, así que dediqué mucho tiempo y pasé momentos difíciles. Escribí sobre las circunstancias y causas de este problema.

Situación problemática

• En ese momento, la empresa utilizaba principalmente MongoDB en muchos servicios.
• Problemas descubiertos al crear un nuevo servicio y prepararse para el lanzamiento global. Después de la prueba de etapa, se produjo un comportamiento anormal cuando el servicio se puso en producción
  • Las consultas solicitadas desde el servidor fallan de forma intermitente (las consultas del servidor llamadas desde el cliente escriben internamente mongodb y luego leen los datos nuevamente)
  • En funcionamiento normal, los datos escritos deben leerse nuevamente y realizarse la siguiente operación, pero en caso de falla, se encuentra un error en el cliente. *Las consultas se realizan en el siguiente flujo:
    • Llamada del cliente
    • Solicite el servicio AWS del servidor y espere el resultado
    • Escribir resultados en mongodb cuando se complete el servicio de AWS
    • Después de escribir, lea los datos nuevamente desde mongodb y realice las siguientes acciones
  • Al observar la consulta del servicio AWS en el servidor, el servicio AWS estaba funcionando normalmente.
  • Cuando entré directamente a mongodb para verificar la parte de escritura del servidor, los datos realmente existían. En otras palabras, se confirmó que no hubo ningún problema con la operación de escritura.
  • La parte de lectura de la consulta del servidor falló, pero había datos escritos en la base de datos. Una situación donde la corrección fue difícil porque no se conocía la causa exacta.
• No se encontraron anomalías cuando se verificó en el entorno de prueba existente
  • El entorno de prueba se está preparando. En el producto se produjo un fenómeno que no se produjo en absoluto en el momento de la prueba.

Resolución

• Al principio, no se reconoció como una diferencia en el entorno, pero se pensó que era un error en el código y se verificó la lógica. Incluso después de comprobarlo varias veces, no pude encontrar ningún problema importante.
• Seguí comprobando y no pude encontrar una solución, así que pregunté a colegas que sabían más y comprobaron juntos.
  • Es un problema con el que ni siquiera mis compañeros están familiarizados, por lo que lleva algo de tiempo resolverlo.
• En ese momento aprendí un poco sobre BD distribuida y pude deducir el problema.
  • Comparar las diferencias entre escenario y producción para identificar problemas. Al comparar las diferencias, las diferencias fueron las siguientes:
  • En etapa, MongoDB opera en un solo nodo sin replicación.
  • En producción, MongoDB tiene dos nodos secundarios en replicación.
• En el entorno de producción, se configuró un conjunto de réplicas para disponibilidad.
  • En la replicación, MongoDB de producción escribe y luego distribuye los datos al nodo secundario.
  • Dado que no había una configuración separada, si escribe desde db y lee inmediatamente, la operación de lectura se realiza antes de que los datos se propaguen al secundario. secundario pasa datos existentes como valor de respuesta
    • Se confirmó que el tiempo de propagación es de aproximadamente 2 a 4 segundos.
  • Posteriormente, al verificar los datos en mongodb compass, el tiempo de propagación había pasado y los datos escritos durante la lectura eran visibles correctamente.
• Los métodos que surgieron en su momento para solucionar el problema anterior son los siguientes.
  • Espere hasta que el estado de la base de datos cambie mediante el sondeo del cliente. Parecía el método más sencillo.
  • Espere hasta que el estado de la base de datos cambie mediante el sondeo del servidor. Desde la perspectiva del cliente, las consultas existentes se pueden utilizar sin cambios.
  • Garantizar que la propagación a la consulta mongodb se complete y se configure como legible, como consultas o colecciones.
• Probé el segundo método entre los métodos anteriores. En lugar de que la operación de lectura ocurra inmediatamente después de la escritura, se agrega un pequeño retraso entre la escritura y la lectura
  • Compruebe que funciona normalmente después de agregar retraso *A través de esto, aprendí un poco más sobre la teoría CAP.
  • En el caso de una estructura distribuida, tiene tres características: consistencia, disponibilidad y tolerancia a la partición.
  • Para satisfacer uno de coherencia y disponibilidad, no tienes más remedio que renunciar al otro.
    • Cuando se cumple la coherencia: el valor de los datos debe ser el mismo sin importar a cuál de los nodos distribuidos se acceda. Si se rompe la coherencia, se pueden pasar datos diferentes al solicitar una consulta.
    • Cuando se satisface la disponibilidad: proporciona la capacidad de procesar solicitudes normalmente incluso si uno o más nodos distribuidos no se sincronizan.
  • Caso en el que se rompe la coherencia porque la estructura de base de datos actual satisface la disponibilidad.

organizar

• Si la replicación está configurada en la base de datos, tenga cuidado cuando los tiempos de escritura y lectura sean diferentes
• Fue una buena experiencia ver y sentir la teoría CAP con mis propios ojos.
• Estudiemos sobre el servicio que estoy desarrollando cada vez que tenga tiempo. No es posible saberlo todo, pero cuanto más sepa, más útil será para solucionar problemas.
• Tenga en cuenta que el entorno entre el escenario y la producción puede ser diferente. En otras palabras, pueden surgir problemas si hay una diferencia entre el entorno de prueba y el entorno operativo real, y sería mejor pensar en esto con anticipación.
  • Para reducir el tiempo de depuración, sería una buena idea mantener los entornos de producción y escenario casi similares o idénticos.
  • El tiempo también es un costo. Muchas cosas, como los costos laborales y los retrasos en la apertura del servicio, pueden retrasarse o generar costos adicionales. Pensé que estaría bien mantener el escenario y la configuración de producción iguales siempre y cuando el costo no fuera demasiado alto en comparación con el costo del servidor.