Parlons de la solution pour le délai maître-esclave MySQL

Cet article vous apporte des connaissances pertinentes sur la solution de traitement des retards maître-esclave dans MySQL. La réplication maître-esclave et la séparation lecture-écriture sont des architectures de bases de données courantes sur Internet. La partie la plus critiquée de cette architecture est la quantité de données entrantes. Dans les scénarios avec une grande concurrence, le retard maître-esclave sera plus important. J'espère que cela aide tout le monde.

Pourquoi le délai maître-esclave est-il si grand ?

Réponse : MySQL utilise un seul thread pour rejouer RelayLog.

Comment optimiser et raccourcir le temps de replay ?

Réponse : La relecture parallèle multithread de RelayLog peut raccourcir le temps.

Quel est le problème avec la relecture parallèle multithread de RelayLog ?

Réponse : Vous devez réfléchir à la manière de diviser le RelayLog afin que plusieurs instances de base de données et plusieurs threads puissent rejouer le RelayLog en parallèle sans incohérence.

Pourquoi y a-t-il des incohérences ?

Réponse : Si le RelayLog est attribué de manière aléatoire à différents threads de relecture, supposez qu'il existe trois enregistrements de modifications en série dans le RelayLog :

mettre à jour le compte défini money=100 où

mettre à jour le compte défini money=150 ; où uid=58;

compte de mise à jour défini money=200 où uid=58;

En cas de relecture série monothread : cela peut garantir que la séquence d'exécution de toutes les bibliothèques esclaves et de la bibliothèque principale est cohérente.

Voix off : L'argent final sera de 200.

Si plusieurs threads allouent la relecture de manière aléatoire : plusieurs threads de relecture exécutent ces 3 instructions simultanément, il est incertain qui les exécute en dernier et les données finales de la base de données esclave peuvent être différentes de la base de données principale.

Voix off : Plusieurs bibliothèques esclaves peuvent avoir de l'argent de 100, 150, 200, je ne suis pas sûr.

Comment distribuer et rejouer plusieurs bibliothèques esclaves et plusieurs threads pour obtenir des données cohérentes ?

Réponse : Pour les opérations d'écriture sur la même bibliothèque, utilisez le même thread pour rejouer RelayLog ; pour les opérations d'écriture sur différentes bibliothèques, plusieurs threads peuvent être utilisés pour rejouer RelayLog simultanément.

Comment faire ?

Réponse : Concevez un algorithme de hachage, hachez (nom de la base de données) % thread-num, hachez le nom de la bibliothèque puis modulez le nombre de threads, cela peut être facilement fait. Les opérations d'écriture sur la même bibliothèque seront traitées par. le même Un thread de relecture s'exécute en série.

Voiceover : La lecture sur différentes bibliothèques se fait en parallèle, ce qui accélère la lecture.

Quelles sont les lacunes de ce plan ?

Réponse : De nombreuses entreprises utilisent une "base de données unique avec plusieurs tables" pour MySQL. Si tel est le cas, il n'y a toujours qu'une seule base de données et la vitesse de relecture de RelayLog ne peut pas être améliorée.

Éducation : mettez à niveau le modèle d'architecture de base de données « base de données unique et plusieurs tables » vers le modèle d'architecture de base de données « plusieurs bases de données et plusieurs tables ».

Voix off : Dans les scénarios commerciaux Internet avec de grandes quantités de données et une grande concurrence, le modèle « multi-bases de données » présente également de nombreux autres avantages, tels que :

(1) Extension d'instance très pratique : les administrateurs de base de données peuvent facilement étendre différentes bibliothèques pour différent selon les instances ;

(2) Isolement des bibliothèques selon les métiers : découplage des métiers, isolement des métiers, réduction du couplage et de l'influence mutuelle

(3) Il est très pratique de diviser les microservices : il est pratique que chaque service ait son propre instance

Dans le scénario « base de données unique et tables multiples », comment optimiser la relecture parallèle multithread de RelayLog ?

Réponse : Même s'il n'y a qu'une seule base de données, les transactions sont exécutées simultanément sur la base de données principale puisqu'elles peuvent être exécutées en parallèle sur la base de données principale, elles devraient également pouvoir être exécutées en parallèle sur la base de données esclave ?

Nouvelle idée : Divisez les transactions exécutées en parallèle sur la base de données principale en un groupe et numérotez-les. La lecture de ces transactions sur la base de données esclave peut être exécutée en parallèle (l'exécution des transactions sur la base de données principale entre toutes dans la préparation). phase, veuillez noter qu'il n'y a pas de conflits entre les transactions, sinon il ne serait pas possible de s'engager), oui, c'est exactement ce que fait MySQL.

Solution : réplication parallèle basée sur GTID.

À partir de MySQL 5.7, les informations soumises par le groupe sont stockées dans le GTID. À l'aide de l'outil mysqlbinlog, vous pouvez voir les informations contenues dans la soumission du groupe :

20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=1
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=2
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=3
20181014 23:52 server_id 58 XXX GTID last_committed=0 sequence_numer=4

Par rapport au journal d'origine, il y a plus de last_commit. et numéro_séquence.

Qu'est-ce que last_commit ?

Réponse : C'est le numéro de la dernière transaction soumise lorsque la transaction est soumise. S'ils ont le même last_commit, cela signifie qu'ils sont dans un groupe et peuvent être rejoués simultanément.

Résumé

La réplication parallèle MySQL, la méthode de réduction du délai de synchronisation maître-esclave, incarne certaines des idées architecturales suivantes :

Le multithreading est une méthode courante pour réduire le temps d'exécution ;

Voix off : par exemple, de nombreuses crontabs peuvent utiliser le multithreading pour diviser les données et les exécuter en parallèle.

Lorsque plusieurs threads répartissent des tâches simultanément, l'idempotence doit être assurée : MySQL propose deux méthodes : « idempotent selon la bibliothèque » et « idempotent selon commit_id », qui méritent d'être apprises

Voix off : par exemple, les messages de groupe ; peut être basé sur group_id est idempotent ; les messages utilisateur peuvent être idempotents selon user_id.

Spécifique au délai de synchronisation maître-esclave MySQL :

mysql5.5 : La réplication parallèle n'est pas supportée, tout le monde doit mettre à jour la version MySQL

mysql5.6 : Réplication parallèle selon la bibliothèque, il est recommandé d'utiliser le architecture "multi-bases de données"

mysql5 .7 : Copie parallèle selon GTID

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!