Voyons pourquoi vous ne devriez pas compter sur la haute disponibilité de MySQL pour la maintenance-tutoriel mysql-php.cn

Voyons pourquoi vous ne devriez pas compter sur la haute disponibilité de MySQL pour la maintenance

Le coût des temps d'arrêt s'accumule rapidement dans un environnement d'entreprise. Dans une enquête, 40 % des personnes interrogées ont déclaré qu'une seule heure d'arrêt coûtait à leur organisation plus d'un million de dollars. Il est évidemment utile de garantir que les services de bases de données soient disponibles en permanence. Cela permet à votre organisation d'économiser des tonnes d'argent, sans parler des relations avec des parties prenantes de toutes formes et tailles.

Alors, comment assurer une disponibilité continue ? Le concept derrière la disponibilité continue s'appelle

Haute Disponibilité

. Dans cet article, nous donnerons un aperçu de ce qu'est la haute disponibilité et comment la mettre en œuvre pour votre cluster MySQL. Nous soulignons également le côté obscur de la haute disponibilité, même lorsque les administrateurs système s'appuient à tort sur la haute disponibilité pour effectuer des tâches de maintenance - et expliquons pourquoi cela va à l'encontre des objectifs de haute disponibilité et met en danger vos opérations commerciales.

1. Introduction à la haute disponibilité

Parlons d'abord de la disponibilité. Il ne sert à rien d’exécuter un service (comme une base de données) s’il est la plupart du temps indisponible pour les utilisateurs. Ainsi, lorsque nous parlons de disponibilité, nous entendons dans quelle mesure un service est accessible.

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

Un service généralement disponible peut être idéal pour de nombreux scénarios de cas d'utilisation, mais si le service est de nature critique ou si un grand nombre d'utilisateurs dépendent d'un service, se fier uniquement à la « disponibilité » n'est pas suffisant.

C'est ce qu'est la haute disponibilité. À la base, la haute disponibilité garantit un niveau de disponibilité plus élevé que celui normalement attendu et, plus précisément, un niveau convenu, permettant la maintenance, l'application de correctifs et les erreurs et pannes générales.

2. Quel niveau de disponibilité correspond à la haute disponibilité ?

Il n'existe pas de définition convenue de ce qu'est la haute disponibilité, il s'agit simplement de répondre à des exigences spécifiques (plus élevées) de disponibilité, qui dépassent généralement ce qui est accepté comme « disponibilité » par le fournisseur. En fait, votre organisation peut définir la disponibilité requise en fonction des besoins de vos opérations, en pesant le coût de la haute disponibilité par rapport au coût des pertes lié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 » signifie un maximum de 52,06 minutes d'indisponibilité par an, tandis que « six neuf » ou une disponibilité de 99,9999 % la limite à 31,56 minutes d'indisponibilité par an.

Essentiellement, le choix vous appartient - mais, encore une fois, c'est un compromis. Maintenir une haute disponibilité coûtera cher : il nécessitera des ressources physiques et des licences logicielles supplémentaires et épuisera vos ressources humaines. Cependant, vous constaterez peut-être que c'est un prix qui vaut la peine d'être payé pour éviter les coûts induits par les perturbations ou le risque de perte de revenus due à des clients mécontents.

3. Comment fonctionne la haute disponibilité en pratique ?

La nature exacte de votre infrastructure haute disponibilité dépend de votre charge de travail. Cependant, d'une manière générale, la haute disponibilité est atteinte lorsqu'il existe une tolérance aux pannes, de sorte que même en cas de panne d'un service ou d'un périphérique, la charge de travail n'est pas interrompue. Généralement, cela signifie qu'il n'y a pas de point de défaillance unique : tous les services et appareils sont entièrement redondants au niveau du réseau et des applications.

Selon le service, cela peut généralement impliquer un certain nombre de nœuds - par exemple, votre cluster MySQL contiendra quelques nœuds supplémentaires sur lesquels les données sont stockées. Plusieurs nœuds sont ensuite combinés avec des outils d'équilibrage de charge afin que si un nœud tombe en panne, les requêtes soient dirigées vers un autre nœud. Les utilisateurs peuvent toujours accéder aux services disponibles, même avec des performances légèrement réduites.

4. Configuration de la haute disponibilité dans MySQL

Bien entendu, votre chemin vers une base de données MySQL hautement disponible dépendra de votre implémentation de MySQL. En un mot, vous devez créer un type de cluster MySQL avec plusieurs nœuds. En d'autres termes, vos données doivent être stockées sur plusieurs serveurs MySQL.

Ensuite, vous avez besoin d'un service capable de répliquer les données sur ces nœuds, garantissant que chaque nœud dispose d'une copie précise des données contenues dans votre base de données. Enfin, vous avez besoin d'un équilibreur de charge pour garantir que toutes les requêtes de base de données sont dirigées uniformément vers les nœuds de base de données - oui, une charge équilibrée - mais assurez-vous que même si un nœud est hors ligne, les requêtes sont satisfaites.

Par exemple, MySQL propose un produit commercial pour la haute disponibilité -

Te MySQL InnoDB Cluster

. Il est basé sur MySQL Group Replication, un moyen populaire d'assurer la haute disponibilité dans les environnements de bases de données MySQL.

Une autre alternative est Galera, qui offre la haute disponibilité de MySQL depuis des années. Si vous utilisez le fork MariaDB de MySQL, vous pouvez configurer votre environnement MariaDB pour une haute disponibilité en exécutant plusieurs nœuds sur votre cluster Galera - tout en vous appuyant sur HAProxy pour l'équilibrage de charge. Alternativement, vous pouvez également consulter le propre produit MaxScale
de MariaDB. 5. De bonnes raisons de s'appuyer sur la haute disponibilité…

