Informations de référence › Manuel de référence du catalogue d'appliance › Catalogue système › Appliances de base de données › MYSQLR, MYSQLR64 - Appliance de base de données MySQL prévue pour la réplication

MYSQLR, MYSQLR64 - Appliance de base de données MySQL prévue pour la réplication

Voir la vidéo

Présentation fonctionnelle

MYSQLR64 est une appliance de base de données basée sur le moteur de base de données MySQL (http://www.mysql.org). Elle permet d'ajouter facilement une base de données quelle que soit l'application. Vous pouvez également utiliser les appliances dans des scénarios de réplication MYSQL complexes. Les appliances sont basées sur MYSQL5 (CentOS 6.3/MySQL 5), mais gèrent également la réplication de base de données.

La réplication de base de données permet la réplication de données d'un serveur de base de données MySQL (maître) sur un ou plusieurs serveurs de base de données MySQL (esclaves). Les appliances MYSQLR64 peuvent aussi bien être configurées pour la réplication maître-esclave que pour la réplication maître-maître avec plusieurs maîtres.

La configuration de la réplication, de la gestion et de la surveillance s'effectue via une interface Web. L'interface Web fournit une méthode simple pour démarrer la réplication avec une durée d'indisponibilité sur le maître proche de zéro. Elle permet également de réparer une réplication en cas de problème. Par ailleurs, elle peut servir à copier des bases de données à partir d'appliances de base de données plus anciennes telles que MYSQL et MYSQL5. MYSQLR64 fournit également une méthode (basée sur phpMyAdmin) permettant de gérer et de parcourir facilement votre base de données.

La réplication est utile dans plusieurs cas :

• Solutions d'échelonnement - Répartition de la charge entre plusieurs noeuds à des fins d'amélioration des performances (configuration "maître-maître").
• Solutions de basculement - Utilisation de plusieurs noeuds dans la réplication maître-maître pour pouvoir utiliser chaque appliance individuellement pour exécuter l'application en cas d'échec des autres. (MYSQLR64 ne traite pas automatiquement les échecs. Si un serveur MySQL échoue, votre application doit le détecter et arrêter de l'utiliser. )
• Solutions de sauvegarde - Deux ou plusieurs noeuds : l'un exécuté en tant que maître, les autres en tant qu'esclaves. L'application utilise uniquement le maître, les esclaves sont utilisés pour la sauvegarde (auquel cas la base de données peut être arrêtée pour assurer la cohérence de la sauvegarde) ou simplement pour analyser les données en profondeur (rapports, récapitulatifs ou toute autre opération qui ne modifie pas les données) sans charger le maître, et de ce fait sans aucune incidence sur les performances de l'application. (MYSQLR64 ne sauvegarde pas automatiquement votre base de données. Vous devez gérer la sauvegarde vous-même. )

Dans sa configuration par défaut, MYSQLR64 agit exactement comme l'appliance MYSQL5 avec une interface Web pour la gestion. Pour l'utiliser dans des scénarios de réplication, vous avez besoin d'au moins deux appliances de MYSQLR64 avec une configuration appropriée (voir Utilisation standard).

MYSQLR64 stocke la base de données sur un volume défini par l'application que vous pouvez configurer sur chaque instance MYSQLR64. MYSQLR64 crée automatiquement une base de données vide lorsqu'elle démarre sur un volume vide.

Important : Il est déconseillé de mélanger les appliances MYSQLR 32 et 64 bits lors de l'utilisation de la réplication lorsque les fichiers de base de données sont copiés en l'état du maître vers l'esclave. De même, les volumes de données de la version 32 bits de l'appliance ne devraient pas être utilisés avec une version 64 bits de la même appliance (et inversement). Pour migrer une base de données entre les versions MYSQLR 32 bits et 64 bits, videz les bases de données d'un hôte et importez-les sur l'autre comme dans la procédure décrite dans la section Migration de MYSQLR vers MYSQLR64 (et inversement). Pour accéder à cette section, cliquez ici.

Ressources

Terminaux

L'interface par défaut est activée. Elle est destinée au diagnostic et au dépannage (via SSH). Les versions futures de cette appliance peuvent désactiver l'accès SSH.

Important : Les terminaux rin et rout sont utilisés aussi bien pour les données SSH (tcp 22) que MYSQL (tcp 3306). Lorsque les passerelles / VPN sont utilisées pour connecter ces terminaux, les pare-feux doivent être configurés pour autoriser les deux ports.

Volumes d'utilisateur

Le volume de données peut éventuellement contenir un fichier my.cnf dans son répertoire supérieur, qui inclut des options de configuration de MYSQL. Pour plus d'informations, reportez-vous à la section Configuration personnalisée. Cette fonctionnalité est disponible dans MYSQLR64 1.6.1 ou version ultérieure.

Important :

• Le volume de données doit être exclusivement dédié à l'instance de MySQL (il ne peut pas être partagé avec d'autres appliances).
• Le volume de données ne doit être formaté avec aucun système de fichiers, car il est utilisé pour créer un volume LVM. Si vous utilisez un volume formaté avec un système de fichiers (éventuellement avec les fichiers d'une ancienne appliance MySQL), l'appliance ne parvient pas à vous empêcher de supprimer vos fichiers/base de données.
• Pour migrer une base de données à partir d'une appliance ancienne (MYSQL, MYSQL5 ou MYSQL64), d'un serveur physique ou de MYSQLR (en cas de migration de la version 32 bits à la version 64 bits de l'appliance), consultez la procédure Migration de la base de données à partir d'une autre appliance.

Propriétés

Important :

• L'utilisation de la propriété use_old_passwords a été supprimée à partir de MYSQLR64 1.6.8. Si vous devez activer old_passwords, créez une configuration personnalisée comme expliqué ci-dessous.
• Si la propriété error_log_filename est spécifiée et que le terminal de journal n'est pas connecté ou que le système de fichiers ne peut pas être monté, l'appliance MYSQLR ne démarre pas.

Propriétés avancées (utilisées dans les scénarios de réplication)

Configuration personnalisée

Cette fonctionnalité est disponible dans MYSQLR64 1.6.1 ou version ultérieure.

MYSQLR64 permet d'utiliser un fichier de configuration MySQL personnalisé qui peut fournir des options de configuration supplémentaires ou remplacer la configuration existante spécifiée dans /etc/my.cnf.

Pour utiliser une configuration personnalisée, créez un fichier nommé my.cnf et placez-le dans le répertoire supérieur du volume de données. Le format du fichier doit respecter la syntaxe du fichier d'options MySQL décrite dans la documentation de MySQL.

Par exemple, vous pouvez utiliser le paramétrage suivant pour optimiser les performances de MYSQLR64 en cas d'utilisation d'InnoDB (la configuration MYSQLR64 par défaut est optimisée pour MyISAM).. Cet exemple repose sur l'utilisation de 512 Mo de mémoire (valeur par défaut pour MYSQLR64).

[mysqld]
# Réduisez les tampons MyISAM
key_buffer = 512 Ko
myisam_sort_buffer_size = 512 Ko

# Définissez InnoDB comme le moteur de stockage par défaut (facultatif)
default-storage-engine = INNODB

# Définissez la taille de tampon d'InnoDB
innodb_buffer_pool_size=350M
innodb_log_file_size=128M
innodb_log_buffer_size=4M
innodb_thread_concurrency=8

# Si vous n'avez pas trop de tables, utilisez cette option. De cette manière, vous pouvez éviter que la taille de l'espace des tables augmente de manière incontrôlée, un processus que vous ne pouvez pas annuler.
innodb_file_per_table=1

Important : Lorsqu'il est utilisé en mode réplication, MYSQLR64 synchronise également le fichier my.cnf sur le volume de données lorsque vous corrigez/initialisez la réplication. De cette manière, la configuration esclave et maître sont identiques.

Interface Web

MYSQLR64 fournit une interface Web accessible sur le terminal ui et l'interface par défaut via l'option Connexion (web) dans l'éditeur CA AppLogic®.. Une authentification HTTP est requise pour utiliser l'interface Web. Laissez le nom d'utilisateur vide et utilisez la valeur web_pwd comme mot de passe. L'interface fournit les fonctionnalités suivantes :

• Affichage de l'état du serveur
  • Démarrage/arrêt/redémarrage du service MySQL
  • Etat et durée de disponibilité du serveur MySQL
  • Etat de réplication de MySQL (pour cette appliance uniquement)
  • Dernières entrées de journal MySQL
  • Durée de disponibilité de l'appliance
  • Utilisation de la mémoire de l'appliance
  • Utilisation du disque de l'appliance
• Affichage/gestion de la réplication
  • Etat de réplication de MySQL (pour cette appliance uniquement)
  • Initialisation/correction de la réplication. Dans ce cas, la base de données sur l'appliance est effacée et la réplication recommence depuis le début sur le maître. Cela n'affecte pas la base de données sur le maître (aucune donnée n'est supprimée sur le maître) et cela n'entraîne pas l'indisponibilité de l'appliance MYSQLR64 maître. Pendant la réparation, l'appliance sera hors ligne et ne doit pas être utilisée.
  • delete snapshot - Supprime un cliché de base de données créé sur cette appliance pour initialiser/corriger la réplication sur son esclave. Si tout fonctionne normalement, aucun cliché ne reste sur l'appliance. Si le bouton Delete snapshot s'affiche, un esclave initialise actuellement la réplication à partir de cette appliance ou une tentative précédente d'initialisation de la réplication a échoué. Veillez à ce qu'aucun esclave n'utilise le cliché avant de le supprimer. Cette option n'est pas visible si l'appliance ne contient aucun cliché.
  • reset master log position - lors de l'ajout d'un nouveau serveur dans une réplication maître-maître multi-noeud, après avoir initialisé/corrigé la réplication sur l'appliance actuelle, vous devez vous connecter à l'interface Web de l'appliance laquelle se connecte à son tour à cette appliance via son terminal rout, puis cliquez sur Reset master log position.
• Gestion de la base de données
  • Navigation et modification de vos bases de données à l'aide de PhPMyAdmin.

Ajout de réplications maître-esclave à des appliances MYSQLR64

CA AppLogic® permet d'ajouter des réplications maître-esclave à des appliances MYSQLR64 existantes sans perdre la moindre donnée.

Pour ajouter des réplications maître-esclave à des appliances MYSQLR64 :

1. Définissez rpl_mode sur master sur l'appliance existante.
2. Ajoutez une nouvelle appliance MYSQLR64 à votre application avec un volume de données vide. Connectez son terminal rout au terminal rin de l'appliance actuelle.
3. (Facultatif) Si vous envisagez de l'utiliser dans une réplication maître-maître, connectez le terminal supprimé de l'appliance actuelle au terminal rin de la nouvelle appliance.
4. Redémarrez l'application.
5. Connectez-vous à l'interface Web de la nouvelle appliance et sélectionnez l'option initiate/fix replication sous l'onglet Manage Replication. La journalisation prend du temps selon la taille des données sur le maître. Si vous utilisez INSSLR pour accéder à MYSQLR64, veillez à définir la propriété de délai d'expiration sur une valeur élevée (36000) pour éviter toute expiration. Vérifiez l'absence de délais d'expiration dans les proxys côté client (il est préférable d'éviter l'utilisation de proxy).
6. Une fois la réplication lancée, connectez-vous à l'interface Web des deux appliances MYSQLR64 et vérifiez l'état de la réplication. La réplication doit normalement s'exécuter dans les 5 minutes sur les deux appliances.

Ajout d'appliances MYSQLR64 à des réplications maître-esclave

CA AppLogic® permet d'ajouter de nouvelles appliances MYSQLR64 à des réplications maîtres-esclave existantes sans perdre la moindre donnée.

Pour ajouter des appliances MYSQLR64 à des réplications maître-esclave :

1. Ajoutez une nouvelle appliance MYSQLR64 à votre application avec un volume de données vide. Par exemple, dbN, en supposant que vous avez déjà N-1 appliances MYSQLR64 (3 <= N <= 10) et que le terminal rout de chaque appliance est connecté au terminal rin de l'appliance suivante dans une configuration circulaire (db1 rout est connecté à db2 rin, etc.).
2. Définissez rpl_mode sur master_and_slave de dbN.
3. Connectez le terminal rout de l'appliance dbN-1 au terminal rin de l'appliance dbN.
4. Connectez le terminal rout de l'appliance dbN au terminal rin de l'appliance db1.
5. Redémarrez l'application pour que les modifications soient appliquées. Après le redémarrage, la réplication n'est pas synchronisée tant que la procédure n'est pas terminée. Il se peut que les données écrites dans une appliance ne soient pas répliquées sur toutes les autres appliances au cours de la procédure.
6. Connectez-vous à l'interface Web de l'appliance dbN et sélectionnez l'option initiate/fix replication sous l'onglet Manage Replication. La journalisation prend du temps selon la taille des données sur le maître. Si vous utilisez INSSLR pour accéder à MYSQLR64, veillez à définir la propriété de délai d'expiration sur une valeur élevée (36000) pour éviter toute expiration. Vérifiez également l'absence de délais d'expiration dans les proxys côté client (il est préférable d'éviter l'utilisation de proxy).
7. Une fois la réplication lancée, connectez-vous à l'interface Web de dbN-1 et sélectionnez l'option reset master log position. La journalisation oblige l'application à lire les journaux binaires de dbN-1 et de dbN depuis le début.
8. Connectez-vous à l'interface Web de toutes les appliances MYSQLR64 et vérifiez l'état de la réplication. Celle-ci doit normalement s'exécuter sur toutes les appliances dans les 5 minutes.

Réparation d'une réplication dans des configurations maître-esclave

CA AppLogic® permet de réparer une réplication dans une configuration maître-esclave sans perdre la moindre donnée.

Pour réparer une réplication dans des configurations maître-esclave :

1. Connectez-vous à l'interface Web de l'esclave et sélectionnez l'option initiate/fix replication. La journalisation prend du temps selon la taille des données sur le maître. Pendant l'opération, le service MySQL sur l'esclave s'arrête. Aucun temps d'indisponibilité n'est introduit sur le maître. Cette opération revient à ajouter une nouvelle appliance à une appliance MYSQLR64 existante. Si vous utilisez INSSLR pour accéder à MYSQLR64, vérifiez que la propriété de délai d'expiration est définie sur une valeur élevée (36000) pour éviter toute expiration. Vérifiez également l'absence de délais d'expiration dans les proxys côté client (il est préférable d'éviter l'utilisation de proxy).
2. Une fois la réplication lancée, connectez-vous à l'interface Web des appliances MYSQLR64 esclaves et vérifiez l'état de la réplication. Celle-ci doit normalement s'exécuter dans les 5 minutes.

Réparation d'une réplication dans des configurations maître-maître

CA AppLogic® permet de réparer une réplication dans une configuration maître-maître sans perdre la moindre donnée.

Pour réparer une réplication dans des configurations maître-maître :

1. Connectez-vous à l'interface Web de l'appliance qui signale que la réplication a échoué et sélectionnez l'option initiate/fix replication. La journalisation prend du temps selon la taille de la base de données sur le maître. Pendant l'opération, le service MySQL sur l'appliance s'arrête. Aucun temps d'indisponibilité n'est introduit sur le maître. La base de données n'est pas synchronisée avec l'ensemble des maîtres tant que la réparation n'est pas terminée. Il se peut que les mises à jour de base de données ne soient pas répliquées sur toutes les autres appliances MYSQLR64 au cours de la réparation.

   Important : Toutes les données sur cette appliance sont initialisées à partir du maître. Si des mises à jour sont apportées à la base de données sur l'appliance actuelle pendant l'interruption de la réplication, elles sont perdues. Le cas échéant, résolvez les conflits manuellement.

2. Connectez-vous à l'interface Web de l'appliance dont le terminal rout est connecté à l'appliance sur laquelle vous exécutez la réparation de la réplication. Sélectionnez l'option reset master log position (réinitialiser l'emplacement du journal principal) pour que l'application lise les journaux binaires de l'appliance réparée depuis le début. Si vous utilisez INSSLR pour accéder à MYSQLR64, vérifiez que la propriété de délai d'expiration est définie sur une valeur élevée (36000) pour éviter toute expiration. Vérifiez également l'absence de délais d'expiration dans les proxys côté client (il est préférable d'éviter l'utilisation de proxy).
3. Connectez-vous à l'interface Web de toutes les appliances MYSQLR64 et vérifiez l'état de la réplication. Celle-ci doit normalement s'exécuter dans les 5 minutes sur toutes les appliances.

Surveillance de la réplication

Une tâche cron surveille la réplication entre les appliances MYSQLR64. Si la réplication est activée, la tâche cron s'exécute toutes les deux minutes et envoie des alertes au tableau de bord de grille dans les cas suivants :

• La réplication n'est pas en cours d'exécution. (Le message suivant s'affiche dans le tableau de bord de la grille : La réplication du serveur maître n'est pas en cours d'exécution. Veuillez vérifier.)
• La réplication s'exécute mais est trop en retard sur le maître. (Le message suivant s'affiche dans le tableau de bord de la grille : La réplication est en retard par rapport au serveur maître. Veuillez vérifier.)
• L'espace disque sur le volume de données est bas (< 20 % d'espace libre). Ce paramètre est vérifié que la réplication soit activée ou non (Le message suivant s'affiche dans le tableau de bord de la grille : L'espace libre sur le volume de données sera bientôt insuffisant.)
• L'espace disque sur le volume binlogs est faible (< 20 % d'espace libre). Ce paramètre est vérifié que la réplication soit activée ou non (Le message suivant s'affiche dans le tableau de bord de la grille : L'espace libre sur le volume binlogs sera bientôt insuffisant.)

Dans ces cas, l'utilisateur doit résoudre le problème manuellement.

Si la réplication échoue, vous pouvez utiliser l'interface Web pour la corriger comme le décrit la section ci-dessus.

Compteurs personnalisés

L'appliance MYSQLR64 signale les compteurs personnalisés suivants via le terminal mon.

Les compteurs suivants appartiennent au groupe de compteurs MySql :

Messages d'erreur

Les messages suivants peuvent s'afficher dans le fichier journal de l'appliance ou dans le journal système du contrôleur de grille lorsque l'appliance ne parvient pas à démarrer :

Les messages d'erreur suivants peuvent également s'afficher dans le tableau de bord de la grille lorsque l'appliance est en cours d'exécution :

Application simple à deux niveaux (aucune réplication)

Le diagramme suivant affiche une utilisation standard de l'appliance MYSQLR64 dans une petite application Web à deux niveaux :

Appliances en cours d'utilisation :

• user - Passerelle d'entrée
• web - Serveur Web
• db - Appliance de base de données MYSQLR64
• logs - Appliance NAS pour le stockage des fichiers journaux
• content - Appliance NAS pour le stockage du contenu de serveur Web
• admin - Passerelle d'entrée pour l'affichage des fichiers journaux
• mon - Appliance MON

La requête client arrive sur la passerelle utilisateur. La passerelle envoie les requêtes au serveur Web, qui les traite. Lorsque des scripts (par exemple, Perl ou PHP) sur le Web doivent accéder à des données permanentes, ils utilisent l'appliance db via le terminal out du serveur Web. L'appliance db est configurée pour stocker ses fichiers journaux dans le répertoire racine du partage fourni par les journaux.

Les administrateurs se connectent à la passerelle admin à l'aide d'un navigateur pour afficher les fichiers journaux MySQL ou du serveur Web. La passerelle admin envoie les requêtes à l'appliance NAS de journaux.

Exemple de configuration de propriétés (les propriétés qui ne figurent pas dans les tableaux ci-dessous doivent être définies sur leurs valeurs par défaut) :

Remarque : Le volume de données doit également être configuré sur l'appliance db ainsi que les journaux, le contenu et les appliances MON. Pour créer des volumes virtuels d'application pouvant être utilisés ici, reportez-vous au Manuel de l'utilisateur de la grille.

Application évolutive à deux niveaux (aucune réplication)

Le diagramme suivant affiche une utilisation standard de l'appliance MYSQLR64 dans une application Web à deux niveaux dans laquelle la base de données est utilisée pour partager l'état et les données entre plusieurs serveurs Web à charge équilibrée. Par ailleurs, dans cet exemple, il existe une entrée distincte pour la maintenance, via laquelle un administrateur peut se connecter et accéder à la base de données à des fins de maintenance, ainsi qu'une autre entrée via laquelle un administrateur peut se connecter et afficher le journal d'erreurs MySQL.

Appliances en cours d'utilisation :

• user - Passerelle d'entrée pour les requêtes utilisateur
• web_lb - Equilibreur de charge Web pour les requêtes utilisateur
• web1, web2 - Serveurs Web hébergeant du contenu actif (par exemple, scripts CGI)
• db - Base de données
• logs - Stockage pour la base de données et les fichiers journaux d'erreurs des serveurs Web et leur accès
• content - Stockage de contenu de serveurs Web
• maint - Passerelle d'entrée pour l'accès de maintenance
• admin - Serveur Linux6server générique utilisé par l'administrateur
• gway - Passerelle réseau pour l'accès de l'administrateur à Internet
• mon - Appliance MON

La requête client arrive sur la passerelle utilisateur. Cette dernière envoie les requêtes à l'équilibreur de charge web_lb, qui les transmet à un des serveurs Web web1 et web2. Les serveurs Web accèdent à la base de données db.

La base de données db et les serveurs web1 et web2 écrivent leurs fichiers journaux dans l'appliance de journaux via les terminaux de journal. De plus, un administrateur peut se connecter à l'appliance de journaux via la passerelle maint et afficher les fichiers journaux.

En outre, un administrateur peut se connecter au serveur admin à l'aide de SSH via la passerelle maint (moyennant la configuration des clés publique-privée). A partir du serveur admin, l'administrateur peut accéder à la base de données db pour consulter des statistiques ou modifier le schéma de base de données. Le serveur admin peut accéder à Internet via la passerelle gway pour, par exemple, télécharger une version plus récente des bibliothèques ou le schéma de base de données.

Exemple de configuration de propriétés (les propriétés qui ne figurent pas dans les tableaux ci-dessous doivent être définies sur leurs valeurs par défaut) :

Remarques :

• Le volume de données doit également être configuré sur la base de données, les journaux, le contenu et les appliances MON.
• Les appliances maint, admin, gway, mon et log ne sont pas nécessaires au fonctionnement de l'application à deux niveaux. Si vous disposez du serveur admin, celui-ci peut avoir des tâches cron pour le nettoyage de la base de données, l'envoi de courriels, etc.

Application à X niveaux avec réplication maître-esclave (prévue pour les sauvegardes)

Le diagramme suivant affiche une utilisation standard de l'appliance MySQL dans une application Web dans laquelle la base de données est répliquée sur un serveur esclave. Vous pouvez utiliser le serveur esclave pour effectuer des sauvegardes cohérentes des données sans arrêter le serveur maître, en introduisant zéro comme durée d'indisponibilité de l'application.

Appliances en cours d'utilisation :

• user - Passerelle d'entrée pour les requêtes utilisateur
• admin - Passerelle d'entrée pour l'accès aux fichiers journaux et l'accès Web à l'appliance MYSQLR64
• sw - Répartit le trafic HTTP entre les différentes appliances MYSQLR64
• web_lb - Equilibreur de charge Web pour les requêtes utilisateur
• web1, web2 - Serveurs Web hébergeant du contenu actif (par exemple, scripts CGI)
• master - MYSQLR64 configuré en tant que maître
• slave - MYSQLR64 configuré en tant qu'esclave
• content - Stockage de contenu de serveurs Web
• logs - Stockage des fichiers journaux de serveurs Web et de bases de données
• mon - Appliance MON

La requête client arrive sur la passerelle utilisateur. Cette dernière envoie les requêtes à l'équilibreur de charge web_lb, qui les transmet à un des serveurs Web web1 et web2. Les serveurs Web accèdent à la base de données maître.

L'appliance esclave est reliée à l'appliance maître et réplique ses données. Vous pouvez arrêter l'esclave à tout moment pour effectuer des sauvegardes cohérentes des données SQL ou des analyses sans interférer avec les performances de l'appliance maître et du reste de l'application.

L'accès Web au maître et à l'esclave est disponible via la passerelle admin sur les ports 8080 et 8081.

Les appliances maître, esclave, web1 et web2 sont configurées pour stocker leurs fichiers journaux dans le répertoire racine du partage exposé par les journaux. De plus, un administrateur peut afficher des fichiers journaux via la passerelle admin.

Exemple de configuration de propriétés (les propriétés qui ne figurent pas dans les tableaux ci-dessous doivent être définies sur leurs valeurs par défaut) :

master (Maître)

Esclave

Remarques :

• Le volume de données doit être configuré sur les journaux, le contenu et les appliances MON.
• Les volumes de données et binlogs doivent être configurés aussi bien sur le maître que sur l'esclave. Ils devraient avoir suffisamment d'espace pour gérer les données et les journaux.
• Chaque appliance doit utiliser son propre volume (un volume ne peut pas être partagé par plusieurs appliances).
• Les appliances admin, MON et log ne sont pas nécessaires au fonctionnement de la réplication.

Application à X niveaux avec réplication maître-esclave (prévue pour l'équilibrage de charge)

Le diagramme suivant affiche une utilisation standard de l'appliance MYSQLR64 dans une application Web dans laquelle la base de données est répliquée sur deux serveurs dans un scénario de réplication maître-maître. Dans ces cas, l'application utilise aussi bien les serveurs WEB que MYSQLR64 pendant l'opération d'équilibrage de charge. De même, en cas d'échec d'une des instances WEB/MYSQLR64, vous pouvez utiliser l'autre instance de WEB/MYSQLR64 pour éviter le problème d'indisponibilité de l'application.

Appliances en cours d'utilisation :

• user - Passerelle d'entrée pour les requêtes utilisateur
• admin - Passerelle d'entrée pour l'accès aux fichiers journaux
• sw - Répartit le trafic HTTP entre les différentes appliances MYSQLR64
• web_lb - Equilibreur de charge Web pour les requêtes utilisateur
• web1, web2 - Serveurs Web hébergeant du contenu actif (par exemple, scripts CGI)
• db1 and db2 - Appliances MYSQLR64 configurées tant sur le maître que sur l'esclave
• content - Stockage de contenu de serveurs Web
• logs - Stockage des fichiers journaux de serveurs Web et de bases de données
• mon - Appliance MON

La requête client arrive sur la passerelle utilisateur. Cette dernière envoie les requêtes à l'équilibreur de charge web_lb, qui les transmet à un des serveurs Web web1 et web2. web1 utilise l'appliance de base de données db1, web2 utilise l'appliance de base de données db2. db1 et db2 sont connectés pour répliquer les mises à jour que les serveurs Web effectuent sur la base de données. Chaque appliance MYSQLR64 utilise un décalage (égal à son server_id) pour ses colonnes auto_increment afin d'éviter toute entrée en double.

L'accès Web à db1 et à db2 est disponible via la passerelle admin sur les ports 8080 et 8081.

Les appliances db1, db2, web1 et web2 sont configurées pour stocker leurs fichiers journaux dans le répertoire racine du partage exposé par les journaux. De plus, un administrateur peut afficher des fichiers journaux via la passerelle admin.

Exemple de configuration de propriétés (les propriétés qui ne figurent pas dans les tableaux ci-dessous doivent être définies sur leurs valeurs par défaut) :

db1

db2

Remarques :

• Le volume de données doit être configuré sur les journaux, le contenu et les appliances MON.
• Les volumes de donnée et binlogs doivent être configurés sur db1 et sur db2. Chaque appliance doit utiliser son propre volume (un volume ne peut pas être partagé par plusieurs appliances).
• Pour commencer une réplication maître-maître, les volumes de données doivent être vides.
• Les appliances admin, MON et log ne sont pas nécessaires au fonctionnement de la réplication.

Application à X niveaux avec réplication maître-maître multinoeud (prévue pour l'équilibrage de charge)

Le diagramme suivant affiche une utilisation standard de l'appliance MYSQLR64 dans une application Web dans laquelle la base de données est répliquée sur quatre serveurs dans un scénario de réplication maître-maître. Dans ces cas, l'application utilise l'ensemble des serveurs WEB et MYSQLR64 pendant l'opération d'équilibrage de charge. De même, en cas d'échec d'une des instances WEB/MYSQLR64, vous pouvez utiliser les autres instances de WEB/MYSQLR64 pour éviter le problème d'indisponibilité de l'application. (MYSQLR64 ne se préoccupe pas des échecs).

Appliances en cours d'utilisation :

• user - Passerelle d'entrée pour les requêtes utilisateur
• admin - Passerelle d'entrée pour l'accès aux fichiers journaux
• sw - Répartit le trafic HTTP entre les différentes appliances MYSQLR64
• web_lb - Equilibreur de charge Web pour les requêtes utilisateur
• web1, web2, web3, web4 - Serveurs Web hébergeant du contenu actif (par exemple, scripts CGI)
• db1, db2, db3, db4 - Appliances MYSQLR64 configurées tant sur le maître que sur l'esclave
• content - Stockage des fichiers journaux d'erreurs de base de données, du contenu Web et des journaux Web
• logs - Stockage des fichiers journaux de serveurs Web et de bases de données
• mon - Appliance MON

La requête client arrive sur la passerelle utilisateur. Cette dernière envoie les requêtes à l'équilibreur de charge web_lb, qui les transmet à un des serveurs Web web1, web2, web3 et web4. Chaque serveur Web utilise sa propre appliance de base de données. Toutes les appliances de base de données sont connectées de façon circulaire pour répliquer les mises à jour que les serveurs Web effectuent sur la base de données. Ainsi, une mise à jour sur db1 est répliquée sur db2, db3 et db4. Chaque appliance MYSQLR64 utilise un décalage (égal à son server_id) pour ses colonnes auto_increment afin d'éviter toute entrée en double.

L'accès Web à db1, db2, db3 et db4 est disponible via la passerelle admin sur les ports 8080, 8081, 8082 et 8083.

Les appliances db1, db2, web1 et web2 sont configurées pour stocker leurs fichiers journaux dans le répertoire racine du partage exposé par les journaux. De plus, un administrateur peut afficher des fichiers journaux via la passerelle admin.

Exemple de configuration de propriétés (les propriétés qui ne figurent pas dans les tableaux ci-dessous doivent être définies sur leurs valeurs par défaut) :

db1

db2

db3

db4

Remarques :

• Le volume de données doit être configuré sur les journaux, le contenu et les appliances MON.
• Le volume de données et binlogs doit également être configuré sur toutes les appliances db. Chaque appliance doit utiliser son propre volume (un volume ne peut pas être partagé par plusieurs appliances).
• Pour commencer une réplication multi-maître, les volumes de données doivent être vides.
• Les appliances admin, MON et log ne sont pas nécessaires au fonctionnement de la réplication.

Application à X niveaux s'exécutant sur différentes infrastructures (prévue pour l'équilibrage de charge et le basculement)

Le diagramme suivant affiche une utilisation standard de l'appliance MYSQLR64 dans une application Web s'exécutant dans plusieurs installations. Avec cette configuration, vous pouvez avoir plusieurs applications identiques s'exécutant sur différentes installations dont la base de données est répliquée sur toutes les applications dans une configuration maître-maître. Cette configuration est utile dans deux cas :

• L'équilibrage géographique de la charge : Installez 2 (ou plusieurs) applications de ce type pour que les utilisateurs puissent utiliser l'application la plus proche de chez eux afin d'améliorer les temps de réponse (équilibrage de charge effectué avec DNS).
• Basculement : Installez 2 (ou plusieurs) applications de ce type pour qu'en cas de panne de l'installation entière contenant l'application (ou de panne de l'application proprement dite), vous puissiez utiliser les autres applications pour éviter les problèmes d'indisponibilité.

Application maître

Application esclave

Appliances en cours d'utilisation :

• user - Passerelle d'entrée pour les requêtes utilisateur
• admin - Passerelle d'entrée pour l'accès aux fichiers journaux
• sw - Redirige le port 8080 de l'administrateur vers le maître ou l'esclave
• vpn - Entrée pour que l'application distante se connecte à l'appliance maître=/=esclave pour répliquer la base de données
• web_lb - Equilibreur de charge Web pour les requêtes utilisateur
• web1, web2 - Serveurs Web hébergeant du contenu actif (par exemple, scripts CGI)
• master - MYSQLR64 configuré en tant que maître
• slave - MYSQLR64 configuré en tant qu'esclave
• content - Stockage des fichiers journaux d'erreurs de base de données, du contenu Web et des journaux Web
• logs - Stockage des fichiers journaux d'erreurs de base de données

La requête client arrive sur la passerelle utilisateur. Cette dernière envoie les requêtes à l'équilibreur de charge web_lb, qui les transmet à un des serveurs Web web1 et web2. Les serveurs Web accèdent à la base de données maître. L'appliance maître se connecte à l'application (esclave) distante. La seule différence étant le server_id de l'esclave et la configuration réseau) pour répliquer la base de données. L'application distante se connecte à l'appliance maître via la passerelle vpn qui est configurée pour n'autoriser la connexion que de la passerelle vpn de l'application distante. Les appliances maître et esclave des deux applications s'exécutent dans une configuration maître-maître afin que leurs données soient toujours identiques.

Exemple de configuration de propriétés (les propriétés qui ne figurent pas dans les tableaux ci-dessous doivent être définies sur leurs valeurs par défaut) :

L'accès Web au maître et à l'esclave est disponible via la passerelle admin sur le port 8080.

master (Maître)

VPN maître

Esclave

VPN esclave

L'application distante est une copie exacte. La seule différence est la configuration réseau de l'utilisateur, de l'administrateur et des appliances VPN. Les connexions entre l'appliance VPN et le maître=/=esclave, et le server_id de l'appliance maître=/=esclave (doit être unique).

Migration de MYSQLR vers MYSQLR64 (et inversement)

Pour effectuer une migration de MYSQLR vers MYSQLR64 (et vice versa), vous ne devez pas uniquement utiliser les volumes de l'appliance 32 bits sur l'appliance 64 bits (ou inversement) car les données seront alors corrompues. Pour ce faire, nous vous recommandons de vider la base de données sur l'ancienne appliance, en transférant le fichier vidé vers la nouvelle appliance, puis en important la base de données dans la nouvelle appliance.

Vous pouvez utiliser la même procédure pour migrer une base de données à partir d'une appliance de base de données plus ancienne (MYSQL, MYSQL5, MYSQL64) ou une base de données MYSQL ne s'exécutant pas sur une appliance CA AppLogic®.

Pour migrer la base de données :

• (facultatif) Empêchez l'accès à l'ancienne base de données. Cette étape est facultative et sert uniquement à empêcher toute modification de la base de données pendant l'opération de vidage de cette dernière. Une méthode consiste à démarrer l'appliance sans aucun élément connecté sur ses terminaux d'entrée.
• Videz toutes les bases de données sur l'ancienne appliance. Avant d'effectuer cette étape, vérifiez que l'espace sur le volume de données est suffisant. (Vous pouvez toujours redimensionner le volume de données si l'espace est insuffisant). Pour ce faire, démarrez l'appliance, connectez-vous à l'appliance et exécutez la commande suivante :
  • mysqldump --all-databases --lock-all-tables | gzip > /mnt/data/my_dump.sql.gz
• Arrêtez l'application.
• Créez un nouveau volume virtuel d'application destiné à stocker la base de données pour la nouvelle appliance (ext3-snapshot). Vérifiez que l'espace sur le volume est suffisant pour contenir le fichier de vidage de la base de données (/mnt/data/my_dump.sql.gz) ainsi que la base de données proprement dite.
• Transférez le fichier de vidage de la base de données vers le volume que vous venez de créer. (La procédure ci-dessous n'indique qu'une méthode pour copier la base de données à l'aide de 2 systèmes de fichiers configurés avec un accès Internet externe. Si cette méthode ne convient pas dans votre configuration, la base de données peut également être copiée à l'aide de scp de la grille vers un serveur externe, puis sur le volume de destination) :
  • Gérez chaque volume séparément à l'aide de deux systèmes de fichiers (un pour chaque volume) à l'aide de la commande vol manage. Transmettez les informations IP externes sur la ligne de commande vol manage pour permettre un accès réciproque à chaque serveur de fichiers afin de copier la base de données entre les deux volumes. Pour plus d'informations sur la configuration des paramètres réseau externes, reportez-vous à l'aide relative à vol manage.
  • Dans le serveur de fichiers du volume source, exécutez la commande suivante : cat /etc/ssh/ssh_host_rsa_key.pub >> /root/.ssh/authorized_keys
  • Dans le serveur de fichiers du volume de destination, exécutez la commande suivante : scp -pr -i /etc/ssh/ssh_host_rsa_key IP_address_to_source_filer:/mnt/vol/my_dump.sql.gz /mnt/vol/.
  • Une fois la base de données copiée, vous pouvez fermer les deux systèmes de fichiers.
• Modifiez l'application et ajoutez une nouvelle instance de MYSQLR/MYSQLR64, paramétrez-la, connectez-la et affectez-lui le volume que vous venez de créer. A ce stade, vous pouvez supprimez l'ancienne instance MYSQLR/MYSQLR64 de l'application. (Toutefois, vous souhaiterez peut-être la conserver à des fins de sauvegarde jusqu'à ce que vous ayez pu vérifier que la base de données a effectivement été transférée vers la nouvelle instance).
• Importez la base de données. Démarrez la nouvelle appliance, connectez-vous et exécutez la commande suivante :
  • zcat /mnt/data/my_dump.sql.gz | mysql
