Mysql Sandbox 2.0 - les slides

MySQL Sandbox est une boîte à outils permettant de configurer rapidement un serveur MySQL ou une replication MySQL quelque soit la version de MySQL que vous voulez tester. Pour cela, il suffit simplement de disposer des binaires MySQL de la version que vous voulez installer.

Un exemple rapide

Je suppose bien sûr que Mysql Sandbox 2.0 est installé dans /usr/local/mysql/mysql_sandbox_2.0.*

cd /usr/local/mysql
SITE="http://dev.mysql.com"
MPATH="get/Downloads/MySQL-5.1"
BINARY="mysql-5.1.29-rc-linux-i686-glibc23.tar.gz"
MIRROR="from/http://mir2.ovh.net/ftp.mysql.com/"
wget $SITE/$MPATH/$BINARY/$MIRROR
mkdir sandbox_dir
cd mysql_sandbox_2.0.*
export USER=mysql
./make_replication_sandbox --how_many_nodes=1 --upper_directory=/usr/local/mysql/sandbox_dir /usr/local/mysql/$BINARY

Et voilà, vous disposer d'une réplication MySQL entre un master et slave tous deux en version 5.1.26

Pour en savoir plus je vous conseil de lire les slides de Giuseppe Maxia qui peuvent vous servir de Bible.

Chargement de données avec Slony

Introduction

Slony est un outil de réplication basé sur des triggers. Dans le cas de l'import ou de la mise à jour massive des données de la base, le retard de réplication peut devenir un réel problème. En effet, un UPDATE sur 100 mille lignes va générer 100 mille instructions à exécuter sur les esclaves. Il peut donc devenir judicieux de ne pas utiliser la réplication Slony dans le cas cité.

Première méthode

Cette méthode consiste à supprimer totalement la configuration slony des bases de données en supprimant purement et simplement les schemas créés par slony, c'est à dire les schemas de la forme _nomdecluster (au sens slony bien sûr, http://slony.info/documentation/clustername.html), et à arrêter les démons slon de chaque machine faisant partie du cluster.
Ensuite les données sont importées sur le provider source, et le cluster est réinitialisé en réutilisant les scripts qui avaient servi à initialiser la configuration. L'initialisation du cluster va engendrer la recopie par slony des données du provider sur l'ensemble des receivers en utilisant la commande postgresql COPY qui est très performante.

Seconde méthode

Cette méthode consiste à désactiver la réplication sur l'ensemble des tables concernées sur chacune des bases faisant partie du cluster Slony. Ensuite les données sont importées et la réplication est réactivée.
Cette méthode s'appuie sur les fonctions Slony alterTableRestore et alterTableForReplication qui respectivement désactive et active les triggers sur la table dont l'identifiant est fourni en paramètre.


Voici par exemple le déroulement de cette méthode sur ma plateforme (mes tables se nomment 's_xxx') :

Génération des scripts pour désactiver la réplication et vider les tables

schema=_nomdecluster
rm -f /var/tmp/disabletriggers-$schema.sql /var/tmp/truncate-$schema.sql
psql ma_base -U mon_user -c \
"SELECT 'SELECT $schema.altertablerestore('||relname||');' FROM pg_class where relname like E's\\\\_%'" >> /var/tmp/disabletriggers-$schema.sql
psql ma_base -U mon_user -c \
"SELECT 'TRUNCATE TABLE '||relname||';' FROM pg_class where relname like E's\\\\_%'" >> /var/tmp/truncate-$schema.sql

Génération des scripts pour réactiver la réplication

schema=_nomdecluster
rm -f /var/tmp/enabletriggers-$schema.sql
psql ma_base -U mon_user -c "SELECT 'SELECT $schema.alterTableForReplication('||relname||');' FROM pg_class where relname like E's\\\\_%'" >> /var/tmp/enabletriggers-$schema.sql

Désactivation de la réplication

schema=_nomdecluster
psql ma_base -U mon_user < /var/tmp/disabletriggers-$schema.sql

Suppression des données existentes

psql ma_base -U mon_user < /var/tmp/truncate-$schema.sql

Chargement des données à partir d'un dump

# On se rend dans le répertoire où se trouvent les backups
cd /dir
schema=_clustername
dumpfile=$schema-lastbackup.sql.gz

# On génère la liste des objets à restaurer
zcat $dumpfile |pg_restore -l|egrep -v 'slony' > /tmp/objects.list

