Étiquette : mysql

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Administration 5/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger(auteur invité).

Je rappelle que ce billet est le dernier (et oui déjà) d’une série de 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

DUMP a chaud sur une base de données de type Cluster MySQL

La plus part des sociétés qui décide d’employer ce genre d’architecture pour leur base de données, pensent avant tout a la sauvegarde en ligne de leur données sans l’interruption de service. L’intérêt de MySQL Cluster est que les données sont donc toutes stockées en mémoire, ce qui rend donc possible ce processus de sauvegarde.

Une sauvegarde représente le contenu d’une base de données, à un moment donné. La sauvegarde contient 3 parties principales :

  • Les méta-données (quelles tables existents, etc.)
  • Les lignes des tables(les données )
  • Un historique des transactions archivées

Chaque partie est stockée sur tous les noeuds qui participent à la sauvegarde.

Durant une sauvegarde, chaque noeud sauve ces données sur le disque, en trois fichiers :

BACKUP-<BackupId>.<NodeId>.ctl 

Le fichier de contrôle, qui contient les données de contrôle et les méta-données.

BACKUP-<BackupId>-0.<NodeId>.data 

Le fichier de données qui contient les lignes des tables.

BACKUP-<BackupId>.<NodeId>.log 

Le fichier de log, qui contient les transactions archivées.

Dans les lignes ci-dessus, <BackupId> est un identifiant pour la sauvegarde, et <NodeId> est l’identifiant du noeud qui a créé le fichier.

Meta data

Les méta-données sont consistuées des définitions de table. Tous les noeuds ont la même définition de table, sauvée sur le disque.

Table records

Les lignes sont sauvées par fragment. Chaque fragment contient un entête qui décrit à quelle table appartient les lignes. Après un groupe de ligne, il y a pied-de-page qui contient une somme de contrôle. Différents noeuds sauvent différents fragment durant la sauvegarde.

Committed log 

L’historique contient les transactions archivées, effectuée durant la sauvegarde. Seules les transactions impliquant les tables stockées sur le noeud sont stockées dans le log. Les différents noeuds de la sauvegarde sauvent différents logs, car ils abritent différents fragments de bases de données.

Utilisation du serveur de gestion pour une sauvegarde de cluster

Il faut suivre les étapes suivantes:

  1. Lancez le serveur de management.
  2. Exécutez la commande START BACKUP.
  3. Le serveur de gestion vous indiquera « Start of backup ordered ». Cela signifie que le serveur de management a envoyé la requête au cluster, mais qu’il n’a pas encore reçu de réponse.
  4. Le serveur de gestion va indiquer « Backup <BackupId> started », où <BackupId> est l’identifiant de la sauvegarde. Cette information sera aussi enregistrée dans le log du cluster (à moins que cela ne soit configuré autrement). Cela signifie que le serveur a reçu des réponses, et que la sauvegarde a été faite. Cela ne signifie pas que la sauvegarde est complète.
  5. Le serveur de gestion va indiquer que la sauvegarde est finie avec le message « Backup <BackupId> completed ».

[cce]

ndb_mgm> start backup

Waiting for completed, this may take several minutes

Node 3: Backup 1 started from node 1

ndb_mgm> Node 3: Backup 1 started from node 1 completed

StartGCP: 76106 StopGCP: 76109

#Records: 2057 #LogRecords: 0

Data: 51188 bytes Log: 0 bytes

[/cce]

Utilisation du serveur pour annuler une sauvegarde :

  1. Lancez le serveur de gestion.
  2. Exécutez la commande ABORT BACKUP <BACKUPID>. Le numéro <BackupId> est l’identifiant de la sauvegarde, qui est inclut dans la réponse du serveur de gestion au moment de la création de la sauvegarde : « Backup <BackupId> started ». L’identifiant est aussi sauvé dans le log du cluster (cluster.log).
  3. Le serveur de gestion répond « Abort of backup <BackupId> ordered ». Cela signifie qu’il a envoyé la requête au cluster, mais n’a pas encore re¸u de réponse.
  4. Le serveur de gestion répond « Backup <BackupId> has been aborted reason XYZ ». Cela signifie que le cluster a annulé la sauvegarde, et supprimé toutes les ressources reliées, y compris les fichiers.

Dans la partition /home de votre serveur noeud vous pouvez donc voir ceci . Un dossier Backup crée par le serveur de management, puis le numeros de la sauvegarde et les fichiers nécessaire a sa restauration.

Utilisation des processus serveurs MySQL par MySQL Cluster

mysqld est le processus traditionnel du serveur MySQL. Pour être utilisé avec MySQL Cluster, il doit être compilé avec le support des tables NDB. Si le binaire mysqld a été compilé correctement, le moteur de tables NDB Cluster est désactivé par défaut.

Pour activer le moteur NDB, il y a deux méthodes. Soit vous utilisez l’option –ndbcluster au démarrage, lorsque vous utilisez la commande mysqld ou bien, insérez une ligne avec ndbcluster dans la section [mysqld] de votre fichier my.cnf.

Un moyen facile pour vérifier que votre serveur supporte le moteur NDB Cluster est d’utiliser la commande SHOW ENGINES depuis un client mysql. Vous devriez voir la valeur YES dans la ligne de NDBCLUSTER. Si vous voyez NO, c’est que vous n’utilisez pas le programme mysqld compilé avec le support de NDB Cluster. Si vous voyez DISABLED, alors vous devez simplement activer le moteur dans votre fichier de configuration my.cnf.

Le serveur MySQL doit savoir comment lire la configuration du cluster. Pour accéder à cette configuration, il doit connaître 3 choses :

  • Son propre numéro d’identifiant de noeud dans le cluster.
  • Le nom d’hôte ou l’adresse IP où le serveur de gestion réside.
  • Le port sur lequel se connecter au serveur de gestion.

Il y a actuellement trois moyens pour donner ces informations au processus mysqld. La méthode recommandée est de spécifier la chaîne de connexion de mysqld appelée ndb-connectstring, soit au démarrage de mysqld ou dans le fichier my.cnf.

