Salut à tous,
Voilà, depuis qqs temps je me penche un peu plus sérieusement sur les bases MySQL et j'en viens à me demander comment font les hébergeurs…
Au travail, j'héberge des bases MySQL à des fins diverses (CMS, inventaire, dév locaux…). Globalement, je ne maîtrise pas ce qui est mis dedans. Je crée une base pour mon utilisateur, et il la rempli selon ses besoins.
Bref, le problème n'est pas là. Je voudrais simplement que ces bases aient une plus grande disponibilité (lors des mises à jour ou un crash). Actuellement, je fonctionne avec du failover, donc si mon serveur tombe, toutes les connexions sont perdues le temps que la standby reprenne le relai.
Je me dis bon, je vais regarder ce qui se fait au niveau des clusters: je devrais gagner en dispo, et en plus ca devrait être plus efficace (en lecture en tout cas). Sauf que voilà, les solutions que je vois ont toutes des limitations (MySQL cluster: moteur NDB, Percona: moteur InnoDB, ne gère pas les locks…).
Donc voilà, je me posais simplement la question de savoir comment les hébergeurs faisaient?
Les gros sites, ce n'est pas vraiment un problème car ils maîtrisent le contenu. Les hébergeurs par contre, doivent avoir qqchose de 100% compatible MySQL standard, pour que les utilisateurs n'aient aucun pb à installer n'importe quel CMS.
Je ne pense pas que ces sites soient en "simple" failover. Par contre, je ne sais pas s'ils utilisent du sharding.
Si l'un d'entre vous bosse ou a bossé dans un tel environnement, je serai curieux de savoir…
Merci pour vos lumières!
# Réplication mysql / multiples slaves
Posté par ze_farf . Évalué à 1.
La réplication mysql ne répondrait pas à tes interrogations ? Un master avec n slave répliqués derrière. (en fonction de la charge)
En séparant bien les appels des lectures/écritures au niveau applicatif, les écritures se font sur le serveur maître et les lectures sont réparties sur les différents slaves derrière une ip virtuelle gérée par un load-balancer.
En cas de perte ou soucis sur le master, un slave prend son rôle et les réplications pointent désormais vers lui. Cela entraine toujours une mini coupure de service sur les écritures seulement le temps de changer le master et de faire pointer la vip des écritures sur le nouveau serveur.
[^] # Re: Réplication mysql / multiples slaves
Posté par apkwa . Évalué à 1.
C'est vrai que c'est pas bête.
Par contre, pour le rw-splitting, je suis moins sûr. Parce qu'on pourrait se trouver dans un cas où une page web écrit des données sur le master, et pour rafraîchir la page elle lise les données d'un slave qui n'a pas encore tout répliqué. Bon, c'est sûr que ca dépend de la façon dont est codée l'appli et/ou comment fonctionne le proxy (on voit de ces choses des fois…).
En tout cas, merci pour l'idée! Je pense qu'effectivement, c'est le seul moyen pour s'assurer que tout soit bien répliqué sans conflit ni omission…
[^] # Re: Réplication mysql / multiples slaves
Posté par ze_lionix (site web personnel) . Évalué à 3.
A noter : il est possible de faire une configuration multi-master de mysql, moyennant une petite contrainte : avoir une clé primaire auto-incrément sur chaque table, ce qui n'est pas franchement très contraignant à mon sens.
Cela qui permet de pouvoir écrire sur tous les nœuds et pas seulement le master !
Plus d'infomations ici !
Fuse : j'en Use et Abuse !
[^] # Re: Réplication mysql / multiples slaves
Posté par apkwa . Évalué à 2.
Merci pour le lien, c'est très intéressant!
# Maitre-esclave
Posté par GG (site web personnel) . Évalué à 2.
Bonjour,
chez un hébergeur, on ne sait pas quels seront les logiciels utilisés.
Donc, on ne peut pas demander aux utilisateurs d'écrire leur scripts de telle ou telle manière.
Du coups, le maitre-esclave n'est pas forcément une bonne solution.
Chez beaucoup d'hébergeur, pour certaines maintenances, il y a une interruption de service.
Les bases de données ne sont pas à mettre à jour tous les jours…
Tu en as plusieurs, avec plusieurs versions, que tu mets à disposition de tes utilisateurs.
Tes utilisateurs choisissent la version qui leur est nécessaire.
Tu es sensé avoir le minimum de crash…
A+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Maitre-esclave
Posté par francoisp31 . Évalué à 2.
Je préciserai même que courament ce qui est fait est la mise en place d'une réplication vers une machine de validation/test/secours… et lors des maintenances ou upgrade de versions etc… nécéssitant une interruption de service, la procédure est souvent
=stopper le master & passer le slave en lecture seule le temps de réaliser l'opération ce qui limite considérablement l'interruption de service.
ou encore
=stopper le master et réaliser l'operation et syncrho manuelle du master derrière quand il est impératif de laisser les écritures se faire.
C'est régulièrement ce que j'ai fait ou vu faire. (et pas uniquement sur mysql en fait)
[^] # Re: Maitre-esclave
Posté par apkwa . Évalué à 2.
Merci à tous les 2 pour votre retour d'expérience. Là aussi, c'est très intéressant de savoir comment ca se passe dans les grosses archi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.