Comment résoudre le retard maître-esclave MySQL

Les capacités de réplication intégrées de MySQL constituent la base de la création de grandes applications hautes performances. Distribuez les données MySQL sur plusieurs systèmes. Ce mécanisme distribué est obtenu en copiant les données d'un certain hôte MySQL vers d'autres hôtes esclaves et en les réexécutant.
Lors de la réplication, un serveur agit en tant que maître et un ou plusieurs autres serveurs en tant qu'esclaves. Le maître écrit des mises à jour dans les fichiers journaux binaires et maintient un index des fichiers pour suivre la rotation des journaux. Ces journaux enregistrent les mises à jour envoyées aux serveurs esclaves. Lorsqu'un esclave se connecte au maître, il informe le maître de l'emplacement de la dernière mise à jour réussie lue par l'esclave dans le journal. Le serveur esclave reçoit toutes les mises à jour survenues depuis, puis bloque et attend que le serveur maître les informe des mises à jour.
Problèmes avec la réplication maître-esclave MySQL :

• Une fois la base de données principale indisponible, les données peuvent être perdues
• La bibliothèque esclave n'a qu'un seul thread SQL, la bibliothèque principale est soumise à une forte pression d'écriture et la réplication risque d'être retardée

Voici quatre façons pratiques de résoudre le délai maître-esclave MySQL

1. Principe de délai de synchronisation maître-esclave de la base de données MySQL.

Réponse : Lorsque nous parlons du principe du délai de synchronisation maître-esclave dans la base de données MySQL, nous devons commencer par le principe de la réplication maître-esclave de la base de données MySQL. La réplication maître-esclave de Mysql est une opération à thread unique. La base de données principale génère un binlog. pour tous les DDL et DML, Binlog est une écriture de séquence, donc l'efficacité est très élevée ; le thread Slave_IO_Running de l'esclave ira dans la bibliothèque principale pour obtenir le journal, et l'efficacité sera relativement élevée. Opérations DDL et DML de la bibliothèque principale sur l'esclave. Les opérations d'E/S de DML et DDL sont aléatoires et non séquentielles, le coût sera donc très élevé. D'autres requêtes sur l'esclave peuvent également provoquer un conflit de verrouillage. Puisque Slave_SQL_Running est également monothread, une carte maître DDL doit s'exécuter 10 fois. minutes, tous les DDL suivants attendront la fin de leur exécution avant de continuer, ce qui entraînera des retards. Certains amis demanderont : « Le même DDL sur la bibliothèque principale doit également être exécuté pendant 10 minutes. Pourquoi l'esclave est-il retardé ? » La réponse est que le maître peut s'exécuter simultanément, mais pas le thread Slave_SQL_Running.

2. Comment se produit le délai de synchronisation maître-esclave dans la base de données MySQL ?

Réponse : lorsque la concurrence TPS de la bibliothèque principale est élevée, le nombre de DDL générés dépasse la plage qu'un thread SQL de l'esclave peut supporter, et un retard se produit alors. Bien sûr, il peut également y avoir une attente de verrouillage avec celui de l'esclave. grande instruction de requête.

3.Solution de délai de synchronisation maître-esclave de la base de données MySQL

Réponse : La solution la plus simple pour réduire le délai de synchronisation des esclaves est d'optimiser l'architecture et d'essayer de faire exécuter rapidement le DDL de la bibliothèque principale. Il y a aussi le fait que la bibliothèque principale est écrite avec une sécurité de données élevée, telle que sync_binlog=1, innodb_flush_log_at_trx_commit = 1 et d'autres paramètres. Cependant, l'esclave n'a pas besoin d'une sécurité de données aussi élevée. Vous pouvez définir sync_binlog sur 0 ou. désactiver binlog. innodb_flushlog peut également être défini sur 0 pour améliorer l'efficacité de l'exécution SQL. L'autre consiste à utiliser un meilleur périphérique matériel que la bibliothèque principale comme esclave.

4. Facteurs provoquant le retard de synchronisation maître-esclave dans la base de données MySQL.

1. Retard du réseau
2. charge principale
3. charge d'esclave
L'approche générale consiste à utiliser plusieurs esclaves pour distribuer les demandes de lecture, puis à utiliser un serveur dédié à partir de ces esclaves uniquement pour la sauvegarde sans aucune autre opération, afin que l'exigence de « temps réel » puisse être atteinte au maximum

.

De plus, introduisons 2 paramètres supplémentaires qui peuvent réduire le délai
–slave-net-timeout=secondes
Signification du paramètre : lorsque l'esclave ne parvient pas à lire les données du journal de la base de données principale, combien de temps attendre pour rétablir la connexion et obtenir les données
L'unité de slave_net_timeout est la seconde. Le paramètre par défaut est 3600 secondes
. |esclave_net_timeout | 3600
–master-connect-retry=secondes
Signification du paramètre : lors du rétablissement de la connexion maître-esclave, si la connexion ne parvient pas à être établie, combien de temps faudra-t-il pour réessayer.
L'unité de master-connect-retry est la seconde. Le paramètre par défaut est 60 secondes
. Habituellement, la configuration des 2 paramètres ci-dessus peut réduire le délai de synchronisation des données maître-esclave causé par des problèmes de réseau

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!