Comment concevoir l'architecture du système de stockage MySQL Binlog

1. Introduction à Kingbus

1.1 Qu'est-ce que Kingbus ?

Kingbus est un système de stockage de journaux binaires MySQL distribué basé sur le protocole de cohérence forte raft. Il peut agir comme un esclave MySQL pour synchroniser le binlog du vrai maître et le stocker dans un cluster distribué. Dans le même temps, il agit également comme un maître MySQL pour synchroniser le binlog du cluster avec d'autres esclaves. kingbus a les caractéristiques suivantes :

Compatible avec le protocole de réplication MySQL, synchronise le binlog sur le maître via le mode Gtid et prend en charge l'esclave pour extraire le binlog de kingbus via le mode Gtid.

Réplication de données interrégionales, Kingbus prend en charge la réplication de données interrégionales via le protocole raft. Il est garanti que les données du journal binaire écrites sur le cluster sont fortement cohérentes sur plusieurs nœuds, et l'ordre du journal binaire est totalement cohérent avec celui du maître.

Haute disponibilité, étant donné que Kingbus est construit sur le protocole de consensus fort Raft, il peut atteindre une haute disponibilité de l'ensemble du service binlog pull et push lorsque plus de la moitié des nœuds du cluster survivent.

1.2 Quels problèmes kingbus peut-il résoudre ?

Kingbus peut réduire le trafic de transmission du réseau Master. Dans une topologie de réplication avec un maître et plusieurs esclaves, le maître doit envoyer un journal binaire à chaque esclave. S'il y a trop d'esclaves, le trafic réseau risque d'atteindre la limite supérieure de la carte réseau du maître. Par exemple, lorsque le maître effectue des opérations telles que la suppression d'une grande table ou d'un DDL en ligne, un grand nombre d'événements binlog peuvent être générés instantanément. Si 10 esclaves sont connectés au maître, le trafic de la carte réseau sur le maître sera amplifié 10 fois. . Si le maître utilise une carte réseau Gigabit, la carte réseau peut être pleine si plus de 10 Mo/s de trafic est généré. En se connectant au maître via kingbus, les esclaves peuvent être distribués sur plusieurs machines pour équilibrer le trafic de transmission.

Pour simplifier le processus de basculement du maître, il vous suffit de promouvoir un esclave connecté au kingbus en maître et de rediriger le kingbus vers le nouveau maître. Les autres esclaves sont toujours connectés au kingbus et la topologie de réplication reste inchangée.

Enregistrez l'espace utilisé par le maître pour stocker les fichiers binlog. Généralement, MySQL utilise des SSD plus chers. Si le fichier binlog prend beaucoup de place, les données stockées dans MySQL devront être réduites. Vous pouvez réduire le nombre de fichiers binlog stockés sur le maître en stockant tous les binlogs dans kingbus

Prend en charge la réplication hétérogène. Connectez-vous à Kingbus via le canal open source d'Alibaba. Kingbus pousse continuellement le binlog vers le canal, reçoit le binlog, puis le pousse vers la file d'attente de messages Kafka, et enfin le stocke dans HBase. Le service commercial écrit du SQL directement via Hive pour obtenir un temps réel. analyse de l'entreprise.

2. Architecture globale du Kingbus

La structure globale de kingbus est présentée dans la figure ci-dessous :

Le stockage est responsable du stockage des entrées du journal raft et des métadonnées. Dans Kingbus, le journal raft et le binlog mysql sont intégrés. Ils se distinguent par des informations d'en-tête différentes. La partie données du journal raft est l'événement binlog, il n'est donc pas nécessaire de stocker les deux types. des journaux séparément, économisez de l'espace de stockage. Parce que kingbus doit stocker certaines méta-informations, telles que les informations de vote des nœuds de radeau et le contenu spécifique de certains événements binlog spéciaux (FORMAT_DESCRIPTION_EVENT).

Raft réplique l'élection principale, la réplication des journaux et d'autres fonctions du cluster kingbus, en utilisant la bibliothèque raft etcd.

Le synchroniseur Binlog ne s'exécute que sur le nœud Lead du cluster Raft. Il n'y a qu'un seul synchroniseur dans l'ensemble du cluster. Le synchroniseur prétend être un esclave et établit une connexion de réplication maître-esclave avec le maître. Le maître filtrera les événements de journal binaire que le synchroniseur a acceptés en fonction de l'execute_gtid_set envoyé par le synchroniseur et enverra uniquement les événements de journal binaire que le synchroniseur n'a pas reçus. reçu. Ce protocole de réplication est entièrement compatible avec le mécanisme de réplication maître-esclave MySQL. Une fois que le synchroniseur a reçu l'événement binlog, il effectuera un traitement en fonction du type d'événement binlog, puis encapsulera l'événement binlog dans un message et le soumettra au cluster radeau. Grâce à l'algorithme raft, cet événement binlog peut être stocké sur plusieurs nœuds et atteindre une forte cohérence.