Vous pouvez aussi inclure cette information dans un fichier appelé Ndb.cfg. Ce fichier doit résider dans le dossier de données de MySQL. Une autre solution est de configurer la variable d’environnement appelée NDB_CONNECTSTRING. La chaîne sera la même dans tous les cas : « [nodeid=<id>;][host=]<host>:<port> ». Si aucune information n’est fournie, cette chaîne vaudra par défaut « host=localhost:2200 ».

[cce]

shell> mysqld –ndb-connectstring=ndb_mgmd.mysql.com:2200

[/cce]

ndb_mgmd.mysql.com est l’hôte où le serveur de gestion réside : il attend sur le port 2200.

Avec cette configuraiton, le serveur MySQL sera partie prenant du cluster MySQL, et accédera à la liste complète de tous les noeuds du cluster ainsi que leur statut. Il va se connecter à tous les noeuds de stockage, et sera capable d’utiliser chacun d’entre eux comme coordonnateur de transaction, ainsi que pour accéder aux données.

ndb_mgmd, le serveur de management

Le serveur de management est le processus qui lit le fichier de configuration du cluster, et distribue cette information à tous les noeuds qui le demande. Il gère aussi le log d’activité du cluster. Les clients de gestion s’y connectent et peuvent l’utiliser pour envoyer des commandes d’analyse et d’administration.

Si vous utilisez plusieurs serveurs de gestion, une chaîne de connexion doit être fournie, et tous les noeuds du cluster doivent explicitement spécifier leur identifiant.

  • config.ini est le fichier de configuration du cluster. Il est créé par l’utilisateur et lu par le serveur de gestion.
  • ndb_1_cluster.log est le fichier où les événements du cluster sont consignés. Les événements du cluster sont, par exemple : les jalons commencés ou complétés, les incidents de noeuds, les démarrages de noeuds, les niveaux d’utilisation de mémoire, etc.
  • ndb_1_out.log est le fichier utilisé pour les entrées et sorties (stdout et stderr) lors de l’exécution du serveur de gestion comme démon. 1, dans ce contexte, est l’identifiant de noeud.
  • ndb_1.pid est le fichier de PID utilisé lors de l’exécution du serveur de gestion comme démon. 1, dans ce contexte, est l’identifiant de noeud.
  • ndb_1_cluster.log.1 , lorsque le log de cluster dépasse un millions d’octets, alors le fichier de log prend le nom indiqué ici, où 1 est le nombre de fichier de logs : si 1, 2 et 3 existent déjà, le suivant sera le numéro 4.

ndb_mgm, le client de gestion du cluster

Le dernier processus important à connaître est le client de gestion. Ce processus n’est pas nécessaire pour faire fonctionner le cluster. Son intérêt est que pouvoir vérifier le statut du cluster, de lancer les sauvegardes, et effectuer les autres activités d’administration. Il fournit un moyen d’accès et un jeu de commandes.

En fait, le client de gestion utilise une interface C qui donne l’accès au serveur de gestion : pour les utilisateurs experts, il est possible de programmer des processus spécifiques qui pourront effectuer des taches d’administration automatisées.

[cce]

shell> ndb_mgm

[/cce]

Commandes du client de gestion du Cluster

En plus du fichier de configuration central, le cluster peut aussi être contrôlé avec une interface en ligne de commande. La ligne de commande est disponible via un processus séparé de client de gestion du cluster. C’est l’interface principale de gestion du cluster.

Le client de gestion a les commandes suivantes de base. Ci-dessous, <id> indique un noeud de base de données (i.e. 21) ou le mot clé ALL qui indique que la commande doit être appliquée à tous les noeuds dans le cluster.

HELP

Affiche les informations sur toutes les commandes disponibles.

SHOW

Affiche les informations sur le statut du cluster.

<id> START

Lance le noeud de base de données identifié par <id>, ou bien tous les noeuds.

<id> STOP

Stoppe le noeud de base de données identifié par <id>, ou bien tous les noeuds.

<id> RESTART [-N] [-I]

Relance le noeud de base de données identifié par <id>, ou bien tous les noeuds.

<id> STATUS

Affiche les informations de statut du noeud de base de données identifié par <id> (ou de tous les noeuds avec ALL).

ENTER SINGLE USER MODE <id> 

Active le mode d’utilisateur unique, où seule l’API avec le noeud <id> est autorisée pour accéder au système de base de données.

EXIT SINGLE USER MODE

Quitte le mode d’utilisateur unique.

QUIT

Quitte le client de gestion du cluster.

SHUTDOWN

Arrête tous les noeuds du cluster, hormis les serveurs MySQL, puis s’arrête.

Conclusion

Note de Nicolargo: Merci encore à Remy pour cette série d’articles sur un sujet d’actualité vu le nombre croissant de données gérées par nos applications.

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Démarrage 4/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger(auteur invité).

Je rappelle que ce billet est le 4em d’une série de 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

Démarrage du Cluster

Démarrer le cluster n’est pas très difficile une fois qu’il a été configuré. Chaque noeud doit être lancé séparément, et depuis l’hôte sur lequel il réside. Même s’il est possible de lancer les noeuds dans n’importe quel ordre, il est recommandé de lancer le serveur d’administration en premier, puis les noeuds de stockage et enfin, les noeuds SQL.

Sur l’hôte de gestion, utilisez la commande suivante depuis le Shell pour lancer le processus de gestion :

[cce]

ndb_mgmd -f /var/lib/mysql-cluster/config.ini

[/cce]

Notez que ndb_mgmd doit recevoir le nom et chemin du fichier de configuration, avec l’option -f ou –config-file.

Sur chaque hôte de stockage, exécutez cette commande pour lancer les processus NDBD :

[cce]

ndbd –initial

[/cce]

Notez qu’il est très important d’utiliser le paramètre –initial uniquement lors du premier démarrage de ndbd, ou lors du redémarrage apràs une opération de restauration des données ou de modification de configuration. En effet, ce paramètre va forcer le noeud à effacer les fichiers créé par les anciennes instances de ndbd, y compris les fichiers de log.

Sur les hôtes SQL, exécutez une commande mysqld classique (sous simple utilisateur le service ne fonctionne pas si vous êtes en root ) :

[cce]

mysqld &

[/cce]