• La base de données est transférée et l'appliance est prête à être utilisée.

Notes

Mise en garde :

• Les performances de MYSQLR64 sont optimisées pour le moteur de stockage MyISAM utilisé par défaut. Si vous souhaitez améliorer les performances pour Innodb ou simplement adapter le service MYSQL à votre application, reportez-vous à la section de Configuration personnalisée pour plus d'informations sur la méthode d'ajout de paramètres de configuration à la configuration existante. Cette fonctionnalité est disponible dans MYSQLR64 1.6.1 ou version ultérieure.
• MYSQLR64 utilise uniquement la réplication asynchrone. (MySQL ne prend pas en charge la réplication synchrone.).
• MYSQLR64 détecte les erreurs de réplication dans un délai de 2 minutes et en informe l'utilisateur en publiant un message dans le tableau de bord de la grille. L'utilisateur peut alors utiliser l'interface utilisateur graphique MYSQLR64 pour régler le problème. (MYSQLR64 n'effectue aucune récupération automatisée.)
• Au démarrage de MYSQLR64, un message s'inscrit dans le fichier journal de l'appliance pour indiquer que chmod n'est pas parvenu à modifier le propriétaire du fichier journal de MySQL. Ce message est attendu et n'affecte en rien le fonctionnement de l'appliance MYSQLR64.
• Théoriquement, le nombre maximum d'appliances MYSQLR64 dans une réplication unique est de 10. Les données étant répliquées de façon circulaire, l'augmentation du nombre d'appliances de MYSQLR64 allonge le délai pour que les esclaves mettent à jour leurs bases de données. Le nombre maximum réel d'appliances d'une réplication peut être inférieur en fonction de votre application, de la charge et de vos besoins. (La mise à jour immédiate des esclaves peut ne pas être critique dans certains scénarios tels que la sauvegarde de données).

