mysql modificar datos usando redolog

 

 

 

 

El problema de no usar redoLog:

Debido a que el   disco Innodb basado  interactúa como una unidad, mientras que es probable que una transacción modifique solo unos pocos bytes de la página de datos que, si toma el segundo enfoque, esta vez a una página completa de datos en el disco, luego cepilla, ¡una pérdida de recursos!

Por ejemplo, la figura (estructura de la página) son filas de datos lógicamente continuas, pero sus posiciones en el disco pueden no ser continuas, sino aleatorias. Conservar toda esta página en el disco es una E / S aleatoria. En este momento, debe encontrar las posiciones correspondientes en el disco una por una y actualizar los datos de la última página de BufferPool en el disco Debido a problemas de E / S aleatorios, este proceso es muy lento.

 

 

 

 

Usar redolog

 

 

redo log Consta de dos partes: una es el búfer de registro en la memoria (  redo log buffer ) y la otra es el archivo de registro ( redo logfile) en el disco  .

mysql Cada vez DML que se ejecuta una  instrucción, primero se escribe el registro  redo log buffery luego se escriben varios registros de operaciones a la vez en un momento posterior  redo log file. Esta   técnica de escribir el registro primero y luego escribir en el disco es una técnica que  MySQLse menciona a menudo en este  WAL(Write-Ahead Logging) artículo.

En el sistema operativo de la computadora, user space los datos del búfer en el espacio de usuario (  ) generalmente no se pueden escribir directamente en el disco, y el espacio del kernel ( kernel space ) búfer ( OS Buffer ) debe pasar a través del espacio del kernel del sistema operativo ( ) en el  medio  .

En consecuencia,  redo log buffer la escritura en  redo logfile realidad se escribe primero  OS Buffer , y luego a través de las llamadas del sistema  fsync() al pincel  redo log file
, el proceso es el siguiente:

mysql Admite tres tipos  de sincronización para  redo log buffer escribir  redo log file,

¿Cuándo es la persistencia? Esto está relacionado con la transacción. Por ejemplo, cuando se abre una transacción y se ejecuta una actualización, ¿debe persistir en este momento redo log?

No es necesario en este momento y solo persiste cuando la transacción está realmente comprometida. La reversión de transacciones ciertamente no necesita persistir.

 

   Se puede innodb_flush_log_at_trx_commit configurar a través de  parámetros, y el significado de cada valor de parámetro es el siguiente:

 

osbuffer, el búfer del sistema operativo.

Por ejemplo, escriba -> sistema operativo y flush -> disco para escribir archivos.


 

Cuando la transacción se confirma, el registro de rehacer se conserva

Si mysql cuelga, cuando myql se inicia nuevamente, los datos de la página anterior + los datos de la página de redolog se encuentran en el disco y se obtienen los datos modificados

¿Por qué es rápido usar redolog?

Porque después de iniciar mysql, se abre un archivo (ib_logfile, por defecto 48M) en el disco. Siempre que haya actualización de datos, el registro de redolog (actualización sql) se escribe al final de este archivo. Esta escritura es secuencial, porque el archivo en sí ya existe (Sequence IO). Esta velocidad de lectura y escritura de E / S es mucho más rápida que el segundo método.

 

¿Por qué redolog tiene dos archivos escritos cíclicamente?

Por supuesto, se puede configurar el tamaño y el número del archivo.

Usando el mecanismo de punto de control, cuando ib_logfile0 e ib_logfile1 están llenos, y luego cambian a ib_logfile0, se activa el mecanismo checkponint. Cuando se encuentra que ib_logfile0 está lleno en este momento, los datos de la página en el BufferPool correspondiente a ib_logfile0 se vacían en el disco , y el espacio está despejado para su uso continuo.

 

