Utilisation de MariaDB MaxScale comme proxy de base de données

Configurer MaxScale en tant que couche proxy

MariaDB MaxScale Il s'agit d'une couche proxy autonome située entre l'application et les serveurs MariaDB. Pour garantir un fonctionnement fiable, la configuration, les fonctionnalités disponibles et les limites connues doivent toujours correspondre à la version effectivement installée. La série MaxScale 25.10 fait l'objet de notes de version spécifiques dans la documentation officielle.

L'application se connecte à un écouteur de MaxScale plutôt qu'directement à un serveur de base de données. Un service regroupe la logique d'accès, un routeur détermine le backend, et des filtres peuvent traiter les requêtes avant leur transfert. Les données restent sur les backends MariaDB ; MaxScale ne devient pas lui-même une base de données.

Cette séparation est particulièrement utile lorsqu'une application ne doit pas savoir elle-même quel serveur occupe actuellement quel rôle. Pour les notions de base sur le modèle de données, le langage SQL et le fonctionnement de la base de données, consultez l'article MariaDB, une base de données open source un complément approprié. Le proxy vient compléter l'architecture du serveur, mais ne remplace ni les droits d'accès à la base de données, ni une stratégie de réplication et de gestion des pannes.

À l'adresse suivante : Routage des connexions Lors de l'établissement d'une session, MaxScale sélectionne une cible ; ce backend reste responsable de la session. Dans le cadre du routage des instructions, le routeur peut affecter différemment les instructions SQL individuelles en fonction de leur contenu. Le choix de la variante appropriée dépend donc des transactions, de l'état de la session et de la capacité de l'application à séparer clairement elle-même les chemins de lecture et d'écriture.

A Proxy de base de données Il ne s'agit pas d'une garantie de performance générale. Il peut centraliser le routage, dissocier les changements de rôle entre les applications ou répartir les requêtes de lecture appropriées. Toutefois, les nœuds de réseau supplémentaires, l’analyse SQL et la topologie concrète du backend influencent son comportement. La résilience et la capacité doivent donc être vérifiées avec votre propre version, configuration et charge.

Surveiller correctement la topologie maître-réplique

Une architecture cible typique se compose d'un serveur principal en écriture et d'une ou plusieurs répliques en lecture. MaxScale est le seul point de terminaison de base de données de l'application, par exemple derrière un nom DNS fixe. L'application ne se connecte donc pas directement à des hôtes individuels ; la sélection d'un backend accessible et approprié s'effectue au sein de la couche proxy.

Pour une topologie maître-réplique, le moniteur détermine mariadbmon l'état des backends et identifie leurs rôles (primaire ou réplique). Les routeurs peuvent utiliser ces informations pour choisir leur destination. Le moniteur doit donc être capable de visualiser la topologie réelle de la réplication ; les affectations erronées, les données non répliquées ou les rôles mal définis ne constituent pas des problèmes de routage, mais des risques opérationnels.

Il convient de distinguer la détection d'un rôle de sa modification. Avec une configuration et des autorisations appropriées, mariadbmon peut gérer les basculements, les commutations planifiées et les réintégrations. Un basculement est un changement de rôle préparé à l'avance à des fins de maintenance ou d'exploitation ; un basculement de secours intervient en réponse à une défaillance. Ces deux opérations nécessitent une topologie claire, une surveillance, un système d'alerte et un processus documenté de gestion des incidents ou de reprise.

Pour les tâches de surveillance uniquement, le compte « Monitor » devrait fonctionner selon le principe Dernier privilège ne reçoivent que les droits nécessaires. La documentation actuelle mentionne « REPLICA MONITOR » à cet effet. Des droits supplémentaires sont requis en fonction des fonctions activées, par exemple « FILE » pour une vérification de l'espace de stockage ou d'autres droits spécifiquement vérifiés pour les analyses de topologie et les manipulations de clusters. L'octroi de droits complets de manière générale ne saurait se substituer à cela.

Avant de mettre en place une automatisation, l'équipe doit définir qui autorise un changement de rôle, comment l'état des répliques est vérifié et comment les applications sont informées des incidents. MaxScale peut adapter les destinations de routage en fonction des rôles détectés. Cependant, c’est le concept de haute disponibilité, avec ses limites en matière de données, de temps et de responsabilités, qui détermine si une bascule est techniquement admissible.

