qu'est-ce que le tissu MySQL

MySQL Fabric est un framework extensible pour gérer les groupes de serveurs MySQL. Il s'agit d'un logiciel open source GPL ; c'est-à-dire que les utilisateurs peuvent librement utiliser et modifier ce logiciel conformément aux spécifications GPL. mysql fabric est le processus qui gère toutes les demandes de gestion ; lorsque vous utilisez la fonctionnalité HA, vous pouvez confier à ce processus la responsabilité de surveiller le serveur maître et, en cas de panne, lancer le basculement et mettre à niveau le serveur esclave vers le serveur maître.

L'environnement d'exploitation de ce tutoriel : système windows7, version mysql8, ordinateur Dell G3.

Introduction à MySQL Fabric

MySQL Fabric est un framework extensible pour gérer les fermes de serveurs MySQL.

MySQL Fabric peut « organiser » plusieurs bases de données MySQL. Le système d'application distribue des tables de plus de plusieurs To à plusieurs bases de données, c'est-à-dire Data Shard. La même partition peut contenir plusieurs bases de données, et Fabric sélectionne automatiquement celle qui convient comme base de données maître, et les autres bases de données sont configurées comme bases de données esclaves pour la réplication maître-esclave. Lorsque la base de données maître raccroche, l'une des bases de données esclaves est sélectionnée pour être promue base de données maître. Ensuite, d'autres bases de données esclaves sont transférées vers la nouvelle base de données primaire pour copier les nouvelles données. Remarque : Le « automatique » mentionné ici signifie que MySQL Fabric le complète en arrière-plan sans que l'utilisateur ait à modifier manuellement la configuration. La chose la plus importante est que MySQL Fabric est un logiciel open source GPL, ce qui signifie que vous pouvez librement utiliser et modifier ce logiciel selon les spécifications GPL.

Le framework Fabric implémente deux fonctionnalités : la haute disponibilité (haute disponibilité) et l'expansion horizontale (sharding) à l'aide du partage de données. Ces deux fonctionnalités peuvent être utilisées seules ou en combinaison.

Les deux fonctionnalités sont implémentées sur la base des deux niveaux suivants :

mysql fabric est le processus qui gère toutes les demandes de gestion. Lorsque vous utilisez la fonctionnalité HA, vous pouvez également laisser ce processus surveiller le serveur maître et lancer le basculement en cas de panne, mettant ainsi à niveau le serveur esclave vers le serveur maître. Le connecteur MySQL Fabric-aware stocke les informations de routage obtenues à partir de MySQL Fabric dans un cache et utilise ces informations pour envoyer des transactions ou des requêtes au bon serveur MySQL.

Haute disponibilité

Le groupe HA se compose de deux serveurs MySQL ou plus ; à tout moment, un serveur agit comme serveur maître (le serveur maître de la fonction de réplication MySQL) et les autres serveurs agissent comme des serveurs esclaves (MySQL fonction de réplication) serveur esclave fonctionnel). Le rôle du groupe HA est de garantir que les données enregistrées dans le groupe sont toujours accessibles. La fonction de réplication de MySQL garantit la sécurité des données grâce à la réplication, et la solution haute disponibilité de MySQL Fabric fournit deux éléments supplémentaires essentiels sur cette base :

Détection des pannes et mise à niveau : MySQL Fabric surveille le serveur maître du groupe HA, sélectionne un esclave et le promeut au rang de serveur maître. maître en cas de panne du maître. Routage des requêtes de base de données : le routage des requêtes d'écriture vers le maître et l'équilibrage de charge des requêtes de lecture entre les esclaves sont transparents pour l'application, même lorsque la topologie change pendant le basculement

Partage - Mise à l'échelle horizontale

. Lorsque vous approchez des limites de capacité ou de performances d'écriture d'un serveur MySQL (ou d'un groupe HA), MySQL Fabric peut évoluer sur plusieurs serveurs MySQL. Les données sont partitionnées au sein de « groupes » de serveurs pour prendre en charge l'évolution du serveur de base de données. Notez qu'un groupe peut contenir un seul serveur MySQL ou qu'il peut s'agir d'un groupe HA. L'administrateur définit la manière dont les données sont partagées entre ces serveurs ; en spécifiant quelles colonnes de table doivent être utilisées comme clés de partitionnement et s'il faut utiliser le mappage HASH ou le mappage RANGE pour mapper ces clés aux partitions appropriées, si un partitionnement supplémentaire est nécessaire. MySQL Fabric peut être divisé. les fragments existants peuvent en outre être réaffectés.

Problèmes à résoudre par MySQL Fabric

Pourquoi partager des données ? Data Shard est souvent nécessaire lorsque votre application doit traiter des tables de plus de 1 To de données. Une table aussi grande entraînera de gros problèmes en termes d'efficacité des requêtes et des mises à jour, ou du temps requis pour sauvegarder et modifier la structure. Cependant, lorsque vous répartissez une table aussi volumineuse sur plusieurs serveurs de base de données, chaque serveur de base de données peut constituer un point de défaillance unique. Tant que un appareil raccroche, cela entraînera des problèmes de fonctionnement de l'ensemble du système . D'un autre côté, le programme côté application deviendra également plus compliqué car chaque requête doit pointer vers différentes bases de données selon ses conditions de requête (le contenu de la clause Where). De plus, lorsque la structure du partage des données change (par exemple, ajout d'une base de données), tous les programmes côté application doivent être modifiés, ce qui rend la maintenance extrêmement compliquée.