Es hora de refrescarse

  • rehacer registro de descarga

    Preparación para el cepillado

    Cuando buffer poolse está modificando la página, el bloque de control de esta página sucia se insertará en la lista enlazada flush. El bloque de control almacena dos variables: el valor lsn correspondiente al inicio de la primera modificación de mtr cuando seoldest_modification carga buffer pool, y el fin de cada modificación mtr El valor lsn correspondiente en el momento; el bloque de control se almacena en orden ascendente .newest_modificationoldest_modification

    Un mtr puede modificar varias páginas, por lo que oldest_modification/ newest_modificationpuede ser el mismo para varios bloques de control .

    Es hora de refrescarse

  • Cuando el espacio del búfer de registro es insuficiente y el espacio libre es menos de la mitad
  • Cuando se confirma la transacción, es posible que las páginas sucias en el grupo de búfer no se vacíen primero, pero el búfer de registro debe eliminarse para evitar pérdidas.
  • Intermitente temporizado del hilo de fondo
  • Cuando el servidor se apaga normalmente
  • Durante el punto de control: vaciar las páginas sucias de la lista de vaciado en lotes: si el sistema modifica las páginas con frecuencia y no puede vaciar las páginas sucias, no puede verificar el punto a tiempo y puede usar directamente el hilo del usuario para sincronizar las páginas sucias modificadas más antiguas en la lista de vaciado .Disco, por lo que los registros de rehacer correspondientes a estas páginas sucias son inútiles,

 

Rehacer el almacenamiento de archivos de registro

En el directorio de datos de MySQL, (al innodb_log_group_home_dirdeterminar la ubicación de almacenamiento, el formulario de almacenamiento es un grupo de archivos de registro conocido por el nombre) un archivo llamado ib_logfile0... n, el número de archivos determina el sufijo del nombre del archivo y el número de archivos es determinado por los parámetros del sistema innodb_log_files_in_groupSe innodb_log_file_sizeespecifica el tamaño de cada archivo .

El archivo se sobrescribirá para cada bloque que se ib_logfileescriba de forma secuencial y cíclica log buffer.

 

 

 

punto de control : vaciar las páginas sucias en el grupo de búfer de nuevo al disco.
Dentro del motor de almacenamiento InnoDB, hay dos puntos de control, a saber:
1. Sharp Checkpoint
2. Fuzzy Checkpoint
Sharp Checkpoint descarga todas las páginas sucias en el disco cuando la base de datos está cerrada. Este es el modo de trabajo predeterminado, a saber, el parámetro: innodb_fast_shutdown = 1 .
Cuando la base de datos se está ejecutando, el motor de almacenamiento InnoDB usa Fuzzy Checkpoint internamente para actualizar solo una parte de las páginas sucias. Varias situaciones de
Fuzzy Checkpoint :
1. MasterThread Checkpoint se
actualiza de forma asincrónica, actualizando un cierto porcentaje de páginas de la lista de páginas sucias del grupo de búferes en el disco cada segundo o cada 10 segundos. Actualización asincrónica, es decir, el motor de almacenamiento InnoDB puede realizar otras operaciones en este momento, y el hilo de consulta del usuario no se bloqueará.
2. FLUSH_LRU_LIST El
motor de almacenamiento de Checkpoint InnoDB debe garantizar que haya casi 100 páginas gratuitas disponibles para su uso en la lista LRU. Antes de InnoDB 1.1.x, el hilo de consulta del usuario (después de que mysql5.6 se coloque en un proceso separado Limpiador de páginas) verificará si la lista LRU tiene suficiente espacio para la operación. De lo contrario, de acuerdo con el algoritmo LRU, desborde las páginas al final de la lista LRU. Si estas páginas tienen páginas sucias, se requiere un punto de verificación.
Parámetros de configuración: innodb_lru_scan_dept: controla el número de páginas disponibles en la lista LRU, el valor predeterminado es 1024
3. Punto de control de descarga asíncrona / sincronizada
Se refiere a la situación en la que el registro de rehacer no está disponible y la página debe actualizarse a la fuerza en el disco. En este momento, la página está seleccionada en la lista de páginas sucias.
Esta situación es para garantizar la disponibilidad de los registros de rehacer. Para decirlo sin rodeos, la parte del registro de rehacer que se puede cubrir en un bucle es demasiado pequeña. En otras palabras, se genera una gran cantidad de registros de rehacer en muy poco tiempo. .

 

mejoramiento

Puede aumentar el redolog o aumentar la cantidad de archivos para reducir la frecuencia de descarga del disco y reducir la E / S del disco, pero otro problema es que se tarda más en reiniciar mysql.

 

 

Supongo que te gusta

Origin blog.csdn.net/liuming690452074/article/details/113817552
Recomendado
Clasificación