Introduction à l'archivage des nouvelles fonctionnalités de MySQL

MySQL 8.0.17 est sorti Après avoir lu la note de version, j'ai constaté que la fonction d'archivage des journaux redo a été restaurée comme prévu. La raison pour laquelle on l'appelle "récupération" est qu'elle existait dans une très ancienne version d'InnoDB (versions antérieures à MySQL 4.0.6) et a été annulée par la suite. À cette époque, le miroir de journalisation était toujours pris en charge et les anciens administrateurs de base de données MySQL. J'en ai peut-être encore l'impression, mais ces deux fonctions étaient peu utiles à l'époque, elles ont donc été annulées.

Tutoriel de proposition : Tutoriel vidéo d'introduction à la base de données MySQL

Cette fois, InnoDB redémarre la fonction d'archivage des journaux redo, suivez Selon l'équipe de développement, il s'agit principalement de résoudre le problème de cohérence des sauvegardes. Voici ce que dit le document :

Backup utilities that copy redo log records may sometimes fail to keep pacewith redo log generation while a backup operation is in progress, resultingin lost redo log records due to those records being overwritten. The redolog archiving feature addresses this issue by sequentially writing redo logrecords to an archive file. Backup utilities can copy redo log records fromthe archive file as necessary, thereby avoiding the potential loss of data.
in lost redo log records due to those records being overwritten. The redo
log archiving feature addresses this issue by sequentially writing redo log
records to an archive file. Backup utilities can copy redo log records from
the archive file as necessary, thereby avoiding the potential loss of data.

En bref, la vitesse de sauvegarde ne peut pas suivre la vitesse de génération du redo log. En conséquence, le redo log est écrasé, et la sauvegarde ne peut alors pas garantir. cohérence. Avec l'archivage du redo log, vous pouvez démarrer l'archive du redo log de manière synchrone lorsque la sauvegarde démarre et arrêter l'archive du redo log de manière synchrone à la fin de la sauvegarde. De cette façon, vous pouvez éviter ce problème et vous pouvez utiliser les données générées pendant. cette période après la fin de la sauvegarde.

Pour activer la fonction d'archivage du redo log, définissez simplement l'option innodb_redo_log_archive_dirs, qui prend en charge la modification dynamique en ligne, par exemple :

[root@yejr.me]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs/";

Spécifiez le répertoire /data/mysql8-redologs/ comme stockage de l'archive du redo log chemin et spécifiez l'étiquette comme "redolog-archiving-for-backup", c'est-à-dire qu'il s'agit du répertoire de stockage des archives de journalisation dédié à la sauvegarde.

Nous pouvons également désigner un autre répertoire pour une future réplication physique basée sur le redo log (je suppose qu'il ne sera peut-être pas implémenté si tôt).

[root@yejr.me]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs1/;redolog-archiving-for-repl:/data/mysql8-redologs2";

　Option innodb_redo_log_archive_dirs peut spécifier plusieurs répertoires comme emplacements de stockage des journaux de rétablissement des archives. Cependant, cette option présente plusieurs limitations :

Après l'avoir configurée, vous pouvez lancer le redo log archivage.

Le premier paramètre est une étiquette que nous avons définie auparavant, et le deuxième paramètre est le sous-répertoire sous le répertoire correspondant à l'étiquette, qui est "/data/mysql8-redologs/20190722". Nous pouvons voir un tel fichier d'archive redo log dans le répertoire correspondant :

[root@yejr.me]> ls -l /data/mysql8-redologs/20190722-r--r-----. 1 mysql mysql 0 Jul 22 20:54 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log

La chaîne de caractères souvent dans le nom du fichier est l'UUID de cette instance. La taille du fichier à ce moment est de 0 octet.

Nous lançons un test oltp sysbench dans une autre session. Après avoir exécuté le test sysbench, nous avons arrêté le travail d'archivage du redo log :

[root@yejr.me]> DO innodb_redo_log_archive_stop();Query OK, 0 rows affected (0.00 sec)

J'ai enregistré les modifications dans le redo log LSN avant et après le test comme suit :

# 测试前的LSNLOG---Log sequence number          27938813989...# 测试后的LSNLOG---Log sequence number          27945024531
---
Log sequence number          27938813989
...

# 测试后的LSN
LOG
---
Log sequence number          27945024531

La différence entre les deux LSN est : 6210542 octets.

Ensuite, nous vérifions la taille du fichier d'archive du journal redo :

[root@yejr.me]> ls -l /data/mysql8-redologs/20190722-r--r-----. 1 mysql mysql 6213632 Jul 22 21:19 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log

Nous pouvons voir que la taille du fichier est de 6213632 octets, ce qui n'est que de 3090 octets différent des 6210542 octets ci-dessus. Le journal généré par le test est de taille comparable. Nous pourrons utiliser ce redo log pour la récupération de données plus tard (cependant, les outils officiels correspondants n'ont pas encore été développés, nous attendrons donc de voir).

Dans des circonstances normales, l'archivage des journaux redo a un impact relativement faible sur les performances (écriture séquentielle). Dans les scénarios avec un grand nombre de transactions hautement simultanées, l'impact sur les performances peut être légèrement plus important, mais ne vous inquiétez pas. trop. Je ferai un test de comparaison des performances quand j'en aurai l'occasion.

Avant le lancement, Yueyue m'a rappelé que l'outil de sauvegarde de MySQL Enterprise Edition prend déjà en charge le réarchivage à l'avance. J'espère que Percona Xtrabackup pourra également le prendre en charge dès que possible.

Enfin, encore une chose. Vous pouvez également remarquer qu'après la version 8.0 de MySQL, il ressemble de plus en plus à ORACLE. Avec ORACLE, la base de données commerciale la plus performante, devant nous, nous avons toutes les raisons de ne pas nous inquiéter pour l'avenir de MySQL.

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!