Haute disponibilité

Name: MySQL 8 Administration et optimisation
Rating: 4 (2 reviews)

Introduction

Après avoir installé et configuré correctement votre serveur, après avoir ajusté les index et le schéma de données en fonction de l’application et des requêtes, après vous être assuré que les sauvegardes sont en place et fonctionnent, après avoir mis en place la réplication pour répartir les lectures sur plusieurs serveurs, vous pensez peut-être en avoir terminé avec la résolution des problèmes les plus courants de l’administration MySQL. Et pourtant, il reste un point qui est capital pour de nombreuses applications : comment minimiser le temps d’indisponibilité du service de base de données si un crash survient ?

Le cas le plus simple est celui du crash d’un esclave servant à répartir les lectures : il suffit en général de reconstruire un nouvel esclave à partir de la sauvegarde la plus récente.

Si c’est le serveur maître qui a une défaillance, la situation est plus critique puisque les écritures ne peuvent plus avoir lieu. Il est là aussi possible de reconstruire un serveur maître à partir de la sauvegarde la plus récente (et sans doute des journaux binaires depuis cette sauvegarde), mais il s’agit d’une méthode très lente si la base de données est volumineuse :...

Utilisation de la réplication classique

1. Mécanisme de promotion d’un esclave

Grandes étapes

En théorie, la promotion d’un esclave suit un processus dont les étapes sont bien claires. Remarquez qu’il existe deux cas de figure bien distincts pour lesquels vous souhaiterez promouvoir un esclave. Le cas le plus évident est celui où le serveur maître arrête de fonctionner, mais il peut aussi arriver que vous souhaitiez changer de serveur maître alors qu’aucun problème n’est en cours, par exemple pour utiliser un serveur avec un meilleur matériel ou pour utiliser une nouvelle version de MySQL.

Listons rapidement les principales étapes d’une promotion :

La première étape consiste à vous assurer que plus aucune transaction n’est en cours d’exécution sur l’ancien maître et qu’aucune nouvelle transaction ne peut aboutir sur l’ancien maître. La raison est la suivante : si l’ancien maître devient un esclave et qu’une transaction exécute une écriture, cette écriture ne sera transmise à aucun autre serveur et ne sera pas non plus connue du nouveau maître. Double problème : la transaction aura réussi donc l’application cliente recevra un message de succès, mais la transaction ne sera pas visible sur le nouveau maître. Dans le cas d’un crash de l’ancien maître, vous n’aurez rien à faire puisque toutes les transactions en cours seront annulées, mais dans le cas où l’ancien maître fonctionne, il vous faudra soit attendre que toutes les transactions soient closes, soit fermer les transactions en cours.
La deuxième étape consiste à sélectionner parmi tous les serveurs esclaves celui qui sera promu serveur maître. A priori, le choix est simple : il faut prendre l’esclave le plus à jour (certains serveurs peuvent avoir un retard de réplication au moment de la promotion). Cette étape peut être difficile à rendre automatique si certains serveurs esclaves ont un rôle particulier (voir la partie Automatisation de la promotion dans la suite de ce chapitre pour plus de détails). N’oubliez pas de vérifier que les journaux binaires...

Réplication de groupe et InnoDB Cluster

1. Introduction

La lecture de la partie précédente vous aura appris que construire un service de base de données hautement disponible avec MySQL n’est pas très simple. Le principal problème vient de la manière dont fonctionne le système de réplication : il est certes possible de dupliquer les écritures du serveur maître vers un ou plusieurs autres serveurs, et ceci de manière généralement quasi synchrone, mais il n’existe pas vraiment de coordination entre les serveurs. Cette absence de coordination se fait ressentir lors d’un problème sur le serveur maître puisque dans ce cas, les serveurs esclaves ne sont pas capables de réaliser le problème en cours sur le serveur maître et encore de prendre une décision sur une éventuelle promotion. D’où la nécessité d’avoir recours à un système tiers pour effectuer cette promotion.

La réplication de groupe (abrégée en RG dans la suite de ce chapitre) propose un mécanisme de réplication alternatif, apportant un système de communication entre serveurs couplé à une réplication synchrone entre le serveur maître et les autres serveurs.

Comme de nombreuses fonctionnalités récentes de MySQL, RG est distribuée sous la forme d’un plugin installé par défaut sous MySQL 8.0.

Attention, au moment de l’écriture de ce livre, RG reste une technologie récente qui reste extrêmement rare en production. Pensez à réaliser de nombreux tests pour être certain de ne pas être affecté par de possibles problèmes encore non identifiés (ou identifiés, mais pas encore corrigés).

2. Bénéfices/limitations

Remplacer la réplication classique de MySQL par RG apporte deux bénéfices immédiats :

La haute disponibilité est simplifiée. La configuration standard ressemble beaucoup à la réplication classique : un serveur maître et plusieurs serveurs esclaves. Mais contrairement à la réplication classique, RG fonctionne également si vous écrivez sur plusieurs serveurs en même temps : on parlera...