Comprendre le routage SQL et les limites de cohérence

Le routeur readwritesplit Il achemine les instructions SQL d'écriture vers le serveur principal et répartit les requêtes de lecture appropriées entre les réplicas. Cela permet à un groupe de serveurs principaux et de réplicas d'exploiter sa capacité de lecture de manière plus ciblée, sans que l'application ait à attribuer elle-même chaque requête à un serveur. Les informations relatives aux rôles fournies par le moniteur servent de base à cette sélection.

Dans la version standard, cette répartition ne garantit pas qu'une lecture effectue immédiatement après chaque écriture la prise en compte des nouvelles données. causal_reads est réglé par défaut sur none. Si, par exemple, une application écrit le statut d'une commande puis le lit via une requête indépendante, une réplique peut donc encore fournir l'état précédent. Un chemin de lecture « primary » choisi délibérément ou un contexte de transaction commun sont des stratégies possibles, mais ce ne sont pas les seules.

Pour Lecture des écritures Lorsque la fonctionnalité « Causal Reads » est activée, readwritesplit peut prendre en compte les écritures précédentes malgré le décalage entre les répliques. Le mode local garantit la visibilité pour cette même connexion. global gère le GTID enregistré par le service sur l'ensemble de ses connexions ; un ordre global « happens-before » des lectures n'est garanti que si toutes les transactions se situent au sein d'un seul domaine GTID. universal intègre l'état des transactions du cluster tel qu'il est observé sur le serveur principal. Cependant, l'élargissement du champ d'application augmente la charge de synchronisation et, par conséquent, potentiellement la latence.

Les lectures causales utilisent les informations GTID et, dans les modes non rapides, attendent la réplication. Si la synchronisation dure plus de causal_reads_timeout – 10 secondes par défaut –, readwritesplit tente d'exécuter la requête sur le serveur principal. Dans une transaction en lecture seule, un délai d'expiration peut toutefois être renvoyé comme erreur, car la requête ne peut pas être transférée vers le serveur principal.

Les modes rapides fast, fast_global et fast_universal n'attendent pas une réplique et utilisent le serveur principal si nécessaire ; le délai d'expiration ne s'applique pas dans ce cas. Elles conviennent donc particulièrement aux charges de travail principalement en lecture avec peu d'écritures. À partir de la version 24.02 de MaxScale, MaxScale configure lui-même le suivi nécessaire pour les nouvelles connexions au backend ; les versions antérieures nécessitent pour cela last_gtid dans session_track_system_variables sur tous les back-ends.

Dans le cadre d'une transaction ouverte en lecture-écriture, la fonction `readwritesplit` redirige les accès en lecture vers le serveur principal. Cela évite que des instructions d'une même transaction soient exécutées sur des backends présentant des niveaux de réplication différents. Cette règle prudente ne dispense pas de définir correctement les limites des transactions d'un point de vue technique et de traiter le décalage de réplication comme une contrainte architecturale à part entière.

Même dans le cas des procédures stockées, des appels à des fonctions définies par l'utilisateur (UDF) et des instructions multiples, la décision est prise avec une prudence délibérée : dans les cas documentés, ces requêtes sont acheminées vers le serveur principal. La raison en est que leur effet ou leur contexte ne doit pas être traité comme une simple requête de lecture. Le routage SQL ne se limite donc pas à une simple recherche du mot SELECT, mais suit des règles visant à garantir la sécurité de la gestion des sessions et de la sémantique.

Une valeur limite fixée par les experts pour Replica-Lag peut exclure les répliques de certaines décisions de lecture, mais ne remplace pas une exigence de cohérence. Le retard acceptable dépend, par exemple, du fait de savoir si une entrée de catalogue obsolète est tolérable ou si un statut de paiement qui vient d’être confirmé doit impérativement être visible. Cette décision relève de la logique métier et du contrat d’exploitation, et non d’un paramètre par défaut général du proxy.

Configurer correctement la fonction « Readwritesplit »

