2012-04-16 638 views
6

Aquí es mi opinión, y no estoy seguro de si es bueno o malo:¿Cómo funciona el trabajo diario MongoDB

El registro diario es el "rehacer" log. Registra la modificación de los archivos de datos.

Por ejemplo, quiero cambiar el valor del campo de un registro de 'a' a 'b', entonces el mongodb encontrará cómo modificar el archivo db (incluya todo el espacio de nombres, datos, índice, etc.), entonces mongodb escribe las modificaciones al diario.

Después de eso, mongodb realiza todas las modificaciones reales en el archivo de db. Si algo sale mal aquí, cuando mongoDB se reinicie, leerá el diario (si existe). Luego cambiará el alter the dbfile para hacer que el conjunto de datos sea consistente.

Por lo tanto, en el diario, no se registran los datos para cambiar, sino cómo cambiar el archivo de db.

¿Estoy en lo cierto? ¿Dónde puedo obtener más información sobre el formato de la revista?

+0

Puede leer el código fuente. Es la fuente de información más confiable. –

+0

Gracias por su sugerencia, en realidad estoy leyendo ahora. Pero costará demasiado tiempo, simplemente quiero la respuesta ahora. – iammutex

+0

¿Por qué es crítico? –

Respuesta

6

EDITAR: mi enlace original a una presentación de 2011 en MongoSF por Dwight ha muerto, pero hay un 2012 presentation de Ben Becker con contenido similar.

Sólo en caso de que deja de funcionar en algún momento también, daré un breve resumen de cómo la revista en el motor original de almacenamiento MMAP funcionó, pero hay que señalar que con la llegada del modelo pluggable storage engine (MongoDB 3.0 y más adelante), esto ahora depende completamente del motor de almacenamiento (y potencialmente de las opciones) que esté utilizando, así que por favor verifique.

Volver al original (MMAP) diario del motor de almacenamiento. A un nivel muy rudimentario, el diario contiene una serie de operaciones en cola y todas las operaciones se escriben a medida que ocurren, básicamente, anexan solo escritura secuencial al disco.

Una vez que se han aplicado y enjuagado estas operaciones en el disco, ya no se necesitan en el diario y se pueden superar. En este sentido, la revista básicamente actúa como un buffer circular para operaciones de escritura.

Internamente, las operaciones en el diario se almacenan en "grupos de confirmación", un grupo lógico de operaciones de escritura. Una vez que una operación se encuentra en un grupo de confirmación completo, se puede considerar que está sincronizada en el disco como parte del diario (y cumplirá con la preocupación de escritura j:true, por ejemplo). Después de un cierre sucio, mongod intentará aplicar todos los grupos de confirmación completos que no hayan sido descargados previamente en el disco, los grupos de compromiso incompletos serán descartados.

Las operaciones en el diario no son lo que verá en el oplog, sino que son un conjunto más simple de archivos, desplazamientos (ubicaciones de disco esencialmente) y datos a escribir en la ubicación. Esto permite una reproducción eficiente de los datos y un formato compacto para la revista, pero hará que los contenidos parezcan un galimatías para la mayoría (a diferencia del oplog mencionado anteriormente, que es básicamente legible como documentos JSON). Esto básicamente responde a una de las preguntas planteadas: no tiene conocimiento del contenido del archivo de la base de datos ni de los cambios que se le deben hacer, es incluso más simple; básicamente, solo sabe ir a la ubicación del disco X y escribir datos Y, Eso es. La escritura secuencial del diario significa que encaja muy bien en un disco giratorio y el patrón de acceso secuencial generalmente estará en desacuerdo con los patrones de acceso a datos MMAP (aunque no necesariamente los patrones de acceso de otros motores) . Por lo tanto, a veces es una buena idea colocar el diario en su propio disco o partición para reducir la contención de IO.

+0

enlace roto. arregla – blueskin

+1

@blueskin - pregunta y recibirás –

Cuestiones relacionadas