MySQL ejecución de actualización de flujo para hacer de nuevo conocimiento profundo de registro

Anteriormente hemos analizado un proceso de ejecución de la consulta, y explica los módulos involucrados en el proceso de implementación. Una consulta a través de un conector generalmente analizador, optimizador, ejecutor y otros módulos funcionales, y finalmente al motor de almacenamiento. Hierro viejo puede hacer clic en un enlace de consulta en MySQL cómo realizar las piezas de contenido de aprendizaje.

Esta vez, tenemos que aprender una instrucción de actualización a fondo en el proceso de implementación de MySQL. Que a través de este artículo podemos entender plenamente lo que es Redo Log

Crear una estructura de tabla

En primer lugar, vamos a crear una tabla, sólo el ID de clave primaria, y un campo de tipo int c.

create table T(ID int primary key, c int);

Ahora queremos poner al día una declaración de datos es el siguiente:

update T set c=c+1 where ID=2;

De hecho, la instrucción de actualización con el proceso de consulta es similar, pero más de registro de rehacer, deshacer y log log binario.

Anterior proceso de ejecución de la consulta que hemos dicho, una época más reciente, relacionado con esta tabla de caché de consulta fallará sobre una mesa, por lo que esta declaración se traducirá caché enteras las tablas T están vacíos. Esta es también la razón por la que usamos la caché de consultas no se recomienda.

Libros y tablero de contabilidad

Si usted como propietario de un pequeño supermercado, naturalmente, habrá unos libros de registro de transacciones, pero puede tener un historial de crédito. Debido a que el pueblo tiene una niña llamada Xiaofang, se ve hermosa y buen corazón. A veces vienen a puta blanca, la cantidad no lo es, es el crédito. Su primer registro escrito en pequeña placa de color rosa, como la oscuridad de la noche cuando el tablero puso el polvo de la sincronización de datos para archivar sus libros. Por supuesto, hay placa de polvo está lleno, por lo que cuando la placa es la reconciliación en polvo completa escribirá los libros,

Por lo tanto, si la gente quiere venir a crédito, o si es tiempo de amortización, por lo general hay dos enfoques:

1. Directamente a los libros resultó que, esta vez para añadir a crédito o deducción.
2. En la primera nota de la junta polvo de cuentas, y otra después de cerrar los libros de contabilidad resultado.

En los negocios ocupado, sin duda elige este último, porque el primero es el funcionamiento demasiado engorroso. En primer lugar, usted tiene que encontrar crédito total de esa persona ese registro. Pensar en ello, de páginas de densa docenas, tesorero para encontrar el nombre, pero
luego tienen que llevar gafas de lectura puede encontrar poco a poco, y luego encontrar a cabo el cálculo del ábaco, a continuación, el resultado final se vuelve a escribir los libros. Esta vez Xiaofang al crédito, y así sucesivamente durante mucho tiempo. Después de aproximadamente Xiaofang también la forma de arboleda que?

En MySQLtambién tienen este problema, si cada operación debe ser escrito en el disco, el disco debe entonces encontrar el registro correspondiente antes de la actualización. IO costo de todo el proceso, los costos son altos consulta, con el fin de resolver este problema, MySQLlos diseñadores utilizan un pequeño supermercado jefe similares ideas de la placa de color rosa para mejorar la eficiencia de actualización.

La junta polvo y los libros con todo el proceso, de hecho, MySQL que a menudo viene a la WALtecnología, WALel nombre completo es Write-Ahead Logging, es el punto clave es escribir primero el registro, de escritura en disco, que es el primero en tablero de polvo de escritura, por lo que en caso de ocupado de nuevo escribir libros.

registro de rehacer

En primer lugar, debe quedar claro que binlogel registro se encuentra en la capa de servidor, y redo loges InnoDBúnico.

Cuando hay una necesidad de registro para ser actualizados, InnoDBel motor va a escribir el primer registro redo log(hoja rosa) y las actualizaciones de la memoria, esta vez incluso completado. Al mismo tiempo, el motor va a ser en el momento apropiado se actualizará este registro en el disco, y las actualizaciones del sistema son a menudo de tiempo relativamente inactivo, eso es lo que la viabilidad futura del tesorero de hacer.