Une configuration « Read/Write-Split » se compose de définitions d'objets distinctes pour les backends, le moniteur, le service et l'écouteur. L'extrait suivant illustre la structure d'un fichier ; il ne s'agit pas d'un modèle prêt à être utilisé en production. Les valeurs entre crochets ne sont en aucun cas des mots de passe, mais des références à des comptes et à des secrets qui doivent être fournis via la gestion des secrets de l'environnement d'exploitation. Le moniteur et le service ont chacun besoin de leurs propres identifiants d'accès pour leurs différentes tâches.

[db-primary]
type=server
address=db-primary.example.invalid
port=3306

[db-replica-1]
type=server
address=db-replica-1.example.invalid
port=3306

[db-replica-2]
type=server
address=db-replica-2.example.invalid
port=3306

[cluster-monitor]
type=monitor
module=mariadbmon
servers=db-primary,db-replica-1,db-replica-2
user=<monitor-account-from-secret-management>
password=<monitor-secret-reference>

[RW-Service]
type=service
router=readwritesplit
servers=db-primary,db-replica-1,db-replica-2
user=<service-account-from-secret-management>
password=<service-secret-reference>

[RW-Listener]
type=listener
service=RW-Service
protocol=MariaDBClient
port=3306

Les objets serveur désignent simplement des backends MariaDB accessibles ; c'est le moniteur qui détermine, en fonction de la topologie, quelle instance est la primaire et laquelle est la réplique. Le compte du moniteur est utilisé pour les requêtes d’état et de rôle. Le compte de service distinct sert à récupérer auprès des backends les informations relatives aux utilisateurs et aux droits nécessaires à l’authentification et à l’autorisation des clients. Ces deux comptes ne nécessitent que les droits documentés pour leur tâche respective. Reconnaître les rôles Le chargement des informations utilisateur est une tâche distincte.

Les espaces réservés de l'exemple doivent être remplacés lors du déploiement via un canal de déploiement sécurisé ; ils ne sont pas destinés à être utilisés comme valeurs de configuration littérales. Les mots de passe en clair, les chemins d'accès réels aux certificats ou les ensembles de droits non vérifiés ne doivent pas figurer dans des fichiers ou des référentiels librement accessibles. Pour les connexions via le protocole MariaDB, MaxScale gère en interne les comptes utilisateurs et les autorisations pertinents à partir des tables système. Si des comptes ou des droits sont modifiés, des informations obsolètes peuvent entraver la connexion ou l'autorisation.

Avant la mise en service, il convient donc de vérifier séparément le port d'écoute, les chemins réseau, la synchronisation des utilisateurs et l'affectation effective des routeurs. Les interventions automatiques du moniteur ne font pas non plus implicitement partie de cette configuration minimale : les fonctions de basculement (failover), de commutation (switchover) ou de réintégration (rejoin) nécessitent une configuration supplémentaire et un concept d'exploitation testé. Une configuration apparemment succincte ne remplace ni la gestion des secrets ni la vérification de la topologie du backend.

Comparer les modèles de routeurs en fonction de leur utilisation

Le choix du routeur dépend du comportement de l'application, et non pas uniquement du nombre de répliques disponibles. Les connexions directes simplifient la mise en place, mais laissent à l'application le soin de gérer les changements de destination et la connaissance des rôles. Deux points d'extrémité distincts avec readconnroute conviennent lorsque l'application gère elle-même délibérément les connexions en lecture et en écriture. Routage des instructions L'option `readwritesplit` est utile lorsqu'une session doit être acheminée, en fonction des requêtes SQL, vers le serveur principal ou vers les réplicas.

readconnroute évalue un serveur de destination lors de l'établissement de la connexion et n'analyse pas chaque instruction SQL suivante. En cas de défaillance du backend sélectionné, la session prend fin ; le routeur ne vous reconnecte pas automatiquement à un autre serveur. Cela se justifie souvent pour des connexions de lecture clairement distinctes et de courte durée, mais peut s’avérer inadapté aux flux d’application à état.

Il convient d'être particulièrement prudent avec un service conçu comme un point de terminaison de lecture avec router_options=slave. Cette option privilégie les serveurs ayant un rôle de réplique ; toutefois, si toutes les répliques sont hors service et que le serveur principal est disponible, readconnroute peut se rabattre sur ce dernier. De plus, cette option n'implique pas de protection en écriture. L'application doit envoyer exclusivement des requêtes SQL en lecture, ou un filtre ReadOnly supplémentaire doit empêcher tout accès en écriture. La destination de routage et la préférence de rôle ne constituent donc ni une limite d’autorisation ni un substitut aux droits restrictifs sur la base de données.