Si tout se passe bien, et que le cluster a été correctement configuré, il devrait être opérationnel à nouveau. Vous pouvez tester cela en utilisant la commande ndb_mgm, c’est à dire le client de gestion; le résultat devrait être similaire à celui-ci :

[cce]

[root@localhost ~]# ndb_mgm

— NDB Cluster — Management Client —

ndb_mgm> show

Connected to Management Server at: localhost:1186

Cluster Configuration

———————

[ndbd(NDB)] 2 node(s)

id=3 @12.0.1.30 (mysql-5.1.56 ndb-7.1.15, Nodegroup: 0, Master)

id=4 @12.0.1.31 (mysql-5.1.56 ndb-7.1.15, Nodegroup: 0)

[ndb_mgmd(MGM)] 2 node(s)

id=1 @12.0.1.10 (mysql-5.1.56 ndb-7.1.15)

id=2 @12.0.1.11 (mysql-5.1.56 ndb-7.1.15)

[mysqld(API)] 2 node(s)

id=5 @12.0.1.20 (mysql-5.1.56 ndb-7.1.15)

id=6 @12.0.1.21 (mysql-5.1.56 ndb-7.1.15)

[/cce]

Quelques pistes si vous avez des messages d’erreurs

Can’t connect to mysql server through socket ‘/tmp/mysql.sock’

Le serveur MySQL n’est pas lancé.