Important : Lors de la création d'utilisateurs pour la base de données, vérifiez que tous les utilisateurs sont créés sans restriction sur l'hôte à partir duquel ils se connectent. Par exemple :

mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
    ->     IDENTIFIED BY 'some_pass' WITH GRANT OPTION;

• Configuration requise pour le volume
  • La taille du volume de données doit être de minimum 100 Mo. Le moteur InnoDB est actuellement activé et occupe environ 22 Mo de l'espace du volume de données. Cette version ne permet pas de le désactiver, même si vous n'utilisez pas InnoDB pour le stockage des données.
  • Le volume de données ne doit être formaté avec aucun système de fichiers, car il est utilisé pour créer un volume LVM. (Le volume ne doit pas être formaté.) Si vous utilisez un volume formaté avec un système de fichiers (éventuellement avec les fichiers d'une ancienne appliance MySQL), l'appliance ne parvient pas à vous empêcher de supprimer vos fichiers.
  • 20 % de l'espace du volume de données est alloué à l'initialisation/la correction de la réplication. Il reste donc 80 % de l'espace du volume pour le stockage de la base de données.
  • Lorsque vous utilisez MYSQLR64 dans des scénarios de réplication en tant que maître, esclave ou maître et esclave, vous devez fournir un volume binlogs. La rotation des journaux binaires est effectuée à 100 Mo et les journaux sont conservés pendant 2 jours après leur rotation, après quoi ils sont supprimés. Si l'appliance s'exécute également en tant qu'esclave, des journaux de relais sont également stockés sur le volume binlogs. L'espace de votre volume binlogs doit au moins être de 500 Mo pour effectuer une réplication maître-maître. La taille réelle dépend de l'intensité des requêtes de mise à jour/d'insertion de MySQL exécutées. L'espace du volume binlogs ne doit être que de quelques Go pour faire fonctionner l'application normalement.
• L'appliance reliée à MYSQLR64 est responsable de la création de ses tables et de sa propre base de données si elles n'existent pas. De même, vous pouvez copier manuellement la base de données initiale sur le volume de données.
• L'appliance ou le serveur connecté à l'entrée IN de MYSQLR64 doit disposer de la bibliothèque client MySQL pour accéder au serveur MySQL et soumettre des requêtes. Tous les serveurs virtuels fournis dans le catalogue d'appliance ont la bibliothèque cliente MySQL installée, y compris le serveur générique LINUX.
• Références :
  • http://www.mysql.com -- site Web de MySQL
  • http://dev.mysql.com/doc/refman/5.0 /en/index.html -- documentation de MySQL 5.0

Logiciels Open Source tiers utilisés dans l'appliance

MYSQLR64 utilise les packages Open Source tiers suivants en plus des packages Open Source tiers utilisés par sa classe de base LUX64.

Dépannage MYSQLR

L'appliance MYSQLR se fige au redémarrage

A partir de MYSQLR 1.6.2, vous pouvez définir/modifier un mot de passe pour le compte root de base de données. Toutefois, l'appliance MSYQLR dispose de quelques comptes root avec des noms d'hôte différents. Lorsque vous définissez/modifier un mot de passe, utilisez toujours le compte root@%. Le compte root@% est le compte auprès duquel s'authentifient les appliances connectées au terminal in de MYSQLR. Les autres comptes root ne sont utilisés que par des utilisateurs locaux. Un mot de passe ne doit jamais être défini pour ces derniers, sinon l'appliance MYSQLR ne parvient pas à démarrer.

Remarque : Si vous ne définissez pas de mot de passe pour le compte root@localhost, la sécurité n'est pas compromise car ce compte peut uniquement être utilisé par des utilisateurs locaux sur l'appliance et quiconque qui a accès à l'appliance peut modifier le mot de passe.

Récupérer une appliance MYSQLR qui ne parvient plus à démarrer à la suite de la modification du mot de passe root de la base de données

Pour récupérer une appliance qui ne parvient plus à démarrer parce que le mot de passe root de la base de données a été modifié, procédez comme suit :

1. Démarrez l'appliance ou l'application en mode de débogage.

   Commande de démarrage d'appliance

   comp start main.MYSQLR --debug 
   

   Commande de démarrage d'application

   app start --debug 
   

   Vous devriez pouvoir vous connecter à l'appliance quelques secondes après l'avoir démarrée. Il n'est pas nécessaire d'attendre que le délai d'expiration de l'appliance soit atteint.

2. Connectez-vous via SSH à l'appliance et exécutez les commandes suivantes :

   mysql -p -e "update mysql.user set Password='' where User='root'" 
   mysqladmin -p flush-privileges 
   mysql -e 'update mysql.user set password=PASSWORD("NEWPASSWORD") where User="root" and Host="%"' 
   mysqladmin flush-privileges
   

3. Redémarrez l'appliance pour vérifier qu'elle démarre et que les connexions MySQL sur le terminal in pour l'utilisateur root requièrent un mot de passe.