sql >> Base de Datos >  >> RDS >> Mysql

Diario de transacciones de MySQL

Definitivamente estás en el camino correcto aquí.

Cada vez que InnoDB realiza una transacción que debe confirmarse, se realiza como una confirmación de dos fases. La transacción se escribe primero en estos registros. Luego, se comprometen desde allí.

Esto es de gran ayuda en caso de que MySQL se bloquee o se bloquee el servidor.

Cuando reinicia mysql, todas las entradas no confirmadas en ib_logfile0 e ib_logfile1 se reproducen como parte de la recuperación de fallas de InnoDB para llevar a InnoDB a un estado armonioso (estas son partes consistentes y duraderas de Cumplimiento de ACID )

Si elimina ib_logfile0 e ib_logfile1 e inicia mysql, cualquier transacción no confirmada que contengan esos archivos se perderá. Durante el ciclo de recuperación de fallas, si faltan los archivos de registro, se regeneran en función de innodb_log_file_size ajuste.

Consulte la documentación de MySQL para obtener una explicación de InnoDB .

@karatedog, la parte MVCC de InnoDB ocurre dentro del espacio de tabla del sistema, más conocido como ibdata1. Cualquier dato que parezca estar antes del inicio de una transacción se registra para permitir que otros que accedan a las filas necesarias tengan una vista de los datos antes de que se impongan actualizaciones. Esto permite lo que se denomina LECTURA REPETIBLE. Esto cae bajo la I de cumplimiento de ACID, lo que significa Aislamiento. Escribí publicaciones sobre esto en DBA StackExchange con respecto a varios escenarios donde el aislamiento de transacciones es bueno, malo o feo.

En cuanto a MyISAM, la recuperación de errores no es automática. Se bloquea con bastante facilidad . Es por eso que el comando SQL REPAIR TABLE existe Esa es también la razón por la que la utilidad MySQL myisamchk tiene el -r opción para realizar REPAIR TABLE para tablas MyISAM que no están en línea.

MariaDB y Aria Ha habido intentos de crear un motor de almacenamiento a prueba de fallas como reemplazo de MyISAM.