Le socket précisé lors du lancement du client ne correspond pas à celui du serveur (option –socket pour le client en ligne de commande

Sous UNIX, le user mysql n’a pas les droits sur le répertoire /tmp du serveur.

Access denied for user : ‘xx@xx’ (using password : Y/N)

Le mot de passe entré n’est pas le bon.

Aucun mot de passe n’a été donné alors que le serveur en attend un (option -p du client MySQL en ligne de commande par exemple).

L’utilisateur n’a pas les droits pour se connecter ou sur certaines tables. Pour voir les droits d’un utilisateur, utilisez la commande SHOW GRANTS FOR user@host. Si nécessaire, donnez les privilèges au user (voir plus haut). N’oubliez pas de faire un FLUSH PRIVILEGES pour recharger les droits

L’utilisateur est occulté par un autre plus prioritaire mais aux droits plus restreints. Le serveur MySQL considère d’abord les users les plus spécifiques (avec une adresse IP précise ou « localhost » par exemple) avant de prendre en compte les plus génériques (caractères ‘%’ ou ‘_’ dans le nom du user ou de l’hôte).

Ex : si l’utilisateur Bob se connecte à partir de la machine locale où se trouve le serveur MySQL, les droits de ‘bob@localhost’ primeront, s’ils existent, sur les droits de ‘bob@%’.

Les erreurs d’accès s’expliquent souvent par la présence d’utilisateurs anonymes (user= ») dans la table users qui masquent les droits de certains autres utilisateurs. Pour y remédier, on peut les supprimer par un DELETE FROM mysql.user WHERE user= ».

Connexion failed 1130- Host ‘X’ is not allowed to connect to this MySQL server

Il n’existe aucun utilisateur autorisé à se connecter depuis l’hôte X (dans la table des droits, il n’y a pas de user …@X).

Can’t connect to mysql server on [hôte]

L’option skip-networking du serveur est activée (au démarrage ou dans le fichier de configuration my.ini/my.cnf) et empêche les connexions TCP/IP venant de l’extérieur.

Désactivez également l’option bind-address 127.0.0.1

Arrêter le cluster

Pour arrêter le cluster, utilisez simplement cette commande dans le Shell sur la machine qui héberge le serveur de gestion MGM :

[cce]

ndb_mgm -e shutdown

[/cce]

Cela va forcer les processus ndb_mgm, ndb_mgm et ndbd à s’arrêter proprement. Tous les noeuds SQL peuvent alors être arrêté avec la commande mysqladmin shutdown classiques ou par d’autres moyens.

Pour relancer le cluster, lancez simplement ces commandes :

Sur l’hôte de gestion (12.0.1.10 et 12.0.1.11 dans notre cas) :

[cce]

ndb_mgmd -f /var/lib/mysql-cluster/config.ini

[/cce]

Sur chaque noeud de stockage (12.0.1.30 et 12.0.1.31) :

[cce]

ndbd

[cce]

N’oubliez pas d’invoquer cette commande avec l’option –initial lorque vous redémarrez un noeud NDBD normalement.

Et les hôtes SQL (12.0.1.20 et 12.0.1.21) :

[cce]

mysqld &

[cce]

Suite et fin au prochain épisode !

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Installation 3/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger(auteur invité).

Je rappelle que ce billet est le second d’une série de 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

Il est préférable de télécharger directement les paquets sur le site officiel de MySQL.

Dans notre cas nous utiliserons une distribution CentOS 6.0 avec les paquets RedHat Cluster Suite . On commence donc par téléchargez les paquets suivant :

MySQL-Cluster-gpl-client-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-tools-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-storage-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-shared-7.1.15a-1.rhel5.x86_64.rpm

MSQL-Cluster-gpl-management-7.1.15a-1.rhel5.x86_64.rpm

MySQL-Cluster-gpl-server-7.1.15a-1.rhel5.x86_64.rpm

On les installe avec la commande suivante:

[cce lang= »bash »]

rpm-ivh mysql-cluster-gpl-*

[/cce]

Je vous conseille de faire l’installation pas à pas. Si jamais lors de l’installation des paquets, vous rencontrez une erreur similaire a celle ci :

Vous devez désinstaller la librairie qui pose soucis . Car elle corrompt les paquets de MySQL-Cluster .

Serveur de management

Dans un premier temps il est préférable de commencer par les serveurs de management, il s’agit de la même configuration sur les deux, avec la même installation de paquet.

Nous devons créer config.ini dans le répertoire /var/lib/mysql-cluster qui permettra le chargement des fichiers de configuration pour le Cluster. On ajoute des directives de configuration suivantes dans le fichier.

[cce lang= »bash »]

# vim /var/lib/mysql-cluster/config.ini

[NDBD DEFAULT]

NoOFReplicas=2

LockPagesInMainMemory=1

DataMemory=4000M

IndexMemory=768M

ODirect=1

NoOfFragmentlogFiles=300

MaxNoOfConcurrentOperations=100000

TimeBetweenGlobalCheckpoints=1000

TimeBetweenEpochs=200

DiskCheckpointSpeed=5M

DiskCheckpointSpeedInRestart=50M

RedoBuffer=16M

MaxNoOfTables=9096

MaxNoOfAttributes=10000

MaxNoOfExecutionthreads=4

MaxNoOfOrderedIndexes=5000

[MYSQLD DEFAULT]

[NDB_MGMD DEFAULT]

[TCP DEFAULT]

SendBufferMemory=8M

ReceiveBufferMemory=8M

[NDB_MGMD]

NodeId=1

HostName=12.0.1.10

[NDB_MGMD]

NodeId=2

HostName=12.0.1.11

[NDBD]

NodeId=3

HostName=12.0.1.30

[NDBD]

NodeId=4

HostName=12.0.1.31

[MYSQLD]

Hostname=12.0.1.20

[MYSQLD]

Hostname=12.0.1.21

[/cce]

Il faut que les deux serveurs de management possède exactement le même fichier de configuration, si vous êtes sous CentOS et que vous n’avez jamais touché a la configuration du parefeu, pensez a le désactiver.

[cce lang= »bash »]

# chkconfig iptables off

[/cce]

Serveurs SQL et serveurs de nœud

Il vous faut installer les mêmes paquets sur ces quatres autres machines, et elles possèdent toutes le même fichier de configuration /etc/my.cnf

[cce lang= »bash »]

# vim /etc/my.cnf

[client]

port=3306

socket=/var/lib/mysql/mysql.sock

[MYSQLD] # Options du processus mysqld

ndbcluster # Fonctionne en mode NDB

ndb-connectstring=12.0.0.100 # Situation du noeud MGM

[MYSQL_CLUSTER] # Options pour le processus ndbd

ndb-connectstring=12.0.0.100 # Situation du noeud MGM

[/cce]

Sur les serveurs SQL pensez a utiliser la commande :

[cce lang= »bash »]

# mysql_secure_installation

[/cce]

Elle permet de donner un mot de passe par défaut a votre serveur SQL, ainsi que l’accès a distance .

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Concept de base 2/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger (auteur invité).

Je rappelle que ce billet est le second d’une série de 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

—

MySQL Cluster est constitué de trois briques:

  1. Premièrement, un jeu de processus serveurs MySQL. Ce sont des serveurs MySQL traditionnelles, avec le nouveau moteur de table NDBCluster qui autorise l’accès aux tables en cluster.
  2. Le second type de processus est représenté par les noeuds de stockage de NDBCluster. Ces processus contiennent les données stockées dans MySQL Cluster. Les données de MySQL Cluster sont réparties entre les différents noeuds du cluster, et sont aussi doublées dans le cluster.
  3. Le troisième type de processus est les processus d’administration. Ces processus sont utilisées pour gérer la configuration du cluster.

Nous appelons ces processus de cluster les noeuds du cluster. Mettre en place la configuration du cluster implique la configuration de chaque noeud dans le cluster, et la configuration de chaque moyen de communication entre les noeuds du cluster.

MySQL Cluster est actuellement configuré avec le pré-requis que les noeuds sont homogènes en terme de puissance processeur, espace mémoire et largeur de bande. De plus, pour activer un point de configuration, il a été décidé de placer toute la configuration du cluster dans un seul fichier de configuration.

De plus, il y a un nombre arbitraire de clients connectés au cluster. Ils sont de deux types: ces clients accèdent au serveur de management, et émettent des commandes pour lancer ou arrêter correctement des noeuds, lancer ou arrêter la trace serveur (pour les versions de débogage), pour afficher la configuration courante, voir l’état des noeuds du cluster, afficher les versions et noeuds, lancer les sauvegardes, etc.

Configuration simple-multi serveurs

Nous allons configurer un cluster de deux noeuds, deux serveurs de management, deux LVS en FailOver, et deux serveurs SQL.

 

Naturellement, les machines multi-processeurs et celles aux fréquences supérieures seront plus rapides. Les besoins en RAM des processus du Cluster MySQL sont relativement raisonnables.

Sécurité

Les communications entre les noeuds du Cluster MySQL ne sont pas chiffrées ou protégées de quelque manière que ce soit. La seule solution pour protéger les transmissions à l’intérieur du Cluster MySQL est de placer le Cluster MySQL dans un réseau protégé. Si vous envisagez d’utiliser le Cluster MySQL pour une application Web, il est recommandé que le Cluster MySQL soit placé derrière un pare-feu, et non pas dans la zone démilitarisée (DMZ) ou ailleurs.

Efficacité

Configurer un Cluster MySQL sur un réseau privé ou protégé donne au Cluster MySQL l’exclusivité de la bande passante. En utilisant un switch dédié au Cluster MySQL aide à la protection contre les accès non autorisés, et il protège les noeuds des interférences causées par les autres machines sur le réseau. Pour une stabilité accrue, vous pouvez utiliser des switchs redondants et des cartes réseau doubles pour supprimer du réseau les points de panne.

Fonctionnement de cette architecture

Nous avons choisis de virtualiser l’ensemble des serveurs sur Vmware ESXi, cela nous donne une meilleure souplesse quand au changement matériel ( augmentation de RAM / Rajout de carte réseau ) .

Les clients contactent l’application hébergé sur nos serveurs, sur ces serveurs nous inscrivons les adresses des LoadBalancer . Le protocole de routage Round Robin alternera l’envoie des paquets sur les serveurs SQL définis dans sa pool .

Les serveurs SQL ne contiennent pas les données propres a la base de données, ils ne sont la que pour traiter les requètes . A leurs tours ils contactent les Noeuds qui possèdent la totalité de la base de données chargé dans leur RAM.

Les serveurs de management servent a renseigner les serveurs du cluster. C’est lui qui définit les rôles des serveurs . Et répartir la charge automatiquement entre les Noeuds .

L’ensemble des données stocké en RAM sont répliqué entre tous les nœuds, et la charge et partagé entre le nombre de serveurs nœud .

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Tutoriels 1/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger (auteur invité).

La problématique de répartition des données est un problème majeur des infrastructures de gestion de l’information. Alors que l’approche historique consiste à dimensionner un seul serveur de façon à ce qu’il absorbe toute la charge, on observe depuis plusieurs années une tendance inverse, inspirée des techniques de RAID pour les volumes de stockage, qui consiste a prendre un très grand nombre de machines a faible coût pour former un cluster de stockage.

Il existe plusieurs façons différente de mettre en place un Clusteur de Stockage avancé, que je vais vous faire découvrir. Cette série de billet va se focaliser sur la solution MySQL Cluster, la base de données distribuée de MySQL.

 J’installerais MySQL Cluster sur une distribution CentOS, qui peut également être adapter a une distribution RedHat, comme il s’agit de paquet disponible dans les dépôts ReDHat Cluster Suite.

De plus vous trouverez des machines virtuelles sous VMware avec l’ensemble de l’architecture .

Voici le sommaire des 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

On commence de ce pas par le premier article !

Introduction

Dans le domaine des systèmes de gestion de bases de données,MySQL fournit une solution élégante pour réaliser un cluster à faible coût permettant d’atteindre un niveau de disponibilité proche des 99,999% annuel.

 Un Cluster MySQL est un groupe de processus qui s’exécutent sur plusieurs serveurs MySQL, des noeuds NDBCluster, et des processus d’administration, ainsi que des processus d’accès spécialisés. Tous ces programmes fonctionnent ensemble pour former un Cluster MySQL. Lorsque les données sont stockées dans le moteur NDBCluster, les tables sont réparties sur les noeuds NDBCluster. Ces tables sont directement accessibles depuis tous les autres serveurs MySQL faisant partie du Cluster. Par conséquent, si une application met à jour une ligne, tous les autres serveurs le verront immédiatement.

Les données stockées dans le moteur de table de MySQL Cluster peuvent être dupliquées, et sont capables de gérer une indisponibilité d’un noeud sans autre impact que l’annulation des transactions qui utilisaient ces données.

Elle permet de répartir des données sur plusieurs serveurs sans avoir de point individuel de défaillance. Contrairement aux moteurs MyISAM et InnoDB généralement utilisés avec MySQL, l’exploitation effective du cluster nécessite l’utilisation du moteur NDB, qui contient plusieurs restrictions, comme l’absence d’index FULLTEXT.

 MySQL est capable, depuis la version 4.1 et grâce au moteur de stockage NDB de gérer une grappe de serveurs complète.

  • augmenter la disponibilité
  • faciliter la montée en charge
  • permettre une répartition de la charge
  • faciliter la gestion des ressources (processeur, mémoire vive, disques dur, bande passante réseau).

Sa structure repose sur la duplication données, c’est-à-dire que chaque nœud fera partie d’un groupe de nœud qui posséderont tous la totalité de la base

Un protocole implémenté dans chaque nœud s’occupe d’adresser chaque transaction aux différents nœuds concernés dans la grappe, il faut un minimum de 3 machines pour établir une solution de clustering MySQL et une machine (qui peut elle-même intégrer un serveur MySQL) qui va jouer le rôle de répartiteur de charge en redirigeant les requêtes sur les nœuds disponibles et les moins occupés.

Par rapport à un système de réplication, la redondance est améliorée : si un nœud tombe en panne, sa charge est automatiquement reprise par les autres nœuds.

L’ajout d’un nouveau nœud peut se faire sans avoir besoin de repartitionner la base, il suffit de le faire reconnaître par la grappe et le redémarrage d’un nœud peut se faire sans avoir à redémarrer la grappe.

Du point de vue de MySQL, chaque nœud fait partie d’un ensemble qui pourrait être reconnue comme une seule machine.

Pour le programmeur, il doit programmer son application pour communiquer avec le répartiteur de charge.

Cette solution s’adapte parfaitement lorsque la disponibilité et la sécurité des données est un problème critique et que l’on recherche un partitionnement technique responsable de l’écriture. Couplé a des fonctionnalités temps réel et a une API de programmation asynchrone NDB Cluster s’adresse principalement aux exigences du marché des télécommunications.

Vous pouvez vous rendre sur la page suivante pour voir la liste exhaustive des fonctions proposées dans la version communautaire (gratuite et open-source) de MySQL Cluster.

Catégories
Blog Open-source Planet-libre Systeme Web

4 hacks pour extraire des statistiques de WordPress

C’est le début de l’année et le moment des bilans concernant les statistiques de votre blog. Voici donc un petit billet sur quelques hacks MySQL permettant d’obtenir des statistiques à diffuser vers vos lecteurs ou à garder au chaud !

Avant tout il faut disposer d’un accès à votre base de donnée MySQL (soit via une interface de type phpMySQL, soit directement via une ligne de commande mysql). Pour avoir vos paramètres de connexion à votre BD WordPress il suffit de regarder le fichier wp-config.php à la racine de votre répertoire Web.

Voici l’architecture des tables de votre BD WordPress. Je ne suis plus trop un expert en requêtes MySQL (les cours datent de plus de 10 ans maintenant ;)) alors si vous voyez des améliorations dans les requêtes ci-dessous je suis preneur de commentaires.

