 SLONIK FAILOVER
|
 
|
slon
|
EXECUTE SCRIPT — Exécute un script SQL/DDL
EXECUTE SCRIPT (options);
Cette commande exécute un script contenant des ordres SQL sur tous les nœuds qui sont abonnés à un ensemble de réplication à un point précis dans le flux des transactions.
L'origine de l'événement doit être l'origine de l'ensemble de réplication. Le fichier de script ne doit pas contenir d'ordres START ou COMMIT TRANSACTION. (Ceci change un peu avec PostgreSQL™ 8.0 puisque les transactions imbriquées, appelée également « points de sauvegarde » (« savepoints »), sont supportés. De plus, les ordres DML non déterministes (par exemple mettre à jour un champ avec la valeur CURRENT_TIMESTAMP) doivent être évitées car les changements effectués par ce script ne sont pas explicitement répliqués.
Le numéro unique de l'ensemble affecté par le script
Le nom du fichier contenant le script SQL à exécuter. Il peut s'agir d'un chemin relatif à l'emplacement de l'instance slonik que vous avez lancé ou, de préférence, un chemin absolu sur le système où slonik est lancé.
Le contenu de ce fichier est propagé dans un événement, donc il n'est pas nécessaire que le fichier soit accessible depuis les autres nœuds.
(Obligatoire) L'identifiant de l'origine courante de l'ensemble. La valeur par défaut est 1.
(Optionnel) L'identifiant du seul nœud qui doit exécuter le script. Cette option implique que le script sera propagé sur tous les nœuds mais exécuté sur un seul. Par défaut, on exécute le script sur tous les nœuds abonnés à l'ensemble de réplication.
Voir également les avertissements dans la section Section 17, « Changements du schéma de la base (DDL) ».
Notons qu'il s'agit d'une opération locking , ce qui signifie qu'elle peut être bloquée par l'activité d'une autre base.
Dans les versions de la branche 1.2, au démarrage de cet événement, toutes les tables répliquées sont déverrouillées par la fonction alterTableRestore(tab_id). Une fois le script SQL exécuté, elles sont remises en « mode réplication » avec alterTableForReplication(tab_id). Cela implique que toutes les tables sont verrouillées par ce processus pendant la durée du script SQL.
Si les colonnes d'une table sont modifiées, il est essentiel que les triggers soient régénérés (e.g. - par alterTableForReplication(tab_id)), sinon les attributs dans le trigger logtrigger() peuvent être inadaptés à la nouvelle forme du schéma.
Notez que si vous devez faire référence au nom du cluster, vous pouvez utiliser l'alias @CLUSTERNAME@ ; si vous devez faire référence au schéma Slony-I™, vous pouvez utiliser l'alias @NAMESPACE@ ; les deux seront remplacés par la valeur appropriée.
Cette commande utilise schemadocddlscript_complete( integer, text, integer ).
Sur les versions antérieures à la branche 2.0, un verrou exclusif est posé sur chaque table répliquée sur le nœud origine, afin de retirer les triggers de réplication. Une fois le script DDL achevé, ces verrous sont enlevés.
Une fois le script DDL exécuté sur le nœud origine, il est lancé sur les nœuds abonnés. Des verrous similaires sont posés sur tous les nœuds pour altérer les triggers des tables répliquées.
À partir de la branche 2.0, Slony-I™ utilise un GUC qui contrôle le comportement des triggers, ce qui permet de désactiver les triggers créés par Slony-I™ pendant l'opération sans poser de verrous exclusifs sur toutes les tables. Désormais, les seules tables qui sont verrouillées sont les tables qui sont effectivement modifiées par le script DDL.
Cette commande fut introduite dans Slony-I™ 1.0.
Avant la version 1.2, l'ensemble du script DDL était soumis dans une requête PQexec(), ce qui impliquait que le script tout entier était traité en se basant sur l'état de la base avant l'invocation du script. Cela signifie que des ordres placés à la fin d'un script ne pouvaient pas dépendre d'un ordre situé au début de ce même script. Ainsi, il n'était pas possible d'ajouter une colonne dans une table, puis une contrainte sur cette colonne au sein du même script.
Dans Slony-I™ version 1.2, le script DDL est découpé ordre par ordre, et chaque ordre est soumis séparément. Cela implique que les ordres de la fin du script peuvent se référer aux objets ou aux attributs créés et modifiés au début du script. De plus, dans la version 1.2, le résultat de sortie de slonik contient la liste des ordre au fur et à mesure de leur traitement sur le nœud d'origine de l'ensemble de réplication. De même, les ordres traités sont listés dans les logs de slon sur les autres nœuds.
Dans Slony-I™ version 1.0, cette commande verrouille uniquement les tables de l'ensemble spécifié. À partir de la version 1.1, toutes les tables répliquées sont verrouillées (c'est-à-dire que les triggers sont retirés au départ et restaurés à la fin). Ceci couvre les risques lorsqu'on lance une requête de changements DDL sur des tables appartenant à plusieurs ensemble de réplication.
Dans la version 2.0, la valeur par défaut pour EVENT NODE a été supprimée, donc un nœud doit être spécifié.