Le mode « read-write-split », en revanche, réduit le nombre de décisions à prendre dans le code de l'application, mais nécessite une analyse sémantique précise. Les lectures appropriées peuvent être réparties sur les répliques, tandis que les opérations d'écriture sont dirigées vers le serveur principal. Pour les processus soumis à des exigences strictes en matière d’actualité, il reste déterminant de savoir si une requête peut attendre des données répliquées après une écriture ou si elle doit délibérément utiliser le serveur principal.

Planifier les séances, le lag et la transition

Une session de base de données ne se limite pas à une seule requête. SET, USE, CHANGE USER et les opérations de type « Prepared Statement » modifient leur contexte. readwritesplit réplique les commandes de session concernées vers les serveurs cibles potentiels, afin que les instructions redirigées puissent ensuite être exécutées avec l'état de session approprié. C’est ce qui distingue le routeur d’un simple équilibrage de charge TCP, mais cela n’élimine pas toutes les limites liées aux cas particuliers.

Cette limite est particulièrement importante dans le cas des instructions préparées pour les tables temporaires. Si une telle instruction est préparée sur le serveur principal, les répliques ne pourront pas nécessairement l'exécuter. L'application doit donc tester les objets temporaires, les instructions préparées et les flux de transactions à l'aide du modèle de routage prévu. État de la session Ce n'est pas une condition secondaire, mais un élément déterminant pour savoir si une répartition SQL est adaptée d'un point de vue fonctionnel et technique.

Pour une application à forte intensité de lecture, l'équipe peut définir une valeur limite de latence spécifiée par les experts comme critère d'exclusion pour les répliques. À elle seule max_replication_lag ne garantit toutefois pas qu'une écriture précédente sur une réplique soit déjà visible. Pour les lectures critiques qui s'ensuivent, on peut envisager, selon le déroulement, un chemin primaire délibéré, un contexte d'écriture partagé ou des lectures causales activées.

Avec les lectures causales, il faut choisir délibérément le champ d'application. local préserve la causalité au sein d'une relation. global utilise un GTID stocké au niveau du service, mais ne garantit l'ordre global « happens-before » des lectures que si toutes les transactions appartiennent à un seul domaine GTID. universal prend en compte l'état des transactions du cluster tel qu'il est observé sur le serveur principal. Les modes non rapides se synchronisent à l'aide des GTID ; si une réplique ne rattrape pas son retard dans le délai d'attente configuré, la requête est systématiquement réitérée sur le serveur principal, dans la mesure où le mode de transaction le permet.

Cette fonctionnalité dépend de la version. À partir de MaxScale 24.02, MaxScale ajoute last_gtid pour les nouvelles connexions backend ; dans les versions antérieures, il fallait session_track_system_variables doivent être configurés en conséquence sur les backends MariaDB. Les modes rapides évitent les temps d'attente, mais peuvent rediriger les lectures vers le serveur principal lorsque les répliques n'ont pas encore rattrapé leur retard ; ils ne sont donc pas adaptés de manière générale aux charges de travail impliquant de nombreuses écritures.

Une bascule planifiée et un basculement automatique doivent également être traités séparément. Lors d’une bascule, le changement de rôle est préparé de manière contrôlée ; lors d’un basculement, l’exploitation réagit à une situation d’erreur. mariadbmon peut surveiller les rôles et les états du backend et, s’il est configuré en conséquence, prendre en charge ces processus. Une synchronisation des données, une topologie claire, un système d’alerte et un processus de gestion des incidents restent toutefois des conditions préalables indispensables.

Dans MaxScale 25.10, il est possible de discover-replicas Identifier les serveurs qui se répliquent directement sur le serveur principal actuel, puis les ajouter à Monitor et à MaxScale. Cette fonctionnalité n'est pas compatible avec la synchronisation de configuration. Avant de l'utiliser, l'équipe doit donc déterminer si les modifications de topologie doivent être détectées automatiquement ou gérées via une configuration synchronisée ; les deux à la fois ne constituent pas une hypothèse valable dans ce contexte.

TLS, sécurisation des droits et des filtres

Dans MaxScale, le protocole TLS doit être configuré sur deux voies distinctes : de l'application vers le listener et du proxy vers les backends MariaDB. Ces deux connexions nécessitent chacune des paramètres spécifiques en matière de chiffrement et de vérification des certificats ; une voie client sécurisée ne chiffre pas automatiquement le trafic en aval. La configuration doit donc refléter les besoins en matière de sécurité et la chaîne de confiance pour ces deux segments.

TLS activé ssl=true le chiffrement dans la configuration du listener ou du serveur concerné. Si un client attend un certificat de serveur, le listener a besoin du certificat et de la clé privée. Un compte avec REQUIRE SSL ne peut pas se connecter via un listener sans TLS. Les fichiers de certificats et les clés doivent être placés dans un environnement d'exploitation sécurisé, et non dans des configurations d'exemple ou de référentiel librement accessibles.

Le Concept des droits Cela reste essentiel au niveau des backends : MaxScale gère les connexions, mais ne remplace pas les comptes de base de données spécifiques. Les comptes de service ne disposent que des autorisations nécessaires à leur tâche. Pour la connexion et l'autorisation, MaxScale s'appuie sur les comptes utilisateurs et les droits issus des tables système de MariaDB ; les modifications apportées à ces comptes doivent donc être rapidement répercutées dans la gestion interne des utilisateurs.

Le filtre du pare-feu peut vérifier le code SQL avant sa transmission à l'aide de règles apprises ou définies. Il dispose de modes veille, apprentissage, surveillance et enforcement ; en mode enforcement, les modèles d'instructions non autorisés entraînent, selon les paramètres, soit un message d'erreur, soit la déconnexion. La phase d'apprentissage doit couvrir des flux d'application autorisés et représentatifs afin que le filtre ne bloque pas les requêtes régulières.

Le filtre constitue une couche de contrôle supplémentaire pour les modèles SQL attendus, et non une autorisation de substitution. Des droits d'accès restrictifs à la base de données, des identifiants protégés et un code d'application vérifié restent indispensables, car le filtre se contente d'évaluer les requêtes qui lui parviennent à l'aune de ses règles. Les informations concernant d'autres filtres doivent être vérifiées séparément à l'aide de leur documentation respective.

Vérifier systématiquement la configuration et les erreurs

En cas d'erreurs de connexion ou de routage, il est préférable de suivre un ordre de vérification bien défini plutôt que d'apporter des modifications à l'aveuglette. Vérifiez d'abord l'état du moniteur : tous les backends sont-ils accessibles, et les rôles « Primary » et « Replica » sont-ils reconnus comme prévu ? Ce n'est qu'alors que les décisions du routeur peuvent être évaluées de manière pertinente. Un nœud mal identifié ou inaccessible n’est pas uniquement un problème lié au listener.

Viennent ensuite le listener et le protocole TLS : le port, le protocole, le certificat, la clé et les exigences des comptes utilisés doivent correspondre. Vérifie ensuite si le système de gestion des comptes utilisateurs dispose des comptes backend et des droits à jour. En particulier après des modifications apportées aux utilisateurs ou aux autorisations, des données de compte obsolètes peuvent empêcher les connexions, même si le compte est correctement configuré sur MariaDB.

Ensuite, vous attribuez le service, le routeur et les serveurs prévus. Dans le cadre du « Read/Write Splitting », il faut également tenir compte du décalage entre les répliques, causal_reads et les limites de transaction de l'application à la liste de contrôle. Si les lectures causales ne sont pas activées, une lecture effectuée en dehors du contexte d'écriture requis sur une réplique peut fournir un état plus ancien ; une limite de décalage ne garantit pas à elle seule la visibilité d'une écriture antérieure.

Ajoute également une seule Source de configuration fixe. MaxScale peut enregistrer les modifications en cours d'exécution ; au redémarrage, la configuration enregistrée peut remplacer les fichiers statiques. Si une équipe modifie en partie des fichiers et en partie maxctrl lorsqu'elle est utilisée, le parcours des modifications, la révision et la sauvegarde de cette configuration d'exécution doivent être documentés de manière contraignante.

Tu dois traiter les fenêtres de maintenance pour les modifications de schéma comme un domaine opérationnel à part entière : les dépendances, le comportement de verrouillage et la réplication doivent être vérifiés au préalable et ne doivent pas être imputés au proxy. Pour planifier des modifications contrôlées sur des tables MariaDB volumineuses, l'article consacré à Modifications de schémas sans temps d'arrêt contexte complémentaire. MaxScale peut alors à nouveau gérer les connexions et le routage en fonction des rôles du backend, mais n'applique aucune stratégie DDL de base de données.

Avertissement : tu dois d'abord tester les modifications apportées aux rôles, aux certificats, aux droits d'utilisateur et au routage dans un environnement similaire. Une intervention en production doit inclure une procédure de restauration, le suivi des erreurs d'application et une définition claire des responsabilités. Cela permet de déterminer si un dysfonctionnement provient de la configuration du proxy, du backend ou du comportement du client.

Utiliser MaxScale à bon escient ou s'en passer

Dans le cas d'un serveur MariaDB unique ne nécessitant ni routage, ni basculement, ni filtrage SQL, les connexions directes constituent généralement la solution la plus simple. L'application doit toutefois alors gérer elle-même tout changement ultérieur de destination. MaxScale s'avère utile lorsque le point de terminaison supplémentaire remplit une tâche spécifique, par exemple pour gérer les changements de rôle, filtrer les accès ou répartir les lectures de manière contrôlée entre les répliques.

Si l'application peut choisir elle-même, de manière délibérée, les chemins de lecture et d'écriture, les points de terminaison distincts avec readconnroute souvent compréhensible. Ce routeur sélectionne un backend lors de l'établissement de la connexion, mais n'analyse pas chaque instruction SQL et ne transfère pas une session interrompue vers un autre serveur. Dans le cas de router_options=slave Les répliques sont privilégiées ; si toutes les répliques sont hors service et que le serveur principal est encore disponible, le routeur peut utiliser ce dernier. De plus, cette option ne rend pas le point de terminaison en lecture seule. Pour cela, il faut un filtre « ReadOnly » adapté, des droits d'accès restrictifs au niveau du backend ou un code SQL de l'application strictement contrôlé.

Pour les charges de travail de type « primary-replica » dont l'ORM et le modèle de transaction sont compatibles, readwritesplit l'application détermine la destination SQL pour chaque instruction. Par défaut, causal_reads=none un décalage de réplication reste toutefois perceptible. Après des écritures critiques, l'application peut utiliser un chemin de lecture principal ou un contexte de transaction partagé adapté ; il est également possible de configurer de manière ciblée des lectures causales pour la plage de visibilité requise.

Les « Causal Reads » font la distinction entre la visibilité au sein d'une même session, un état GTID global géré par le service et l'état du cluster observable sur le nœud principal. local s'applique à cette même connexion. Dans le cas de global L'ordre global « happens-before » des lectures n'est garanti que si toutes les transactions appartiennent à un seul domaine GTID ; ce mode ne doit donc pas être considéré de manière générale comme une garantie de cohérence illimitée à l'échelle du service. universal vérifie l'état observable sur le serveur principal avant les opérations de lecture. Les modes de synchronisation peuvent entraîner un temps d'attente supplémentaire ; les variantes rapides n'attendent pas, mais peuvent transférer davantage la charge vers le serveur principal lors des opérations d'écriture.

Les cas limites doivent faire l'objet de tests ciblés avec le pilote et le modèle de données réels avant leur mise en œuvre. Les tables temporaires et les instructions préparées à partir de celles-ci peuvent ne pas être disponibles sur les répliques si la préparation s'effectue sur le serveur principal. De même, les procédures stockées, les appels à des fonctions définies par l'utilisateur (UDF), les instructions multiples et l'état de la session influencent la décision du routeur d'acheminer les requêtes de manière prudente vers le serveur principal.

La fonction « Transaction Replay » ne garantit pas que les transactions s'effectuent sans perte. Si une connexion est interrompue pendant COMMIT , on peut ne pas tenir compte du fait que le commit ait déjà été effectué avec succès. Certaines configurations de relecture risquées peuvent exécuter deux fois les opérations d'écriture ; les résultats dépendant du serveur, tels que NOW() ou @@server_id peuvent également entraîner des écarts de somme de contrôle. Évaluez donc leur utilisation en fonction des exigences de cohérence, des séquences d'erreurs et de la répétabilité des écritures, et non sur la base de promesses de performances générales.