MySQL Real Time Optimization Master 04 discute de ce qu'est binlog en mettant à jour le processus d'exécution des déclarations dans le moteur de stockage InnoDB.

1、Réponse à la question de réflexion précédente：redoSuggestions pour le choix de la politique de brossage des journaux

Expliquez d'abord les questions de réflexion de la Conférence précédente,Un Conseil que je vous donne,En fait,redoTrois stratégies de brossage des journaux,Nous suggérons généralement de mettre en placePour1

C'est - à - dire,Lors de l'engagement d'une transaction,redoLe journal doit être brossé dans le fichier disque.

Cela garantit strictement qu'une fois la transaction engagée,Les données ne sont jamais perdues,Parce qu'il y aredoLog récupère toutes les réparations que vous avez faites dans le fichier disqueModifier.

Si vous choisissez0Et si,Peut - être qu'après avoir déposé la transaction,mysqlTemps d'arrêt,À ce stade,redoLe journal n'a pas de disque de brosse,Qui a causéredoJournal perdu,Les données mises à jour sur les transactions que vous avez soumises sont perdues;

Si vous choisissez2Et si,Si la machine tombe en panne,Bien que lorsque la transaction a été soumise,redoEntrée du Journalos cacheC'est,Mais pas encore entré dans le disquePièce (s),Le temps d'arrêt de la machine peut encore causeros cacheÀ l'intérieur.redoJournal perdu.

Donc pour un système aussi strict qu'une base de données,Recommandations généralesredoLa politique de brossage des journaux est définie à1,Une fois la transaction garantie engagée,Les données ne doivent jamais être perdues.

2、MySQL binlogQu'est - ce que c'est？

Alors regardons.MySQL binlogQu'est - ce que？

En fait, ce qu'on a ditredo log,C'est un journal Redo de nature physique,Parce qu'il y a quelque chose comme ça dans son dossier,“Oui, lequel? Quels enregistrements dans la page de données , Qu'est - ce qui a changé ”.

Etredo logElle appartient àInnoDB Une chose unique au moteur de stockage .

EtbinlogAppelé Journal d'archives, C'est un journal logique. ,Similaire à“C'est exact.usersDans le tableauid=10 Une ligne de données a été mise à jour Faire, Quelles sont les valeurs après la mise à jour ”

binlogNon, pas du tout.InnoDBFichiers journaux spécifiques au moteur de stockage,C'est àmysql serverLeurs propres fichiers journaux.

3、Lors de l'engagement d'une transaction,Écrit en même tempsbinlog

Donc, en fait, la dernière fois que nous avons parlé de , Au moment de la transaction ,Il varedo log Log write to disk file to . Puis, en fait, au moment où la transaction a été engagée Attendez., Nous allons également faire correspondre cette mise à jour binlog Log écrit sur le fichier disque ,Comme le montre la figure ci - dessous.

             

Vous pouvez voir quelques changements dans cette image , C'est moi qui InnoDB Le composant dans lequel le moteur de stockage interagit est ajouté à l'actionneur mentionné précédemment. , Il s'occupera des relations avec InnoDBPour interagir, Y compris le chargement des données du disque à Buffer PoolCache en cours,Inclure l'écritureundoLog,Y compris les mises à jourBuffer PoolLes données de,Et écrireredo log buffer,redo logBrosser le disque,Écris.binlog,Attendez un peu!.

En fait,, L'actionneur est un composant très central , Responsable de la coordination avec le moteur de stockage SQL Toutes les opérations de mise à jour des données de l'instruction au niveau du disque et de la mémoire Faire.

Et nous pouvons voir sur la photo ci - dessus , Je vais mettre à jour l'exécution de l'instruction , Divisé en deux étapes ,Dans l'image ci - dessus1、2、3、4Quelques étapes,En fait, l'essence C'est ce que vous avez fait en exécutant cette mise à jour .

Et puis dans l'image ci - dessus 5Et6Deux étapes, C'est à partir du moment où vous soumettez la transaction ,C'est l'étape de la transaction..

4、binlog Analyse de la politique de brossage des journaux

PourbinlogLog, En fait, il existe différentes stratégies de brossage ,Il y a unsync_binlogLes paramètres peuvent être contrôlésbinlogStratégie de brossage pour,Sa valeur par défaut est0,À ce stade, vous mettezbinlog En écrivant sur le disque ,En fait, ce n'est pas un accès direct au fichier disque,C'est l'entrée.os cacheCache mémoire.

Donc, comme dans l'analyse précédente ,Si la machine s'arrête,Alors tu esos cacheÀ l'intérieur.binlog Les journaux sont perdus , Regardons le schéma ci - dessous

             
Si vous mettezsync_binlogParamètre défini à1Et si, Cela forcera la transaction à s'engager ,Prends ça.binlog Écrivez directement dans le fichier disque , Après avoir engagé la transaction comme ça , Même si la machine s'arrête ,Sur le disquebinlog Il n'est pas perdu ,Comme le montre la figure ci - dessous

            

5、Basé surbinlogEtredo logTerminer la soumission de la transaction

Quand on metbinlog Après avoir écrit le fichier disque , La transaction finale est alors terminée. ,Cette mise à jour correspond àbinlog Nom du fichier et cette fois Mise à jourbinlogEmplacement du journal dans le fichier,Tout est écrit àredo log Dans le fichier journal ,En même tempsredo logÉcrivez un dans le fichier journalcommitObjetNote.

