Propriétés

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 › Propriétés

Propriétés

Nom de propriété	Type	Description
auto_create	Nombre entier	Indique si la base de données doit être créée lorsqu'elle n'existe pas. Valeurs possibles : 1 pour la créer et 0 pour empêcher sa création automatique (pour éviter tout écrasement accidentel en cas de volumes endommagés). Si cette propriété est définie sur 0 et qu'aucune base de données n'existe sur le volume de données, l'appliance démarre en mode maintenance. (L'appliance démarre correctement, mais le démon MySQL n'est pas démarré pour que l'utilisateur puisse identifier le problème). La valeur par défaut est 1.
error_log_filename	Chaîne	Nom du fichier journal d'erreurs, associé au système de fichiers journaux (par exemple, /mysql_logs/my.log). Les répertoires sont automatiquement créés dans le chemin d'accès. Si aucun nom n'est spécifié, le journal d'erreurs est écrit sur le volume de données (/mnt/data/error.log). Valeur par défaut : vide.
error_log_level	Chaîne	Niveau de journalisation des erreurs. Valeurs possibles : error, pour ne consigner que les erreurs, et warn, pour consigner les avertissements et les erreurs. Cette propriété n'est pas sensible à la casse. Valeur par défaut : error
timezone	Chaîne	Spécifie le fuseau horaire utilisé dans l'appliance. Si cette propriété est vide, le fuseau horaire reste inchangé. Une liste des fuseaux horaires pris en charge est disponible ici.

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)

Nom de propriété	Type	Description
server_id	Nombre entier	ID du serveur. Les valeurs possibles sont comprises entre 1 et 10. Cela permet de spécifier l'ID du serveur lors de la réplication. Veillez à avoir configuré des ID uniques pour tous vos serveurs qui font partie de la réplication. Valeur par défaut : 1
rpl_mode	Chaîne	Mode de réplication. Les valeurs possibles sont none (pas de réplication), master, slave et master_and_slave (pour des scénarios de réplication multi-maîtres où un serveur est à la fois un maître et un esclave). Valeur par défaut : none
web_pwd	Chaîne	Mot de passe pour l'authentification à l'interface Web. Ce paramètre est facultatif. S'il est défini, le serveur HTTP de l'appliance est démarré et l'interface Web est présente sur le terminal ui et l'interface par défaut à partir desquels elle est accessible via l'option Connexion (web) dans l'éditeur CA AppLogic. Valeur par défaut : (vide).

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 :

Définissez rpl_mode sur master sur l'appliance existante.
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.
(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.
Redémarrez l'application.
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).
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 :

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.).
Définissez rpl_mode sur master_and_slave de dbN.
Connectez le terminal rout de l'appliance dbN-1 au terminal rin de l'appliance dbN.
Connectez le terminal rout de l'appliance dbN au terminal rin de l'appliance db1.
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.
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).
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.
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 :

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).
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.

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.

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.

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

Connectez-vous à l'interface Web de l'appliance dont le terminal rout est connecté à l'appliance qui exécute la réparation de réplication. Sélectionnez l'option reset master log position. La définition du journal maître oblige l'application à lire 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).
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 :

Nom du compteur	Description
Aborted Clients	Nombre de clients interrompus par le serveur
Aborted Connections	Nombre de connexions interrompues par le serveur
Bytes Received	Nombre d'octets reçus
Bytes Sent	Nombre d'octets envoyés
Total Connections	Nombre de connexions
Questions	Nombre total de questions
Slow Queries	Nombre de requêtes lentes
Threads Created	Nombre de threads créés
Threads Connected	Nombre de threads connectés
Threads Running	Nombre de threads en cours d'exécution
Max Used Connections	Nombre maximum de connexions utilisées
Open Files	Nombre de fichiers ouverts
Admin Commands	Nombre de commandes d'administration
Alter Table Commands	Nombre de commandes de modification de table
Analyze Commands	Nombre de commandes d'analyse
Change DB Commands	Nombre de commandes de modification de base de données
Change Master Commands	Nombre de commandes de modification de maître
Check Commands	Nombre de commandes de contrôle
Commit Commands	Nombre de commandes de validation
Create DB Commands	Nombre de commandes de création de base de données
Create Function Commands	Nombre de commandes de création de fonction
Create Index Commands	Nombre de commandes de création d'index
Create Table Commands	Nombre de commandes de création de table
Delete Commands	Nombre de commandes de suppression
Drop DB Commands	Nombre de commandes de suppression de base de données
Drop Function Commands	Nombre de commandes de suppression de fonction
Drop Index Commands	Nombre de commandes de suppression d'index
Drop Table Commands	Nombre de commandes de suppression de table
Flush Commands	Nombre de commandes de vidage
Grant Commands	Nombre de commandes d'attribution
Insert Commands	Nombre de commandes d'insertion
Insert Select Commands	Nombre de commandes d'insertion de la sélection
Kill Commands	Nombre de commandes d'arrêt
Load Commands	Nombre de commandes de chargement
Lock Tables Commands	Nombre de commandes de verrouillage de table
Optimize Commands	Nombre de commandes d'optimisation
Purge Commands	Nombre de commandes de purge
Rename Table Commands	Nombre de commandes de renommage de table
Repair Commands	Nombre de commandes de réparation
Replace Commands	Nombre de commandes de remplacement
Replace Select Commands	Nombre de commandes de remplacement de la sélection
Reset Commands	Nombre de commandes de réinitialisation
Revoke Commands	Nombre de commandes de retrait
Rollback Commands	Nombre de commandes d'annulation
Select Commands	Nombre de commandes de sélection
Set Option Commands	Nombre de commandes de définition d'option
Truncate Commands	Nombre de commandes de troncation
Unlock Tables Commands	Nombre de commandes de déverrouillage de tables
Update Commands	Nombre de commandes de mise à jour

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 :

