Debido a que InnoDB es una base de datos con multiversión, debe llevar información acerca de las versiones anteriores de una fila en el espacio de tablas. Esta información se almacena en una estructura de datos llamada Rollback Segment (Segmento de Cancelación) al igual que una estructura de datos análoga de Oracle.

Internamente, InnoDB agrega dos campos a cada fila almacenada en la base de datos. Un campo de 6 bytes indica el identificador de la última transacción que insertó o actualizó la fila. Además, una eliminación se trata internamente como una actualización en la que un bit especial en la fila se establece a un valor que la señala como eliminada. Cada registro también contiene un campo de 7 bytes llamado "roll pointer" que apunta a una entrada del registro (log) de cancelación de modificaciones (undo) grabado en el segmento de cancelación (RollBack Segment). Si la fila fue actualizada, la entrada en el registro de cancelación de modificaciones (undo log) contiene la información necesaria para recrear el contenido de la fila tal como estaba antes de actualizarse.

InnoDB utiliza la información en el segmento de cancelación para deshacer los cambios durante la cancelación de una transacción. También la emplea para generar versiones anteriores de una fila en una lectura consistente.

Los registros de cancelación de modificaciones en el segmento de cancelación se dividen entre originados por inserciones (insert undo logs) y actualizaciones (update undo logs). Los insert undo logs se necesitan solamente para la cancelación de transacciones y se descartan tan pronto como se confirma la transacción. Los update undo logs se emplean también para lecturas consistentes, y pueden descartarse solamente cuando no quedan transacciones integrando una captura tomada por InnoDB, que en una lectura consistente podría necesitar esta información para reconstruir versiones anteriores de una fila.

Se deben confirmar las transacciones regularmente, incluyendo aquellas que solamente realizan lecturas consistentes. De otro modo, InnoDB no podrá descartar datos de los update undo logs, y el segmento de cancelación puede crecer en demasía, llenando el espacio de tablas.

El tamaño físico de una entrada en el registro de cancelación de cambios en el segmento de cancelación es generalmente menor que el de la correspondiente fila insertada o actualizada. Se puede emplear esta información para calcular el espacio necesario para el segmento de cancelación.

En el esquema de multiversión de InnoDB, una fila no es quitada inmediatamente de la base de datos cuando se la elimina mediante una sentencia SQL. Sólo cuando InnoDB pueda descartar la entrada en el registro de cancelación de modificaciones creada para la eliminación, procederá a quitar físicamente de la base de datos la fila y sus entradas en los índices. Esta operación se llama depuración (purge) y es bastante rápida, generalmente requiere el mismo tiempo que la sentencia SQL que realizó la eliminación.

En un escenario donde el usuario inserte y elimine filas aproximadamente en la misma proporción y en pequeños lotes, es posible que el subproceso de depuración comience a sufrir retrasos y la tabla crezca contínuamente, haciendo muy lenta cualquier operación que se realice sobre el disco. Incluso si una tabla contuviera sólo 10 MB de datos útiles, puede crecer hasta ocupar 10 GB con las filas “muertas”. En tal caso podría ser bueno limitar las operaciones de filas nuevas y asignar más recursos al subproceso de depuración. La opción de inicio (y también variable global configurable) innodb_max_purge_lag existe precisamente para este propósito. Consulte Sección 15.4, “Opciones de arranque de InnoDB” para más información.