Nombre de billets publiés en 2010

Cette première requête donne le nombre de billets publiés (status= »publish ») sur l’année 2010 (c’est à dire entre le 1er janvier et le 31 décembre 2010).

mysql> SELECT COUNT(*) FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’;

+———-+

| COUNT(*) |

+———-+

| 161 |

+———-+

1 row in set (0.00 sec)

Nombre de commentaires pour les billets publiés en 2010

Une requête un peu plus complexe qui somme (SUM) le nombre de commentaires pour les billets 2010.

mysql> SELECT SUM(comment_count) FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ GROUP BY post_status;

+——————–+

| SUM(comment_count) |

+——————–+

| 1314 |

+——————–+

1 row in set (0.01 sec)

Liste des 10 billets les plus commentés publiés en 2010

On continu pas le classement (TOP 10) des nouveaux billets les plus commentés.

mysql> SELECT post_title,comment_count FROM wp_posts WHERE post_status= »publish » AND post_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ ORDER BY comment_count DESC LIMIT 0,10;

+——————————————————————-+—————+

| post_title | comment_count |

+——————————————————————-+—————+

| Configurer VPNTunnel sous Ubuntu | 58 |

| Installation et test de Flumotion 0.8 | 46 |

| Script d’installation automatique de Nagios | 42 |

