diario de transacciones MySQL

Question

Estoy trabajando en un proyecto para el cual debemos usar "diario de transacciones" en nuestro DBMS (MySQL). Ya hemos cambiado a usar InnoDB para usar transacciones para otro requisito. Estoy tratando de entender qué es el diario de transacciones. He estado buscando durante más de un día, incluida la lectura a través de la documentación de MySQL. Quizás no estoy buscando las palabras clave correctas, no estoy seguro. O tal vez "diario de transacciones" es una terminología inapropiada.

Por lo que entiendo, el diario de transacciones de base de datos es similar a un sistema de archivos en diario porque los cambios se realizan en un diario antes de que se confirmen en el sistema de archivos. Según lo que he leído, parece que el motor InnoDB almacena las transacciones en algún tipo de diario antes de que estén comprometidas con el disco. ¿Esto suena exacto? Si es así, ¿dónde está el diario de transacciones? ¿Es ib_logfile0 y ib_logfile1?

Answer 1

Definitivamente está en el camino correcto aquí.

Cuando InnoDB realiza una transacción que debe comprometerse, se realiza como una confirmación de dos fases. La transacción se escribe en estos registros primero. Entonces, están comprometidos desde allí.

Esto ayuda mucho en el caso del bloqueo de MySQL o el bloqueo del servidor.

Al reiniciar MySQL, todas las entradas no comprometidos en ib_logfile0 y ib_logfile1 se reproducen como parte de la recuperación de una caída de InnoDB para llevar InnoDB a un estado armónico (Esto es consistente y piezas duraderas de ACID Compliance)

Si elimina ib_logfile0 e ib_logfile1 e inicie mysql, cualquier transacción no confirmada que esos archivos contengan se pierde. Durante el ciclo de recuperación de bloqueo, si faltan los archivos de registro, se regeneran en función de la configuración innodb_log_file_size.

Consulte MySQL Documentation for a detailed explanation of InnoDB.

@karatedog la parte MVCC de InnoDB ocurre dentro del espacio de tablas del sistema, mejor conocido como ibdata1. Cualquier información que aparezca antes del inicio de una transacción se registra para permitir que otras personas que acceden a las filas necesarias tengan una vista de los datos antes de que se impongan las actualizaciones. Esto permite lo que se llama REPEATABLE-READ. Esto cae bajo el cumplimiento I de ACID, lo que significa aislamiento. Escribí publicaciones sobre esto en DBA StackExchange con respecto a varios escenarios en los que el aislamiento de transacciones es bueno, malo o feo.

• read before write transaction
• Will these two queries result in a deadlock if executed in sequence?
• Is raid 5 suitable for mysql installation?

En cuanto a MyISAM, crash recovery is not automatic. It crashes rather easily. Es por eso que existe el comando SQL REPAIR TABLE. Esa es la razón por la cual la utilidad MySQL myisamchk tiene la opción -r para realizar REPAIR TABLE para las tablas MyISAM que no están en línea.

MariaDB and Aria han intentado hacer un motor de almacenamiento seguro contra fallas como reemplazo de MyISAM.