Reseau
Configurer varnish-cache avec des virtualhosts, apache, fedora, redhat, centos
Cet article fait suite à celui ci : http://blog.inforeseau.com/2011/05/installer-varnish-depuis-sources-sur-fedora-11
Nous allons voir comment configurer varnish-cache afin d’optimiser notre serveur apache sur un seul serveur dédié (destiné à un public averti maitrisant la configuration d’apache).
Sur le post précédent nous avons compilé et installé varnish-cache, qui est donc dans un état fonctionnel, sur un port qui lui est propre. En suivant les différents documents cité en bas de ce poste comme sources, je vous propose ce petit mémo.
Comme toujours, il s’agit pour moi de garder une référence sur les travaux réalisés afin de prendre en main une technologie.
Dans cet article nous allons :
-Configurer varnish-cache avec des règles de base en VCL (varnish configuration language), pour prendre en charge nos virtualhost apache, et personnaliser les configurations selon le type de site.
-Configurer apache pour travailler avec varnish sur le même serveur, et pas forcément dans cet ordre :D
En ayant suivi mon POST précédent, votre installation de varnish-cache écoute actuellement le port 8080 (où le port que vous avez défini dans /etc/sysconfig/varnish pour la variable « VARNISH_LISTEN_PORT ». Apache écoute donc le port 80 (http), et varnish le 8080.
Pour que varnish-cache soit activé par défaut nous allons inverser ceci !
C’est varnish-cache qui va recevoir les demandes, et les gérer en fonction de règles que nous allons établir (le port que vous avez choisi doit être ouvert dans votre firewall évidemment).
On édite le fichier /etc/sysconfig/varnish et on change la variable « VARNISH_LISTER_PORT » en lui attribuant la valeur 80 (port http).
On édite le fichier /etc/varnish/default.vcl, et on va redéfinir le backend default en conséquence,votre fichier devra pour commencer contenir :
[bash]backend default {
.host = "127.0.0.1";
.port = "8080";
}[/bash]
Ceci défini que varnish-cache va par défaut demander le contenu au serveur local sur le port 8080, et tant qu’on ne redémarre pas le service, aucun soucis, les modifications n’ont pas d’impact.
On va maintenant éditer la configuration apache, afin de le faire écouter sur le port 8080.
Vous devez éditer le (ou les) fichier(s) de configuration apache qui définissent vos virtualhost (hôtes virtuels), ainsi que le port d’écoute par défaut. Généralement tout ceci est paramétré dans /etc/httpd/conf/httpd.conf.
Il faut donc remplacer le port par défaut sur l’ensemble des champs présents dans votre fichier de configuration comme suit :
FAITES UNE COPIE DE SAUVEGARDE AVANT DE MODIFIER POUR POUVOIR REVENIR EN ARRIERE AU BESOIN.
Listen 80 devient Listen 8080
NameVirtualHost *:80 devient NameVirtualHost *:8080
Il faut ensuite formater les logs de apache pour que ça soit compatible avec varnish-cache, pour cela, il faudra ajouter la directive suivante (en plus de celles existantes, cherchez LogFormat dans votre configuration) :
[bash]LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" varnishcombined[/bash]
Puis, remplacer dans vos VirtualHost (hôtes virtuels), le format du log à utilisé :
CustomLog logs/xxxdomaine_access_log common devient CustomLog logs/xxxdomaine_access_log varnishcombined
A ce stade, nous sommes prêt à basculer sur le fonctionnement avec Varnish, mais avec les règles par défaut, ce qui peut conduire à des incompatibilités avec vos produits installés (wordpress, phpbb etc.). Si vous redémarrez tout de suite vos services (apache et varnish), chacun va utiliser le nouveau port et assurer le service, vous pouvez le faire, mais tant que vous n’aurez pas placé les règles, certains sites ne réagirons pas comme attendu (authentification impossible ou autre élément utilisant les cookies).
Pour adapter cela nous allons créer les règles qui vont bien en VCL, !
Je vais donner l’exemple avec quelques sites à moi, bien entendu vous adapterez à votre besoin.
L’idée pour moi et d’avoir une configuration par type de site (une pour wordpress, phpbb, sites autres etc.) et donc de conditionner la configuration selon le VirtualHost traité.
Voici donc les ajouts aux paramètres par défaut du fichier /etc/varnish/default.vcl :
[bash]backend default {
.host = "127.0.0.1";
.port = "8080";
}
#On va gérer les regles VCL selon les vhosts par hostname comme expliqué ici http://www.varnish-software.com/blog/virtual-hosts-varnish
#Traitement des requetes reçue depuis le net sur varnish-cache
sub vcl_recv {
if (! req.http.Host)
{
#soit j’affiche une erreur
#error 404 "Need a host header";
#Mais perso je prefere pouvoir appeler le serveur par son ip pour le site par défaut
#Alors je bypass et c’est le site par défaut sans cache qui sera affiché :
return (pass);
}
#On peut supprimer le www devant le host demandé si besoin, utile si on ne veut gérer que le site par défaut et unifier les logs.
#set req.http.Host = regsub(req.http.Host, "^www\.", "");
#Supprime l’eventuel :80 en fin de requete sur le host (permet de garantir que le filtre sera bien effectif.
set req.http.Host = regsub(req.http.Host, ":80$", "");
#Ici je pose une condition pour appeler le backend (serveur) et le fichier de configuration pour les sites donnés
#Pour les conditions, avec la tilde ~ je déclare que j’utilise les expression régulière regexp pour poser ma condition
if (req.http.Host ~ "blog.inforeseau.com|www.droledetroc.com")
{
#Permet de définir un backend (serveur) par site si besoin, comme chez moi tout est sur le meme serveur, ça sera identique partout !
set req.backend = default;
#appelle le fichier de règle RECV dédié à wordpress
include "/etc/varnish/wordpress_recv.vcl";
}
elsif (req.http.Host ~ "canada.maumautte.com|scrapblog.maumautte.com|www.kine-sport.com|just-cs.maumautte.com")
{
#Sinon (eslif) si ce sont les virtualhosts dans la condition ci dessus, je traite comme ceci :
set req.backend = default;
include "/etc/varnish/wordpress_recv.vcl";
#Oui c’est la meme configuration, mais j’aurai pu, par exemple renvoyer sur un autre serveur en backend, qui ne serait pas celui de cache (un autre serveur qui hebergerait le blog dont le backend peut être défini en haut du fichier)
}
elsif (req.http.Host ~ "forum.inforeseau.com|www.forum-scrapbooking.com")
{
#si c’est un forum à la base j’avais un bypass (pas de cache) car je n’avais pas les regles pour ignorer les cookies d’auth dans le cache, mais bande de veinards maintenant c’est fait, on verra le fichier plus bas.
set req.backend = default;
#return (pass);
#Application des règles dediées RECV à phpbb :
include "/etc/varnish/phpbb_recv.vcl";
}
else
{
#Par defaut, pour tous les autres sites "classiques", j’utilise le cache par défaut de varnish-cache
#Je défini quand même le serveur sur lequel le trafic est dirigé (oui toujours le même ici)
set req.backend = default;
return (lookup);
}
#ci dessous fin sub vcl_recv (fin du traitement des requêtes provenant du web)
}
##########################################################################
#On attaque la partie qui traite la lecture des pages sur le(s) serveur(s) source
sub vcl_fetch {
#Meme chose que pour le traitement amont, je ne redétaille pas, seul les fichiers associés sont différents.
if (req.http.Host ~ "blog.inforeseau.com|www.droledetroc.com")
{
include "/etc/varnish/wordpress_fetch.vcl";
}
elsif (req.http.Host ~ "canada.maumautte.com|scrapblog.maumautte.com|www.kine-sport.com")
{
include "/etc/varnish/wordpress_fetch.vcl";
}
#Attention, ne fonctionne pas avec le ou logique
#elsif (req.http.Host =="forum.inforeseau.com||www.forum-scrapbooking.com")
#On pass en regexp avec la tilde ~ comme indiqué plus haut
elsif (req.http.Host ~ "forum.inforeseau.com|www.forum-scrapbooking.com")
{
#si c’est un forum je bypass à la base, puis finalement non, j’ai tout corrigé comme plus haut.
#return (pass);
#J’ai mes propres règles (la loi c’est moi gnark gnark gnark) :
include "/etc/varnish/phpbb_fetch.vcl";
}
else
{
#Finalement on va delivrer le contenu caché (en cache hein, pas celui qui est sous la table!) pour augmenter les performances du reste des sites :
return (deliver);
}
#Fin vcl_fetch
}
########################################################################
#Puis tout ça c’est pour ajouter un peu de sécurité, masquer le fait que les pages sont traitées par varnish etc (bon avec ce post c’est sûr on se doute un peu que c’est le cas! niarf!)
sub vcl_deliver {
# Secure the header
remove resp.http.Via;
remove resp.http.X-Varnish;
remove resp.http.Server;
remove resp.http.X-Powered-By;
}[/bash]
Maintenant les 4 fichiers contenant les règles pour les sites qui sont en include (bah ouai, je ne suis pas un chien, je ne vous laisse pas en plan :) ) :
wordpress_recv.vcl (oui c’est de la récup de chez nicolargo, un grand merci à lui pour son super blog!) :
[bash] # Compatiblity with Apache log
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# Post requests will not be cached
if (req.request == "POST") {
return (pass);
}
# Normalize encoding/compression
if (req.http.Accept-Encoding) {
if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; }
elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; }
else { remove req.http.Accept-Encoding; }
}
# Remove has_js and Google Analytics __* cookies.
if (req.http.cookie) {
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
# Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
# Remove empty cookies.
if (req.http.Cookie ~ "^\s*$") {
unset req.http.Cookie;
}
}
# Serve the page
unset req.http.vary;
# If I am logged in to wordpress, I DO NOT WANT TO SEE cached pages
if ( req.url ~ "^/wp-(login|admin)" || req.http.Cookie ~ "wordpress_logged_in_" ) {
return (pass);
} else {
# If I’m just a regular visitor
# If the request is static
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)$") {
# Remove the cookie and make the request static
unset req.http.cookie;
return (lookup);
}
# Try to lookup in the cache
return (lookup);
}
# Cookie ? Not cacheable by default
if (req.http.Authorization || req.http.Cookie) {
return (pass);
}
[/bash]
wordpress_fetch.vcl :
[bash] if (req.request == "POST") {
return (pass);
}
# If the request is static
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)$") {
# Cache it, and make it last 2 hours
set beresp.ttl = 7200s;
# Make the request static by removing any cookies set by those static files
unset beresp.http.set-cookie;
# Deliver the cached object
return (deliver);
}
# If I am logged in to wordpress, I DO NOT WANT TO SEE cached pages
if (req.http.cookie ~ "wordpress_logged_in") {
return (pass);
} else {
# Cache anything for 2 minutes. When the cache expires it will be cached again and again, at the time of the request
set beresp.ttl = 120s;
return (deliver);
}
[/bash]
phpbb_recv.vcl :
[bash] # Compatiblity with Apache log
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# Post requests will not be cached
if (req.request == "POST") {
return (pass);
}
# Normalize encoding/compression
if (req.http.Accept-Encoding) {
if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; }
elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; }
else { remove req.http.Accept-Encoding; }
}
# Serve the page
unset req.http.vary;
# If I am logged in to phpbb, I DO NOT WANT TO SEE cached pages
if ( req.url ~ "^/(admin|adm)" || req.http.Cookie ~ "phpbb2hirikiki" || req.http.Cookie ~ "phpbb3_5xoui" ) {
return (pass);
} else {
# If I’m just a regular visitor
# If the request is static (sauf html/htm car on utilise url rewriting donc html=php)
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz)$") {
# Remove the cookie and make the request static
unset req.http.cookie;
return (lookup);
}
# Try to lookup in the cache
return (lookup);
}
# Cookie ? Not cacheable by default
if (req.http.Authorization || req.http.Cookie) {
return (pass);
}
[/bash]
Note : oui ça ressemble à celui de wordpress, notez juste les noms des cookies qui doivent correspondre aux noms de cookies que vous avez choisi dans votre config phpbb (on peut aussi identifier ça dans les préférences firefox, quand vous êtes sur votre site, en affichant les cookies dans l’onglet « vie privée »), et les pages html qui ne sont pas cachée car j’utilise de l’url-rewriting,et donc les pages html ne sont pas des pages statiques :D .
phpbb_fetch.vcl :
[bash]# Do not cache POST requests
if (req.request == "POST") {
return (pass);
}
# If the request is static (sauf html/htm utilisé en url_rewriting et donc dynamique)
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz)$") {
# Cache it, and make it last 2 hours
set beresp.ttl = 7200s;
# Make the request static by removing any cookies set by those static files
unset beresp.http.set-cookie;
# Deliver the cached object
return (deliver);
}
# If I am logged in to phpbb, I DO NOT WANT TO SEE cached pages
if (req.http.Cookie ~ "phpbb2ronours" || req.http.Cookie ~ "phpbb3_5xr75") {
return (pass);
} else {
# Cache anything for 2 minutes. When the cache expires it will be cached again and again, at the time of the request
set beresp.ttl = 120s;
return (deliver);
}
[/bash]
Voilà pour les fichiers contenant les règles pour chacun des sites.
Pour en apprendre plus en VCL vous trouverez plein d’exemples ici :
http://www.varnish-cache.org/trac/wiki/VCLExamples
Maintenant on est prêts à la mise à feu :
[bash]/etc/rc.d/init.d/httpd restart
/etc/rc.d/init.d/varnish restart[/bash]
Ayé, on est à fond ! :D, c’est maintenant Varnish qui gère les requêtes HTTP sur le port 80, puis qui, en fonction du site demandé, va réaliser les traitements adaptés.
Comme dirait Nicolargo, les commandes utiles :
varnishlog : affiche les log de varnish
varnishstat : affiche les stats depuis le dernier lancement de varnish et les tâches s’évanouissent! (arf désolé j’ai pas pu résister)
Explication sur les valeurs de varnishstat : http://kristianlyng.wordpress.com/2009/12/08/varnishstat-for-dummies/
varnishhist : Affiche un historique des requêtes faites sur votre machine.
varnishadm : pour administrer votre varnish en local.
Avec tout ça vous devriez pouvoir personnaliser la configuration à souhait, avec je l’espère une meilleure compréhension du système.
Ah oui j’oubliais! Varnish vous permet aussi de faire du load balancing / failover ! Vous pouvez en lire plus ici :
http://www.varnish-cache.org/trac/wiki/LoadBalancing
Bien sûr ça implique d’avoir plusieurs machines (au moins un frontal et 2 serveurs de contenu – backend)
Note : Si vous utilisiez des outils de statistiques en php, ceux-ci ne fonctionneront plus correctement car les pages distribuées par le cache ne sont donc plus traitées en php, c’est le but !
La doc en détail : http://www.varnish-cache.org/docs/2.1/
Sources :
http://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html
http://www.varnish-cache.org/trac/wiki
http://www.varnish-cache.org/trac/wiki/VarnishAndWordpress
http://www.varnish-cache.org/docs/2.1/tutorial/vcl.html
http://blog.inforeseau.com/2011/05/installer-varnish-depuis-sources-sur-fedora-11
http://www.varnish-software.com/blog/virtual-hosts-varnish
Installer Varnish depuis les sources sur Fedora 11
Le post du jour va traiter de l’installation de varnish depuis les sources sur Fedora 11 de manière manuelle.
Varnish-cache est un serveur proxy qui va mettre en cache les pages demandées afin d’éviter au « moteur » de les recalculer systématiquement. Varnish-cache est un outil simple et puissant permettant un usage multiple, de la simple mise en cache à la répartition de charge comme on peut le lire ici : http://www.varnish-cache.org/docs/2.1/tutorial/advanced_backend_servers.html
Pour faire simple, vanish-cache reçoit les requêtes http sur un port que l’on défini dans son fichier de configuration, et rediriger la requête sur le (ou les) « backend » défini. On entend par « backend », le serveur qui fournit le contenu, typiquement apache, sur la même machine physique, ou encore sur un (ou plusieurs) autre(s) serveur(s).
Ce mode d’installation diffère légèrement de l’installation par paquets dans la mesure ou les fichiers de configuration ne sont pas positionnés au même endroit. (Généralement dans /usr/local/etc au lieu de /etc pour la config, et /usr/local/(bin|sbin) au lieu de /bin|/sbin).
On va donc dans notre dossier préféré pour compiler les programmes depuis la source, et on télécharge le programme en dernière version (2.1.5) au moment de ce post (Notez qu’il vaut mieux généralement passer par le dépot de votre distribution, ou une version packagée pour appliquer les mises à jour plus facilement), ici on vise l’aspect didactique, si vous maîtrisez le manuel, vous aurez gérer encore plus facilement les installations « packagées », car la seul différence se situe au niveau des chemins au final.
[bash]cd /usr/local/src
wget http://repo.varnish-cache.org/source/varnish-2.1.5.tar.gz
tar xvzf varnish-2.1.5.tar.gz[/bash]
On va commencer par installer les dépendances (voir ici http://www.varnish-cache.org/docs/2.1/installation/install.html#compiling-varnish-from-source):
[bash]yum install automake autoconf libtool ncurses-devel libxslt groff pcre-devel pkgconfig[/bash]
Varnish est maintenant décompressé, on va entrer dans le dossier de configurer, compiler, installer.
On va dans le dossier et on lance l’opération :
[bash]cd varnish-2.1.5
sh autogen.sh
sh configure
make[/bash]
Varnish est maintenant compilé et le binaire fonctionnel (en cas d’erreur, s’assurer que toutes les dépendances sont bien installées).
Comme indiqué dans la documentation vous pouvez maintenant effectuer un test du programme :
[bash](cd bin/varnishtest && ./varnishtest tests/*.vtc)[/bash]
La plupart des tests doivent renvoyer « passed ». Il se peut qu’une erreur ou deux se glisse, mais pas plus, et c’est sans gravité. Si la plupart des tests ne fonctionnent pas (failed) alors vous avez un problème et il faut revoir la procédure.
On peut maintenant installer :
[bash]make install[/bash]
On copie le fichier de configuration par défaut à la bonne place :
[bash]cp redhat/varnish.sysconfig /etc/sysconfig/varnish[/bash]
On va lier le dossier « etc/varnish » créé lors de l’installation avec le chemin par défaut :
[bash]ln -s /usr/local/etc/varnish /etc/varnish[/bash]
Il nous faut maintenant copier le script de démarrage de varnish à la bonne place, et corriger les chemins dans celui ci.
[bash]cp redhat/varnish.initrc /etc/rc.d/init.d/varnish[/bash]
Puis on édite ce fichier (/etc/rc.d/init.d/varnish) pour corriger les chemins vers les binaires comme suit :
/usr/sbin/varnishd devient /usr/local/sbin/varnishd
Voilà pour le script de lancement/arrêt de varnish, que l’on ajoute dans chkconfig (pour pouvoir le lancer automatiquement plus tard) :
[bash]chkconfig –add varnish[/bash]
Dans le fichier /etc/sysconfig/varnish on peut consulter les options par défaut qu’il faut adapter si vous le souhaitez. Dans mon cas, je souhaite positionner le cache dans un autre endroit, car je manque de place sur la racine.
Pour cela je vais donc changer la valeur de « VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin » pour le faire pointer vers un dossier de mon choix créé pour l’occasion. Libre à vous de faire cette modification selon votre configuration.
Il faudra aussi définir un utilisateur qui existe sur votre système (ou en créer un : adduser varnish), et adapter les « DAEMON_OPTS » à la ligne
[bash]-u varnish -g varnish[/bash]
avec l’utilisateur de votre choix.
Le dossier /usr/local/var/varnish devra appartenir à cet utilisateur et à son groupe (chown utilisateur:groupe /usr/local/var/varnish).
Il faut créer un mot de passe pour l’accès à l’interface d’administration :
[bash]echo "votre-password">/etc/varnish/secret[/bash]
On va maintenant créer une configuration de base pour tester la solution.
On ouvre le fichier /etc/varnish/default.vcl dont le contenu doit être totalement commenté par défaut, et on y ajoute ceci en bas du fichier :
[bash]backend default {
.host = "127.0.0.1";
.port = "80";
}[/bash]
Cette configuration va permettre de lancer un essai sans modifier la configuration de votre machine. On défini en gros que la source par défaut est votre serveur sur le port 80, soit le site affiché par défaut quand vous allez sur http://ip_serveur/.
On lance donc le processus :
[bash]/etc/rc.d/init.d/varnish start[/bash]
Vous pouvez maintenant consulter les statistiques et vérifier ainsi que ça tourne en tapant :
[bash]varnishstat[/bash]
(on quitte les stats en appuyant sur la touche « q »)
En fonction de la valeur que vous avez défini dans le fichier /etc/sysconfig/varnish pour la variable « VARNISH_LISTEN_PORT », vous pouvez consulter la page affichée par varnish à l’adresse :
http://votre_serveur:port (où port = la valeur choisie dans le fichier de configuration).
Si vous avez un firewall comme iptables, vous devrez ouvrir le port pour pouvoir consulter la page sur ce port.
Par exemple pour mon test sur le port 8080 :
[bash]iptables -A INPUT -p tcp –dport 8080 -j ACCEPT[/bash]
(ou éditer directement votre fichier /etc/sysconfig/iptables et relancer iptables pour prendre en compte la modif)
Si votre site s’affiche c’est gagné il est pris en compte par varnish sur ce port.
Note : Pour avoir des infos en cas de plantage, il faut lancer varnishd avec les options définies dans /etc/sysconfig/varnish et le parametre « -d », sans quoi varnish ne renvoie aucune information relative au plantage !
Enfin pour rendre le service varnish actif au démarrage nous activons le service avec chkconfig :
[bash]chkconfig –level 345 varnish on[/bash]
Pour la suite, comme la configuration avec par exemple wordpress je vous invite à lire cet excellent POST :
http://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html
ainsi que le wiki de varnish :
http://www.varnish-cache.org/trac/wiki
OU BIEN, la suite de l’opération en configurant varnish-cache avec la gestion des virtualhost :
http://blog.inforeseau.com/2011/05/configurer-varnish-cache-avec-virtualhosts-fedora-redhat-centos
Sources utilisées pour ce post :
http://www.varnish-cache.org
http://www.varnish-cache.org/trac/wiki/VarnishAndWordpress
http://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html
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.
(2)
On affiche le « status » et on le copie pour pouvoir le lire plus tard (faites la copie de VOS infos afin d’en disposer plus loin) :
[bash]show master status;
+———————+————+———————+————————–+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+———————+————+———————+————————–+
| mysql-bin.000001 | 729 | | |
+———————+————+———————+————————–+
1 row in set (0.00 sec)
[/bash]
(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
Publicité – liens
Calendrier
| L | M | M | J | V | S | D |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
Recherche
Derniers articles
- You’ll most likely find me on LinkedIn
- The Russian roulette landing page !
- RTSP, Debian, VLC, not playing, IP Camera
- 5G network hosted in the cloud, no internet, no phone ! So smart ! And I ended on TV, This week in cyber
- They lock the door for privacy… but they keep a copy of the key, and couple of backdoors
Tresronours Twitter
Keywords cloud topic
Membre de la FSF
![[FSF Associate Member]](https://blog.inforeseau.com/fsf.png){kind=small}
Liens qui vont bien
Mots clés vrac – keyword cloud
License du contenu – CC By NC SA
This création is licensed under a Creative Commons Paternité - Pas d'Utilisation Commerciale - Partage des Conditions Initiales à l'Identique 2.0 France License.
Archives
- You’ll most likely find me on LinkedIn
- The Russian roulette landing page !
- RTSP, Debian, VLC, not playing, IP Camera
- 5G network hosted in the cloud, no internet, no phone ! So smart ! And I ended on TV, This week in cyber
- They lock the door for privacy… but they keep a copy of the key, and couple of backdoors
- Worst is yet to come, but they all warned you
- Migrating an old WordPress and handling character set, UTF8, latin1, latin1_swedish_ci
- From a broken TLS CA, to Facebook, to FIN12 hit and run
- Yes we can fix this mess, but do we want to ? That’s another story
- Criminals are still dominating the game, why are we doing so wrong, and what can we learn in this tech ocean ?
- Riding cloud can be tricky, don’t fall from it, in the weekly cyber !
- The threat landscape is very dynamic – Cyber news this week
- Cybersecurity is not obvious even for this newsletter !
- Install Slack desktop app on Kali rolling fixing libappindicator3-1 missing dependency
- How to delete all resources in azure to avoid charges after trial on your forced credit card registration
- Proxmox – ZFS – Dead drive on active VM, recover from replicated disk
- Restrict access to proxmox web admin interface
- Migrate your ESXI VMs to proxmox ZFS
- Install your VPN server with pi-hole on OVH VPS in 30 min
- Using raspberry pi 3 as wifi bridge and repeater and firewall
- Raspberry 3 – create a wifi repeater with USB wifi dongle
- raspberry 3 – routeur pare feu point d’acces wifi avec filtrage pub et tracking – router firewall access point with ads and tracking filtering
- Dell XPS 13 touchpad – corriger la sensibilité
- Utiliser Zazeen set top box depuis une connexion videotron
- Fermeture de mon compte facebook – la dernière goutte
- Choisir un kernel par defaut au demarrage de Centos 7.2 – configuration grub2
- Openvpn access server 2.0.25 et android
- Régler la luminosité du laptop par ligne de commande
- chromium outlook web app version complete sous linux
- Nexus 7 2012 – android 5 lollipop solution au probleme de lenteur
- HDD led sur Xubuntu – xfce
- xubuntu 14.04 verrouiller ecran de veille et desactiver mise en veille a la fermeture de l’ecran
- Authentification avec Radmin en utilisant Wine sur Gentoo
- Patcher bash sur une distribution plus supportee comme fedora 11
- Zimbra desktop sous xubuntu 14.04 64bit – fix
- xubuntu 12.10 probleme de son avec VLC – pulse audio – alsa – toshiba L855D – solution
- Evolution sous xubuntu 12.10 – bug affichage a la configuration – solution temporaire
- Booster son acces internet en changeant de DNS pour opendns
- Serveur DLNA sous ubuntu – minidlna
- sshfs sous windows – dokan sshfs
- xubuntu 11.10 Installer le plugin java pour firefox
- Installer Google Earth sur Xubuntu 11.10
- Installer nagios sur Fedora 11 depuis les sources
- Configurer varnish-cache avec des virtualhosts, apache, fedora, redhat, centos
- Installer Varnish depuis les sources sur Fedora 11
- Replication mysql – Configuration maitre-esclave
- Journée anti DRM – le 4 Mai 2011
- Configurer le menu grub en interface graphique – startupmanager – ubuntu gnu linux
- Déconnexions avec le routeur sans fil thomson TG585 v7 et les coupures adsl
- Installation de GFS pour utilisation avec volume DRBD sous Centos 5.5 ou redhat