suivi du décalage d'esclave

Question

J'ai une configuration maître-maître et j'ai remarqué que le maître actif peut gérer plusieurs requêtes simultanées à la fois tandis que l'esclave lit une requête à la fois et prend beaucoup de temps à rattraper.

1) Y at-il une solution à cela?

2) Pourquoi l'esclave affiche-t-il 0 seconde comme "secondes_support_maser". Il y a des moments où il montre le bon nombre de secondes qu'il est derrière. Mais dans mon cas, il montre 0 secondes tout en lisant à partir du journal.

3) Pourquoi mmm_control montre-t-il que les deux maîtres sont en ligne alors que je m'attendais à ce qu'un maître soit dans l'état "en attente de récupération".

Answer 1

Pour le maître, peu importe l'ordre des mises à jour simultanées/rollbacks/timeout etc. Tout ce qu'il a fait pour résoudre un conflit est correct et les clients reçoivent les bonnes réponses.

L'esclave doit cependant exécuter les mises à jour exactement dans le même ordre que le maître, la seule manière d'y parvenir est d'exécuter les mises à jour séquentiellement dans l'ordre dans lequel le maître les a validées. Donc non seulement il doit être un thread unique, il ne peut commencer à travailler qu'après que le maître a engagé. Habituellement, cela signifie que lorsque l'enregistrement du journal de validation est vidé sur le disque, il y a donc des E/S physiques à attendre.

Answer 2

Re: 1) Bien que plusieurs instructions puissent s'exécuter simultanément sur le maître actif, le processus d'exécution de la réplication est monothread afin d'assurer la cohérence des données entre les serveurs.

Je ne l'ai jamais utilisé, mais vous pourriez vouloir étudier Maatkit'smk-slave-prefetch pour réchauffer votre esclave dans l'espoir d'accélérer vos mises à jour.

Re: 2) L'esclave affichera 0 secondes derrière le maître s'il n'a encore rien à exécuter depuis le fil de récupération. Cela peut souvent arriver dans des environnements avec une latence de réseau élevée (par rapport au thread d'exécution).