| Spideroak, un sérieux concurrent à Dropbox | 40 |

| Utiliser Nmap pour générer vos fichiers de configuration Nagios | 38 |

| Installation d’un serveur OpenVPN sous Debian/Ubuntu | 36 |

| 12 étapes pour optimiser les performances de son blog WordPress | 35 |

| Le blog de Nicolargo a son application IOS | 35 |

| Tu fais quoi après l’installation de Firefox ? | 26 |

| MyScreenCast, comment faire du screencast avec GStreamer | 26 |

+——————————————————————-+—————+

10 rows in set (0.01 sec)

Top 10 des lecteurs ayant le plus posté de commentaires sur le blog en 2010

Enfin une requête un peu plus complexe qui donne le classement des plus gros « commentateurs » sur le blog.

mysql> SELECT comment_author,COUNT(comment_count) AS F01 FROM wp_comments,wp_posts WHERE comment_approved=1 AND comment_post_ID=ID AND comment_date BETWEEN ‘2010-01-01’ AND ‘2010-12-31’ GROUP BY comment_author ORDER BY F01 DESC LIMIT 0,10;+—————-+—–+

| comment_author | F01 |

+—————-+—–+

| NicoLargo | 315 |

| Albert | 22 |

| Pierre-Yves | 18 |

| ninja21a | 18 |

| Mr Xhark | 15 |

| Sylvain | 14 |

| Christophe | 12 |

| floppy84 | 12 |

| Nico | 11 |

| Guillaume | 10 |

+—————-+—–+

10 rows in set (0.07 sec)

Si vous avez d’autres requêtes MySQL dans votre besace et bien faites tourner !

Catégories
Blog Open-source Planet-libre

Architecture pour un blog optimisé

Hier, j’ai passé une grande partie de ma journée dans les aéroports, j’en ai profité pour résumer dans un schéma quelques techniques d’optimisations que l’on peut actuellement mettre en place pour booster son blog.

Depuis que Saint Google prend en compte le temps de chargement des pages dans ses algorithmes, le sujet est devenu très à la mode. Antoine, Jérôme et moi même avont abordé récemment  le sujet dans nos blogs respectifs.

J’aimerai que l’on échange sur cette architecture afin que je puisse faire évoluer ce schéma.

Vous pouvez également récupérer le schéma au format Dia.

Catégories
Blog Open-source Systeme Web

12 étapes pour optimiser les performances de son blog WordPress

Lorsque l’on choisi d’héberger son blog WordPress (sur un serveur dédié ou virtuel), la problématique des performances vient assez vite sur le tapis. En effet, l’optimisation du blog permet non seulement de réduire le temps de chargement des pages (et donc d’être bien vu par seigneur gOOgle) mais également de dimensionner au plus juste son serveur: gain de temps d’un coté, gain d’argent de l’autre.

Nous allons donc dans ce billet parcourir une liste non exhaustive de techniques d’optimisations:

  • ETAPE 1: Hardware
  • ETAPE 2: Noyau Linux
  • ETAPE 3: Mise à jour du système d’exploitation
  • ETAPE 4: MemCached
  • ETAPE 5: Les modules Apache
  • ETAPE 6: Configuration d’Apache
  • ETAPE 7: XCache (PHP)
  • ETAPE 8: MySQL
  • ETAPE 9: WP-DBManager
  • ETAPE 10: W3 Total Cache
  • ETAPE 11: Thème WordPress
  • ETAPE 12: Tester/Surveiller

Les commentaires seront bien sur là pour nous faire partager vos solutions !

Le hardware

ETAPE 1) C’est un peu le serpent qui se mort la queue… En effet il est assez difficile de dimensionner le hardware d’un serveur sans avoir fait les optimisations est sans connaitre précisément le trafic du blog (surtout vrai pour les nouveaux blog).

C’est en partie pour ces raisons qui j’ai choisi un serveur VPS de chez Gandi. En effet il est possible d’augmenter ou de diminuer les « parts » affectées à son serveur de manière dynamique (une « part » correspond à une ressource CPU, mémoire et disque).

J’ai actuellement « 3 parts » sur le serveur du Blog de Nicolargo mais je m’en sers également pour d’autres besoins (je pense que pour ce blog, un serveur avec « 2 parts » suffirait largement). Pour une première expérience dans le monde du blogging, un serveur « 1 part » devrait convenir (environ 12€ HT par mois).

Je n’entrerai pas dans les discussions sur le coups relativement élevé de cette solution par rapport à un serveur dédié comme l’offre Dedibox de Online.net.

Le système d’exploitation

L’optimisation du système d’exploitation dépend bien sûr de la distribution Linux utilisée. Lors de la création de mon serveur j’ai choisi d’utiliser Ubuntu Server 8.04 que j’ai fait évolué en 9.04. Pourquoi cette distribution GNU/Linux ? Tout simplement car c’est celle que je connais le plus…

ETAPE 2 ) On commence par optimiser le noyau Linux . Je passe rapidement sur les explications. Il existe de nombreux article sur le net détaillant ces configurations. La configuration donnée est celle de mon serveur VPS (3 parts, 1 Go de RAM), elle doit être adaptée à votre configuration hardware.

Il faut éditer/modifier le fichier /etc/sysctl.conf (disponible sur GitHub):



Puis on applique:


sudo sysctl -p


Sources: 



ETAPE 3) La première chose à faire quand on administre un serveur est bien entendu de le maintenir à jour au niveau des logiciels systèmes et applicatifs. Pour cela je m’aide d’un petit logiciel nommé cron-apt. Ce dernier permet de m’avertir par mail quand une mise à jour est disponible (par exemple une nouvelle version d’Apache ou une librairie PHP). En plus de corriger des failles de sécurités, les mises à jours permettent souvent d’obtenir de meilleures performances (que ce soit en rapidité ou en consommation de ressources).


L’installation est des plus simple:


