Une brève analyse de l'architecture MySQL

Présentation

La base de données est au cœur de tous les systèmes d'application, garantir le fonctionnement stable, efficace et sûr de la base de données est donc la priorité absolue du travail quotidien de toutes les entreprises. Une fois qu'un problème survient dans le système de base de données et qu'il ne peut pas fournir de services, l'ensemble du système peut ne plus pouvoir continuer à fonctionner. Par conséquent, une architecture de base de données réussie doit également prendre pleinement en compte la conception à haute disponibilité. Ci-dessous, je vais vous présenter comment créer un système de base de données MySQL hautement disponible.

La base de données est au cœur de tous les systèmes d'application, garantir le fonctionnement stable, efficace et sûr de la base de données est donc la priorité absolue de toutes les entreprises dans leur travail quotidien. Une fois qu'un problème survient dans le système de base de données et qu'il ne peut pas fournir de services, l'ensemble du système peut ne plus pouvoir continuer à fonctionner. Par conséquent, une architecture de base de données réussie doit également prendre pleinement en compte la conception à haute disponibilité. Ci-dessous, je vais vous présenter comment créer un système de base de données MySQL hautement disponible.

Les étudiants qui ont fait de la DBA ou de l'exploitation et de la maintenance doivent savoir que l'existence d'un point unique pour tout appareil ou service entraînera d'énormes risques, car une fois que la machine physique tombe en panne ou que le module de service tombe en panne, il est impossible de trouver un remplaçant en un rien de temps. période de temps. L'équipement affectera inévitablement l'ensemble du système d'application. Par conséquent, comment garantir qu'il n'y a pas de point unique est notre tâche importante. L'utilisation des solutions de haute disponibilité MySQL peut bien résoudre ce problème. Généralement, il existe les types suivants :

. 1. Utilisez la propre réplication de MySQL pour obtenir une haute disponibilité

La réplication fournie avec MySQL est ce que nous appelons souvent la réplication maître-esclave (réplication AB). En créant une machine esclave pour le serveur maître, lorsque le serveur maître est en panne, l'entreprise peut être rapidement basculée vers la machine esclave pour garantir sa sécurité. l'utilisation normale de l'application. Les solutions de haute disponibilité utilisant la réplication AB se déclinent également en plusieurs architectures différentes :

1. Solution MAÎTRE---ESCLAVE conventionnelle

Ordinary MASTER---SLAVE est actuellement la solution architecturale la plus couramment utilisée par la plupart des petites et moyennes entreprises au pays et à l'étranger. Ses principaux avantages sont la simplicité, moins d'équipement (coût inférieur) et une maintenance facile. Cette architecture peut résoudre des problèmes ponctuels et résoudre dans une large mesure les problèmes de performances du système. Un MASTER peut être suivi d'un ou plusieurs SLAVE (réplication en cascade maître-esclave). Cependant, cette architecture nécessite qu'un MASTER soit capable de satisfaire toutes les demandes d'écriture du système. Dans le cas contraire, un fractionnement horizontal est nécessaire pour partager la pression de lecture.

Image 1

Image 2
Les figures 1 à 2 montrent le processus de résolution de problèmes ponctuels et d'utilisation de la séparation de lecture et d'écriture pour améliorer les performances.

2. Combinaison de DUAL MASTER et de réplication en cascade
Un double maître et plusieurs esclaves constituent une solution plus raisonnable dérivée de la solution ci-dessus. L’avantage de cette solution est qu’en cas de panne de l’un des deux serveurs principaux, l’ensemble de l’architecture ne nécessite pas d’ajustements majeurs.

Image 3

Image 4

Image 5

Ce processus est illustré dans l'image ci-dessus. Mais la situation de la figure 5 est assez particulière : que devons-nous faire si MASTER-B tombe en panne ? La première chose qui peut être déterminée est que toutes nos requêtes d'écriture ne seront affectées d'aucune façon et que toutes les requêtes de lecture seront accessibles normalement ; mais toutes les réplications de l'esclave seront interrompues et les données sur l'esclave commenceront à prendre du retard. Ce que nous devons faire à ce stade est d'effectuer une opération CHANGE MASTER TO sur tous les esclaves et de les copier à partir du maître A à la place. Étant donné que toutes les réplications de l'esclave ne peuvent pas avancer par rapport à la source de données d'origine, le point de départ exact de la réplication peut être trouvé en comparant les informations d'horodatage du journal de relais sur l'esclave avec les informations d'horodatage du maître A pour éviter toute corruption ou perte de données.

2. Utilisez MYSQL CLUSTER pour obtenir une haute disponibilité globale

Pour l'instant, la solution consistant à utiliser MYSQL CLUSTER pour atteindre une haute disponibilité globale (c'est-à-dire NDB CLUSTER) n'est pas très populaire parmi les entreprises nationales. Le nœud NDB CLUSTER est en fait un serveur MySQL multi-nœuds, mais il ne contient pas de données, il peut donc être utilisé sur n'importe quelle machine tant qu'il est installé. Lorsqu'un nœud SQL du cluster tombe en panne, les données ne seront pas perdues car le nœud ne stocke pas de données spécifiques. Comme le montre la figure 6 :

