Comprendre la haute disponibilité de MySQL : Bonnes et mauvaises raisons de l'utiliser

Le coût des temps d'arrêt dans l'environnement de l'entreprise s'accumule rapidement. Dans une enquête, 40 % des personnes interrogées ont indiqué qu'une seule heure d'indisponibilité coûtait à leur organisation plus d'un million de dollars de pertes. S'assurer que les services de base de données sont disponibles en permanence en vaut clairement la peine.

Elle permet à votre organisation d'économiser d'importantes sommes d'argent, sans parler de l'apaisement des relations avec les parties prenantes de toutes formes et de toutes tailles.

Alors, comment assurer une disponibilité continue ? Le concept qui sous-tend la disponibilité persistante est appelé haute disponibilité. Dans cet article, nous décrivons ce qu'est la haute disponibilité et comment vous pouvez l'obtenir pour vos clusters MySQL.

Nous soulignons également un aspect plus sombre de la haute disponibilité, lorsque les administrateurs système s'appuient à tort sur la haute disponibilité pour effectuer des tâches de maintenance - et nous expliquons pourquoi cela sape les objectifs de la haute disponibilité et met en péril les opérations de votre entreprise.

Introduction à la haute disponibilité

Parlons d'abord de la disponibilité. Il n'y a guère d'intérêt à exploiter un service tel qu'une base de données s'il n'est pas disponible pour les utilisateurs la plupart du temps. Par conséquent, lorsque nous parlons de disponibilité, nous faisons référence au degré d'accessibilité d'un service.

Pour tout service qui fonctionne, on peut raisonnablement s'attendre à ce qu'il soit disponible en cas de besoin - mais on peut également s'attendre à des temps d'arrêt, un jour ou deux par an ou peut-être quelques heures par mois.

Un service généralement disponible peut convenir à de nombreux cas d'utilisation, mais lorsqu'il s'agit d'un service critique ou qu'un très grand nombre d'utilisateurs dépendent d'un service, la simple "disponibilité" n'est tout simplement pas suffisante.

C'est là qu'intervient la haute disponibilité. En termes simples, la haute disponibilité garantit un niveau de disponibilité supérieur à celui normalement attendu et, plus précisément, un niveau convenu, même en tenant compte de la maintenance, des correctifs et des erreurs et pépins en général.

Quel est le niveau de disponibilité de la haute disponibilité ?

Il n'existe pas de définition convenue de ce qui constitue une haute disponibilité, si ce n'est qu'elle dépasse ce qui est généralement considéré comme "disponible" afin de répondre à une exigence de disponibilité spécifiée (plus élevée). En fait, votre organisation définira probablement la disponibilité dont elle a besoin en fonction de ses besoins opérationnels, en mettant en balance les coûts de la haute disponibilité et les pertes associées aux temps d'arrêt.

Le niveau de disponibilité dont vous avez besoin peut être exprimé en pourcentage. Par exemple, une disponibilité de 99,99 % ou "quatre neuf" implique un maximum de 52,60 minutes de temps d'arrêt par an, tandis qu'une disponibilité de "six neuf" ou 99,9999 % limite le temps d'arrêt à 31,56 secondes par an.

Pour l'essentiel, vous avez le choix - mais, une fois encore, il y a un compromis à faire. Le maintien d'une haute disponibilité sera coûteux - il nécessitera des ressources physiques et des licences logicielles supplémentaires et mobilisera également les ressources de votre personnel. Cependant, il se peut que vous trouviez que ce prix vaut la peine d'être payé pour éviter les coûts d'interruption ou les risques de perte de revenus dus à des clients mécontents.

Comment fonctionne la haute disponibilité dans la pratique ?

La nature exacte de votre infrastructure de haute disponibilité dépend de votre charge de travail. Toutefois, de manière générale, on peut dire que la haute disponibilité est atteinte lorsqu'il existe une tolérance aux pannes, de sorte que même si un service ou un dispositif tombe en panne, la charge de travail n'est pas interrompue. En règle générale, cela signifie qu'il n'y a pas de point de défaillance unique - tous les services et dispositifs sont entièrement redondants au niveau du réseau et de l'application.

