Cuando emite el comando SHOW GLOBAL STATUS;MySQL, una de las líneas que recibo es la siguiente:¿Cómo arreglar las páginas sucias de InnoDB?
Innodb_buffer_pool_pages_dirty 28
Cuando miro hacia arriba the documentation, todo lo que veo es:
El número de páginas actualmente sucias . Agregado en MySQL 5.0.2.
¿Cómo puedo solucionar este problema (estoy suponiendo que tiene páginas sucias no es algo bueno)?
Tener páginas sucias es algo normal. Cuando actualiza una fila, MySQL la actualiza en el grupo de búferes, marcando la página como sucia. El cambio también está escrito en el registro binario, por lo que en caso de falla, MySQL reproducirá el registro y los datos no se perderán. La escritura en el registro binario es una operación de solo adición, mientras que la actualización real involucra escrituras aleatorias, y la escritura aleatoria es más lenta.
MySQL flushesh páginas sucias en el disco cuando necesita cargar nuevos datos en el grupo de búferes. Por lo tanto, tener páginas sucias en InnoDB es algo normal, así es como funciona y se hace para mejorar el rendimiento general.
Pero si realmente quiere deshacerse de ellos, establezca innodb_max_dirty_pages_pct a 0
Así que entiendo que puedo bajar 'innodb_max_dirty_pages_pct', lo que puede tener un impacto en el rendimiento (porque InnoDB se escribirá más a menudo en el disco) pero garantizará que las consultas se escriban inmediatamente en los archivos de la base de datos. Parece la habitual discusión de "rendimiento frente a confiabilidad" en la que cuanto menos se escribe mejor es el rendimiento, pero mayor es la posibilidad de perder datos. ¿Alguna vez ha tenido la necesidad de bajar 'innodb_max_dirty_pages_pct' para preservar la integridad de los datos? ¿Debo molestarme con esta configuración? – Max
@ user359650 La integridad la manejan los registros de transacciones, por lo que la única configuración efectiva es innodb_flush_log_at_trx_commit; determina si el registro de transacciones se vacía en el disco en cada transacción (cumplimiento total de ACID) o una vez por segundo (puede perder un máximo de 1 segundo de transacciones en caso de fallo del sistema operativo). La cantidad de páginas sucias puede afectar el tiempo de cierre de MySQL, así como el tiempo de recuperación de fallos (no estoy seguro para el segundo, pero tiene sentido). Sin embargo, si tiene una aplicación de escritura intensiva, puede probar si la configuración innodb_max_dirty_pages_pct afecta el rendimiento y cómo –
el tiempo de cierre lleva mucho tiempo y nos preguntamos por qué. Este tipo de ajustes se parecen a aquellos con los que no debería estar jugando a menos que realice pruebas exhaustivas antes de lanzarse a producción, a diferencia de otros que hemos cambiado con éxito con un impacto positivo en el rendimiento. Podemos ver esto en el futuro. Gracias. – Max
Su supuesto "sucio == malo" es incorrecto. – hirschhornsalz