Message d'erreur	Description
Echec de la définition du fuseau horaire.	La définition du fuseau horaire de l'appliance, tel que configuré par la propriété Fuseau horaire, a échoué.
L'appliance est en cours d'exécution en mode Réplication [$rpl_mode], mais le volume binlogs est manquant.	L'appliance est configurée pour s'exécuter en tant que maître, esclave ou maître et esclave, mais aucun volume binlogs n'a été indiqué.
L'appliance est exécutée en mode Réplication [$rpl_mode], mais le terminal rout n'est pas connecté.	L'appliance est configurée pour s'exécuter en tant qu'esclave ou maître et esclave, mais le terminal rout n'est pas connecté.
Le terminal rout est connecté, mais la propriété [rpl_mode] est définie sur none. Configurez la réplication via la propriété [rpl_mode] ou déconnectez le terminal rout	Le terminal rout est connecté, mais la propriété [rpl_mode] est définie sur none. Configurez la réplication via la propriété [rpl_mode] ou déconnectez le terminal rout.
Echec du démarrage de mysql car error_log_filename est défini et le terminal de journalisation n'est pas connecté.	La propriété error_log_filename est configurée mais le terminal de journal n'est pas connecté.
Echec du montage du partage via le terminal de journalisation.	L'appliance a été configurée pour écrire des journaux dans le terminal de journal, le partage n'a pas pu être monté sur le terminal de journal.
Le partage n'est pas accessible en écriture via le terminal de journalisation.	Le partage sur le terminal de journalisation n'est pas accessible en écriture.
Echec de la création du répertoire de journaux [$logdir] sur le terminal de journalisation	Echec de la création du répertoire de journaux [$logdir] sur le terminal de journalisation
Le répertoire de journaux [$logdir] n'est pas accessible en écriture.	Le répertoire de journal [$logdir] n'est pas accessible en écriture sur le terminal de journal.
Le fichier journal [$error_log] n'est pas accessible en écriture.	Le fichier journal [$error_log] n'est pas accessible en écriture sur le terminal de journal.
Echec de la création de la base de données	L'appliance a été démarrée sans base de données et n'est pas parvenue à installer les bases de données MySQL.
Echec de la configuration de la réplication	L'appliance n'est pas parvenue à configurer la réplication.
Echec du démarrage de MySQL	Le démon MySQL n'a pas pu être démarré.
Autorisations insuffisantes au niveau de la base de données MySQL	Les autorisations pour 'root'@'%' sont insuffisantes ou si le mode de réplication est utilisé, 'replication_user'@'%' ne dispose pas des autorisations suffisantes pour exécuter la réplication de MySQL.
Echec du démarrage de l'interface Web	Echec du démarrage de l'interface Web
La taille du volume de données doit être d'au moins 100 Mo.	La taille du volume de données devrait être supérieure à 100 mégaoctets. Reportez-vous aux remarques relatives aux exigences de volume.

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 :

Message d'erreur	Description
L'espace libre sur le volume de données sera bientôt insuffisant. Veuillez vérifier.	L'espace disponible sur le volume de données est inférieur à 20 %.
La réplication du serveur maître n'est pas en cours d'exécution, veuillez vérifier.	La réplication du serveur maître ne s'exécute pas..
La réplication du serveur esclave est en retard par rapport au serveur maître. Veuillez vérifier.	La réplication de l'esclave est trop en retard par rapport au maître. Veuillez vérifier.
L'espace libre sur le volume binlogs sera bientôt insuffisant.	L'espace disponible sur le volume binlogs est inférieur à 20 %.

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 :

Application simple à deux niveaux (aucune réplication)

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) :

Nom de propriété	Value (Valeur)	Commentaires
auto_create	1	Crée la base de données si les volumes sont vides.
error_log_filename	db.error	Nom de fichier journal d'erreurs qui doit être stocké sur le volume de données des journaux.
error_log_level	error	Niveau de journalisation des erreurs

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.

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

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 Linux5 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) :

Nom de propriété	Value (Valeur)	Commentaires
auto_create	1	Crée la base de données si les volumes sont vides.
error_log_filename	db.error	Nom de fichier journal d'erreurs qui doit être stocké sur le volume de données des journaux.
error_log_level	error	Niveau de journalisation des erreurs

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.

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

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

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) :

Maître

Nom de propriété	Value (Valeur)	Commentaires
auto_create	1	Crée la base de données si les volumes sont vides.
error_log_filename	master-db.error	Nom de fichier journal d'erreurs qui doit être stocké sur le volume de données des journaux.
error_log_level	error	Niveau de journalisation des erreurs
server_id	1	Serveur maître (la valeur ne doit pas forcément être 1, elle doit cependant être différente de celle de server_id sur l'esclave).
rpl_mode	Maître	Ecrit des journaux binaires pour effectuer la réplication.

Esclave

Nom de propriété	Value (Valeur)	Commentaires
auto_create	1	Crée la base de données si les volumes sont vides.
error_log_filename	slave-db.error	Nom de fichier journal d'erreurs qui doit être stocké sur le volume de données des journaux.
error_log_level	error	Niveau de journalisation des erreurs
server_id	2	Serveur esclave (la valeur ne doit pas forcément être 2, elle doit cependant être différente de celle de server_id sur le maître).
rpl_mode	Esclave	Se connecte au maître.

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.