Idées de réglage du délai maître-esclave
1. Qu'est-ce que le délai maître-esclave ?
L'essentiel est que la lecture de la bibliothèque esclave ne peut pas suivre celle de la bibliothèque principale et que l'étape de lecture est retardée.
2. Quelles sont les causes courantes du retard maître-esclave ?
1. Pour les transactions volumineuses, le temps de lecture de la bibliothèque esclave est long, ce qui entraîne un retard maître-esclave.
2. La bibliothèque principale écrit trop fréquemment et la bibliothèque esclave ne peut pas suivre la lecture.
3. Configuration des paramètres déraisonnable
4. Différences de matériel maître-esclave
5. Retard du réseau
6. La table n'a pas de clé primaire ou l'index est mis à jour fréquemment et fréquemment.
7. Certaines architectures qui séparent la lecture et l'écriture exercent une plus grande pression sur la bibliothèque esclave.
3. Quelles sont les méthodes pour résoudre le délai maître-esclave ?
1. Pour les transactions importantes, divisez-les en petites transactions
2. Activer la réplication parallèle
3. Mettre à niveau le matériel esclave
4. Essayez d'avoir des clés primaires
4. Qu'est-ce que la réplication parallèle et quels sont ses paramètres ?
Revoir le parcours de la réplication parallèle MySQL
MySQL5.6 est basé sur la réplication parallèle au niveau de la base de données
slave-parallel-type=DATABASE (transactions dans différentes bibliothèques, pas de conflits de verrouillage)
MySQL5.7 Réplication parallèle basée sur la validation de groupe
slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based模式(同一组的事务[last-commit相同]Il n'y a pas de conflit de verrouillage. Dans le même groupe, il ne doit y avoir aucun conflit, sinon il n'y a aucun moyen de devenir le même groupe.)
Ce qui précède est la configuration de la bibliothèque esclave. La réplication parallèle dépend de la soumission de groupe de la bibliothèque maître (notez la distinction entre la réplication de groupe).
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
-
binlog_group_commit_sync_delay: Combien de temps attendre avant de soumettre le groupe -
binlog_group_commit_sync_no_delay_count: Combien de transactions attendre avant de valider le groupe
Les paramètres ci-dessus dépendent tous de la situation d'occupation de la base de données principale. Si les affaires ne sont pas fréquentes, ce sera très embarrassant.
binlog_group_commit_sync_no_delay_count: Ce paramètre est réglé sur 2
Par exemple, si un seul thread exécute une transaction et que la deuxième transaction est exécutée 24 heures plus tard, alors cette transaction doit attendre 24 heures avant d'être soumise, ce qui est très frustrant.
binlog_group_commit_sync_delay
S'il est défini sur 200 ms et qu'un seul thread exécute une transaction, elle peut être soumise en 10 ms, mais elle doit attendre 200 ms.
Généralement, les deux sont mis en place en ligne. Par exemple, c'est comme un petit bateau transportant des personnes sur une rivière.
Supposons que nos paramètres soient définis comme ceci :
binlog_group_commit_sync_delay=200;
binlog_group_commit_sync_no_delay_count=2
Soit vous pouvez y aller directement si vous avez besoin de 200 ms, soit vous pouvez y aller directement si vous avez besoin de 2 personnes. C'est beaucoup plus convivial, mais cela reste gênant lorsque l'entreprise n'est pas occupée.
Réplication parallèle MySQL8.0 basée sur un jeu d'écriture
Détection de conflit basée sur la clé primaire (binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION, s'il n'y a pas de conflit dans la clé primaire ou la clé unique non vide de la ligne modifiée, elle peut être parallélisée)
Algorithme de détection de transactions :transaction_write_set_extraction = XXHASH64
MySQL aura une variable pour stocker la valeur HASH de la transaction soumise. Après le hachage, les valeurs de la clé primaire (ou clé unique) modifiées par toutes les transactions soumises seront comparées à l'ensemble de cette variable pour déterminer si le changement est effectué. de ligne est en conflit avec elle, et Pour déterminer les dépendances
Les variables mentionnées ici peuvent être définies en taille grâce à ceci :binlog_transaction_dependency_history_size
Ce type de granularité a atteint le niveau de la ligne, c'est-à-dire que la granularité parallèle est plus raffinée à ce moment-là et que la vitesse parallèle sera plus rapide. Dans certains cas, il n'est pas exagéré de dire que le parallélisme de l'esclave dépasse le niveau. maître ( le maître est une écriture monothread, l'esclave peut également lire en parallèle )
En termes simples, il s'agit d'une lecture parallèle basée sur des lignes. Différentes lignes au niveau rc n'auront pas de conflits de verrouillage.
Performances de soumission de groupe :
Vérifiez si la valeur last_commit du journal binaire de la bibliothèque principale est cohérente. Si elle est cohérente, elle peut être lue en parallèle. Si elle est incohérente, elle ne peut être lue qu'en série.
5. Analyse pratique
5.1 Vérifier le délai maître-esclave en ligne
Seconds_Behind_Master: 48828
On peut voir que le délai est très élevé, proche de 14 heures. A ce moment, la bibliothèque principale écrit également en permanence des données, environ 6 minutes pour un binlog et une pour 500M.
5.2 Afficher la configuration de réplication actuelle
Affichez la configuration de la bibliothèque esclave :
greatsql> show variables like '%slave%para%';
+------------------------+---------------+
| Variable_name | Value |
+------------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 128 |
+------------------------+---------------+
2 rows in set (0.02 sec)
Phénomène de retard :
La bibliothèque esclave a poursuivi, indiquant qu'il ne s'agit pas d'une grosse transaction, mais Seconds_Behind_Masterle retard a augmenté.
Retrieved_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:242966351-253068975,
00000000-0000-0040-0095-5fff003b4b99:91056629-110569633,
00000000-0000-005c-0ced-7bae003b4b99:150292055-160253193,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Executed_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:1-252250235,
00000000-0000-0040-0095-5fff003b4b99:1-109120315,
00000000-0000-005c-0ced-7bae003b4b99:1-159504296,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Auto_Position: 1
À l'heure actuelle, on soupçonne qu'il n'y a pas de réplication parallèle et que la bibliothèque principale n'a peut-être pas configuré la soumission de groupe (juste une supposition)
5.3 Pour une vérification plus approfondie, vérifiez le binlog de la bibliothèque principale
Vérifier la configuration des paramètres de la bibliothèque principale : toujours les règles soumises pour le groupe
greatsql> show variables like '%binlog_transac%';
+--------------------------------------------+----------+
| Variable_name | Value |
+--------------------------------------------+----------+
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
+--------------------------------------------+----------+
4 rows in set (0.02 sec)
Regardez la configuration de la soumission de groupe : cela signifie qu'il n'y a pas de soumission de groupe.
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
Après une vérification plus approfondie, en examinant le binlog, nous avons constaté que last_commit est effectivement différent, indiquant que le parallélisme n'est pas possible.
5.4 Définir les paramètres de la bibliothèque principale et analyser à nouveau son binlog
sera binlog_transaction_dependency_trackingchangé en WRITESETmode
greatsql> show variables like '%transaction%';
+----------------------------------------------------------+-----------------+
| Variable_name | Value |
+----------------------------------------------------------+-----------------+
| binlog_direct_non_transactional_updates | OFF |
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
| kill_idle_transaction | 300 |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size | 10 |
| replica_transaction_retries | 10 |
| session_track_transaction_info | OFF |
| slave_transaction_retries | 10 |
| transaction_alloc_block_size | 8192 |
| transaction_allow_batching | OFF |
| transaction_isolation | REPEATABLE-READ |
| transaction_prealloc_size | 4096 |
| transaction_read_only | OFF |
| transaction_write_set_extraction | XXHASH64 |
+----------------------------------------------------------+-----------------+
17 rows in set (0.00 sec)
Vérifiez à nouveau son binlog et voyez que beaucoup d'entre eux peuvent être lus en parallèle.
5.5 Optimisation terminée
Même si la bibliothèque principale écrit en gros lots, le délai diminue lentement. Ce n'est qu'une question de temps avant de rattraper son retard.
Profitez de GreatSQL :)
À propos de GreatSQL
GreatSQL est une base de données open source nationale indépendante adaptée aux applications financières. Elle possède de nombreuses fonctionnalités de base telles que des performances élevées, une fiabilité élevée, une grande facilité d'utilisation et une sécurité élevée. Elle peut être utilisée en remplacement facultatif de MySQL ou du serveur Percona. et est utilisé dans des environnements de production en ligne, entièrement gratuit et compatible avec MySQL ou Percona Server.
Liens connexes : Communauté GreatSQL Gitee GitHub Bilibili
Communauté GreatSQL :
Suggestions et commentaires de récompenses de la communauté : https://greatsql.cn/thread-54-1-1.html
Détails de la soumission primée du blog communautaire : https://greatsql.cn/thread-100-1-1.html
(Si vous avez des questions sur l'article ou si vous avez des idées uniques, vous pouvez accéder au site Web officiel de la communauté pour les poser ou les partager ~)
Groupe d'échange technique :
Groupe WeChat et QQ :
Groupe QQ : 533341697
Groupe WeChat : ajoutez GreatSQL Community Assistant (WeChat ID : wanlidbc) comme ami et attendez que l'assistant de communauté vous ajoute au groupe.