17. Changements du schéma de la base (DDL)

Le script ne doit pas contenir d'instructions BEGIN ou END car il s'exécute déjà dans une transaction. Avec la version 8 de PostgreSQL™, l'introduction des transactions imbriquées change cela quelque peu, mais vous devez rester attentif au fait que les actions du script sont exécutées comme une transaction simple dans laquelle on ne maîtrise pas le BEGIN et le END.

S'il y a une erreur quelconque dans le script ou un problème quelconque sur la manière dont il s'exécute sur un nœud particulier, cela conduira le démon slon(1) de ce nœud à paniquer et à tomber. Vous pouvez consulter plusieurs types de messages attendus lors d'un déroulement normal ou anormal à Section 26.7.2, « Traces à propose des scripts DDL ». Si vous redémarrez le démon slon(1), il tentera, de manière très probable, de rejouer le script DDL, ce qui conduira certainement au même échec qu'à sa première tentative. J'ai eu un tel scénario, m'obligeant à supprimer du nœud « maître » l'évènement de la table sl_event pour arrêter de le voir tomber en échec.

La conséquence est qu'il est vital que les modifications ne soient pas faites de manière hasardeuse sur un nœud ou un autre. Les schémas doivent toujours rester synchronisés.

Pour slon(1) aussi, à ce niveau, « panic » est probablement la réponse correcte car il permet au DBA de sortir la base du nœud défecteux, de corriger manuellement le problème en supprimant l'évènement incorrect et de redémarrer slon(1). Vous pouvez être certain que les mises à jour faites après le changement DDL sur le nœud maître sont enregistrées dans une file d'attente, avant d'être traitées par l'abonné. Vous ne courrez ainsi pas le risque qu'il y ait des mises à jour demandées alors qu'elles dépendaient des modifications DDL.

Lorsque vous exécutez SLONIK EXECUTE SCRIPT(7), cela conduit slonik(1) à poser, pour chaque table faisant partie du jeu de réplication, un verrou exclusif sur la table.

Cela commence par la pose du verrou, poursuit avec l'altération de la table pour supprimer les triggers Slony-I™, et se termine avec la restauration de tous les triggers qui ont été cachés.

BEGIN;
LOCK TABLE table_name;
SELECT _oxrsorg.altertablerestore(tab_id);
--tab_id is _slony_schema.sl_table.tab_id

Après l'exécution du script, chaque table est « restaurée » dans le but d'ajouter en fin soit le trigger qui collecte les mises à jour sur le nœud origine soit celui qui rejette les mises à jour sur l'abonné.

SELECT _oxrsorg.altertableforreplication(tab_id);
--tab_id is _slony_schema.sl_table.tab_id
COMMIT;

Notez que c'est ce qui permet à Slony-I™ de prendre connaissance de l'altération de tables : avant ce SYNC, Slony-I™ réplique des lignes suivant le vieux schéma ; après le script DDL_SCRIPT, les lignes sont répliquées suivant le nouveau schéma.

Sur un système réalisant de nombreuses mises à jour, il peut être difficile « d'obtenir » tous les verrous nécessaires. Les verrous peuvent conduire à des situations de blocages. Vous pouvez régler le problème de deux manières différentes :

Vous devez envisager de définir des ensembles de réplication représentant un plus petit nombre de tables de manière à ce que moins de verrous soient posés et permettent au script DDL d'être joué.

Si un script DDL affecte une seule table, il ne devrait pas être nécessaire de verrouiller toutes les tables de l'application.

Note

Véritablement, à partir de la version 1.1.5 ou plus, ce n'est plus vrai. Le danger que quelqu'un opère des changements DDL interférant avec l'ensemble de réplication est suffisamment évident pour que slon(1) verrouille toutes les tables répliquées, qu'elles soient ou pas dans l'ensemble de réplication.

Vous pouvez avoir besoin de faire un arrêt de votre système pour vous assurer que vos applications ne demandent pas des verrous qui rentreraient en conflit avec ceux dont vous auriez besoin pour faire les changements de schéma de base.

Dans les versions 1.0 à 1.1.5 de Slony-I™, le script s'exécute comme une simple requête, ce qui peut poser problème si vous réalisez des modifications complexes. À partir de la version 1.2, le script est découpé en traitements SQL individuels, et chaque requête est soumise séparemment, ce qui est préférable.

Le problème avec une requête traitant une « requête imbriquée » est que l'analyseur SQL réalise son plan d'exécution pour le jeu entier de requête avant même l'exécution de la requête.

Cela ne pose pas de problème particulier si les requêtes sont indépendantes les unes des autres, telles que deux requêtes d'ajout de deux colonnes à une table.

ALTER TABLE t1 ADD COLUMN c1 integer; ALTER TABLE t1 ADD COLUMN c2 integer;

Par contre, les problèmes se rencontrent si vous devez référencer une requête précédente. Considérez la requête DDL suivante...

ALTER TABLE t1 ADD COLUMN c1 integer; CREATE SEQUENCE s1; UPDATE t1 SET c1=nextval('s1'); ALTER TABLE t1 ALTER COLUMN c1 SET NOT NULL; ALTER TABLE t1 ADD PRIMARY KEY(c1);

Jusqu'à la version 1.2 de Slony-I™, cette requête aurait échouée lors de l'atteinte de la condition UPDATE, indiquant l'inexistence de la colonne c1. Cela est dû au fait que toutes ces requêtes sont découpées et analysées avant même l'exécution de l'une d'entre elles. Ainsi, l'UPDATE est évalué sur une table avant que la colonne n'ait été ajoutée. Oops.

Si vous avez des versions antérieures, vous pouvez contourner cela en invoquant une requête séparée SLONIK EXECUTE SCRIPT(7) dans un script distinct, en générant un nouveau script pour chaque requête qui référence un objet créé dans une requête précédente.

Dans la version 1.2 de Slony-I™, il y a un mécanisme qui sépare le script DDL en requêtes individuelles. Chaque requête est soumise par une requête PQexec() séparée, ce qui ne pose plus de problème.