Exécuter deux serveurs MySQL qui utilisent le même répertoire de données
La situation
J'ai deux instances MySQL, déployées sur deux machines distantes différentes.
[.
Je suis conscient qu'il est fortement découragé d'exécuter deux serveurs MySQL à l'aide du même répertoire de données, mais ce n'est pas une chose impossible à faire, tant que l'on prend les bonnes précautions. Pour ce faire, j'ai suivi les étapes suggérées par la documentation officielle ( https://dev.mysql.com/doc/refman/5.6/fr/MultiPle-Data-Directories.html ), Plus spécifiquement dans le paragraphe nommé Avertissement . Résumer:
- J'utilise MySQL 5.6.
- J'utilise Myisam comme moteur par défaut, selon les besoins.
- J'ai spécifié les noms de fichiers journaux propres à chaque serveur.
- Un serveur va être en lecture-écriture, tandis que l'autre serveur sera en lecture seule.
Donc, j'ai tout mis en place, j'ai importé une base de données de test et tout a fonctionné parfaitement. Les deux serveurs pourraient lire les données du même répertoire de données.
Le problème
Vient maintenant le problème. Dès qu'un serveur effectue une écriture (en insérant une ligne dans une table), l'autre serveur marque le tableau comme corrompu pour lui-même. Après avoir examiné le problème pendant un certain temps, j'ai découvert pourquoi cela s'est passé. Fondamentalement, chaque serveur détient ses propres métadonnées décrivant chaque table. Donc, dès que le premier serveur mis à jour une table, il a également mis à jour ses propres métadonnées, mais elle n'a pas mis à jour les métadonnées du deuxième serveur. Comme le deuxième serveur a vérifié la table, il a constaté une inadéquation entre le nombre actuel de lignes dans la table et le nombre de lignes qu'elle avait précédemment enregistrées dans ses métadonnées, elle a donc marqué la table comme corrompue. Après quelques recherches, il s'avère que les métadonnées sont sauvegardées dans une base de données par défaut nommée informations_schema. Au début, j'ai pensé à faire partager les deux serveur le même informations_schema, mais cela n'était nulle part être trouvé. Comme je l'ai découvert plus tard, il est sauvé à l'intérieur de la mémoire du programme et que vous ne pouvez pas mettre à jour manuellement ou y accéder manuellement.
Questions
- Étant donné que la documentation vous dit exactement quelles précautions à prendre, je m'attendais à ce que cela fonctionne réellement ... ou bien, quel est le point de ce guide dans la documentation officielle? Si cela ne pouvait pas être fait, pourquoi voudriez-vous vous dire comment le faire en premier lieu?
- Plus important encore, savez-vous comment faire ce travail, en utilisant MySQL?
- Sinon, connaissez-vous d'autres DBMS qui vous permettent d'obtenir ce résultat (c'est-à-dire exécutant deux serveurs qui utilisent le même répertoire de données)?
N'oubliez pas que je ne veux pas configurer la réplication de maître-esclave.
[.____] Toutes les autres suggestions sont les bienvenues, merci à tout le monde pour l'aide.
EDIT: J'ai fini par ne pas le faire, comme tout le monde m'a découragé de le faire. Merci à tous pour votre contribution!
Étant donné que la documentation vous dit exactement quelles précautions à prendre, je m'attendais à ce que cela fonctionne réellement ... ou bien, quel est le point de ce guide dans la documentation officielle? Si cela ne pouvait pas être fait, pourquoi voudriez-vous vous dire comment le faire en premier lieu?
Plus important encore, savez-vous comment faire ce travail, en utilisant MySQL?
Vous avez dit quelque chose qui pourrait avoir une incidence sur les deux premières questions
Les deux instances MySQL accèdent au même répertoire de données, qui est stockée sur un volume persistant (ce volume est fourni par GLUSTER, mais ce n'est pas vraiment pertinent, je ne dis que ceci à des raisons d'exhaustivité).
Fait intéressant, quelqu'un a prétendu l'avoir tiré.
Sur Sep 24, 2010 (presque les années, il y a des années), Richard Holloway répondit-il à une question qu'il avait lui-même affichée en défaut de serveur: Can I run mysqld on top of glusterfs?
Critant la réponse de Richard Holloway
- Désactiver le cache de requête (SET QUERY_CACHE_TYPE = 0, QUERY_CACHE_SIZE = 0)
- Allumez le verrouillage extérieur
- désactiver les retards à écrire.
C'est une réponse très audacieuse ( Godspeed, Spiderman !!! )
Juste pour jeter mes 2 cents
- NE PAS UTILISER GLUSTERFS EN MODE ASYNC !!!
- Configurer Skip-Innodb sur les deux cas mysqld
- Sinon, connaissez-vous d'autres DBMS qui vous permettent d'obtenir ce résultat (c'est-à-dire exécutant deux serveurs qui utilisent le même répertoire de données)?
La réponse est Oracle RAC. Il est conçu pour utiliser plusieurs instances Oracle partageant un seul ensemble de datafiles. Chaque instance a son propre tampon de journal. Oh oui, vous aurez besoin d'une charge de bateau (Oracle RAC n'est pas open source).
Ne le fais pas. MySQL n'est pas conçu pour gérer des instances séparées touchant les mêmes fichiers de disque. Même si c'est le cas, je ne le ferais pas confiance car les développeurs sont axés sur d'autres problèmes, tels que l'optimisation.
L'optimisation dépend souvent de l'utilisation de RAM et moins d'utilisation du disque. Même s'il y a du code pour un verrouillage externe, pensez à quel point cela ralentirait les requêtes!
Que espérez-vous gagner? Si vous supposez que le serveur est plus fragile que le réseau et les lecteurs de disque, considérez Galera (bien testé, populaire, etc.). La réplication du groupe sera bientôt un concurrent important de Galera; Il est fortement développé, poussé et soutenu par Oracle.
MySQL est résilient au crash d'un serveur. Si vous pouvez récupérer le (s) disque (s) et les attacher à une nouvelle CPU + etc., alors essentiellement la "récupération d'une panne de courant" peut vous ramener là où vous avez laissé OFF (moins toutes les transactions non engagées).
La résilience de la perte d'un lecteur de disque tilisé pour Soyez le grand souci. Par conséquent, RAID, DRBD, Réplication, Galera, Réplication du groupe, Aurora, etc.
On dirait que Glusterfs est un concurrent avec NetApp. Les deux sont d'énormes disques. N'hésitez pas à mettre deux instances de mysql parler à deux Partitions d'un Glusterfs; C'est souvent fait avec NetApp.
Retour à l'échec du serveur ... Il est également correct d'avoir ne Configuration du disque avec ne instance MySQL, plus la possibilité de tirer un autre exemple contre ce même "disque" dans l'événement d'une défaillance du serveur. Il suffit de ne pas avoir les deux instances courir en même temps.