Afin de résoudre le problème de la complexité croissante des applications, quelqu'un ajoute un proxy (proxy) ou devient un commutateur entre l'application et le serveur de base de données. Toutes les instructions vers la base de données depuis l'application sont d'abord envoyées au proxy. , puis proxy détermine vers quelle base de données transférer . L'image ci-dessous est un diagramme schématique de ce plan. Cela peut résoudre le problème de la maintenance difficile des applications, mais lorsque le nombre d'applications augmente, le partage des bases de données ou la pression du système augmente, ce commutateur deviendra un goulot d'étranglement en termes de capacité et de performances. Il y a un point de défaillance unique (lorsqu'il tombe en panne). , l'application ne trouve pas la base de données ), et toutes les instructions de la base de données doivent être transmises deux fois (d'abord au commutateur, puis à la base de données). Chaque requête crée une charge supplémentaire.

L'architecture de MySQL Fabric

MySQL Fabric adopte une approche différente, et son architecture est présentée dans la figure ci-dessous. La fonctionnalité principale consiste à fusionner les commutateurs dans des connecteurs de chaque côté de l'application pour résoudre le point de défaillance unique et le goulot d'étranglement des performances d'un seul commutateur.

MySQL Fabric se compose de trois parties :

1. Nœud de gestion MySQL Fabric :

est un script python, qui est le cœur de toute l'architecture.

La fonction principale du nœud de gestion MySQL Fabric est de gérer l'intégralité de la batterie de serveurs de base de données. Lorsqu'il démarre, il trouvera le fichier de configuration /etc/mysql/fabric.cnf, qui spécifie que la structure derrière lui doit être. utilisé pour stocker l'architecture de la ferme de serveurs. Et configurer l'emplacement de la base de données MySQL, le port, le compte de connexion et d'autres informations du référentiel.

Lorsque Fabric est initialisé (exécutez la commande mysqlfabric manage setup), il ouvrira un schéma sur la base de données MySQL (généralement une base de données nommée fabric) pour stocker les informations relatives à la configuration de la batterie de serveurs, telles que les groupes de serveurs qui sont composés. quelles bases de données, quels sont les serveurs maître et esclave dans chaque groupe de serveurs, etc.