sudo aptitude install cron-apt


Configuration en éditant le fichier /etc/cron-apt/config, notamment les lignes suivantes:


MAILTO= »nom@domaine.com »


MAILON= »always »


Un mail sera automatiquement envoyé à l’adresse nom@domaine.com, tout les matins à 4:00. Voici un exemple:




On peut voir qu’une mise à jour est disponible. Il ne reste plus qu’a se connecter en SSH sur le serveur et faire un:


sudo aptitude safe-upgrade


Il est possible de faire automatiquement les mises à jour mais je pense cela risqué si quelque chose se passe mal…


On critique souvent les serveurs VPS pour leurs faibles performances disque. Bien que je trouve celle des VPS Gandi plutôt acceptable (environ 6 Mo/s pour l’écriture et 24 Mo/s pour la lecture de petits fichiers type script PHP), il est intéressant de mettre en place un cache mémoire sur notre serveur. Ainsi, les applications compatibles pourront lire et écrire les données en RAM et non plus sur disque.


ETAPE 4) Nous allons donc installer MemCached, un cache mémoire libre.  On commence par installer le cache ainsi que la librairie Perl associée (qui sera utilisée par WordPress):


sudo aptitude install libcache-memcached-perl php5-memcache memcached


Par défaut, le cache écoute sur l’adresse 127.0.0.1 et sur le port TCP/11211. La taille du cache mémoire est de 64 Mo. J’ai gardé ces paramètres pour mon utilisation.


On peut obtenir des statistiques sur l’utilisation de MemCached en utilisant la commande:


# echo « stats » | nc localhost 11211


STAT pid 2806


STAT uptime 698465


STAT time 1283351366


STAT version 1.2.2


STAT pointer_size 32


STAT rusage_user 31.829989


STAT rusage_system 123.891742


STAT curr_items 12834


STAT total_items 1394993


STAT bytes 48830599


STAT curr_connections 11


STAT total_connections 16845


STAT connection_structures 31


STAT cmd_get 4012823


STAT cmd_set 1394993


STAT get_hits 2547543


STAT get_misses 1465280


STAT evictions 5694


STAT bytes_read 10561103955


STAT bytes_written 37908972470


STAT limit_maxbytes 67108864


STAT threads 1


END


Apache & PHP


On continue ensuite avec l’optimisation du serveur Apache (version 2.xx au moment de l’écriture de ce billet).


ETAPE 5) Apache se base sur un système de modules pour ajouter de nouvelles fonctions à votre serveur Web. Sous Ubuntu Server, la liste des modules actifs se trouvent dans le répertoire /etc/apache2/mods-enabled. Un petit ls dans ce répertoire vous donne donc la liste. L’optimisation consiste à supprimer les modules non utilisés. Je vous conseille la lecture de ce billet qui donne la liste des modules nécessaires au fonctionnement de WordPress. Attention, si votre serveur héberge d’autres sites Web que votre blog, il faut vérifier de ne pas supprimer un module utile…


Voici la liste de mes modules sur mon serveur:


alias.conf autoindex.conf dir.conf negotiation.load


alias.load autoindex.load dir.load php5.conf


auth_basic.load cgi.load env.load php5.load


authn_file.load dav.load expires.load rewrite.load


authz_default.load dav_svn.conf headers.load setenvif.conf


authz_groupfile.load dav_svn.load mime.conf setenvif.load


authz_host.load deflate.conf mime.load status.conf


authz_user.load deflate.load negotiation.conf status.load


ETAPE 6) On configure ensuite la manière dont les processus Apache sont lancés et gérés en mémoire et d’autres paramètres. Il faut éditer la section suivante dans le fichier /etc/apache2/apache2.conf (ou httpd.conf sur d’autre distribution GNU/Linux). Pour une description des paramètres, merci de lire le billet suivant:


<IfModule mpm_prefork_module>


StartServers 5


MinSpareServers 5


MaxSpareServers 10


MaxClients 40


MaxRequestsPerChild 2000


</IfModule>


# KeepAlive: Whether or not to allow persistent connections


KeepAlive On


# MaxKeepAliveRequests: The maximum number of requests to allow


MaxKeepAliveRequests 200


# KeepAliveTimeout: Number of seconds to wait for the next request


KeepAliveTimeout 5


# Timeout: The number of seconds before receives and sends time out.


Timeout 50


J’ai également modifier le fichier /etc/apache2/conf.d/optimization pour gagner quelques précieux  points aux tests Yslow et Page Speed:


Header unset ETag


FileETag None


On applique la configuration en relançant Apche:


sudo /etc/init.d/apache2 restart


Sources:



ETAPE 7) WordPress se base sur le langage PHP qui est connu pour être flexible mais pas très performant. C’est pour cela qu’il est nécessaire d’installer un cache PHP sur votre serveur Web WordPress. En gros, il permet de mettre en cache le code PHP déjà compilé. J’utilise personnellement XCache.


L’installation est simple:


sudo aptitude install php5-xcache


On configure ensuite le fichier/etc/php5/conf.d/xcache.ini (à adapter à votre configuration):


xcache.size = 64M


On relance le serveur Web:


sudo /etc/init.d/apache2 restart


Source:



MySQL


Souvent décriée, MySQL reste à l’heure actuelle la base de donnée officielle supportée par le moteur de blogging WordPress. Nous allons donc étudier quelques techniques d’optimisation.


ETAPE 8) On commence par éditer le fichier de configuration /etc/mysql/my.cnf pour ajuster la taille des caches (encore une fois les valeurs sont à adapter en fonction de votre audience/configuration):


query_cache_type = 1


query_cache_limit = 2M


query_cache_size = 32M


ETAPE 9) On installe ensuite le plugin WordPress WP-DBManager. Ce dernier permet de maintenir une base de données optimisée à travers le temps. En plus des fonctions de sauvegarde (manuelle ou automatique) et de restauration de votre base de données WordPress, ce plugin permet de d’optimiser et réparer cette même base.


Source:



WordPress


ETAPE 10) L’installation standard de WordPress (la fameuse installation en 5 minutes) ne tient pas en compte de l’optimisation. Nous allons voir comment configurer l’utilisation parallèle de XCache et Memcached (préalablement installé dans les étapes n°3 et n°5). Pour cela nous allons utiliser l’indispensable plugin W3 Total Cache.


