SLONIK TABLE ADD KEY

Description

Dans un système de réplication Slony-I™, chaque table répliquée doit avoir au moins une contrainte UNIQUE dont les colonnes sont déclarées NOT NULL. N'importe quel clef primaire respecte ces pré-requis.

En dernier recours, dans les versions de Slony-I™ antérieures à la 2.0, cette commande peut être utilisée pour ajouter un attribut à une table qui ne possède par de clef primaire. Sachant que cette modification peut avoir des effets secondaires indésirables, il est très fortement recommandé que les utilisateurs ajoutent les attributs unique et not null par leurs propres moyens.

Si vous comptez utilisez Slony-I™ version 2.0, vous devez vous débrouiller pour définir une clef primaire plus adéquate. Slony-I™ ne vous en fournira pas une et si vous avez des clefs créées via TABLE ADD KEY, ne vous attendez pas à ce que Slony-I™ fonctionne correctement.

NODE ID = ival: Identifiant du nœud de l'ensemble de réplication d'origine où l'on ajoute la table dans l'ensemble (voir SLONIK SET ADD TABLE(7)).
FULLY QUALIFIED NAME = 'string': Le nom complet de la table composé du nom du schéma et du nom de la table, au format SQL suivant quote_ident(nspname) || '.' || quote_ident(relname).

Note

Pour le moment il existe des limitations; vous pouvez créer une table PostgreSQL™ avec aucune colonne, par exemple create table table_vide ();. Slony-I™ refusera de manipuler une telle table. Ce n'est pas vraiment une limitation gênante car il est n'est pas très intéressant de répliquer des tables qui ne contiennent aucune information.

Attention

TABLE ADD KEY ne doit pas être utilisée si vous pouvez vous en passer. C'est un élément des Best Practice.

L'absence d'une clef primaire adéquate est une indication très sérieuse que le schéma est défectueux. La bonne méthode pour le réparer est d'introduire un clef primaire adéquate, et non pas de demander à Slony-I™ d'en « bricoler » une.

Cette commande n'est pas supportée par le log shipping, et nous n'avons pas l'intention de développer ce support.

Cette commande utilise schemadoctableaddkey( text ).

Exemple

     TABLE ADD KEY ( NODE ID = 1, 
     FULLY QUALIFIED NAME = 'public.history' );

Utilisation de verrous

Sur le nœud origine, la commande posera un verrou exclusif sur la table modifiée tant que ces opérations ne seront pas terminées :

Modifier la table, ajouter la colonne ;
Modifier chaque ligne de la table, attacher la valeur de la séquence ;
Ajouter un nouvel index unique à la table.

Sur les nœuds abonnés, ces modifications sont réalisées sur la table lorsqu'elle est TODO, et perturbe pas particulièrement l'abonnement au cours du verrouillage sur le nœud abonné.

Si la table est volumineuse et fréquemment mise à jour par vos applications, cela imposera une coupure de service significative qui correspond au temps de modification de la table sur le nœud d'origine. C'est pourquoi il est recommandé que cette commande ne soit pas utilisée quand c'est possible.

Note de version

Cette commande fut introduite dans Slony-I™ 1.0.

Avertissement

Cette commande n'est plus supportée à partir de Slony-I™ version 2.0. Dans la version 2, les différentes « modifications du catalogue » réalisée sur les versions de PostgreSQL™ antérieures à la 8.3 sont éliminées afin que les exports de schéma puissent être utilisés sur n'importe quel nœud. Ainsi les colonnes « bricolées » par TABLE ADD KEY sont la chose qui empêche la commande SLONIK UNINSTALL NODE(7) d'être équivalente à la commande SQL drop schema _nom_du_cluster cascade;.

Documentation Slony-I 2.0.3 -

Commande de configuration et d'action