Le serveur Binlog est un maître qui implémente le protocole de réplication. Le véritable esclave peut se connecter au port surveillé par le serveur binlog. Le serveur binlog enverra l'événement binlog à l'esclave. L'ensemble du processus d'envoi des événements binlog est implémenté en référence au serveur binlog. Protocole de réplication MySQL. Lorsqu'aucun événement binlog n'est envoyé à l'esclave, le serveur binlog envoie périodiquement des événements de battement de cœur à l'esclave pour maintenir la connexion de réplication active.

Le serveur API est responsable de la gestion de l'ensemble du cluster kingbus, y compris les éléments suivants :

Opération d'adhésion au cluster Raft, affichage de l'état du cluster, ajout d'un nœud, suppression d'un nœud, mise à jour des informations sur le nœud, etc.

Opérations liées au synchroniseur binlog : démarrez un synchroniseur binlog, arrêtez le synchroniseur binlog et vérifiez l'état du synchroniseur binlog.

Opérations liées au serveur binlog, démarrer un serveur binlog, arrêter le serveur binlog et vérifier l'état du serveur binlog. Diverses anomalies dans la couche serveur n'affecteront pas la couche radeau. Le serveur peut être compris comme un plug-in, qui peut être démarré et arrêté à la demande. Lors de l'extension future de Kingbus, il vous suffit d'implémenter le serveur avec la logique appropriée. Par exemple, si vous implémentez un serveur du protocole kafka, vous pouvez consommer les messages dans kingbus via le client kafka.

​3.implémentation principale de Kingbus

3.1 Implémentation de base du stockage

Il existe deux formulaires de journal stockés, l'un est le journal du radeau (ci-après dénommé le journal du radeau), qui est généré et utilisé par l'algorithme du radeau, et l'autre est le journal du formulaire utilisateur (c'est-à-dire l'événement mysql binlog) . Dans la conception du stockage, deux formulaires de journal sont combinés en une seule entrée de journal. Il se distingue uniquement par des informations d'en-tête différentes. Le stockage se compose de fichiers de données et de fichiers d'index, comme le montre la figure ci-dessous :

Le segment a une taille fixe (1 Go) et ne peut être écrit qu'en plus. Le nom est first_raft_index-last_raft_index, qui indique la plage d'index de radeau du segment.

Seul le dernier segment peut être écrit et son nom de fichier est first_raft_index-inprogress. Les autres segments sont en lecture seule.

Les segments en lecture seule et les fichiers d'index correspondants sont écrits et lus via mmap.

Le contenu de l'index du dernier segment est stocké à la fois sur le disque et dans la mémoire. La lecture de l'index nécessite uniquement une lecture depuis la mémoire.

3.2 Utilisation de la bibliothèque raft etcd

La bibliothèque raft Etcd est monothread lors du traitement des journaux appliqués, des entrées validées, etc. Veuillez vous référer au lien pour les fonctions spécifiques. Le temps de traitement de cette fonction doit être le plus court possible. Si le temps de traitement dépasse le temps d'élection du radeau, cela entraînera la réélection du cluster. Ce point nécessite une attention particulière.

3.3 L'implémentation principale du synchroniseur binlog

La tâche principale du synchroniseur binlog est :

Tirer l'événement binlog

Analyser et traiter l'événement binlog

Soumettez les événements binlog au cluster radeau. De toute évidence, le mécanisme de pipeline peut être utilisé pour améliorer la vitesse de traitement de l'ensemble du processus. Kingbus utilise un goroutine distinct pour traiter chaque étape et connecte les différentes étapes via des pipelines. Étant donné que le synchroniseur de journaux binaires reçoit les événements de journaux binaires un par un, le synchroniseur ne peut pas garantir l'intégrité des transactions. Il est possible que le maître doive être reconnecté après le raccrochement du synchroniseur. À ce stade, la dernière transaction peut être incomplète. constater que la transaction est terminée. Avec des capacités uniques, kingbus implémente la fonction d'analyse de l'intégrité des transactions, qui est entièrement implémentée en référence au code source MySQL.

​3.4 Implémentation de base du serveur binlog

Le serveur binlog implémente la fonction d'un maître. Lorsque l'esclave établit une connexion de réplication avec le serveur binlog, l'esclave envoie les commandes pertinentes et le serveur binlog doit répondre à ces commandes. Enfin, envoyez l'événement binlog à l'esclave. Pour chaque esclave, le serveur binlog démarrera une goroutine pour lire en continu le journal du radeau, supprimer les informations d'en-tête pertinentes et le transformer en un événement binlog, qui sera ensuite envoyé à l'esclave.

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!