Image 6

3. Obtenez une haute disponibilité grâce aux dérivés MySQL

Parmi les dérivés MySQL actuels qui atteignent une haute disponibilité, les plus connus et les plus populaires sont GALERA CLUSTER et PERCONA XTRDB CLUSTER (PXC). Le contenu pertinent ne sera pas décrit dans cet article pour le moment. Les étudiants intéressés peuvent consulter les informations pertinentes pour en savoir plus. Les méthodes de mise en œuvre de ces deux clusters sont similaires, comme le montrent la Figure 7 et la Figure 8 :

Image 7

Image 8

4. Comparaison des avantages et des inconvénients de différentes solutions de haute disponibilité

Dans l'introduction précédente des diverses solutions de conception à haute disponibilité, les lecteurs ont peut-être découvert que quelle que soit la solution utilisée, elle présente ses propres avantages, mais il existe également plus ou moins de limites. Cette section procédera à une analyse des avantages et des inconvénients des principales options ci-dessus pour votre référence dans le processus de sélection.

1. Réplication MySQL

Avantages : déploiement simple, mise en œuvre facile et maintenance simple. Il s'agit d'une fonction que MySQL prend en charge de manière inhérente. Et il est facile de basculer entre les machines actives et en veille. La commutation active et en veille peut être automatiquement effectuée via un logiciel tiers ou des scripts auto-écrits.

Inconvénient : si le matériel de l'hôte maître tombe en panne et ne peut pas être restauré, certaines données qui n'ont pas été transmises à l'esclave peuvent être perdues.

2. Cluster MySQL (NDB)

Avantages : Très haute disponibilité et très bonnes performances. Chaque élément de données possède au moins une copie sur différents hôtes et les copies de données redondantes sont synchronisées en temps réel.

Inconvénients : la maintenance est plus compliquée, le produit est plus récent, il y a quelques bugs et il peut ne pas convenir actuellement aux systèmes en ligne de base.

3. GRAPPE GALERA et GRAPPE PERCONA XTRDB (PXC)

Avantages : La fiabilité est très élevée. Tous les nœuds peuvent lire et écrire chaque élément de données en même temps. Il existe au moins une copie sur différents hôtes et les copies de données redondantes sont synchronisées en temps réel.

Inconvénients : à mesure que la taille du cluster augmente, les performances deviendront de moins en moins bonnes.

4. La solution de mise en miroir du réseau de disques DRBD qu'il faut mentionner

Architecturalement parlant, il est quelque peu similaire à la réplication, sauf qu'il implémente le processus de synchronisation des données via un logiciel tiers. La fiabilité est supérieure à la réplication, mais elle sacrifie également les performances.
Avantages : le logiciel est puissant, les données sont reflétées sur les hôtes physiques au niveau du périphérique bloc sous-jacent et différents niveaux de synchronisation peuvent être configurés en fonction des exigences de performances et de fiabilité. Les opérations d'E/S maintiennent l'ordre, ce qui peut répondre aux exigences strictes de la base de données en matière de cohérence des données.

Inconvénients : les environnements de système de fichiers non distribués ne peuvent pas prendre en charge la visibilité simultanée des données miroir, c'est-à-dire que les performances et la fiabilité sont contradictoires et ne peuvent pas être appliqués à des environnements qui ont des exigences strictes pour les deux. Les coûts de maintenance sont plus élevés que la réplication MySQL.

Après avoir parlé des avantages et des inconvénients des différentes architectures couramment utilisées, la question restante est de savoir comment choisir l'architecture appropriée à utiliser dans un environnement de production réel. Chacun a ses propres idées et expériences à cet égard, et quelle solution est la meilleure est une question d'opinion. Dans le travail quotidien, l'amélioration de l'architecture ne se réalise pas du jour au lendemain, mais constitue un processus d'évolution, d'optimisation et d'amélioration continue.

Gitui a également expérimenté le processus du point unique au maître-esclave puis au maître-esclave + haute disponibilité en termes de base de données. Il a également expérimenté le passage d'un seul MySQL+redis à MySQL+redis+es, et enfin au MySQL+ actuel. redis+es +L'évolution de codis et ainsi de suite. Chaque évolution vise à résoudre des problèmes pratiques et des points sensibles dans l'environnement de production. Du seul point de vue de MySQL, aucune architecture ne peut résoudre tous les problèmes (points douloureux), et une architecture appropriée doit être sélectionnée en fonction de la situation réelle. La solution mise en œuvre par le cluster MySQL est très flexible et modifiable. C'est également un défi pour les travailleurs de MySQL de choisir une architecture adaptée. C'est également une motivation pour nous de continuer à étudier et à apprendre 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!