Ordres DDL sur un cluster Slony

Introduction

Il est important de connaître les différentes méthodes pour exécuter des instructions DDL en production dans un environnement utlisant Slony.

Première méthode

Nous considérerons dans cette partie que le fichier slon_tools.conf est correctement configurées.

Créer un script SQL pour chaque SET Slony qui doit être modifié.

alter-set1.sql :

ALTER TABLE table1 ADD COLUMN vcol1 VARCHAR(5000),
ADD COLUMN icol2 smallint,
ADD COLUMN ccol3 CHAR(10);
ALTER TABLE table2 ADD COLUMN vcol1 VARCHAR(5000),
ADD COLUMN icol2 smallint,
ADD COLUMN ccol3 CHAR(10);
ALTER TABLE table3 ADD COLUMN vcol1 VARCHAR(5000),
ADD COLUMN icol2 smallint,
ADD COLUMN ccol3 CHAR(10);
alter-set2.sql : 

ALTER TABLE table4 ADD COLUMN vcol1 VARCHAR(5000),
ADD COLUMN icol2 smallint,
ADD COLUMN ccol3 CHAR(10);
ALTER TABLE table5 ADD COLUMN vcol1 VARCHAR(5000),
ADD COLUMN icol2 smallint,
ADD COLUMN ccol3 CHAR(10);

Il ne reste plus qu'à effectuer les modifications de structures sur chacun des sets en exécutant les commandes suivantes sur n'importe quel noeud du cluster Slony.

slonik_execute_script 1 /scripts/alter-set1.sql
slonik_execute_script 2 /scripts/alter-set2.sql

Le script slonik_execute_script va exécuter la commande Slony EXECUTE SCRIPT avec les arguments adéquates sur le noeud source de chaque SET, et cet ordre sera propagé sur les noeuds cibles. Le principal problème dans l'utilisation de cette commande est qu'elle vérrouille toutes les tables de la base durant l'exécution des scripts SQL ce qui peut être très problématique pour un service 24/7

Seconde méthode

Cette méthode est valable pour l'ajout de colonnes mais non la suppression.

Comme dans le cas précédent, vous disposez des scripts alter-set1.sql et alter-set2.sql nécessaires pour effectuer les modifications de structures. Exécuter sur chacun des noeuds cibles (subscribers) du cluster Slony les scripts SQL :

psql -U mon_user ma_base < /scripts/alter-set1.sql
psql -U mon_user ma_base < /scripts/alter-set2.sql

Créer 2 nouveaux scripts comme suit :

update_triggers-set1.sql

UPDATE pg_trigger SET tgargs=substring(tgargs for octet_length(tgargs)-1)||E'vvv\000'
WHERE tgname='_mon_cluster' AND tgrelid IN
(SELECT oid FROM pg_class WHERE relname IN ('table1','table2','table3'));

update_triggers-set2.sql

UPDATE pg_trigger SET tgargs=substring(tgargs for octet_length(tgargs)-1)||E'vvv\000'
WHERE tgname='_mon_cluster' AND tgrelid IN
(SELECT oid FROM pg_class WHERE relname IN ('table4','table5'));

Le nombre de caractères v dans la requête de mise à jour correspond au nombre de nouvelles colonnes. Si nous avions ajouté une seule colonne, nous aurions concaténé la valeur E'v\000' au lieu de E'vvv\000' Dans le cas de la modification du type d'une colonne il n'y a pas besoin de mettre à jour le trigger Slony de la table concernée puisque le nombre de colonnes reste inchangé.

Puis exécuter les scripts suivants sur le noeud source et mettre à jour les triggers Slony :

psql -U mon_user ma_base < /scripts/alter-set1.sql
psql -U mon_user ma_base < /scripts/update_triggers-set1.sql

psql -U mon_user ma_base < /scripts/alter-set2.sql
psql -U mon_user ma_base < /scripts/update_triggers-set2.sql

Cette méthode permet de ne pas utiliser la commande EXECUTE SCRIPT et donc ne pas vérrouiller toutes les tables de la base.

Conclusion

Ce document a permis de comprendre qu'il y a une autre méthode que l'utilisation de la commande EXECUTE SCRIPT pour mettre à jour la structure des tables répliquées par Slony (dans le cas de l'ajout/modification de colonnes), ce qui permet de réduire considérablement l'impact de ces modifications sur une base de production 24/7.