I. Introducción
- Como se mencionó en el artículo anterior ( https://blog.csdn.net/m0_46405589/article/details/113844781 ), el propósito del diseño del grupo de búfer es coordinar la brecha entre la velocidad de la CPU y la velocidad del disco. Por lo tanto , la operación de la página se completa primero en el grupo de búferes . Si una declaración DML, como Actualizar o Eliminar, cambia el registro en la página , entonces la página está sucia en este momento . Es decir, la versión de la página en el grupo de búferes es más nueva que la del disco. La base de datos necesita vaciar la nueva versión de la página del grupo de búferes al disco
La naturaleza de D (persistencia) en ACID
- Si cada vez que cambia una página, la versión de la nueva página se descarga en el disco, entonces esta sobrecarga es muy grande . Si los datos calientes se concentran en unas pocas páginas, el rendimiento de la base de datos será muy deficiente. Al mismo tiempo, si se produce un tiempo de inactividad al vaciar la nueva versión de la página del grupo de búferes al disco, los datos no se pueden recuperar.
- Para evitar el problema de la pérdida de datos , el sistema de base de datos de transacciones actual generalmente adopta la estrategia Write Ahead Log , es decir, cuando se confirma la transacción, primero se escribe el registro de rehacer y luego se modifica la página . Cuando se pierden datos debido a un tiempo de inactividad, el registro de rehacer se utiliza para completar la recuperación de datos . Este es el requisito de D en la transacción ACID
2. Por qué diseñar la tecnología Checkpoint
- Considere el siguiente escenario: si el registro de rehacer puede crecer indefinidamente y el grupo de búfer es lo suficientemente grande como para almacenar en búfer todos los datos de la base de datos , entonces no es necesario vaciar la nueva versión de las páginas del grupo de búfer en el disco. Porque cuando ocurre un tiempo de inactividad, es completamente posible restaurar los datos en todo el sistema de base de datos a través del registro de rehacer hasta el momento del tiempo de inactividad, pero se requieren dos requisitos previos :
- 1. El grupo de búferes puede almacenar en caché todos los datos de la base de datos.
- Como primer requisito previo, los usuarios experimentados saben que cuando se crea la base de datos por primera vez, no hay datos en la tabla. De hecho, el grupo de búferes puede almacenar en caché todos los archivos de la base de datos. Sin embargo, con la promoción del mercado y el aumento de usuarios, los productos están recibiendo cada vez más atención y el uso también está aumentando. En este momento, la capacidad de la base de datos responsable del almacenamiento de back-end debe seguir aumentando. Actualmente, 3 TB de MySQL no son infrecuentes, pero 3 TB de memoria son muy raros
- 2. El registro de rehacer puede crecer infinitamente
- De acuerdo con el segundo requisito previo: el registro de rehacer puede aumentar indefinidamente. Puede ser posible, pero esto requiere demasiado costo y no es conveniente para la operación y el mantenimiento. El DBA o SA no pueden saber cuándo el registro de rehacer está cerca del umbral del espacio en disco disponible, y requiere ciertas habilidades y soporte de equipo para soportar la expansión dinámica del dispositivo de almacenamiento.
- Incluso si se cumplen las dos condiciones anteriores, hay otra situación a considerar : el tiempo de recuperación de la base de datos después de un tiempo de inactividad. Cuando la base de datos se ha estado ejecutando durante meses o incluso años, habrá un tiempo de inactividad en este momento, y el tiempo para volver a aplicar el registro de rehacer será muy largo, y el código de recuperación en este momento también será muy grande.
- Por tanto, el propósito de la tecnología Checkpoint es solucionar los siguientes problemas:
- ① Acortar el tiempo de recuperación de la base de datos
- ② Cuando el grupo de búfer no sea suficiente, descargue las páginas sucias en el disco
- ③Cuando el registro de rehacer no esté disponible, actualice la página sucia
① Acortar el tiempo de recuperación de la base de datos
- Cuando la base de datos está inactiva, la base de datos no necesita rehacer todos los registros, porque las páginas anteriores a Checkpoint se han vaciado de nuevo al disco.
- Por lo tanto, la base de datos solo necesita restaurar el registro de rehacer después de Checkpoint. Esto acorta enormemente el tiempo de recuperación.
② Cuando el grupo de búfer no sea suficiente, descargue las páginas sucias en el disco
- Además, cuando el grupo de búferes no está disponible, la página usada menos recientemente se desbordará de acuerdo con el algoritmo LRU . Si la página es una página sucia, entonces se debe aplicar un punto de control para vaciar la página sucia, que es la nueva versión de la página, volver al disco
③Cuando el registro de rehacer no esté disponible, actualice la página sucia
- El registro de rehacer no está disponible porque :
- El sistema de base de datos de transacciones actual está diseñado para reciclar el registro de rehacer , no para aumentarlo indefinidamente, lo cual es más difícil en términos de costo y administración.
- La parte reutilizable del registro de rehacer significa que estos registros de rehacer ya no son necesarios , es decir, cuando la base de datos está inactiva, la operación de recuperación de la base de datos no necesita esta parte del registro de rehacer, por lo que esta parte se puede sobrescribir y reutilizar.
- Si el registro de rehacer aún necesita ser utilizado en este momento, se debe forzar a generar un punto de control para vaciar las páginas en el grupo de búfer al menos a la ubicación actual del registro de rehacer.
Tres, LSN
- Para InnoDB, usa LSN para marcar la versión . El LSN es un número de 8 bytes y su unidad es el byte
- Cada página tiene LSN, el registro de rehacer también tiene LSN, el punto de control también tiene LSN . Puede ver la información que se muestra con el siguiente comando:
show engine innodb status\G;
Cuatro, punto de control agudo y punto de control difuso
- En el motor de almacenamiento InnoDB, el momento y las condiciones de aparición de puntos de control y la selección de páginas sucias son muy complicados . Lo que hace Checkpoint no es más que vaciar las páginas sucias en el grupo de búfer de nuevo al disco. La diferencia radica en cuántas páginas se vacían en el disco cada vez, dónde se recuperan las páginas sucias cada vez y cuándo se activa Checkpoint.
- Dentro del motor de almacenamiento InnoDB, hay dos puntos de control, a saber:
- Punto de control agudo
- Punto de control difuso
Punto de control agudo
- Sharp Checkpoint devuelve todas las páginas sucias al disco cuando se cierra la base de datos . Este es el modo de trabajo predeterminado, es decir, el parámetro innodb_fast_shutdown = 1
Punto de control difuso
- Si la base de datos también usa Sharp Checkpoint en tiempo de ejecución, la disponibilidad de la base de datos se verá muy afectada. Por lo tanto, InnoDB todavía usa Fuzzy Checkpoint para la actualización de la página, es decir, solo se actualiza una parte de las páginas sucias , en lugar de vaciar todas las páginas sucias al disco.
- El punto de control difuso se producirá en las siguientes situaciones :
- 1.Punto de control del hilo principal
- 2.Punto de control FLUSH_LRU_LIST
- 3.Punto de control de descarga asíncrona / sincronizada
- 4.Página sucia demasiado punto de control
①Punto de control del hilo principal
- Para el punto de control que se produce en el hilo principal (descrito en detalle en un artículo posterior), un cierto porcentaje de páginas se vuelcan al disco desde la lista de páginas sucias del grupo de búfer a una velocidad de casi cada segundo o cada diez segundos . Este proceso es asincrónico, es decir, el motor de almacenamiento InnoDB puede realizar otras operaciones en este momento y el hilo de consulta del usuario no se bloqueará.
② FLUSH_LRU_LIST Punto de control
- principio de funcionamiento:
- FLUSH_LRU_LIST Checkpoint se debe a que el motor de almacenamiento InnoDB debe garantizar que haya casi 100 páginas gratuitas disponibles para su uso en la lista LRU . Si no hay 100 páginas libres disponibles, InnoDB eliminará las páginas al final de la lista LRU . Si hay páginas sucias en estas páginas, se requiere un punto de control
- Y estas páginas son de la lista LRU, por lo que se llaman FLUSH_LRU_LIST Checkpoint
- Antes de la versión InnoDB 1.1.x, debe verificar si hay suficiente espacio libre en la lista LRU. La operación ocurre en el hilo de consulta del usuario, lo que obviamente bloqueará la operación de consulta del usuario.
- A partir de la versión MySQL 5.6, que es la versión InnoDB 1.2.x, esta verificación se realiza en un hilo de Page Cleaner separado , y el usuario puede controlar el número de páginas disponibles en la lista LRU a través del parámetro innodb_lru_scan_depth , el valor predeterminado es 1024
show variables like 'innodb_lru_scan_depth'\G;
③Punto de control de descarga asíncrona / sincronizada
- Async / Sync Flush Checkpoint se refiere a la situación en la que el archivo de registro de rehacer no está disponible. En este momento, es necesario forzar que algunas páginas se vuelvan a vaciar al disco , y las páginas sucias se seleccionan de la lista de páginas sucias.
- Si el LSH que se ha escrito en el registro de rehacer es redo_lsn y el LSN que se ha vaciado de nuevo a la última página del disco se registra como checkpoint_lsn, puede definir :
- Luego defina las siguientes variables :
- Si el tamaño de cada archivo de registro de rehacer es de 1 GB y se definen dos archivos de registro de rehacer, el tamaño total del archivo de registro de rehacer es de 2 GB. Entonces async_water_mark = 1.5GB, sync_water_mark = 1.8GB, luego:
- Cuando checkpoint_age <async_water_mark : no es necesario vaciar las páginas sucias en el disco
- Cuando async_water_mark <checkpoint_age <sync_water_mark : desencadena Async Flush, elimina suficientes páginas sucias de la lista Flush de nuevo al disco, de modo que checkpoint_age <async_water_mark se satisfaga después de la descarga
- La situación de checkpoint_age> sync_water_mark generalmente ocurre raramente, a menos que el archivo de registro de rehacer establecido sea demasiado pequeño y se esté realizando una operación BULK INSERT similar a LOAD DATA. En este momento, la operación Sync Flush se activa para vaciar suficientes páginas sucias de la lista Flush de nuevo al disco, de modo que checkpoint_age <async_water_mark se satisface después de vaciar
- Se puede ver que Async / Sync Flush Checkpoint es para garantizar la disponibilidad del reciclaje de registros de rehacer
- Antes de InnoDB 1.2.x , Async Flush Checkpoint bloquearía los hilos de consulta del usuario que encontraran problemas, mientras que Sync Flush Checkpoint bloquearía todos los hilos de consulta del usuario y esperaría a que se completara la actualización de la página sucia. A partir de la versión InnoDB1.2.x , esta parte de la operación de actualización también se coloca en un hilo de limpieza de página separado, por lo que no bloqueará el hilo de consulta del usuario.
- La versión oficial de MySQL no puede verificar si la página de actualización es un punto de verificación de la lista Flush o de la lista LRU, ni conoce el número de Async / Sync Flush generados debido a los registros de rehacer, pero la versión InnoSQL proporciona un método. Puede utilice el siguiente comando para observar:
show engine innodb status\G;
④Página sucia demasiado Punto de control
- Principio de funcionamiento : página sucia demasiado, es decir, la cantidad de páginas sucias es demasiado, lo que hace que el motor de almacenamiento InnoDB fuerce Checkpoint. En general, su propósito es garantizar que haya suficientes páginas libres en el grupo de búferes.
- Que puede ser controlado por el parámetro innodb_max_dirty_pages_pct :
- El valor 75 que se muestra arriba significa que cuando el número de páginas sucias en el grupo de búfer ocupa el 75%, el punto de control se ve obligado a actualizar parte de las páginas sucias en el disco. Antes de la versión InnoDB 1.0.x, el valor predeterminado de este parámetro es 90 y la siguiente versión es 75
show variables like 'innodb_max_dirty_pages_pct'\G;
