Expertise cluster MySQL MariaDB – réalisations

Voici quelques exemples de réalisations en expertise et audit sur un cluster MySQL MariaDB :  audit et optimisation de performances, évolution d’architecture cluster.

Cluster MySQL master-master sur sites distants : problème de synchronisation et de performances

Le Cluster et le contexte

Prestataire expert MySQL

Notre client exploite une application critique sur base de données MySQL configurée en cluster de serveurs « master-master » situés chez le client dans deux datacenters distants d’une centaine de km. Cette distance assez importante est une exigence de sécurité liée au métier du Client et ne peut être réduite. La volumétrie est inférieure à 50Go et maintenue à ce niveau par une limitation de la rétention par crainte de pénaliser les performances. L’application basée sur ce cluster MySQL étant critique, il est impératif que le cluster assure une réplication synchrone, ou quasi-synchrone, des données sur les deux sites distants avec un décalage en minutes.

Cette base de données fait l’objet d’un contrat de TMA auprès d’une SSII mais les difficultés s’accumulent :

  • Dé-synchronisation croissante des bases, au point que la synchro a été arrêtée,
  • Détection tardive d’incident,
  • Crainte de ne pouvoir absorber l’augmentation continue du volume de données.

Il nous est demandé d’effectuer un audit ciblé sur la synchronisation du cluster, mais nous insistons pour faire un audit complet de la configuration.

Notre audit du cluster MySQL et nos analyses

Nous réalisons un audit complet de la configuration:

  • Réseau et interconnexion entre les 2 DC :  la latence est bonne, la liaison stable et la bande passante est suffisante,
  • Serveurs : les serveurs sont bien dimensionnés et identiques, mais nous relevons un taux d’I/O Wait élevé (>10%),
  • Configuration MySQL : beaucoup d’optimisations de configuration ne sont pas effectuées:
    • la config MySQL ne permet pas d’exploiter toute la RAM des serveurs,
    • méthode d’écriture Flush InnoDB via le File System est à optimiser
    • aucune optimisation du moteur InnoDB,
    • la méthode de réplication semble OK,
  • Exploitation , des axes d’amélioration nombreux
    • tâches planifiées mal organisées : trop de répétitions sur des opérations trop lourdes,
    • des index manquants, trop de « slow queries »,
    • méthode de sauvegarde inadaptée et trop consommatrice sur le serveur primaire, passer en sauvegarde sans lock sur le replica en changeant d’outil (xtrabackup),
    • L’analyse des volumétries montre que l’augmentation des volumes n’alourdit pas la réplication,  il devrait être possible de passer de 50Go à 150Go sans contrainte une fois les optimisations effectuées.

Conclusion et plan d’action : la réplication n’est pas en cause, pas plus que l’infrastructure, des investissements matériels complémentaires ne sont pas nécessaires et ne suffiront pas à résoudre les problèmes.

Ce sont bien la configuration MySQL et son exploitation qui ne sont pas optimisées et pénalisent les performances au point d’empêcher la réplication de bien tourner. Pour chacun des points relevés nous proposons des actions d’optimisations, que nous présentons au Client pour qu’il se les approprie et les mette en oeuvre lui-même. Clairement le contrat de TMA n’est pas adapté, et un suivi d’exploitation régulier doit être mené.

Base de données MySQL sous AWS Aurora : audit et optimisations

La base et le contexte

AWS cloud publicAWS Aurora pour MySQLLe Client exploite un site internet important et a développé un outil d’analyse du comportement de ses internautes qui repose sur une base MySQL de volumétrie conséquente (>100 Go). La base est utilisée par le site ainsi que par des outils d’agrégation et de data-visualisation.

La base est déployée sur le cloud public Amazon Web Services (AWS) comme le reste de l’infrastructure du site, elle est configurée sur une instance RDS/Aurora pour MySQL 8vCPU/61 Go RAM avec un read-replica pour isoler les lectures/écritures.

Avant de mettre l’application en production, le Client souhaite faire valider sa configuration sur AWS, les performances de la base et des traitement, ainsi que la sécurité des accès à la base.

Audit et préconisations

Notre audit confirme une configuration bien conçue ; nous axons notre analyse sur des optimisations de performances et identifions un renforcement indispensable de la sécurité.

  • Défragmentation des tables à intervalle régulier pour réduire les espaces consommés,
  • Optimisation de la taille et des types de champs, afin de réduire leur taille et gagner sur les requêtes,
  • Configuration de la mémoire : analyse et ajustement de paramètres comme par exemple
    • buffer_pool , dimensionnement et capacité d’extension,
    • innodb_buffer_pool_instances à augmenter graduellement pour augmenter la concurrence d’accès,
    • sort_buffer_size à augmenter légèrement,
  • Analyse des slow queries, et exemples d’optimisation des indexes,
  • Sécurité, malgré l’usage de filtrage des accès aux bases de données, nous relevons une faille qui rend la base accessible depuis l’extérieur dans certaines conditions, celle-ci est facilement corrigée avec les « Security Group » d’AWS.

Audit Cluster MySQL Galera 3 noeuds : analyse de la synchronisation et extension de capacité

La base et le contexte

Cluster Galera MySQLGalera Cluster MySQL haute disponibilité actif-actif

Le Client exploite un portail à très forte audience avec une base My SQL conséquente (150Go)  déployée sur un cluster Galera 3 nœuds de 4 vCPU et 32 Go RAM, la répartition des requêtes entre les 3 nœuds se fait par un HA Proxy. Cette mise en place est assez récente ; le Client a observé des dé-synchronisations ponctuelles et souhaite être rassuré sur sa configuration, d’autre part il besoin d’étendre la capacité de la base MySQL et il souhaite valider la méthodologie pour le faire à chaud.

Audit du cluster MySQL Galera et extension de la capacité

Notre audit confirme une configuration bien conçue ; nos contrôles et préconisations d’optimisations portent sur :

  • Amélioration du monitoring Munin pour disposer de métriques sur l’activité du cluster et de la base, ajout d’alertes, les incidents passés peuvent être difficilement analysés par manque d’informations,
  • Augmentation de la rétention des logs, afin de disposer des moyens d’analyse des incidents,
  • Configuration du cluster Galera, optimisation des conditions de reprise en cas de désynchronisation :
    • analyse de la méthode de synchro (rsync vs xtrabackup) et des paramètres de timeout,
    • analyse de la capacité du cache pour permettre une reprise sans perte de transactions en cas de resycnhro entre les noeuds,
  • Configuration MySQL, script de tuning mysqltuner, étude d’une spécialisation des noeuds en lecture/écriture non retenue,
  • Méthode de sauvegardes, effectuées toutes les 2 h et non bloquantes,
  • Capacité réseau, pas de points de contention identifiés,
  • Extension de capacité : Dans le cadre de l’audit, la méthode a été définie et appliquée à chaud pour une extension de 30% sur l’ensemble des noeuds.

Conclusion : l’architecture est bien conçue et dimensionnée ; le monitoring et les logs permettront de mieux analyser l’activité à l’avenir et les ajustements de paramètres Galera amélioreront la stabilité du cluster et la reprise en cas de perturbation.

Contactez nous pour en savoir plus

Les exemples ci-dessous sont une sélection de réalisations classiques, nos interventions sont très variées et nous nous attachons à bien analyser l’usage des données et le contexte applicatif de chaque cas client pour optimiser nos préconisations.

Pour en savoir plus , pour un premier échange exploratoire, n’hésitez pas à nous contacter et nous écrire.

 

Contactez-nous