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 › Application à X niveaux s'exécutant sur différentes infrastructures (prévue pour l'équilibrage de charge et le basculement)

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.

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.

Commentaires

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.