Rollback MySQL (partage du résumé)

Cet article vous apporte des connaissances pertinentes sur mysql. Il organise principalement les problèmes liés à la restauration et présente principalement le mécanisme de restauration et de restauration de la librairie. Examinons-le ensemble, j'espère qu'il sera utile à tout le monde.

Apprentissage recommandé : Tutoriel vidéo mysql

Nous rencontrons souvent des scénarios dans lesquels nous exploitons une grande table et constatons que l'opération prend trop de temps ou affecte les affaires en ligne, et nous souhaitons annuler l'opération de grande table. Après l'arrêt des opérations sur des tables volumineuses, l'attente de la restauration est un processus très long. Bien que vous connaissiez certaines méthodes pour réduire le temps et que vous soyez impressionné par l'intégrité des données dans l'environnement de production, vous pouvez choisir de ne pas intervenir.

Annulation de transaction

Une transaction est une unité d'exécution dans une base de données relationnelle, et vous pouvez choisir de valider ou d'annuler via le contrôle de l'étape finale. Effectuez des opérations de restauration dans divers scénarios où l'intégrité ne peut pas être garantie. La restauration dans MySQL s'effectue via le journal d'annulation, qui contient des informations sur la manière d'annuler les dernières modifications liées à la transaction. Les journaux d'annulation existent dans le segment du journal d'annulation et le segment du journal d'annulation est inclus dans le segment d'annulation. Le segment d'annulation se trouve dans l'espace table d'annulation et dans l'espace table temporaire global.
La relation est la suivante :

• fichier d'annulation

  

mysql > show variables like '%undo%';
+--------------------------+--------------------+
| Variable_name            | Value              |
+--------------------------+--------------------+
| innodb_max_undo_log_size | 1073741824         |
| innodb_undo_directory    | /opt/data8.0/mysql |
| innodb_undo_log_encrypt  | OFF                |
| innodb_undo_log_truncate | ON                 |
| innodb_undo_tablespaces  | 2                  |
+--------------------------+--------------------+
5 rows in set (0.00 sec)

Un espace table temporaire (ibtmp1) pointé par global Temporary, utilisé pour stocker les segments d'annulation pour les modifications apportées aux tables temporaires créées par les utilisateurs.

mysql > SELECT @@innodb_temp_data_file_path;
+-------------------------------+
| @@innodb_temp_data_file_path  |
+-------------------------------+
| ibtmp1:128M:autoextend:max:30G |
+-------------------------------+

Comprenez quels fichiers sont inclus dans la restauration, continuez à lire.

Mécanisme de restauration :

Le contrôle de restauration MySQL est coordonné par le moteur interne innodb et ne fournit pas de mécanisme contrôlé par l'homme. Les paramètres d'annulation MySQL actuellement fournis sont les suivants :

mysql> SHOW VARIABLES LIKE  '%ROLL%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| innodb_rollback_on_timeout | OFF   |
| innodb_rollback_segments   | 128   |
+----------------------------+-------+

innodb_rollback_on_timeout :

InnoDB par défaut n'annule la dernière instruction que lorsque la transaction expire. Si --InnoDB -rollback-on-timeout est spécifié, un délai d'expiration de transaction entraînera l'abandon et l'annulation par InnoDB de la totalité de la transaction. Il est désactivé par défaut, une fois l'heure spécifiée, comme l'échec de la restauration. Il est concevable qu'il y ait des incohérences dans les données. Cette méthode n'est pas conseillée.

Innodb_rollback_segments (1~128) :

Définit le nombre de segments d'annulation alloués à chaque espace table d'annulation et le nombre d'espaces table temporaires globaux alloués aux transactions qui génèrent des enregistrements d'annulation.
Le nombre de transactions prises en charge par le segment de restauration : dépend du nombre d'emplacements d'annulation dans le segment de restauration et du nombre de journaux d'annulation requis pour chaque transaction

Le nombre d'emplacements d'annulation dans le segment de restauration officiellement fourni est lié à InnoDB taille de la page :

À partir de la dernière implémentation du code source MySQL8.0.27, storageinnobaseincludetrx0rseg.h:

/* Number of undo log slots in a rollback segment file copy 
这里 UNIV_PAGE_SIZE正常页面的大小  即 1024*/
#define TRX_RSEG_N_SLOTS (UNIV_PAGE_SIZE / 16)

/* Maximum number of transactions supported by a single rollback segment 
单个回滚段支持的最大事务数1024/2=512
*/
#define TRX_RSEG_MAX_N_TRXS (TRX_RSEG_N_SLOTS / 2)

Par défaut, la page est divisée en 1024 emplacements (TRX_RSEG_N_SLOTS), et chaque emplacement correspond à un objet de journal d'annulation, donc en théorie, InnoDB peut prendre en charge 128 * 512 = 65 536 transactions ordinaires.
Pour la partie principale, veuillez vous référer à MySQL · Caractéristiques du moteur · Itinérance d'annulation du journal InnoDB
Fournit officiellement des scénarios de lecture et d'écriture simultanés de restauration d'undbo :

Du principe d'appel au scénario d'application réel :
Pour la capacité pour prendre en charge les segments de restauration, toujours considérables, mais souvent très lents lors de l'exécution de restaurations par lots importants. En particulier lors du traitement en ligne, la restauration de 100 000 lignes peut prendre 10 minutes. Ou même plus longtemps.
Ensuite, préparez 5 000 W de données de table unique via sysbench. Sans charge, supprimez-les pendant environ 1 minute, puis utilisez kill -9 pour arrêter de force la transaction et annuler la transaction :

Évidemment, l'effet de redémarrer c'est mieux.
Cependant, la méthode kill -9 peut facilement endommager la page de données et présente un grand risque. La base de données est également sollicitée au quotidien. On peut imaginer que le coût de l'annulation de transactions volumineuses est très élevé.

Résumé

Les opérations de restauration importantes doivent être évitées autant que possible, car elles consomment des ressources et des performances de base de données et peuvent entraîner des accidents de production majeurs dans un environnement de production. Si l'annulation d'une transaction importante ne peut être évitée, vous pouvez utiliser les méthodes suivantes :

• Pour les opérations par lots, vous pouvez les soumettre par lots, par exemple, 1 000 à 5 000 lignes, etc.
• L'espace d'annulation et l'espace de table temporaire global peuvent être ajustés de manière appropriée. Il est recommandé d'utiliser 4 fichiers d'annulation et d'initialiser 1 Go d'ibtmp1 global. Dans un environnement à haute disponibilité et garantir la cohérence des données, vous pouvez promouvoir l'esclave vers un nouveau maître, fournir des services et attendre l'annulation des transactions volumineuses.
• Dans les cas extrêmes, vous pouvez utiliser kill -9 pour redémarrer l'opération. Étant donné que la quantité de données est très importante, la récupération de MySQL sera lente. À ce stade, vous devez attendre que MySQL plante et récupère. quantité de données, le temps d'attente est également différent
• Si vous redémarrez Pendant le processus, si la page de données est endommagée ou si la restauration est ignorée, vous pouvez passer innodb_force_recovery=3 (l'opération de restauration de la transaction n'est pas effectuée.)
• Apprentissage recommandé :

tutoriel vidéo 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!