# On restaure les données de la base ma_base
zcat $dumpfile |pg_restore -d ma_base --no-owner --data-only -L /tmp/objects.list

Rétablissement de la réplication

psql ma_base -U mon_user < /var/tmp/enabletriggers-$schema.sql

Il est clair que les écritures autres que le chargement des données doivent être interrompues au niveau applicatif pour ne pas désynchroniser les bases de données entre elles.

Conclusion

Il y a donc la possibilité de charger des données sans utiliser la réplication Slony courante, ce qui permet d'accélérer le processus. Cependant, cela demande dans ces cas là de désactiver le service (s'il y a besoin de supprimer les données au préalable) ou au moins de désactiver les écritures.
La seconde méthode peut aussi être utilisée dans le cas où vous n'auriez plus sous la main les scripts d'initialisation de la configuration Slon, ce qui ne devrait pas être le cas pour des plateformes de production.

Mettre à jour Slony

Introduction

La mise à jour de Slony peut être nécessaire pour améliorer les performances de l'outil ou corriger un BUG comme dans la version 1.2.15 par exemple qui corrige un problème de fuite mémoire (http://bugs.slony.info/bugzilla/show_bug.cgi?id=52). Cette mise à jour nécessite l'arrêt total de la réplication sur l'ensemble des noeuds d'un même cluster (http://www.slony.info/documentation/concepts.html), mais permet de continuer à mettre à jour les données sur le noeud source.

Algorithmie

Voici les différentes étapes qui composent ce mode opératoire :

* Mettre à jour la configuration apt pour pouvoir récupérer le nouveau paquet Slony
* Arrêter tous les processus slon sur tous les serveurs
* Installer le nouveau paquet Slony
* Mettre à jour Slony
* Redémarrer tous les processus slon sur tous les serveurs

Procédure

Le fichier /etc/slony/slon_tools.conf, il est possible d'utiliser un autre nom, doit être correctement renseigné pour que cette procédure fonctionne correctement. Par exemple, vous pouvez avoir la configuration suivante :

postgres@McQueen:~$ cat /etc/slony1/slon_tools.conf
&add_node(host => 'localhost', dbname => 'pgbench', port =>5432,
user=>'postgres', password=>'', node=>1 );
&add_node(host => 'localhost', dbname => 'pgbenchslave', port =>5432,
user=>'postgres', password=>'', node=>2 , parent=>1);
@KEYEDTABLES=(
"public.accounts",
"public.branches",
"public.tellers",
);
@SERIALTABLES=(
"public.history",
);
$CLUSTER_NAME = 'mycluster';
$MASTERNODE = 1;

Pour vérifier que votre fichier est correct vous pouvez utiliser la commande suivante :

postgres@McQueen:~$ slonik_print_preamble
cluster name = mycluster;
node 1 admin conninfo='host=localhost dbname=pgbench user=postgres port=5432';
node 2 admin conninfo='host=localhost dbname=pgbenchslave user=postgres port=5432';

Si votre fichier de configuration est différent, utilisez l'option --config sur la ligne de commande, mais dans tous les cas vous devez obtenir la configuration de votre cluster sous la forme présentée précédemment.

Une fois ce prérequis validé, il est possible de commencer la procédure en suivant l'algorithmie énoncée plus haut :

* Mettre à jour la configuration apt pour pouvoir récupérer le nouveau paquet Slony

* Arrêter tous les processus slon sur tous les serveurs

dsh -r ssh -o -lroot -m node1,node2,node3,node4 /etc/init.d/slony1 stop

* Installer le nouveau paquet Slony

apt-get install slony1-bin=1.2.15-1~bpo1-2 postgresql-8.2-slony1=1.2.15-1~bpo1-2

* Mettre à jour le schema Slony de tous les noeuds (à ne faire qu'une fois et sur un seul noeud)

slonik_update_nodes |slonik

* Redémarrer tous les processus slon sur tous les serveurs

dsh -r ssh -o -lroot -m node1,node2,node3,node4 /etc/init.d/slony1 start

Conclusion

Il est donc possible de mettre à jour rapidement la version de Slony sans impacter les écritures. Cependant, la réplication étant coupée, les lectures seront désynchronisées sauf si elles sont faites directement sur le noeud source durant la procédure de mise à jour.
La mise à jour du schema Slony sera par contre à faire sur tous les clusters. Dans le cas où les objets d'une base sont répliquées sur 2 clusters différents, il faudra donc effectuer 2 mises à jour. Ceci est à prendre en considération si les serveurs des clusters Slony sont mutualisés.