Réflexions sur l'optimisation de l'architecture causée par un problème de réplication maître-esclave

Il y a un problème

L'architecture de réplication maître-esclave présente de nombreux problèmes de stagnation de la réplication tels que les erreurs 1032 et 1062. Parmi eux, l'erreur 1032 se produit après le succès de la base de données maître. exécute la mise à jour ou la mise à jour de la base de données esclave lors de la suppression, il a été constaté que cet enregistrement était introuvable sur la bibliothèque esclave. L'erreur 1062 était provoquée par un conflit de clé primaire survenu lors de l'exécution de la bibliothèque esclave après la bibliothèque principale. l'insertion a été terminée et l'insertion n'a pas pu réussir. Ces problèmes peuvent être résolus en ignorant l'erreur et la vérification des données de copie précédente résolue, mais la cause directe de ces problèmes est l'incohérence des données de la base de données maître-esclave. Outre d'éventuelles incohérences de données dans la réplication logique elle-même, cette incohérence est également causée par des ajouts, suppressions et modifications illégaux sur la base de données de secours par le côté commercial ou les développeurs.

Dans l'architecture de réplication maître-esclave, la bibliothèque maître-esclave réalise la bibliothèque désignée comme bibliothèque maître via une liaison VIP, assurant la lecture et l'écriture, et la bibliothèque esclave joue le rôle de sauvegarde lorsqu'un problème survient. dans la bibliothèque maître, le VIP passe à la bibliothèque esclave. La bibliothèque esclave assure la lecture et l'écriture, sinon la bibliothèque esclave n'est qu'une sauvegarde. Dans des circonstances normales, nous n'autorisons pas les développeurs à se connecter directement à la base de données esclave via une adresse IP fixe, mais dans le travail réel, il est souvent difficile de l'éviter. Alors, d'un point de vue technique, comment empêcher les développeurs d'opérer dans la base de données esclave ? Comment pouvons-nous éviter cela sans affecter le fonctionnement normal et le basculement de l’architecture à haute disponibilité ?

2. Optimisation de la configuration de l'architecture

(1) Solution directe

La manière directe de résoudre les problèmes ci-dessus est de considérer La configuration de l'architecture est optimisée, c'est-à-dire que l'état de lecture-écriture de la bibliothèque esclave est configuré comme un état de lecture seule.

Le site officiel de MySQL contient la description suivante concernant la lecture seule :

1.Whenthe read_only system variable is enabled, the server permits no client updatesexcept from users who have the SUPER privilege. 
只读情况下，super权限可读写。
2.Updates performed by slave threads, if theserver is a replication slave. In replication setups, 
it can be useful toenable read_only on slave servers to ensure that slaves accept updates only from themaster server and not from clients.
不影响主从复制线程的读写。

Après avoir activé la lecture seule, à l'exception des comptes super privilégiés et des threads de réplication, etc., les développeurs côté entreprise et les autres membres du personnel ne seront pas affectés Même si vous vous connectez à la base de données de secours, vous ne pouvez pas exploiter les données de la base de données de secours.

MySQL [db1]> show global variables like'read_only%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | ON   |
+---------------+-------+
1 row in set (0.00 sec)
 
MySQL [test]> insert child values('1','12');
ERROR 1290 (HY000): The MySQL server is running withthe --read-only option so it cannot execute thisstatement

(2) Comment effectuer un basculement parfait après l'avoir configuré en lecture seule ?

La lecture seule à partir de la bibliothèque esclave peut éviter les opérations illégales, mais le problème est que s'il y a un problème avec la bibliothèque principale, le VIP doit passer à la bibliothèque esclave, mais à ce stade, la lecture seule de la bibliothèque esclave entraînera la base de données. Les services externes ne sont pas disponibles, donc lors du changement, il est nécessaire d'annuler la fonction de lecture seule de la bibliothèque esclave et de définir la fonction de lecture seule de la bibliothèque principale. .

En prenant comme exemple l'architecture double maître (maître-esclave) Keepalived + MySQL, pendant le fonctionnement normal, le VIP est sur Master1, Master1 est en état de lecture-écriture et Master2 est en état de lecture seule. Une fois qu'un problème survient avec Master1, le VIP passera automatiquement à Master2, deux étapes doivent être complétées avant de basculer : 1. Réglez Master1 en lecture seule. 2. Annulez la lecture seule de Master2 ;

3. Idées de mise en œuvre automatisée

Pour une architecture maître-esclave, le basculement doit être effectué manuellement, donc les deux étapes ci-dessus peuvent également être effectuées manuellement mais Keepalived ; + MySQL double maître (dans l'architecture maître-esclave, une surveillance automatique des défauts et une commutation VIP automatique ont été mises en œuvre. Les deux étapes ci-dessus doivent également être intégrées dans des scripts pour réaliser l'automatisation.

Nous devons principalement intégrer des fonctions pour activer et désactiver la lecture seule pour la base de données dans les scripts de surveillance et de commutation automatiques. Nous écrivons principalement les instructions "set global read_only=ON" et "set globalread_only=OFF". En même temps, faites attention à Avant de définir le statut, déterminez d'abord le statut existant. Le shell appelle l'instruction "show variables like 'read_only';" pour obtenir l'état de lecture et d'écriture, définissez-le. le paramètre en lecture seule à l'état requis. Notez que la personnalisation du déclencheur de ces paramètres d'état est effectuée avant qu'une panne soit détectée et qu'un basculement soit effectué.

Les idées ci-dessus ont maintenant été automatiquement converties et le test personnel a réussi, indiquant que les idées sont correctes.

Ce qui précède est le contenu de la réflexion sur l'optimisation de l'architecture provoquée par le problème de réplication maître-esclave. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !