replication

Replication mysql – Configuration maitre-esclave

Configuration de la réplication avec mysql, dans un modèle maître esclave.

Voilà un petit post qui va expliquer en suivant en gros la documentation de mysql (http://dev.mysql.com/doc/refman/5.0/fr/replication-howto.html), comment mettre en place la réplication, de manière pragmatique et fonctionnelle.

Comme toujours, avant toute opération, assurez vous d’avoir une copie de sauvegarde de l’ensemble des éléments modifiés avant d’appliquer quoi que ça soit, afin de pouvoir revenir en arrière en cas de soucis (fichiers de configuration, données etc.).

J’ai pour cette opération un serveur sous Fedora 8 (qui date mais qui fait le job) équipé de mysql-server 5.0.45 en production et standalone (qui travaille tout seul comme un grand) jusqu’ici; et, un serveur sous Fedora 13 (utilisé pour du stockage uniquement jusqu’ici) équipé de mysql-server 5.1.56 fraichement installé avec un petit :
[bash]yum install mysql-server
chkconfig –level 345 mysqld on[/bash]

L’idée étant de mettre en place la réplication du premier qui deviendra « master » (maître), sur le second, qui deviendra « slave » (esclave). A mon sens l’utilité de la réplication avec MySQL est principalement valable pour 2 points :
– Avoir une copie des données, lisible en production
– Répartir la charge sur plusieurs serveurs (un serveur exclusivement pour les requêtes en écriture – le maitre, un autre dédié aux requêtes en lecture – le ou les esclave(s)).

Attention cependant, la réplication MySQL ne dispense pas de mettre en place une stratégie de sauvegarde ! Car, par exemple, un effacement accidentel de données sur le maître entraîne la modification quasi immédiate sur les machines répliquées ! Dans une telle situation, seule une sauvegarde « traditionnelle » (façon mysql dump) vous permettra de récupérer vos données.

Un article évoquant plusieurs configurations et usages de la réplication MySQL est disponible sur cette page http://bertrand.letous.fr/replication-mysql/ qui évoque notamment la réplication RING (multi-master replication) permettant la réplication combinée à l’écriture sur les esclaves propageant la modification en chaine et ainsi permettant d’ajouter autant de serveurs que nécessaire pour absorber une montée en charge. Une documentation détaillée est disponible ici : http://onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html

Revenons donc à nos moutons, avec pour objectif, basculer l’installation actuelle d’un simple serveur MySQL tout seul, en maître avec l’ajout d’un esclave répliqué.

=> Serveur maitre :

Sur le serveur maître, nous allons créer un compte utilisateur dédié à la réplication. Soit en passant par une interface d’administration style Webmin, soit en passant par la ligne de commande mysql (requête).
Je vais donc créer un utilisateur « replication » sur mon master, avec un mot de passe, et autoriser pour le host « ip_du_slave » (sur vpn pour mon cas) avec pour permission « Slave replication ».

Ce qui donne donc en commande SQL sur le maître :
[bash]mysql> GRANT REPLICATION SLAVE ON *.* TO replication@’ip_du_slave’ IDENTIFIED BY ‘<mot de passe>’;[/bash]

Si vous n’avez jamais utilisé la réplication, il y a des chances que votre serveur mysql n’ait pas de log binaire activé !
Afin de s’assurer de ceci, vous devez éditer votre fichier my.cnf (généralement dans /etc/my.cnf) et vous assurer qu’il contient dans la section « mysqld » les lignes suivantes :
[bash]log-bin
server-id=1[/bash]

La valeur de serveur-id doit être un entier positif entre 1 et 2^32 − 1, mais doit être unique pour chaque serveur (maitre ou esclave).
Si les valeurs ne sont pas présentes, ajoutez les, puis relancez votre serveur mysql.

On va vérifier que la modification est bien active en se connectant en local en root au serveur mysql :
[bash]mysql -u root -p[/bash]
Puis on contrôle qu’il y ait bien un log binaire (après avoir saisi votre mot de passe root mysql) :
[bash]show master status;
+———————+————+———————+————————–+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+———————+————+———————+————————–+
| mysql-bin.000001 | 729 | | |
+———————+————+———————+————————–+
1 row in set (0.00 sec)
[/bash]

Nous avons maintenant un serveur MySQL avec un utilisateur qui détient les privilèges de réplication, et, un fichier de log binaire qui va contenir la chaine des transactions/modifications réalisées sur les bases.

Afin de lancer la réplication, nous allons devoir (1) verrouiller la base (READ LOCK), (2) noter le « status » du fichier binaire afin d’indiquer à l’esclave d’où il repart quand on le lancera (comme vu à l’instant), (3) arrêter mysql sans déverrouiller et faire un backup afin de pouvoir transférer les données en l’état sur l’esclave, (4) et relancer mysql et déverrouiller (unlock tables), DANS CET ORDRE PRÉCIS.

L’impact pour votre système actuel va être un blocage des écritures pendant que vous notez le « status » des transactions et réalisez le backup.

En avant donc :

(1)
On se connecte au serveur (maitre) en local et on bloque les transactions :
[bash]mysql -u root -p[/bash]
[bash]mysql> FLUSH TABLES WITH READ LOCK;[/bash]
ok, les transactions sont maintenant bloquées.

(3)
On arrête mysql bloqué et on sauvegarde les fichiers de données (dans /var/lib/mysql chez moi):
[bash]mysqladmin -uroot -p shutdown
cd /var/lib
tar -cvzf mysql_full.tgz mysql[/bash]

Le backup est fait avec les données non modifiées depuis que l’on a noté le master « status ».

(4)
On va maintenant relancer mysql et débloquer les transactions :
[bash]/etc/rc.d/init.d/mysqld start
mysql -u root -p[/bash]
Puis on débloque :
[bash]mysql> UNLOCK TABLES;[/bash]

Nous avons maintenant nos bases dans un fichier de sauvegarde et l’état des transactions à ce moment là. C’est fini pour le serveur maître MySQL qui est opérationnel comme avant.

Vous devriez voir des informations relatives à l’activation de log-bin dans les logs de mysqld (ici /var/log/mysqld.log).

Note : Il faut autoriser l’accès au port 3306 depuis l’esclave dans votre firewall si vous en avez un actif sur le maître, sinon l’esclave ne pourra pas communiquer avec le maître et la réplication ne pourra s’effectuer.

################################################################
=> Serveur Esclave :

On arrête le serveur mysql (vierge jusqu’ici car tout fraîchement installé).
[bash]/etc/rc.d/init.d/mysqld stop[/bash]

Il faut configurer le serveur mysql en éditant le fichier /etc/my.cnf comme pour le maître en ajoutant le server-id dans la configuration (c’est le numéro unique du serveur, qui doit être différent du serveur maître) et les informations permettant la synchronisation :

[bash][mysqld]
server-id=2
master-host = ip_du_master
master-user = utilisateur_replication
master-password = mot_de_passe_replication
master-port = 3306
[/bash]

On va ensuite replacer les données sur l’esclave (attention aux droits sur les fichiers, généralement tout appartient à l’utilisateur « mysql »), ceci en copiant l’archive mysql_full.tgz créée sur le serveur maître, dans le serveur esclave.
Je me positionne dans /var/lib (qui contient le dossier mysql également), qui appartient à l’utilisateur mysql et je décompresse l’archive :
[bash]tar xvzf mysql_full.tgz[/bash]
Ceci va sauvagement écraser les fichiers en place au profit de la copie conforme du maître.

On peut maintenant relancer le serveur mysql :
[bash]/etc/rc.d/init.d/mysqld start[/bash]

Puis on active la synchronisation (qui va également rattraper les modifications depuis la reprise de l’activité du maître) :
Connection en root à mysql en local sur l’esclave :
[bash]mysql -u root -p[/bash]

On arrête le (service) slave :
[bash]mysql> STOP SLAVE;[/bash]

On applique les modifications :
[bash]mysql> CHANGE MASTER TO
-> MASTER_HOST='<master host name ou ip>’,
-> MASTER_USER='<replication user name>’,
-> MASTER_PASSWORD='<replication password>’,
-> MASTER_LOG_FILE='<recorded log file name>’,
-> MASTER_LOG_POS=<recorded log offset>;[/bash]
Note : ce sont les informations définies plus haut, saisie entre apostrophes, sauf pour la dernière valeur numérique saisie directement (et sans les < >).

On lance enfin le processus esclave qui démarre effectivement la synchronisation :
[bash]mysql> START SLAVE;[/bash]

Dans les log de /var/log/mysqld.log vous devriez voir quelque-chose du genre :
« Slave SQL thread initialized, starting replication in log ‘mysql-bin.000001’ at position xxx… etc. »
« Slave I/O thread: connected to master ‘replication@ip_du_maitre:3306’,replication started in log ‘mysql-bin.xxx…etc. »

Maintenant consultez les données dans les tables du serveur esclave, toutes les modifications apportées au maître doivent être automatiquement appliquées à l’esclave.

Vous pouvez aussi consulter l’état sur l’esclave par exemple en vous connectant au serveur :
[bash]mysql -u root -p[/bash]
Puis en tapant la commande suivante :
[bash]mysql> SHOW SLAVE STATUS\G;[/bash]
et celle ci pour voir l’etat des processus :
[bash]mysql> SHOW PROCESSLIST;[/bash]

Maintenant, si vous arrêtez le serveur mysql esclave, et que vous le relancez, il reprendra la synchronisation là où il s’est arrêté ! :D cool.

################################################################
=> En cas de plantage (perte des données sur une des machines) :
– Si le maitre plante :
On verrouille l’esclave (FLUSH TABLES WITH READ LOCK;), on « dump » (copie) les données de l’esclave sur le maître, et on relance la synchronisation après avoir relancé le maître.

-Si l’esclave plante :
On recommence la mise en place à partir des étapes 1,2,3,4 dans la section « maître » de ce post, sur le maître, comme ci on réalisait à nouveau cette mise en place.

=> Vous pouvez ajouter autant d’esclaves que vous le voulez, pour répliquer autant de fois que nécessaire l’infrastructure (et donc augmenter la puissance de l’ensemble en répartissant la charge sur plusieurs serveurs).

Autres ressources pertinentes :
http://www.system-linux.eu/index.php?post/2009/09/10/R%C3%A9plication-Mysql
http://km.azerttyu.net/Replication-Mysql-ou-comment.html
http://www.howtoforge.com/mysql_database_replication

Tags: cluster, esclave, maitre, master, mysql, replication, replications, slave, synchronisation

mercredi, mai 4th, 2011 GNU - Linux, Reseau, Technologie Un commentaire

Installation DRBD sur Centos 5.5 ou redhat

Voici un nouveau post « mémo » pour l’installation de DRBD sur Centos 5.5 ou Redhat.

DRBD est utilisé sur les clusters de haute disponibilité afin de maintenir des volumes synchronisés entre plusieurs machines, et ainsi de garantir une reprise transparente en cas cas de panne d’un système par exemple. DRBD exploite le réseau TCP/IP pour effectuer la synchronisation des données. Il est souvent qualifié de système de RAID logiciel en réseau, agissant au niveau bloc des périphériques de stockages, et étant de faire totalement transparent pour le système.

Installation DRBD Centos 5.5 :
On télépharge la dernière version (au moment de la rédaction du post), on décompresse, installe les dépendances et on compile (idéalement dans /usr/local/src) :
[bash]wget http://oss.linbit.com/drbd/8.3/drbd-8.3.10.tar.gz
tar xvzf drbd-8.3.10.tar.gz
cd drbd-8.3.10
yum install make gcc glibc-devel flex kernel-devel[/bash]
Compilation des outils :
[bash]./configure
make
make install[/bash]

Compilation du pilote (module) pour le noyau (kernel) pour un noyau modulaire, évidemment ! :
[bash]cd drbd
make
make install[/bash]

Les pilotes (modules) sont installé dans le dossier /lib/module/`uname -r`/kernel/drivers/block/.

On va également forcer le chargement du module automatiquement au reboot de la machine :
[bash]echo modprobe drbd>>/etc/rc.modules
chmod +x /etc/rc.modules[/bash]

Note : Si vous mettez à jour votre machine, et que le noyau est changé, il faudra recompiler les modules comme précédemment.

Note 2 : on peut aussi générer un RPM comme indiqué ici : http://www.drbd.org/users-guide-emb/s-build-rpm.html mais dans tous les cas, en cas de nouveau noyau, il faut les recréer, donc l’intégration en RPM est recommandée (pour faciliter la gestion des outils installés) mais pas obligatoire sur un point de vue fonctionnel.

Évidemment il faut réaliser cette étape sur tous les noeuds du futur cluster!! (Donc sur toutes les machines qui vont gérer le volume, dans mon cas, 2 machines).

Pour poursuivre, nous allons utiliser 2 éléments de stockage (disques / partitions / volumes accessibles par dev-mapper => volgroup etc.) de tailles strictement identiques. Dans le cas présent je pratique l’installation en environnement de test, en utilisant virtualbox. Je vais donc ajouter sur mes deux virtualbox un disque dur virtuel de taille identique (5Go) avec une seule partition utilisant 100% du disque (qui seront utilisés ici an tant que partitions/périphériques directement, soit /dev/sdb1).

Il est noté sur le site du projet que, bien que ça soit techniquement possible, il est décommandé d’utiliser des volumes basés sur des fichiers montés en boucle interne (loop device) ref : http://www.drbd.org/users-guide-emb/ch-configure.html.

On va ensuite préparer la partie réseau. Il est recommandé pour DRBD d’utiliser la ressource la plus performante possible bien entendu. Dans mon cas, je vais effectuer la réplication par un VPN afin de pouvoir tenter l’opération dans plusieurs configurations. Dabord en local puis au travers d’un Wan. Les ports utilisés commencent au 7788 jusqu’au 7799, de plus, DRBD ne pourra pas utiliser plus d’une interface réseau (limité à une seule connexion TCP active).

Nous allons devoir sur notre Centos 5.5 ouvrir les ports réseaux en TCP de 7788 à 7799 au niveau d’iptables.
Pour ce faire, on va ouvrir le fichier /etc/sysconfig/iptables et ajouter les lignes suivantes à la cinquième ligne en partant du la dernière (qui contient le COMMIT, l’ordre des règles a une importance). On notera que les instructions IPTABLES dans centos utilisent une syntaxe propre à Centos/redhat/fedora pour les règles d’entrées :

[bash]#Autorisation port 7788 à 7799 pour le proof of concept DRBD en entrée sur la carte tap0 utilisée par le VPN
-A RH-Firewall-1-INPUT -i tap0 -p tcp -m state -m tcp –dport 7788:7799 –state NEW -j ACCEPT[/bash]

Puis on relance iptables pour appliquer les modifications /etc/rc.d/init.d/iptables restart

On va maintenant procéder à la configuration de DRBD. Comme on a installé DRBD depuis les sources, les fichiers par défaut (skel) ne sont pas présents dans /etc/ mais dans /usr/locat/etc.

On va donc les copier et créer le lien qui permettra à drbd de trouver ses petits.

[bash]cp -R /usr/local/etc/* /etc/[/bash]

On renomme le dossier pour pouvoir créer le lien symbolique :
[bash]mv /usr/local/etc /usr/local/etc.old[/bash]

On crée le lien qui va permettre au tout de trouver les fichiers de configuration :
[bash]ln -s /etc /usr/local/[/bash]

Par convention c’est le fichier /etc/drbd.d/global_common.conf qui contiends les sections « global » et « common » tandis que les « resource » seront définie dans des fichier « .res » individuels (un pour chaque resource) dans le dossier /etc/drbd.d.

Référence: http://www.drbd.org/users-guide-emb/s-configure-resource.html

La configuration « de base » dans le fichier /etc/drbd.d/global_common.conf contient déjà les éléments de base comme suit :
[bash]global {
usage-count yes;
}
common {
protocol C;
}[/bash]

Puis nous allons créer le fichier /etc/drbd.d/r0.res qui va définir la ressource DRBD que nous utiliserons dans cet exemple :
[bash]resource r0 {
net {
allow-two-primaries;
}
startup {
become-primary-on both;
}
on pchp {
device /dev/drbd1;
disk /dev/sdb1;
address 10.21.3.16:7789;
meta-disk internal;
}
on pcmsi {
device /dev/drbd1;
disk /dev/hdb1;
address 10.21.3.17:7789;
meta-disk internal;
}
}[/bash]

Note : ici on nomme la ressource r0, pchp est mon premier pc (doit correspondre au hostname de votre machine, et doit être un nom reconnu par l’une et l’autre des machine !), pcmsi le second, avec leur IP respectives, ainsi que le « disk » utilisé sur chacune des machines (rappel : ils doivent être de taille strictement identique, mais ça peut être n’importe quel périphérique, attention à bien placer les informations dans le fichier de configuration sur les 2 machines).
Note 2 : info sur meta-disk ici http://www.drbd.org/users-guide-emb/ch-internals.html#s-internal-meta-data
Note 3 : Cette configuration autorise les 2 noeuds à être primaires et demande au premier initié de devenir primaire par défaut.

Nous allons maintenant activer la ressource qui va exploiter les partitions (celle de 5Go créées au début de la manipulation, on peut utiliser le disque/périphérique entier aussi /dev/sdb et /dev/hdb dans mon cas) définies dans le fichier de configuration.

Les étapes suivantes sont à réaliser sur tous les noeuds (machines avec DRBD) concernés par la « resource ».

On crée donc les metadata du périphérique (resource = r0 pour l’exemple) :
[bash]drbdadm create-md resource[/bash]

ce qui donne :
[bash]Writing meta data…
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.[/bash]

On attache la resource au périphérique (resource est à remplacer par r0 comme pour la commande d’avant):
[bash]drbdadm attach resource[/bash]

Si vous avez une erreur relative au module, comme indiqué il faudra charger le module (pilote dans le noyau) :
[bash]modprobe drbd[/bash]
et recommencer la commande (il faudra penser à ajouter le module dans la listes des modules chargés par défaut : http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-kernel-modules-persistant.html).

On définit les paramètres de synchronisation (remplacer resource par r0):
[bash]drbdadm syncer resource[/bash]

On connecte les noeuds (remplacer resource par r0):
[bash]drbdadm connect resource[/bash]

Note : les étapes drbdadm attach, drbdadm syncer, et drbdadm connect peuvent être remplacée par l’unique commande : « drbdadm up » ou « drbdadm down » pour deconnecter

Si tout s’est bien passé, les informations sur le statut de la connexion doivent s’afficher en interrogeant /proc/drbd :
[bash]cat /proc/drbd[/bash]
ceci doit renvoyer une information de ce type :
[bash]version: 8.3.10 (api:88/proto:86-96)
GIT-hash: 5c0b0469666682443d4785d90a2c603378f9017b build by root@localhost.localdomain, 2011-03-08 21:09:46

1: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r—–
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:5236960[/bash]

L’information importante est ici le « Connected ». Si ça n’est pas le cas, vérifiez que vos hôtes communiquent bien et que les hostnames utilisés pour définir la « resource » au niveau de la valeur « on » sont des noms valident et qui communiquent.

Nous allons maintenant synchroniser les données d’un hôte sur l’autre. Dans le cas présent, pas de préférence, les 2 unités sont vides, cependant, si vous devez reconnecter un noeud qui n’a plus de donnée, la commande est à lancer sur celui qui contient les données !!! ATTENTION, là machine où la commande est lancée écrasera l’autre ! NE PAS SE TROMPER.

On synchronise depuis la machine source (remplacer resource par r0):
[bash]drbdadm — –overwrite-data-of-peer primary resource[/bash]

Après avoir lancé cette commande, la synchronisation complète commence !
On peut en surveiller l’évolution en répétant la commande :
[bash]cat /proc/drbd[/bash]
(Ca ressemble étrangement à une reconstruction de RAID avec un contrôleur smartarray pour ceux qui connaissent).

Votre réplication DRBD est maintenant opérationnelle ! Tout ce que vous allez faire sur votre périphérique sera maintenant répliqué sur l’autre ! (sous réserve que le débit de votre réseau le permette – vous voyez l’évolution sur /proc/drbd)

Si aucun des noeuds n’est passé « Primary » malgré les options du fichier de configuration, vous pouvez « forcer » l’élection du « primary » en tapant la commande suivante sur la machine où ça doit être appliqué :
[bash]drbdadm primary resource[/bash]
De fait pour passer un noeud en secondaire :
[bash]drbdadm secondary resource[/bash]

Vous trouverez ici une information pour démarrer avec un volume pré-rempli et éviter la première synchronisation :
http://www.drbd.org/users-guide-emb/s-using-truck-based-replication.html

Plus généralement, les informations sur l’utilisation et configuration de DRBD sont disponibles ici:
http://www.drbd.org/users-guide-emb/p-work.html

Vous pouvez ensuite utiliser votre nouveau périphérique via /dev/drbdX ou X est le numéro accordé à votre périphérique/partition DRBD (dans l’ordre d’implémentation en suivant votre fichier .res spécifié par la ligne « device »).
Il est donc ensuite simple de formater le support comme n’importe quel disque / périphérique de stockage :
[bash]mkfs.ext3 /dev/drbd1[/bash]

Voilà, j’espère que ce mini guide vous donnera une idée de ce que peut représenter la mise en place de DRBD. Évidemment une telle solution doit s’inscrire dans une stratégie globale de gestion des données afin de garantir la plus haute disponibilité de l’infrastructure. Ce type de solution va de pair avec une gestion des flux en load balancing, et une redondance des ressources de stockage, au moins équipée d’un raid 1 ou mieux.

Le débit réseau nécessaire au maintient de la synchronisation dépendra du volume de données modifiées sur la plateforme, afin que le système puisse répliquer les écritures le plus rapidement possible, et ainsi diminuer la perte en cas de panne d’un noeud.

Vous pouvez également définir le débit réseau à utiliser par chaque « resource » avec l’option suivante dans la configuration de celle ci :
[bash]resource resource
syncer {
rate 40M;
…
}
…
}[/bash]
C’est en bytes/s et pas en bit/s.

Gérer les erreurs :
http://www.drbd.org/users-guide-emb/s-configure-io-error-behavior.html

Une autre ressource intéressante sur la mise en place de DRBD :
http://blog.guiguiabloc.fr/index.php/2008/10/17/cluster-haute-disponibilite-chez-ovh-avec-ipfailover-heartbeat-et-drbd-via-ipsec/
et là :
http://blog.guiguiabloc.fr/index.php/2009/02/16/mise-en-oeuvre-dun-systeme-de-fichier-distribue-et-acces-concurrents-en-san-avec-drbd-iscsi-ocfs2-et-dm-multipath/

Autre(s) référence(s) :
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-kernel-modules-persistant.html

Tags: disque, drbd, ethernet, haute disponibilité, ip, raid, replication, Reseau, stockage