Maison > Article > base de données > Comment utiliser le binlog, le redo log et le undo log de MySQL
Binlog est utilisé pour enregistrer des informations sur les opérations d'écriture effectuées dans la base de données. Il exclut les opérations de requête et est enregistré sur le disque au format binaire. Binlog est le journal logique de MySQL et est enregistré par la couche serveur. Les bases de données Mysql utilisant n'importe quel moteur de stockage enregistreront les journaux binlog.
Journal logique : peut être simplement compris comme une instruction SQL ;
Journal physique : les données dans MySQL sont stockées dans la page de données et le journal physique enregistre les modifications sur la page de données ;
Projet Dans les applications pratiques, il existe deux principaux scénarios d'utilisation de binlog, à savoir la réplication maître-esclave et la récupération de données.
Principe de synchronisation maître-esclave de la base de données MySQL
Comme mentionné ci-dessus, le binlog est un journal logique qui peut être simplement compris comme un journal logique. sql, mais en fait, il contient également la logique inverse de l'instruction sql exécutée. delete correspond à la suppression elle-même et la mise à jour d'insertion inverse contient des informations sur les lignes de données avant et après l'exécution de la mise à jour correspondante, l'insertion contient sa propre insertion et les informations de suppression correspondantes.
Il existe trois formats de binlog, à savoir instruction, ligne et mixte. Avant MySQL 5.7.7, l'instruction était utilisée par défaut, et après MySQL 5.7.7, la ligne était utilisée par défaut. Le format du journal peut être modifié via binlog-format dans le fichier de configuration my.ini. (1) Déclaration : Réplication basée sur les instructions (SBR), chaque instruction SQL qui modifie les données sera enregistrée dans le binlog.
Pour le moteur de stockage InnoDB, le binlog ne sera enregistré que lorsque la transaction est soumise. À ce moment, l'enregistrement est toujours dans la mémoire. MySQL contrôle le timing de vidage du binlog via sync_binlog, et le. la plage de valeurs est 0-N :
0 : Pas de vidage forcé sur le disque, le système décidera quand écrire sur le disque
1 : Chaque Après chaque soumission, le journal binaire sera écrit sur le disque ;
N : Le journal binaire sera écrit sur le disque pour toutes les N transactions ; 🎜 🎜#
Vous pouvez contrôler la taille du binlog en configurant le paramètre max_binlog_size, qui se trouve dans le fichier my.ini fichier de configuration. Le système créera un nouveau fichier pour continuer à stocker les journaux lorsque la taille du journal dépasse la limite de capacité du fichier binlog. Que dois-je faire lorsqu'une transaction est relativement importante, ou lorsqu'il y a de plus en plus de logs et que l'espace physique qu'elle occupe est trop grand ? MySQL fournit un mécanisme de suppression automatique, qui peut être résolu en configurant le paramètre expire_logs_days dans le fichier de configuration my.ini. L'unité est en jours. Lorsque ce paramètre est à 0, cela signifie qu'il ne sera jamais supprimé ; lorsqu'il est à N, cela signifie qu'il sera automatiquement supprimé après le Nième jour.
2. redo log
InnoDB interagit avec le disque en unités de données de pages, et une transaction ne peut modifier que plusieurs éléments d'une page, s'il s'agit d'une page de données complète. est renvoyé sur le disque, c'est un gaspillage de ressources ;
Une transaction peut impliquer plusieurs pages de données. Ces pages de données ne sont que logiquement continues, et non physiquement continues. trop médiocre ;
Par conséquent, MySQL a conçu le redolog pour enregistrer les modifications spécifiques apportées à la page de données par la transaction, puis renvoyer le redolog sur le disque. Vous avez peut-être des doutes. À l’origine, je voulais réduire io. Cela n’ajouterait-il pas un autre io ? Les concepteurs d'InnoDB en ont tenu compte dès le début de la conception. Les fichiers de journalisation sont généralement petits et des E/S séquentielles sont utilisées lors du vidage du disque. Meilleures performances par rapport aux E/S aléatoires.
Concept de base du redo log redolog se compose de deux parties, l'une est le tampon de journalisation du cache de journal dans la mémoire et l'autre est le fichier journal refaire une session dans le fichier disque. Chaque fois que l'enregistrement de données est modifié, ces modifications seront d'abord écrites dans le tampon de journalisation, puis attendront l'opportunité appropriée pour vider les modifications de la mémoire dans le fichier de journalisation. Cette technologie consistant à écrire d'abord des journaux, puis à écrire sur le disque, est la technologie WAL (Write-Ahead Logging). Il convient de noter que le redolog est renvoyé sur le disque avant la page de données. Les modifications apportées à l'index clusterisé, à l'index secondaire et à la page d'annulation doivent toutes être enregistrées dans le redolog.
Dans un système d'exploitation informatique, les données du tampon dans l'espace utilisateur ne peuvent généralement pas être écrites directement sur le disque et doivent passer par le tampon d'espace du noyau du système d'exploitation (OS Buffer). Par conséquent, l'écriture du tampon de journalisation dans le fichier de journalisation l'écrit d'abord dans le tampon du système d'exploitation, puis le vide dans le fichier de journalisation via l'appel système fsync(). Le processus est le suivant :
#🎜🎜. #
Valeur du paramètre
0 (écriture différée) # 🎜🎜# | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 (écriture en temps réel, brossage en temps réel) | Chaque fois qu'une transaction est soumise, le journal dans le tampon de journalisation sera écrit dans le tampon du système d'exploitation et appelé fsync() vidé dans le fichier de journalisation. Cette méthode ne perdra aucune donnée même si le système tombe en panne, mais comme chaque soumission est écrite sur le disque, les performances d'E/S sont médiocres. | ||||||||||||||
2 (écriture en temps réel, brossage différé) | Chaque soumission est uniquement écrite dans le tampon du système d'exploitation, puis fsync( est appelé toutes les secondes) Écrivez le journal dans le tampon du système d'exploitation dans le fichier de journalisation. | ||||||||||||||
Lors du démarrage d'innodb, peu importe qu'il ait été arrêté normalement ou anormalement la dernière fois, l'opération de récupération sera toujours effectuée. Lors de la récupération, le LSN dans la page de données sera vérifié en premier. Si ce LSN est plus petit que le LSN dans le redolog, c'est-à-dire la position d'écriture, cela signifie que les opérations inachevées sur la page de données sont enregistrées dans le redolog, puis il commencera à partir du point de contrôle le plus proche, commencera à synchroniser les données. Est-il possible que le LSN dans la page de données soit plus grand que le LSN dans le redolog ? La réponse est bien sûr possible. Lorsque cela se produit, la partie au-delà du redolog ne sera pas refaite, car cela signifie en soi que ce qui a été fait n'a pas besoin d'être refait.
Cela ressort de la différence entre binlog et redo log : le journal binlog est uniquement utilisé pour l'archivage, et s'appuyer uniquement sur binlog n'a pas de fonctionnalités de sécurité en cas de crash. Mais seul le journal redo ne fonctionnera pas, car le journal redo est unique à InnoDB et les enregistrements du journal seront écrasés après avoir été écrits sur le disque. Par conséquent, le binlog et le redo log doivent être enregistrés en même temps pour garantir que lorsque la base de données est arrêtée et redémarrée, les données ne seront pas perdues. Supposons qu'il y ait une instruction de mise à jour à exécuter maintenant, mise à jour à partir de table_name défini c=c+1 où id=2, le processus d'exécution est le suivant :
Ce processus de division de l'écriture du journal redo en deux étapes, préparer et commit, est appelé commit en deux phases .
|
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!