Hay seis tipos de archivos de registro en MySQL
: rehacer registro, deshacer registro, binlog, registro de errores, registro de consulta lenta y registro de consulta general (registro general), registro de retransmisión (registro de retransmisión).
Entre ellos, el registro de rehacer y el registro de reversión están estrechamente relacionados con las operaciones de transacción, y el registro binario también está relacionado con las operaciones de transacción Estos tres tipos de registros son de gran importancia para comprender las operaciones de transacción en MySQL.
Aquí hay un breve resumen de los tres registros relevantes.
Rehacer registro
Rol:
asegurar la durabilidad de la transacción.
Para evitar que se escriban páginas sucias en el disco en el punto de falla, cuando se reinicia el servicio mysql, rehaga de acuerdo con el registro de rehacer, para lograr la durabilidad de la transacción.
Contenido:
el registro en formato físico, que registra la información de modificación de la página de datos físicos, y su registro de rehacer se escribe secuencialmente en el archivo físico del archivo de registro de rehacer.
Cuándo se genera: El
registro de rehacer se genera después de que comienza la transacción. El registro de rehacer no se escribe con la confirmación de la transacción, sino que se escribe en el archivo de registro de rehacer durante la ejecución de la transacción.
Cuándo liberar:
cuando las páginas sucias de la transacción correspondiente se escriben en el disco, la misión del registro de rehacer se completa y el espacio ocupado por el registro de rehacer se puede reutilizar (sobrescribir).
Archivo físico correspondiente:
De forma predeterminada, el archivo físico correspondiente se encuentra en ib_logfile1 & ib_logfile2 en el directorio de datos de la base de datos.
Innodb_log_group_home_dir especifica la ruta donde se encuentra el grupo de archivos de registro. El ./ predeterminado significa que está en el directorio de datos de la base de datos.
innodb_log_files_in_group especifica la cantidad de archivos en el grupo de archivos de registro de rehacer. El valor predeterminado 2 es
aproximadamente el tamaño y la cantidad de
archivos. El tamaño del archivo de registro de rehacer innodb_log_file_size se configura mediante los dos parámetros siguientes .
innodb_mirrored_log_groups especifica el número de grupos de archivos de espejo de registro, el valor predeterminado es 1.
Otro:
Es muy importante, ¿cuándo se escribe el registro de rehacer en el disco? Dije antes que escribí el disco gradualmente después de que empezaran las cosas.
La razón por la que se dice que el registro de rehacer se escribe gradualmente en el archivo de registro de rehacer después de que comienza la transacción, y no necesariamente solo después de que se confirma la transacción. La
razón es que el registro de rehacer tiene un área de búfer Innodb_log_buffer y el tamaño predeterminado de Innodb_log_buffer es 8M (16M establecido aquí), el motor de almacenamiento Innodb escribe primero el registro de rehacer en innodb_log_buffer.
Luego, el registro en el búfer de registro innodb se descargará en el disco
1 de las siguientes tres formas : Master Thread descargará Innodb_log_buffer en el archivo de registro de rehacer una vez por segundo.
2. Cuando se confirma cada transacción, el registro de rehacer se vaciará en el archivo de registro de rehacer.
3. Cuando el espacio libre del caché del registro de rehacer es menos de la mitad, el caché del registro de rehacer se vacía en el archivo de registro de rehacer. Se
puede ver que el registro de rehacer se escribe en el disco de más de una forma, especialmente para la primera Uno. Way, Innodb_log_buffer al archivo de registro de rehacer es una tarea de sincronización del subproceso principal.
Por lo tanto, la escritura del registro de rehacer no se escribe necesariamente en el archivo de registro de rehacer con la confirmación de la transacción, sino que comienza gradualmente con el comienzo de la transacción.
Además, cito las palabras originales en Innodb Storage Engine (página 37):
Incluso si no se ha confirmado una transacción, el motor de almacenamiento Innodb todavía vaciará la caché del registro de rehacer en el archivo de registro de rehacer cada segundo.
Es imprescindible saberlo, porque bien puede explicar que el tiempo de compromiso de una transacción grande también es muy corto.
Deshacer registro
Función:
guarde una versión de los datos antes de que se produzca la transacción, que se puede utilizar para la reversión y, al mismo tiempo, puede proporcionar lectura de control concurrente de múltiples versiones (MVCC), es decir, lectura sin bloqueo
Contenido:
Registros en formato lógico. Cuando se ejecuta deshacer, los datos solo se restauran lógicamente al estado anterior a la transacción, en lugar de realizarse a partir de la operación en la página física. Esto es diferente del registro de rehacer.
Cuándo se genera:
antes de que comience la transacción, la versión actual generará un registro de deshacer, y deshacer también generará rehacer para garantizar la confiabilidad del registro de deshacer
Cuándo liberar: una
vez confirmada la transacción, el registro de deshacer no se puede eliminar inmediatamente,
sino que se coloca en la lista vinculada para su limpieza, y el hilo de purga determina si otras transacciones utilizan la información de la versión antes de la transacción anterior en el segmento de deshacer. ¿Se puede limpiar el espacio de registro del registro de deshacer?
Archivo físico correspondiente:
antes de MySQL5.6, el espacio de tabla para deshacer se encuentra en el segmento de retroceso del espacio de tabla compartido. El nombre predeterminado del espacio de tabla compartido es ibdata, que se encuentra en el directorio del archivo de datos.
Después de MySQL5.6, el espacio de tabla de deshacer se puede configurar como un archivo separado, pero debe configurarse previamente en el archivo de configuración. Una vez inicializada la base de datos, entrará en vigor y no se podrá cambiar el número de archivos de registro de deshacer.
Si no hay una configuración relevante antes de que se inicialice la base de datos, no será posible Configurada como un espacio de tabla separado.
Acerca de los parámetros de configuración del espacio de tabla independiente de deshacer después de MySQL5.7 son los siguientes
innodb_undo_directory = / data / undospace / --undo directorio de almacenamiento de espacio de tabla independiente
innodb_undo_logs = 128 - el segmento de reversión es 128KB
innodb_undo_tablespaces = 4 - especificar 4 archivos de registro de deshacer
Si el espacio de tabla compartido utilizado por deshacer, este espacio de tabla compartido no solo almacena información de deshacer, el valor predeterminado del espacio de tabla compartido está en el directorio de datos con MySQL y sus atributos se configuran mediante el parámetro innodb_data_file_path.
Otros:
deshacer es una versión de los datos modificados que se guardan antes del inicio de la transacción, cuando se genera el registro de deshacer, también irá acompañado de la generación de un redolog similar al mecanismo de persistencia de la transacción de protección.
De forma predeterminada, el archivo de deshacer se mantiene en el espacio de tabla compartido, es decir, en el archivo ibdatafile.Cuando ocurren algunas operaciones transaccionales grandes en la base de datos, se genera una gran cantidad de información de deshacer, todo lo cual se almacena en el espacio de tabla compartido.
Por lo tanto, el espacio de tabla compartido puede llegar a ser muy grande De forma predeterminada, cuando el registro de deshacer utiliza el espacio de tabla compartido, el espacio de tabla compartido que está "estirado" no se reducirá ni puede reducirse automáticamente.
Por lo tanto, la configuración del "espacio de tabla de deshacer independiente" después de mysql5.7 es muy necesaria.
Registro binario (binlog):
Función:
1. Se utiliza para la replicación : en la replicación maestro-esclavo, la biblioteca esclava usa el binlog en la biblioteca maestra para reproducir y lograr la sincronización maestro-esclavo.
2. Se utiliza para la restauración puntual de la base de datos.
Contenido: los
registros en formato lógico se pueden considerar simplemente como declaraciones SQL en transacciones ejecutadas.
Pero no es exactamente tan simple como la instrucción sql, pero incluye la información inversa de la instrucción sql ejecutada (adición, eliminación, modificación), lo que
significa que eliminar corresponde a eliminarse a sí mismo y su inserción inversa; la actualización corresponde a antes y después de la actualización Ejecución Información de la versión; insertar corresponde a la información de eliminar e insertar.
Después de usar mysqlbinlog para analizar el binlog, algo de la verdad saldrá a la luz.
Por lo tanto, la función de flashback similar a Oracle se puede lograr en función de binlog, pero en realidad depende de los registros de bitácora en binlog.
Cuándo se genera: cuando
se envía la transacción, las declaraciones SQL de la transacción (una cosa puede corresponder a varias declaraciones SQL) se registran en el binlog en un formato determinado a la vez.
La diferencia obvia entre el registro de rehacer y el registro de rehacer es que el registro de rehacer no se descarga necesariamente en el disco cuando se confirma la transacción. El registro de rehacer se escribe gradualmente en el disco después de que comienza la transacción.
Por lo tanto, la confirmación de una transacción es muy rápida incluso para una transacción grande, pero cuando bin_log está activado, la confirmación de una transacción grande puede volverse más lenta.
Esto se debe a que el binlog se escribe una vez cuando se confirma la transacción, y esto se puede verificar mediante pruebas.
Cuándo publicar:
el valor predeterminado de binlog es que el tiempo de retención se configura mediante el parámetro expire_logs_days, lo que significa que los archivos de registro inactivos se eliminarán automáticamente después de que el tiempo de generación supere el número de días configurado por expire_logs_days.
Archivo físico correspondiente:
la ruta del archivo de configuración es log_bin_basename, y el archivo de registro binlog está de acuerdo con el tamaño especificado. Cuando el archivo de registro alcanza el tamaño máximo especificado, se actualiza de manera progresiva para generar un nuevo archivo de registro.
Para cada archivo de registro binlog, está organizado por un archivo de índice unificado.
Otros:
una de las funciones del registro binario es restaurar la base de datos, que es muy similar al registro de rehacer, y muchas personas lo han confundido, pero los dos son esencialmente diferentes
1. La función es diferente: el registro de rehacer es garantizar la durabilidad de la transacción, es el nivel de la transacción Sí, binlog, como función de restauración, está en el nivel de la base de datos (por supuesto, también puede ser exacto al nivel de la transacción). Aunque tiene el significado de restaurar, el nivel de datos la protección es diferente.
2. El contenido es diferente: rehacer el registro es el registro físico, que es el registro físico después de la modificación de la página de datos, binlog es el registro lógico, que puede considerarse simplemente como la declaración sql
3. Además, el momento en que Se generan los dos registros, y el tiempo que se puede liberar. En el caso de la liberación, el mecanismo de limpieza es completamente diferente.
4. La eficiencia de la restauración de datos, la eficiencia de la restauración de datos basada en el registro físico de rehacer el registro es mayor que la del registro lógico de declaraciones binlog
Con respecto a la confirmación de transacciones, el orden de escritura de rehacer log y binlog, para garantizar la consistencia maestro-esclavo durante la replicación maestro-esclavo (por supuesto, incluido el uso de binlog para la restauración en un momento determinado), debe ser estrictamente consistente .
MySQL se compromete en dos etapas Proceso para completar la consistencia de la transacción, es decir, la consistencia del registro de rehacer y binlog, teóricamente escriba el registro de rehacer primero, luego escriba el binlog, ambos registros se envían con éxito (vaciar al disco), la transacción es considerado verdaderamente completado.
Referencia: http://www.cnblogs.com/hustcat/p/3577584.html