Après l’installation du plugin, il faut se rendre dans le menu Performance > General setting de la page d’administration de WordPress puis cliquer sur le bouton Compatibility check pour vérifier que XCache et Memcached sont bien détectés:


Opcode cache: XCache


Memcache extension: OK


Ensuite on configure WordPress pour utiliser Memcached en activant toutes le fonctions de cache (CDN mis à part) et en utilisant le démon Memcached. Exemple de configuration pour les pages:




Dans le menu Page cache settings j’active toutes les fonctions sauf pour les pages 404:




Dans le menu suivant (Minify settings), j’active toutes les fonctions. Cela à pour but d’optimiser les pages, css et js avant d’être envoyés vers les lecteurs (attention, certains JS n’aiment pas beaucoup ces optimisations, à tester donc…).


Enfin, dans le menu Browser Cache setting, j’active toutes les fonctions et les expires header lifetime à:


    

  • 3600 secondes pour JS / CSS
    • 

  • 3600 secondes pour le HTML
    • 

  • 2592000 secondes pour les autres fichiers
    • 



A l’heure actuelle, le trafic généré par mon blog ne nécessite pas l’utilisation de caches réseau répartis (CDN). Mais c’est une optimisation à prendre en compte pour les « gros » sites.


Sources:



ETAPE 11) Rien ne sert d’avoir un kernel Linux, un serveur Web, un moteur PHP et un WordPress optimisés si le thème de votre blog est mal développé. Il est important de tester ce thème et notamment les plugins utilisées. Ces derniers utilisent souvent des JavaScripts qui peuvent pénaliser fortement le temps de chargement de vos pages. Rien de tel que des mesures de type YSlow et Page Speed pour mettre en évidence ce qui ne va pas.


Sources:



Tester/surveiller son serveur


ETAPE 12) Pour tester les optimisations mise en place, j’utilise l’outil  GTMetrix qui donne les valeurs YSlow et Page Speed (avec un archivage vous permettant de voir l’évolution des performances de votre blog à travers le temps).


De manière locale et surtout pour valider la configuration de votre serveur Web (Apache dans ce document), vous pouvez utiliser la commande suivante:


ab -t30 -c5 http://blog.mondomaine.com/


La ligne intéressante donnant le nombre maximal de requête par seconde que votre blog peut supporter est la suivante:


Requests per second: 158.19 [#/sec] (mean)


A un niveau plus bas, la commande Linux netstat permet de donner pas mal d’informations sur l’état des sockets:


netstat -tan | grep ‘:80 ‘ | awk ‘{print $6}’ | sort | uniq -c


Enfin, pour surveiller l’activité de MySQL, j’utilise la commande MySqlReport.


Autres optimisations possibles


D’autres optimisations sont possibles, pour vous donner un exemple, je suis tombé l’autre jour sur le première article d’une série en cours sur le blog d’Antoine Benkemoun qui propose d’utiliser Squid pour booster les performances de votre site. C’est une technique très intéressante mais qui nécessite, pour être vraiment efficace, l’utilisation deux deux machines différentes. Une servant de reverse proxy-cache et une autre hébergeant votre blog.


Il est aussi possible de se passer du serveur Web Apache (il est vrai un peu lourd à administrer) pour se pencher vers des serveurs plus légers comme NGinx ou Cherookee. Update: Ou bien d’utiliser NGinx comme serveur Web pour les pages statiques et Apache pour les pages dynamiques (voir exemple de configuration ici). L’avantage d’une telle configuration est un gain non négligeable en terme de consommation mémoire.


Il existe un nombre incalculable d’optimisations possibles, j’espère d’ailleurs en découvrir de nouvelles dans vos commentaires…


		


	


	

		
		


			

		


		
	


	






	



	


		
			

				
					Catégories				
				

					Blog Web				

			


			
Apache, MySQL et PHP sur MacOS X

		


			

		


		
	





	


		


			
Je souhaite faire évoluer mon blog, notamment au niveau du thème. Pour cela, j’hésite encore entre créer mon propre thème (en suivant par exemple le très bon tutorial de Fran6) ou bien en modifiant un thème existant à mes besoins.


Dans les deux cas, j’ai besoin d’un serveur de développement pour installer WordPress avec le nouveau thème. Plusieurs solutions s’offrait à moi:


    

  • créer une deuxième arborescence sur mon serveur avec une nouvelle base de donnée WordPress.
    • 

  • utiliser un serveur gratuit (commme mon hébergement chez Free).
    • 

  • héberger un serveur directement sur mon PC.
    • 



J’ai donc choisi ce dernier choix pour des raisons de performances et aussi pour me laisser la possibilité de travailler sur ce projet même sans connection internet (si si ca existe encore des zones blanches).


Voici donc un petit tutorial pour installer un serveur de developpement WordPress sous un Mac OS X.


Pour cela, j’ai installé MAMP sur mon Macbook. En deux cliques de souris on installe Apache (avec support PHP 4 ou 5) et MySQL (avec phpMyAdmin).


Lors de l’installation, il faut choisir la version standard et pas la pro:




En allant dans le répertoire d’installation, on a même droit (en cadeau bonux) à un petit Widget pour controler le status des services.




Par la suite, il reste à installer WordPress dans le sous répertoire htdocs (/Applications/MAMP/htdocs) et à configurer le fichier wp-config.php:


...

define('DB_NAME', 'wordpress');    // Le nom de la base de donnees

define('DB_USER', 'root');     // Votre identifiant MySQL

define('DB_PASSWORD', 'root'); // ...et votre mot de passe

define('DB_HOST', 'localhost:8889');    // Dans la plupart des cas, vous n'aurez pas a modifier cette ligne

...


On accéde au serveur par l’adresse: http://localhost:8888/wordpress/

L’administration se fait par l’adresse: http://localhost:8888/wordpress/wp-admin/


Nous voila donc avec un beau serveur de développement pour tester les nouveaux thèmes et plugins.

A bientôt pour la suite des aventures de Nicolargo à la découverte du thème parfait.