Lors de la configuration, le nœud MySQL Fabric émettra des commandes pour établir la réplication maître-esclave pour chaque base de données de la ferme de serveurs (la ligne rouge dans l'image ci-dessus).

Pingez régulièrement le serveur principal de chaque groupe pendant le fonctionnement normal. Lorsqu'il s'avère que la base de données principale ne fonctionne pas normalement, il démarre le programme de basculement et recherche un serveur approprié dans la base de données esclave de la batterie de serveurs à promouvoir. au serveur principal. Les autres bases de données esclaves se tourneront vers la nouvelle base de données maître pour continuer à répliquer les données.

2. Ferme de serveurs de base de données

Il s'agit du moteur de travail dans toute l'architecture. Dans les applications de base de données traditionnelles, il s'agit d'une seule base de données MySQL, tandis que MySQL Fabric prend en charge plusieurs bases de données (niveau To ou supérieur). et les exigences en matière de base de données à haute disponibilité. Ces bases de données sont divisées en plusieurs groupes à haute disponibilité (groupe HA), chaque groupe contient plusieurs serveurs de base de données. Les quelques carrés gris et bleu clair du bas de la figure ci-dessus représentent des groupes à haute disponibilité. S'il y a plusieurs bases de données dans le groupe haute disponibilité, MySQL Fabric sélectionnera (utilisez la commande mysqlfabric group promouvoir la commande) pour en promouvoir une vers la base de données maître (Maître), et les autres bases de données deviendront des bases de données esclaves (La base de données esclave). copiera les modifications de la base de données maître et terminera la configuration de la réplication maître-esclave au sein du même groupe haute disponibilité. À l'avenir, Fabric accédera périodiquement à cette base de données principale. Lorsque les données principales tombent en panne, Fabric en sélectionne une dans le groupe haute disponibilité et la promeut vers la base de données principale, et les autres bases de données se tournent vers cette nouvelle base de données principale pour poursuivre la réplication.

D'un autre côté, MySQL Fabric utilisera uniquement le connecteur côté application pour séparer la lecture et l'écriture de ces bases de données maître-esclave. Lorsque l'application effectue à la fois des opérations de lecture et d'écriture sur la base de données, le connecteur soumettra l'instruction. à la base de données principale. Si l'application effectue uniquement des opérations de lecture sur la base de données et que le paramètre read_only de la connexion est défini sur "ON", toutes les requêtes seront envoyées tour à tour à ces bases de données. Avec la séparation de la lecture et de l'écriture, les capacités de traitement des données du système d'application peuvent être augmentées. De plus, comme mentionné précédemment, MySQL Fabric peut également gérer des tables (tables de partitionnement) qui doivent être divisées en plusieurs serveurs de base de données. Chaque groupe haute disponibilité peut stocker une partie des données de la table de partitionnement. Le connecteur côté application enverra les instructions pour la table de partitions à différents groupes à haute disponibilité en fonction des paramètres du nœud de gestion MySQL Fabric. Cela permet à la capacité de la base de données d'augmenter à mesure que le nombre de groupes à haute disponibilité augmente. Dans le même temps, les instructions et tous les DDL émis pour la table non fractionnée seront envoyés par le connecteur au groupe global groupe haute disponibilité (groupe global La base de données principale du groupe global haute disponibilité est définie). à d'autres groupes haute disponibilité par la base de données principale MySQL Fabric. Les bases de données principales de tous les groupes à haute disponibilité qui stockent les tables fractionnées répliquent les modifications apportées au groupe global, de sorte que les autres groupes à haute disponibilité disposent d'une copie des données des tables non fractionnées. Cela facilite l'opération JOIN des tables fractionnées sur des tables non fractionnées dans SQL.

3. Connecteur

Lorsque le système d'application est en cours d'exécution, chaque commande SQL sera envoyée à la base de données via le connecteur. Le connecteur dont MySQL Fabric est équipé est le même que la base de données MySQL autonome générale, sauf que la version la plus récente du connecteur est le connecteur compatible Fabric qui a plus de fonctions pouvant gérer des batteries de serveurs de bases de données. Cela leur permet de vérifier la configuration de la batterie de serveurs dans le nœud de gestion de MySQL Fabric à l'aide du protocole XML-RPC lors de l'établissement d'une connexion à la base de données, puis les requêtes sous la connexion peuvent être envoyées à la base de données appropriée selon les instructions de la structure. .

De cette façon, le proxy qui peut provoquer des goulots d'étranglement de performances dans les solutions de fragmentation de base de données courantes est placé dans le connecteur, résolvant ainsi ce problème. Actuellement, les technologies prises en charge par MySQL Fabric incluent Java, Python et PHP, c'est-à-dire que Connector/J, Connector/Python et Connector/PHP sont tous compatibles Fabric.

Prenons Java comme exemple. Le pilote JDBC doit être Connector/J 5.1.30 ou version ultérieure. Le programme Java de Fabric est similaire au programme Java général pour interroger MySQL autonome, sauf que lors de l'établissement d'un objet de connexion à une base de données, l'URL de connexion à la base de données ne pointe pas vers la base de données mais vers le nœud de gestion MySQL Fabric (l'adresse IP et le port du serveur sont généralement 32274).

Lorsque la table interrogée est une table globale (sans fragment de table) ou DDL (comme la création d'une table ou la modification de la structure de la table), le paramètre ''fabricServerGroup=" doit être ajouté lors de l'établissement de l'objet de connexion, puis le paramètre ''fabricServerGroup=" est utilisé pour créer l'objet de connexion. La commande SQL émise sera envoyée à la base de données principale du Groupe Global, puis la base de données sera copiée vers d'autres groupes haute disponibilité (shard)

Si la table à exploiter par la commande SQL est une table partitionnée (shard table), une connexion sera établie. Ajoutez le paramètre ''fabricShardTable=" au paramètre. Ensuite, les commandes SQL émises via cet objet de connexion seront être envoyé au groupe haute disponibilité de chaque partition (fragment) selon le principe de fragmentation défini par MySQL Fabric.

De cette façon, lorsque le programme d'application émet des instructions SQL sous ces tables de partitions, il n'a pas besoin de déterminer à quelle base de données envoyer en SQL. Il appartient entièrement au connecteur de vérifier le serveur trouvé par MySQL. Fabric lors de l'établissement d'une connexion à la base de données. Il est déterminé par les informations de configuration de la batterie (quelle base de données appartient à quel groupe de partitions, le principe de division de chaque table de partitions, etc.). Et cette configuration est mise en cache côté application où se trouve le connecteur une fois la connexion principale établie.

De cette façon, il n'est pas nécessaire d'interroger à plusieurs reprises le nœud de gestion MySQL Fabric à chaque fois qu'une commande SQL est émise, et la configuration de partitionnement qui dépend du côté application est directement envoyée à la bonne base de données. L'efficacité de l'application ne sera en aucun cas réduite en raison du fractionnement des tables.

【Recommandations associées : 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!