Similares, InnoDB registro de rehacer de tamaño fijo, como se puede configurar como un conjunto de cuatro archivos, cada archivo es de 1 GB, entonces esta "hoja rosa" será un total de 4 GB de la operación de grabación. Escrito desde cero, se escribe en la parte posterior final al principio del ciclo de escritura, como se muestra en el siguiente diagrama.

pos de escritura es la posición del registro actual, mientras que el lado de escritura del cambio, escribir al número 3 después del final de la parte posterior archivo al principio 0 archivos. puesto de control es borrar la ubicación actual, sino que también va y ciclos, debe actualizarse para grabar archivos de datos antes de borrar registros.

Y entre los pos puesto de control de escritura es la parte vacía "hoja rosada" también se puede utilizar para grabar una nueva operación. Si se escribe pos captura puesto de control, dijo que "la hoja rosada" completo, esta vez ya no se puede realizar una nueva actualización, tuvo que parar para limpiar algunos registros, el puesto de control promueven.

Con el registro de rehacer, la base de datos InnoDB puede garantizar que incluso reinicio anormal, antes de presentar el registro se perderá esta capacidad se llama Crash-Safe .

Para entender este concepto de choque de seguridad, considere el ejemplo de nuestro historial de crédito anterior. Mientras los registros de crédito registradas en el tablero de polvo o escritas en los libros, incluso después de que el tesorero se olvide, tales como el cierre repentino de unos pocos días, después de la reanudación de las cuentas de crédito del negocio puede todavía claramente a través de libros y datos de la placa de color rosa.

binlog

MySQL arquitectura general de hecho, hay dos: una es la capa de servidor, hay una capa de motor, se encarga de almacenar relevante. Anteriormente hemos mencionado redo logque InnoDBla sentina del motor, y la capa de servidor tiene su propia revista, llamada binlog (registro de archivo).

Así que por qué tener dos log ella?

Desde el principio no tiene motor InnoDB de MySQL. propio motor de MySQL es MyISAM, pero
MyISAM no puede permitirse a chocar-safe (porque el motor es de capa de servidor y la capa son dos módulos separados), registro de binlog sólo se puede utilizar para archivar. La introducción de MySQL InnoDB es otra empresa en forma de plug-ins, ya que sólo se basan en binlog no es la capacidad de choque de seguridad, por lo que InnoDB utiliza otro conjunto de sistema de registro - es decir, registro de rehacer para lograr la capacidad de choque de fallos.

Si sólo se binlog, cuando la capa de nivel motor del servidor binlog rollizo acabado todavía sincronizado con el disco en el poder. Esta vez, después de la operación de actualización de registro reinicio binlog, pero el motor no fue escrito para la capa de disco ha llevado al uso inconsistente de la biblioteca de la sincronización de datos binlog.

registro de rehacer, las diferencias binlog

1. motor de rehacer registro InnoDB es único; binlog es la implementación de la capa de MySQL Server, todos los motores se pueden utilizar.
2. rehacer físico de registro de registro de registro es "se ha hecho datos en un cambio de página"; registro lógico binlog registra la lógica original de la frase, tal como "a campo ID = c 2 de esta línea más uno" .
3. registro de rehacer está escrito en la circulación, espacio fijo se acabará; binlog puede anexar por escrito. "Adicionales de escritura" se refiere al archivo binlog escrito a un cierto tamaño, se cambiará a la siguiente y no sobrescribe el registro anterior.

Actualización proceso de ejecución de la sentencia

Con el concepto de dos comprensión de registro, podemos continuar a entender los procesos internos del actuador cuando el motor InnoDB lleva a cabo la instrucción de actualización.

