Il existe de nos jours de nombreux fournisseurs de cloud. Ils peuvent être petits ou grands, locaux ou avec des centres de données répartis dans le monde entier. Beaucoup de ces fournisseurs de cloud proposent une sorte de solution de base de données relationnelle gérée. Les bases de données prises en charge sont généralement MySQL ou PostgreSQL ou une autre variante de base de données relationnelle.
Lors de la conception de tout type d'infrastructure de base de données, il est important de comprendre les besoins de votre entreprise et de décider du type de disponibilité que vous devez atteindre.
Dans cet article de blog, nous examinerons les options de haute disponibilité pour les solutions basées sur MySQL de l'un des plus grands fournisseurs de cloud :Google Cloud Platform.
Déployer un environnement hautement disponible à l'aide d'une instance SQL GCP
Pour ce blog, nous voulons un environnement très simple - une base de données, avec peut-être une ou deux répliques. Nous voulons pouvoir basculer facilement et restaurer les opérations dès que possible en cas de défaillance du maître. Nous utiliserons MySQL 5.7 comme version de choix et commencerons par l'assistant de déploiement d'instance :
Nous devons ensuite créer le mot de passe root, définir le nom de l'instance et déterminer où il doit être situé :
Ensuite, nous examinerons les options de configuration :
Nous pouvons apporter des modifications en termes de taille d'instance (nous irons avec db-n1-standard-4), le stockage et le calendrier de maintenance. Ce qui est le plus important pour nous dans cette configuration, ce sont les options de haute disponibilité :
Ici, nous pouvons choisir de créer un réplica de basculement. Cette réplique sera promue maître en cas de défaillance du maître d'origine.
Après avoir déployé la configuration, ajoutons un esclave de réplication :
Une fois le processus d'ajout de la réplique terminé, nous sommes prêts pour quelques essais. Nous allons exécuter la charge de travail de test à l'aide de Sysbench sur notre maître, notre réplica de basculement et notre réplica en lecture pour voir comment cela fonctionnera. Nous exécuterons trois instances de Sysbench, en utilisant les points de terminaison pour les trois types de nœuds.
Ensuite, nous déclencherons le basculement manuel via l'interface utilisateur :
Tester le basculement MySQL sur Google Cloud Platform ?
J'en suis arrivé là sans aucune connaissance détaillée du fonctionnement des nœuds SQL dans GCP. J'avais cependant certaines attentes, basées sur l'expérience précédente de MySQL et sur ce que j'ai vu chez les autres fournisseurs de cloud. Pour commencer, le basculement vers le nœud de basculement devrait être très rapide. Ce que nous aimerions, c'est garder les esclaves de réplication disponibles, sans avoir besoin d'une reconstruction. Nous aimerions également voir à quelle vitesse nous pouvons exécuter le basculement une seconde fois (car il n'est pas rare que le problème se propage d'une base de données à une autre).
Ce que nous avons déterminé lors de nos tests...
- Lors du basculement, le maître est redevenu disponible au bout de 75 à 80 secondes.
- L'instance dupliquée de basculement n'a pas été disponible pendant 5 à 6 minutes.
- Le réplica en lecture était disponible pendant le processus de basculement, mais il est devenu indisponible pendant 55 à 60 secondes après que le réplica de basculement est devenu disponible
Ce dont nous ne sommes pas sûrs...
Que se passe-t-il lorsque l'instance dupliquée de basculement n'est pas disponible ? En fonction de l'heure, il semble que le réplica de basculement est en cours de reconstruction. Cela a du sens, mais le temps de récupération serait alors fortement lié à la taille de l'instance (en particulier les performances d'E/S) et à la taille du fichier de données.
Que se passe-t-il avec le réplica en lecture après que le réplica de basculement ait été reconstruit ? À l'origine, le réplica en lecture était connecté au maître. Lorsque le maître échoue, nous nous attendons à ce que le réplica en lecture fournisse une vue obsolète de l'ensemble de données. Une fois que le nouveau maître apparaît, il doit se reconnecter via la réplication à l'instance (qui était auparavant une réplique de basculement et qui a été promue maître). Il n'y a pas besoin d'une minute de temps d'arrêt lorsque CHANGE MASTER est en cours d'exécution.
Plus important encore, pendant le processus de basculement, il n'y a aucun moyen d'exécuter un autre basculement (ce qui a du sens) :
Il n'est pas non plus possible de promouvoir un réplica en lecture (ce qui n'a pas forcément de sens - nous nous attendrions à pouvoir promouvoir des répliques en lecture à tout moment).
Il est important de noter qu'il faut compter sur les réplicas en lecture pour fournir une haute disponibilité (sans créer de réplica de basculement) n'est pas une solution viable. Vous pouvez promouvoir un réplica en lecture pour qu'il devienne un maître, mais un nouveau cluster sera créé ; détaché du reste des nœuds.
Il n'y a aucun moyen d'asservir vos autres répliques du nouveau cluster. La seule façon de le faire serait de créer de nouvelles répliques, mais c'est un processus qui prend du temps. Il est également pratiquement inutilisable, ce qui fait de l'instance dupliquée de basculement la seule véritable option de haute disponibilité pour les nœuds SQL dans Google Cloud Platform.
Conclusion
Bien qu'il soit possible de créer un environnement hautement disponible pour les nœuds SQL dans GCP, le maître ne sera pas disponible pendant environ une minute et demie. L'ensemble du processus (y compris la reconstruction du réplica de basculement et certaines actions sur les réplicas en lecture) a pris plusieurs minutes. Pendant ce temps, nous n'avons pas été en mesure de déclencher un basculement supplémentaire, ni de promouvoir un réplica en lecture.
Avons-nous des utilisateurs GCP ? Comment obtenez-vous une haute disponibilité ?
