Ce que nous faisons · Données et web: Bases de données en cluster avec Percona XtraDB Cluster
Votre application parle à une seule base de données, mais derrière elle se trouvent trois copies synchrones, chacune sur un matériel distinct. Une écriture validée existe sur chaque nœud avant que votre application n'entende « OK », de sorte que perdre un serveur, le corriger ou le redémarrer est un travail de routine, pas une interruption.
De quoi il s'agit
Percona XtraDB Cluster est compatible MySQL et bâti sur la réplication synchrone Galera. Votre application WordPress, Magento, PrestaShop, Laravel ou PHP sur mesure continue de parler du MySQL ordinaire. Ce qui change est en dessous : il ne reste plus un seul serveur de base de données dont la panne emporte tout le site.
Nous associons le cluster à ProxySQL, qui envoie les écritures vers un nœud élu et répartit les lectures sur tous. L'application n'a besoin d'aucune modification ni d'aucune connaissance de la topologie.
Comment nous le construisons
- Trois nœuds, trois domaines de panne. Chaque nœud tourne sur son propre blade ou sa propre machine virtuelle et, là où la plateforme le permet, chacun démarre depuis une baie de stockage différente et y stocke ses données. Une panne d'hôte ou de baie coûte un réplica, jamais le quorum.
- ProxySQL en sidecar local sur chaque nœud web. Il n'y a pas de load balancer de base de données partagé qui deviendrait le prochain point unique de défaillance. Le moniteur de santé de ProxySQL, conscient de Galera, suit l'état du cluster et, si le writer tombe, en promeut un nouveau en quelques secondes.
- Lectures causales pour les rédacteurs. Nous activons des contrôles de lecture synchrones afin qu'un rédacteur qui enregistre sur un nœud et recharge depuis un autre voie toujours sa propre modification. Aucun ticket « mon article a disparu ».
- De la place pour rejoindre. Le cache des write sets est dimensionné pour qu'un nœud puisse rester hors ligne pendant des heures de maintenance et rejoindre le cluster de façon incrémentale, au lieu de recopier tout le jeu de données.
- Des backups toutes les trente minutes. Percona XtraBackup prend des backups physiques à chaud et cohérents, compressés et tirés vers un hôte de backup distinct. Le côté production ne pousse jamais vers l'infrastructure de backup.
- Surveillé en continu. Chaque nœud est dans Percona Monitoring and Management.
Sur OpenShift, les mêmes règles s'appliquent
Lorsque la base de données tourne sur OpenShift ou OKD, elle tourne comme StatefulSet avec une anti-affinity stricte entre châssis et un PodDisruptionBudget qui garde le quorum intact. Un redémarrage glissant des nœuds dû à une mise à jour de la plateforme ne peut ainsi jamais faire tomber plus d'un membre de la base à la fois. C'est le standard de conception que nous appliquons sur chaque plateforme de conteneurs, pas une option.
Ce dont il vous protège
- L'interruption classique : tout le site est hors ligne parce que l'unique serveur MySQL est hors ligne.
- Les tempêtes de deadlocks dues aux écritures sur tous les nœuds à la fois, que produisent les montages round robin naïfs sous la charge de WordPress et des plugins e-commerce.
- Des rédacteurs qui perdent un enregistrement parce que leur lecture suivante a atteint un nœud qui ne l'avait pas encore appliqué.
- Les fenêtres de maintenance pour les mises à jour du noyau, les correctifs de base de données et les interventions matérielles.
- Une baie de stockage ou un châssis qui emporte la base de données avec lui.
- Une mise à jour glissante de Kubernetes qui casse discrètement le quorum.
En pratique
Une plateforme d'analytique. Pour la plateforme d'analytique et de transactions d'un client, nous avons bâti le tier transactionnel sur Percona XtraDB Cluster avec ProxySQL et une adresse flottante. Avant la livraison, nous avons retiré le writer à dessein ; ProxySQL a déplacé les écritures vers un nœud survivant et l'application a continué.
Pourquoi EuroVPS
- Nous concevons les domaines de panne, pas seulement le cluster : hôtes différents, baies différentes, châssis différents.
- Aucun proxy de base de données partagé au milieu. Chaque nœud web route ses propres requêtes.
- Les backups sont physiques, fréquents et tirés par le côté backup, jamais poussés depuis la production.
- Nous testons le failover avant la livraison, avec l'application du client qui tourne dessus.
- La même discipline sur machines virtuelles, bare metal et OpenShift.
Questions fréquentes
- Devons-nous modifier notre application ? Non. ProxySQL présente un endpoint MySQL normal. Les applications qui écrivent dans des tables non transactionnelles ou s'appuient sur un verrouillage inhabituel sont d'abord examinées avec vous.
- Est-ce compatible MySQL ou MariaDB ? Percona XtraDB Cluster est un serveur compatible MySQL. Nous y migrons des bases MySQL et MariaDB et vérifions les jeux de caractères, les plugins d'authentification et les modes SQL pendant la migration.
- La réplication synchrone à trois nœuds ralentit-elle les écritures ? Chaque commit attend que les autres nœuds le certifient, donc la latence entre nœuds compte. C'est pourquoi tous les membres se trouvent sur le même fabric à faible latence dans un seul datacenter, les copies hors site étant assurées par des réplicas asynchrones.
- Pouvons-nous le faire tourner dans OpenShift ? Oui, en StatefulSet avec anti-affinity entre châssis et un PodDisruptionBudget, ce qui est notre standard pour toute base de données à quorum sur Kubernetes.
- Que se passe-t-il lors d'une panne de nœud ? Les nœuds survivants gardent le quorum et continuent de servir. ProxySQL contourne le nœud manquant et, à son retour, celui-ci se resynchronise de façon incrémentale.
Vous voulez une base de données qui encaisse la perte d'un serveur ? Parler à un ingénieur.
Votre prochain partenaire d'infrastructure
Examinons votre environnement.
Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.
+357 222 32280
Commençons par votre environnement.
Un peu de contexte nous aide à démarrer la bonne conversation.