1. capa actuador servidor eliminó a llamar a la ID del motor = 2 esta línea. ID es la clave principal, motor de búsqueda de árbol para encontrar el uso directo de la línea. Si ID = 2 páginas de datos en esta línea ya está en la memoria, se devuelve directamente al actuador, de lo contrario, necesitan empezar a disco en la memoria, y viceversa.
2. Actuador para obtener el valor de datos + 1, para obtener una nueva línea de datos, a continuación, llamar a este motor de almacenamiento línea de escribir una nueva interfaz de datos.
3. actualización del motor InnoDB estas filas de datos en la memoria, mientras que las páginas de registro afectados por esta actualización de registros en el registro de rehacer, a continuación, acceder preparar estado, entonces le dice a los actuadores es completo, listo para confirmar la transacción.
4. Actuadores generan binlog esta operación, y el binlog escriben en el disco.
5. actuadores estatales siguen pidiendo el motor de interfaz de presentación del motor de transacción recibe una petición para poner acaba de escribir el registro de rehacer en la sumisión (commit), la actualización se ha completado.

Los tres últimos pasos se ven un poco "en torno", escribe la división de registro de rehacer en dos pasos:
"confirmación de dos fases" preparar y perpetrar, este es el

Como se muestra en verde para actuadores abajo, el blanco representa motor InnoDB para llevar a cabo:

Confirmación en dos fases

¿Por qué tiene que haber "en dos fases" significa? Esto es por lo que lógicamente consistentes entre dos troncos. Para ilustrar este problema, tenemos que hablar sobre esta cuestión desde el principio del artículo: cómo hacer que la base de datos de vuelta al estado durante dos semanas en un mismo segundo?

Anteriormente hablamos, binlog registrará todas las operaciones lógicas, y es en forma de "adicionales de escritura". Si su DBA prometido un plazo de dos semanas puede ser restaurado, el sistema de copia de seguridad guardará todas las últimas semanas el
binlog, y el sistema hará toda la copia de seguridad de forma regular. Aquí es un "regular" dependen de la importancia del sistema, se puede preparar un día, una semana se puede preparar.

Cuando es necesario restaurar un segundo especificados, como el mediodía el día dos de la tarde me encontré una vez por error elimina la tabla, necesidad de recuperar los datos, se puede hacer esto:

1. En primer lugar, encontrar la copia de seguridad completa más reciente, si tiene suerte, puede ser que sea una copia de seguridad de anoche, esta copia de seguridad para recuperar desde el repositorio temporal;
2. Luego, a partir del punto de tiempo de la copia de seguridad, binlog una copia de seguridad tomado secuencialmente, puso el tiempo de pesada antes del mediodía por error elimina la tabla.

Debido registro de rehacer y binlog son dos separados lógico, si no se comprometen en dos fases, o se le pide a fin de rehacer binlog registro de escritura, o el uso de orden de turno. Nos fijamos en estos dos métodos será un problema. (Incoherencia de datos Causa)

Utilizando el ejemplo anterior todavía lo hacen la instrucción de actualización. Supongamos que la fila actual con ID = 2, el valor del campo c es 0, entonces el supuesto de que la instrucción de actualización proceso de implementación después de escribir el primer registro, el segundo registro no ha finalizado durante el accidente ocurrido, ¿qué ocurre entonces?

Después de la primera a rehacer escritura binlog registro de escritura

Si después de registro de rehacer escrito en el motor, registro bin no terminó, reinicios, todavía se puede recuperar los datos de acuerdo a rehacer registro de registro, pero binlog ningún registro de esta declaración. Así de la biblioteca por datos de sincronización binlog ha llevado a no poner esta línea de sincronización de datos a través de la pérdida de esta operación transacción que resulta en datos inconsistentes.

El primero en escribir registro de rehacer escritura binlog

Si escrita colapso binlog, debido al registro de rehacer no se ha escrito, el inválido transacción después de la recuperación de fallos, pero hay registro binlog. De acuerdo con el registro de binlog de la biblioteca dará lugar a un múltiplo transacción, incompatible con la biblioteca principal.

En pocas palabras, registro de rehacer y presentar binlog se puede utilizar para representar el estado de las cosas, y la confirmación de dos fases es hacer que la lógica consistente de dos estados. (Llama a la pizarra de los estudiantes)