Les charges de travail à l'échelle de l'entreprise utilisent de plus en plus les principes de haute disponibilité car ils fournissent les meilleurs résultats à long terme. Voici quelques bonnes raisons pour lesquelles vous devriez envisager de mettre en place une haute disponibilité dans votre opération :

Certaines applications ne peuvent tout simplement pas se permettre de temps d'arrêt, pensez aux applications militaires ou aux réseaux énergétiques. Dans ces cas-là, la haute disponibilité est indispensable et vous n'avez d'autre choix que de garantir une disponibilité extrêmement élevée, même si vous pouvez procéder à une évaluation des risques et décider du niveau de garanties de haute disponibilité dont vous avez besoin.
Si le système est au cœur d'une charge de travail, même une brève panne peut provoquer des problèmes généralisés, car les systèmes connectés et synchronisés tomberont en même temps en panne. Il vaut la peine d'envisager d'investir dans la haute disponibilité dans quelques domaines essentiels, tels que les bases de données, car cela peut valoir la peine de prendre en compte le coût de problèmes associés plus importants, dont il peut être difficile de se remettre.
Une haute disponibilité, même un faible nombre de 9, évite la perte de revenus. Pour un grand détaillant en ligne, quelques heures de ventes perdues, ainsi que les dommages à sa réputation qui en découlent, peuvent avoir un impact très significatif sur ses résultats.
Vos opérations commerciales peuvent être soumises à un accord de niveau de service qui garantit un certain temps de disponibilité pour vos clients. Si tel est le cas, vous devez vous assurer que les charges de travail de vos clients sont gérées avec un niveau de disponibilité – et vous y parviendrez grâce à une haute disponibilité. Ne pas le faire pourra entraîner la résiliation du contrat, ou des pénalités d’indemnisation selon votre contrat.

6. …et les mauvaises raisons de s'appuyer sur la haute disponibilité

Malheureusement, la popularité croissante de la haute disponibilité a conduit à son utilisation abusive. La haute disponibilité rendant les systèmes extrêmement robustes, les équipes techniques peuvent être tentées de prendre des raccourcis lors de l'exécution des tâches de gestion du système (telles que l'application de correctifs), car elles pensent que l'infrastructure haute disponibilité supportera simplement le fardeau de la mise hors ligne d'une machine.

En fait, ça devient très vite plus compliqué. Prenons l'exemple du cluster MySQL. Oui, si vous redémarrez une machine pour la patcher, votre cluster MySQL continuera à fonctionner en raison de la haute disponibilité. Cependant, gardez à l’esprit que lorsque vous arrêtez un nœud pour appliquer des correctifs, puis le redémarrez, cela crée un retard de données qui doivent être saisies. Ce processus peut prendre beaucoup de temps.

Inutile de dire que chaque hébergeur de base de données doit voir les mêmes données. Le danger vient du processus de resynchronisation : si un autre nœud tombe en panne alors que vous l'avez déjà arrêté et corrigé, cela pourrait entraîner la perte du quorum final valide. En d’autres termes, le nombre de serveurs détenant la « vérité » sur les données peut être inférieur à un niveau acceptable. La récupération à partir de cet état peut être difficile et complexe, et peut même entraîner une perte de données.

7. Ne comptez pas sur la haute disponibilité pour la maintenance

La haute disponibilité vise à assurer le fonctionnement normal du système en cas de panne. Cette protection inhérente contre les pannes n'est pas un laissez-passer gratuit pour s'appuyer sur une maintenance système robuste et irresponsable pour une haute disponibilité sans que personne ne s'en aperçoive.

Au lieu de cela, les équipes techniques devraient s'appuyer sur d'autres solutions - par exemple, mettre en place une redondance complète pour les systèmes en cours de patch, plutôt que d'espérer simplement que l'infrastructure à haute disponibilité puisse résister au stress. Ou, lorsque cela est possible,

utilisez plutôt des correctifs en temps réel

, éliminant ainsi le besoin de redémarrer les services pour installer le correctif. Néanmoins, le recours à une haute disponibilité pour les travaux de maintenance montre des signes inquiétants. Regardez attentivement et vous trouverez même des conseils officiels de fournisseurs demandant aux utilisateurs de s'appuyer sur la haute disponibilité pour effectuer les tâches de correction. Les utilisateurs espèrent simplement que lorsqu'un nœud se déconnecte pour appliquer des correctifs, les autres nœuds n'auront aucun problème.

8. La fin

La haute disponibilité est essentielle pour de nombreuses applications - et bénéfique pour beaucoup d'autres. Correctement configurée, une base de données MySQL peut fournir une disponibilité quasi parfaite, mais cela ne signifie pas que les équipes techniques peuvent tenir la disponibilité pour acquise.

Il n'est pas conseillé d'abuser des architectures à haute disponibilité pour maintenir des raccourcis de maintenance - les risques sont plus grands qu'il n'y paraît à première vue.

Au lieu de cela, les administrateurs système doivent rechercher des alternatives éprouvées - notamment la redondance et l'application de correctifs en direct - pour effectuer les opérations de maintenance sans compromettre la capacité de la solution à haute disponibilité.

Adresse originale : https://tuxcare.com/understanding-mysql-high-availability-good-and-bad-reasons-to-use-it/

Adresse de traduction : https://learnku.com/mysql /t/71681

【Recommandations associées : Tutoriel vidéo MySQL】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!