Surveillance base de données pour serveur MariaDB et Percona

A la fois le serveur MariaDB et Percona  sont les embranchements de MySQL et s’efforce d’être déployés en remplacement de MySQL d’un point de vue binaire, comptabilité de l’API et perspective de commande en ligne.

Il est important de disposer d’une alternative à MySQL car vous ne savez jamais ce qui pourrait se passer, étant donné qu’Oracle l’a acheté pour 1 milliard de dollars. Dans ce blog, je veux voir si ces embranchements MySQL travailleront à 100% avec AppDynamics pour les bases de données. Si vous n’êtes pas familiarisé avec AppDynamics pour les bases de données produit je vous suggère de prendre quelques minutes pour lire cet autre blog.

L’installation

Disposer à la fois du serveur MariaDB et Percona installé dans les exemples de tests était très simple. Je choisis d’utiliser 2 Red Hat Enterprise Linux (RHEL) serveurs s’exécutant sur Services web d’Amazon (SWA) sans raison particulière autre qu’il était rapide et facile à exécuter. Ma première étape était de s’assurer que MySQL avait disparu de mes serveurs RHEL en exécutant “supprimer serveur mysql”.

Installant à la fois le serveur MariaDB et Percona constituait à installer mes fichiers du référentiel (documentéici et là) et exécutant les commandes d’installation. Cela a pris soin d’obtenir les binaires installées ainsi le reste du processus qui était lié à démarrer et configurer les serveurs de bases de données individuels.

La commande de démarrage pour à la fois le serveur MariaDB et Percona est “/etc/init.d/mysql start” ainsi vous pouvez voir que ses produits vraiment recherche à baisser directement dans le respect de MySQL. Comme vous pouvez le voir dans la capture d’écran ci-dessous je terminais d’exécuter le serveur MariaDB 10.0.3 et Percona 5.5.31-30.3.

Connecté à chaque de ses bases de données étaient 1 exemple de WordPress et 1 exemple de Drupal dans une configuration proche “prête à l’emploi” hormis l’ajout d’un couple de nouveau message pour chaque SMC afin d’aider à conduire une petite quantité de chargement. Je ne veux pas installer un outil de test de charge ainsi j’induisais un risque élevé de charge interne et externe sur chaque serveur en exécutant la commande UNIX “cat /dev/zero > /tmp/zerofile”. Cette commande extrait le nombre de 0 dans ce fichier aussi vite qu’il peut écraser le disque dur (Utilisez Ctrl-C pour tuer cette commande avant de remplir votre disque.)

La surveillance

Disposez de la surveillance installée était très simple. J’ai utilisé un exemple test d’AppDynamics pour bases de données afin de surveiller à distance chaque exemple de bases de données (oui, aucun agent installé exigé). Afin d’initier la surveillance j’ouvrais la console d’AppDynamics pour bases de données, naviguait jusqu’au gestionnaire de l’agent, cliquait sur le bouton “ajouter agent”, et remplissait les champs comme montré ci-dessous (Je sélectionnais MySQL comme type de base de données):

Mon agent à distance ne s’est pas connecté la première fois que j’ai essayé cela car j’ai oublié de configurer iptables et laisser ma connexion à travers même si j’avais mise en place mon SWA pare-feu réglé correctement (facepalm). Après avoir configuré iptables en dehors de cette voie (je venais de l’éteindre car c’était des cas de tests) ma base de données surveillant les connexions prenait vie et j’étais lancé.

Le Résultat

Jetant un œil à toutes les données versées dans AppDynamics pour base de données je puis voir que 100% de celles-ci étaient compatibles avec le serveur MariaDB et Percona. Il n’y a aucune erreur être rejeté et la donnée est comme elle devrait être.

La beauté de mon disque induit de charge Interne/Externe était que juste en cliquant autour de l’interface Web de WordPress et Drupal je recevais des temps de réponse lents. Cela rend toujours les données intéressantes à regarder. Ainsi, voici quelques captures d’écran pour chaque type de base de données pour vous afin de vérifier…

AppDynamics pour Bases de données activité écran pour la base de données MariaDB.

AppDynamics pour Bases de données activité écran pour la base de données Percona.

Explique l’état pour un état sélectionné dans MariaDB.

Explique état pour un état sélectionné dans Percona.

Un couple de tableaux statistiques pour MariaDB.

Un couple de tableaux statistiques pour Percona.

Si vous êtes en cours d’exécution de MySQL vous devriez vouloir contrôler le serveur MariaDB et Percona. Il est possible que vous pussiez voir certaines améliorations de la performance depuis que le moteur de stockage pour MariaDB et Percona et XtraDB par opposition à MySQL’s InnoDB. Disposer d’un choix de technologie est une chose importante. Disposer d’une plateforme de surveillance unifiée pour votre  MySQLMariaDB,Percona Serveur, OracleSQL ServeurSybaseIBM DB2, et de la base de données PostgreSQL est même meilleure. Cliquez ici pour démarrer votre essai gratuit d’AppDynamics pour bases de données dès aujourd’hui.

Cet article est la traduction du texte original en anglais. Ci-joint le texte original: http://www.appdynamics.com/blog/database/database-monitoring-for-mariadb-and-percona-server/#sthash.TNISEHam.dpuf