En fonction du service, cela peut impliquer un certain nombre de nœuds - par exemple, votre cluster MySQL contiendra plusieurs nœuds sur lesquels les données sont stockées. Les nœuds multiples sont ensuite combinés avec un outil d'équilibrage de la charge de sorte que, si un nœud tombe en panne, les demandes sont simplement dirigées vers un autre nœud. Les utilisateurs continueront d'accéder à un service disponible, même si les performances sont légèrement dégradées.

Configuration de la haute disponibilité dans MySQL

Votre chemin vers une base de données MySQL à haute disponibilité dépendra, bien sûr, de votre implémentation de MySQL. D'une manière générale, vous devrez créer un type de cluster MySQL avec plusieurs nœuds - en d'autres termes, vos données doivent résider sur plusieurs serveurs MySQL.

Ensuite, vous aurez besoin d'un service capable de répliquer les données sur ces nœuds, de sorte que chaque nœud dispose d'une copie exacte des données contenues dans votre base de données. Enfin, vous avez besoin d'un équilibreur de charge qui veille à ce que toutes les demandes de base de données soient dirigées de manière égale vers les nœuds de base de données - assurant, oui, une charge équilibrée - mais garantissant également que les demandes sont satisfaites même si un nœud est hors ligne.

Par exemple, MySQL propose un produit commercial destiné à la haute disponibilité : le MySQL InnoDB Cluster. Il repose sur MySQL Group Replication, une méthode couramment utilisée pour garantir la haute disponibilité dans un environnement de base de données MySQL. Si vous utilisez des versions plus anciennes, il est essentiel de suivre le statut de fin de vie de MySQL afin de vous assurer que vous continuez à recevoir des mises à jour de sécurité actives.

Une autre alternative est Galera, qui offre la haute disponibilité de MySQL depuis de nombreuses années. Si vous utilisez la version MariaDB de MySQL, vous pouvez par exemple configurer votre environnement MariaDB pour la haute disponibilité en exécutant plusieurs nœuds à l'aide de Galera Cluster - tout en s'appuyant sur HAProxy pour l'équilibrage de la charge. Vous pouvez également vous pencher sur le propre produit MaxScale de MariaDB.

Si vous utilisez spécifiquement MariaDB 10.6, il est également utile de savoir que cette version arrivera en fin de vie en juillet 2026. Renseignez-vous sur les implications de la fin de vie de MariaDB 10.6 pour votre environnement avant de planifier votre configuration de haute disponibilité.

DE BONNES RAISONS DE S'APPUYER SUR LA HAUTE DISPONIBILITÉ...

Les charges de travail à l'échelle de l'entreprise font de plus en plus appel aux principes de la haute disponibilité, tout simplement parce qu'à long terme, c'est ce qui donne les meilleurs résultats. Voici quelques-unes des nombreuses bonnes raisons pour lesquelles vous devriez envisager de mettre en place la haute disponibilité dans vos opérations :

• Applications critiques. Certaines applications ne peuvent tout simplement pas se permettre le moindre temps d'arrêt, comme les applications militaires ou les réseaux d'énergie. La haute disponibilité est indispensable dans ces scénarios, et vous n'avez guère d'autre choix que de garantir des niveaux de disponibilité extrêmement élevés - même si vous pouvez encore évaluer les risques et décider exactement du niveau de garantie de disponibilité dont vous avez besoin.
• Effets d'entraînement. Lorsqu'un système est au cœur d'une charge de travail, un temps d'arrêt, même bref, peut entraîner des problèmes beaucoup plus étendus, car les systèmes connectés et synchronisés tombent en cascade. Il vaut la peine d'envisager d'investir dans la haute disponibilité dans quelques domaines essentiels - tels qu'une base de données - car le coût peut en valoir la peine, étant donné que les coûts des problèmes en cascade beaucoup plus importants peuvent être très difficiles à récupérer.
• Perte de revenus. Une haute disponibilité, même si elle n'atteint qu'un nombre modeste de neuf, peut protéger contre les pertes de revenus. Pour un grand détaillant en ligne, quelques heures seulement de ventes perdues, combinées à l'atteinte à la réputation qui en découle, peuvent avoir un impact très important sur le résultat net.
• Attentes des clients et accords de niveau de service. Vos opérations peuvent être liées à des accords de niveau de service garantissant à vos clients un certain niveau de disponibilité. Si c'est le cas, vous devez vous assurer que les services qui prennent en charge les charges de travail de vos clients ont le niveau de disponibilité requis - et vous y parviendrez grâce à la haute disponibilité. Si vous ne le faites pas, vous risquez de voir vos contrats résiliés ou de devoir payer des pénalités.