Après avoir fait ça, , Pour terminer la transaction , Regardons le schéma ci - dessous .

           

6、La dernière étape estredoÉcrire dans le journalcommit Quel est le sens du marquage ？

Il doit y avoir des camarades de classe qui demandent ,Enfin,redoÉcrire dans le journalcommit A quoi bon marquer ？

C'est clair., Il est en fait utilisé pour garder redo logLog vs.binlogJournal cohérent.

Prenons un exemple, Supposons que lorsque nous soumettons une transaction , Il y a au total 5、6、7Trois étapes, Les trois étapes doivent être terminées ,Ça compte. C'est une transaction engagée . Alors, quand on vient de finir les étapes 5Quand,C'est - à - direredo log Quand je viens de brosser le fichier disque ,mysqlC'est éteint., Et maintenant? Faites？

Parce qu'il n'y a pas d'affaire finale. commitMarqué surredoDans le journal de bord, Donc cette transaction peut être jugée infructueuse .Je ne dirai rien.redo Dans le fichier journal Il y a un journal de cette mise à jour ,MaisbinlogIl n'y a pas de journal pour cette mise à jour dans le fichier journal,Il n'y aura pas de problème d'incohérence des données.

Si les étapes sont terminées 6Quand,C'est - à - direbinlogÉcrit sur le disque,En ce momentmysqlC'est éteint.,Comment faire?？

Même chose.,Parce qu'il n'y a pasredo logFinal incommitMarquage, Par conséquent, l'engagement de transaction a échoué à ce stade. .

Doit êtreredo log Écrivez la transaction finale commitMarqué,Ensuite, la transaction est engagée avec succès,Etredo log Il y a la date de cette mise à jour Chi.,binlog Il y a aussi le journal correspondant à cette mise à jour ,redo logEtbinlogTout à fait cohérent..

7、BackgroundIOLe thread brosse aléatoirement les données sales mises à jour de la mémoire sur le disque

Supposons maintenant que la transaction a été engagée ,Mise à jour maintenant“update users set name='xxx' where id=10”, Il a mis en mémoire buffer poolMise à jour des données mises en cache dans, En même temps, il y a redoJournal etbinlogLog,C'est enregistré. C'est ce qu'on nous a assigné.“id=10”Cette ligne de donnéesModifié“name='xxx'”.

Nous allons maintenant réfléchir à une question , Mais à ce moment - là, les fichiers de données sur le disque “id=10”Cette ligne de donnéesname Le champ est toujours égal à zhangsan Cette vieille valeur ！

Alors...MySQL Il y a un fond IOThread, Et à un moment ou à un autre , Mettre la mémoire au hasard buffer pool Les données sales modifiées sont retournées au magnétisme Dans le fichier de données sur le disque ,Regardons l'image ci - dessous.：

             

Quand la figure ci - dessus IOThread setbuffer pool Après que les données sales modifiées ont été retournées sur le disque , Les données sur le disque sont les mêmes que dans la mémoire ,Tous.name=xxx Cette valeur modifiée ！

À toi.IO Avant que le thread ne retourne les données sales sur le disque ,Même simysql Ce n'est pas grave si le temps d'arrêt s'écrase ,Parce qu'après le redémarrage,Sera basé surredo Rendez - vous avant la récupération du Journal Assurez - vous de faire des changements dans la mémoire ,C'estid=10De donnéesnameModifié pourxxx,Et attendez le bon moment.,IO Le thread va naturellement changer ça Les données suivantes sont brossées dans un fichier de données sur le disque

8、 Processus basé sur la mise à jour des données ,RésuméInnoDB Principes architecturaux du moteur de stockage

Tout le monde passe par un processus de mise à jour des données ,Vous pouvez voir clairement,InnoDB Le moteur de stockage contient principalement buffer pool、redo logbufferAttendre les données mises en cache en mémoire, Il contient également undoFichiers journaux,redo Fichiers journaux, etc ,En même tempsmysql serverMoi aussi.binlogFichiers journaux.

Pendant que vous effectuez la mise à jour ,Par articleSQLDéclarations,Sera modifié en conséquencebuffer poolDonnées mises en cache dans、Écris.undoLog、Écris.redo log bufferCombien?Étapes;

Mais quand vous soumettez l'affaire ,Il va sûrementredo logBrosser le disque,binlogBrosser le disque,Terminé.redo logTransactions encommitMarquage;EnfinBackgroundIO Les fils vont mettre au hasard buffer poolLes données sales dans le disque.

9、Questions de réflexion：Lors d'une opération de mise à jour, Pourquoi ne pas modifier les données sur le disque ？

C'est bon, L'article d'aujourd'hui touche à sa fin , Réfléchissons à une autre question ：

PourquoiMySQLLors de la mise à jour des données, Il faut beaucoup de travail ,Y compris:buffer pool、redo log、undo log、binlog、Présentation des transactions、Données sales. Beaucoup de concepts ont été introduits , Il y a des processus et des étapes complexes .

Pourquoi modifie - t - il les données sur le disque? ,Pour passerIO Le thread s'exécute irrégulièrement ？

Pourquoi n'a - t - il pas simplement exécuté SQLDéclarations, Mettez à jour les données directement sur le disque. ？