InnoDB implementa un mecanismo de puntos de verificación llamado fuzzy checkpoint (punto de verificación difuso). InnoDB descarga las páginas modificadas de la base de datos desde el pool de buffers en lotes pequeños. No es necesario descargar al disco el pool de buffers en una sola acción, lo cual en la práctica podría detener temporalmente el procesamiento de sentencias SQL del usuario.

Durante la recuperación de caídas, InnoDB busca un marcador de checkpoint escrito en los ficheros de registro (log). Ya sabe que todas las modificaciones a la base de datos anteriores al marcador están presentes en la imagen en disco de la misma. Entonces InnoDB recorre los ficheros de registro (log) desde el checkpoint hacia adelante, aplicando sobre la base de datos las modificaciones registradas.

InnoDB escribe en los ficheros de registro en una forma rotativa. Todas las modificaciones confirmadas que hagan a las páginas de la base de datos en el pool de buffers diferentes de las grabadas en disco deben estar disponibles en los ficheros de registro en caso de que InnoDB tenga que hacer una recuperación. Esto significa que cuando InnoDB comienza a reutilizar un fichero de registro, tiene que asegurarse de que las imágenes en disco de las páginas de base de datos contienen las modificaciones asentadas en el fichero de registro que se va a reutilizar. En otras palabras, InnoDB debe crear un punto de verificación (checkpoint) y esto a menudo implica la descarga a disco de las páginas de base de datos modificadas.

La descripción anterior explica porqué hacer los ficheros de registro muy grandes puede ahorrar operaciones de E/S en disco destinadas a la creación de puntos de verificación. A menudo se hace hincapié en establecer el tamaño total de los ficheros de registro en lo mismo que el pool de buffers o aún más grande. La desventaja que tienen los ficheros de registro grandes es que la recuperación ante una caída puede tomar más tiempo debido a que hay más información que debe aplicarse a la base de datos.