Vous êtes définitivement sur la bonne voie ici.
Chaque fois qu'InnoDB effectue une transaction qui doit être validée, cela se fait comme une validation en deux phases. La transaction est d'abord écrite dans ces journaux. Ensuite, ils sont engagés à partir de là.
Cela aide beaucoup en cas de plantage de MySQL ou de plantage du serveur.
Lorsque vous redémarrez mysql, toutes les entrées non validées dans ib_logfile0 et ib_logfile1 sont rejouées dans le cadre de la récupération après incident d'InnoDB pour amener InnoDB dans un état harmonieux (il s'agit de parties cohérentes et durables de Conformité ACID )
Si vous supprimez ib_logfile0 et ib_logfile1 et démarrez mysql, toute transaction non validée contenue dans ces fichiers est perdue. Pendant le cycle de reprise sur incident, si les fichiers journaux sont manquants, ils sont régénérés en fonction de innodb_log_file_size réglage.
Veuillez consulter la Documentation MySQL pour une description détaillée explication d'InnoDB .
@karatedog la partie MVCC d'InnoDB se produit dans l'espace de table système, mieux connu sous le nom de ibdata1. Quelles que soient les données qui semblent être avant le début d'une transaction, elles sont enregistrées pour permettre aux autres personnes qui accèdent aux lignes nécessaires d'avoir une vue des données avant que des mises à jour ne soient imposées. Cela permet ce qu'on appelle une REPEATABLE-READ. Cela relève du I de la conformité ACID, I signifiant Isolement. J'ai écrit des articles à ce sujet dans le DBA StackExchange concernant divers scénarios où l'isolation des transactions est bonne, mauvaise ou moche.
- lire avant d'écrire la transaction
- Ces deux requêtes entraîneront-elles un blocage si elles sont exécutées dans l'ordre ?
- Le raid 5 est-il adapté à l'installation de mysql ?
Comme pour MyISAM, la récupération après un crash n'est pas automatique. Il plante assez facilement
. C'est pourquoi la commande SQL REPAIR TABLE existe. C'est aussi pourquoi l'utilitaire MySQL myisamchk a le -r option pour effectuer REPAIR TABLE pour les tables MyISAM qui ne sont pas en ligne.
MariaDB et Aria ont été tentées de créer un moteur de stockage sécurisé en cas de panne en remplacement de MyISAM.