Ce sont là quelques-unes des raisons valables de la haute disponibilité - et, encore une fois, dans le monde technologique d'aujourd'hui, il existe de nombreuses charges de travail qui ne peuvent tout simplement pas fonctionner sans une plate-forme de haute disponibilité en place.

... et la mauvaise raison de compter sur la haute disponibilité 

La prévalence croissante de la haute disponibilité a malheureusement conduit à des abus. Parce que la haute disponibilité rend les systèmes incroyablement robustes, les équipes techniques peuvent être tentées de prendre des raccourcis lorsqu'elles effectuent des tâches d'administration telles que l'application de correctifs, parce qu'elles supposent que l'infrastructure à haute disponibilité supportera simplement le fardeau de la mise hors ligne d'une machine.

Dans la pratique, cela peut rapidement devenir plus compliqué. Prenons l'exemple d'un cluster MySQL. Oui, si vous redémarrez une machine pour la corriger, votre cluster MySQL continuera à fonctionner grâce à la haute disponibilité. Cependant, n'oubliez pas que lorsque vous mettez un nœud hors service pour appliquer un correctif et que vous le redémarrez ensuite, il en résulte un arriéré de données qui doivent être introduites. Ce processus peut prendre beaucoup de temps.

Il va sans dire que chaque hôte de la base de données doit voir les mêmes données. Le danger survient lors de la resynchronisation : si un autre nœud tombe en panne alors que vous avez déjà retiré un nœud pour le réparer, vous pouvez vous retrouver avec une perte de quorum valide. En d'autres termes, le nombre de serveurs qui détiennent la "vérité" sur les données tombe en dessous d'un niveau acceptable. La récupération d'un tel état peut s'avérer difficile et complexe et même conduire à la perte de données.

Ne pas compter sur la haute disponibilité pour la maintenance

La haute disponibilité est là pour maintenir vos systèmes opérationnels même en cas de défaillance. Cette protection inhérente contre les défaillances n'est pas un laissez-passer pour dépendre de la robustesse de la haute disponibilité afin d'effectuer la maintenance du système de manière irresponsable, en espérant que personne ne s'en apercevra.

Les équipes techniques devraient plutôt s'appuyer sur d'autres solutions - par exemple, mettre en place une redondance complète pour un système qui fait l'objet d'un correctif plutôt que d'espérer simplement que l'infrastructure à haute disponibilité absorbera la pression. Ou, lorsque c'est possible s'appuyer plutôt sur des correctifs en direct et, ce faisant, supprimer la nécessité de redémarrer un service pour installer un correctif.

Néanmoins, la dépendance à l'égard de la haute disponibilité pour les tâches de maintenance montre des signes inquiétants de prévalence. En cherchant un peu, vous trouverez même des conseils officiels de fournisseurs qui demandent aux utilisateurs de dépendre de la haute disponibilité pour exécuter les tâches de correction et d'espérer que rien d'autre ne se passe avec d'autres nœuds pendant qu'un nœud est mis hors ligne pour la correction.

L'EMBALLAGE

La haute disponibilité est essentielle pour de nombreuses applications - et très bénéfique pour beaucoup d'autres. Configurée correctement, une base de données MySQL peut offrir une disponibilité pratiquement parfaite, mais cela ne signifie pas que les équipes techniques peuvent considérer la disponibilité comme acquise.

Abuser de l'architecture de haute disponibilité pour prendre des raccourcis en matière de maintenance n'est tout simplement pas une option - les risques sont plus importants qu'il n'y paraît à première vue.

Les administrateurs système devraient plutôt se tourner vers des solutions éprouvées - notamment la redondance et les correctifs en direct - pour effectuer des opérations de maintenance sans compromettre les capacités des solutions à haute disponibilité.