14. Ajouter des objets à la réplication

Ajouter la nouvelle table sur chaque nœud.

En principe, le script SLONIK EXECUTE SCRIPT(7) peut être utilisé pour cela, mais en réalité cela provoque des problèmes d'inter-blocages et cela nécessite la modification de toutes les tables dans l'ensemble de réplication existant, sur tous les nœuds, ce qui fait que SLONIK EXECUTE SCRIPT(7) est une approche peu attrayante sur un serveur chargé. Ceci brise la règle de Slony-I™ qui dit qu'« il n'est pas nécessaire d'interrompre l'activité normale pour ajouter la réplication ».

À contrario, vous pouvez ajouter la table via psql sur chaque nœud.

Créer un nouvel ensemble de réplication avec SLONIK CREATE SET(7).

Ajouter la table dans le nouvel ensemble avec SLONIK SET ADD TABLE(7)

Demander l'abonnement de ce nouvel ensemble avec SLONIK SUBSCRIBE SET(7). S'il existe plusieurs nœuds, vous devez utiliser SLONIK SUBSCRIBE SET(7) une fois pour chaque nœud que vous voulez abonner.

Si vous voulez savoir de manière déterministe si un abonnement est complet, vous devez soumettre pour chaque abonnement un script slonik qui ressemble à cela :

SUBSCRIBE SET (ID=1, PROVIDER=1, RECEIVER=2);
WAIT FOR EVENT (ORIGIN=2, CONFIRMED = 1);
SYNC(ID = 1);
WAIT FOR EVENT (ORIGIN=1, CONFIRMED=2);

Une fois que les abonnements sont configurés de manière à ce que les abonnements du nouvel ensemble soient identiques à ceux de l'ancien ensemble, vous pouvez fusionner le nouveau et l'ancien avec la commande SLONIK MERGE SET(7).

Vous ne devez absolument jamais inclure des commandes de contrôle de transaction, notamment BEGIN et COMMIT, à l'intérieur de ces scripts. Slony-I™ encapsule les scripts DDL avec une paire BEGIN/COMMIT ; ajouter des opérateurs de contrôle de transaction supplémentaires implique que des parties des ordres DDL seront « validées » en dehors du contrôle de Slony-I™.

Avant la version 1.2, il était nécessaire d'être extrêmement restrictif sur ce qu'on envoyait au script SLONIK EXECUTE SCRIPT(7).

Il était interdit de placer du texte entre guillemets simples dans le script car cela l'empêchait d'être stocké et transmis correctement. À partir de la version 1.2, les guillemets simples sont correctement prises en compte.

Si vous soumettez une séries d'ordre DDL, les derniers ne peuvent pas faire référence aux objets créés par les premiers car tous les ordres sont soumis dans une requête unique, dont le plan d'exécution est basé sur l'état de la base de données au début, avant que les modifications ne soient effectuées. À partir de la version 1.2, il y a 12 ordres SQL, chacun est soumis individuellement ainsi la commande ALTER TABLE x ADD COLUMN c1 integer; peut désormais être suivie par ALTER TABLE x ALTER COLUMN c1 SET NOT NULL;.

Triggers de logs / Triggers de blocage de mises à jour

Le schéma « cluster » contenant les tables Slony-I™ indiquant l'état du nœud et diverses procédures stockées

Le processus slon(1) qui gère le nœud

Accessoirement, les scripts SQL, les scripts pl/pgsql et les binaires Slony-I™ qui font partie de la compilation de PostgreSQL™. (Bien sûr, cela complique la tache si vous souhaitez redémarrer la réplication ; il est peu probable que vous ayez besoin de supprimer ces fichiers...)

Vous pouvez utiliser la commande Slonik SLONIK DROP NODE(7) pour supprimer un nœud du cluster. Ceci provoquera la suppression des triggers et tout ce qui se trouve dans schéma cluster. Le processus slon(1) va mourir automatiquement.

Dans le cas d'un nœud en échec (lorsque vous avez utilisé la commande SLONIK FAILOVER(7) pour basculer sur un autre nœud), vous devrez peut-être utiliser SLONIK UNINSTALL NODE(7) pour supprimer les triggers, le schéma et les fonctions.

Si le nœud est en échec à cause d'une panne matérielle dramatique (par exemple si vos disques ont pris feu), il est possible qu'il n'y ait plus de traces de la base de données sur le nœud ; en général, la base ne survit que lorsque la panne matérielle est un problème de réseau qui n'endommage pas les données mais qui vous oblige à supprimer le nœud à cause de coupures réseau persistantes.

Si les opérations ci-dessus se sont particulièrement mal passée, vous pouvez lancer la commande SQL DROP SCHEMA "Nom_du_cluster" CASCADE; qui supprime toutes les fonctions, les tables et les triggers de Slony-I™. En général, c'est une opération moins pratique que SLONIK UNINSTALL NODE(7) car cette commande ne se contente pas de supprimer le schéma et son contenu, elle supprime également toutes les colonnes ajoutées avec la commande SLONIK TABLE ADD KEY(7).

Note

Dans Slony-I™ 2.0, SLONIK TABLE ADD KEY(7) n'est plus supporté et, du coup, SLONIK UNINSTALL NODE(7) consiste très simplement en des commandes DROP SCHEMA "Nom_du_cluster" CASCADE;.

Déterminer le numéro du nœud et les DSN adéquats pour le nœud. Utilisez la commande PostgreSQL™ createdb pour créer la base ; ajoutez les définitions des tables que vous voulez répliquer car Slony-I™ ne propage pas automatiquement cette information.

Si vous ne disposez pas d'un script SQL parfaitement propre pour ajouter les tables, alors vous pouvez utiliser l'outil slony1_extract_schema.sh situé dans le répertoire tools afin d'obtenir le schéma utilisateur sans les « morceaux » de Slony-I™.

Si le nœud était un nœud en échec, vous devez lancer la commande SLONIK DROP NODE(7) de slonik(1) afin de vous débarrasser de ses vestiges dans le cluster et de supprimer le schéma que Slony-I™ a créé.

Lancer la commande SLONIK STORE NODE(7) de slonik pour établir le nouveau nœud.

À cet instant, vous pouvez lancer le démon slon(1) sur le nouveau nœud. Il ne connaîtra rien des autres nœuds, donc les logs de ce nœud seront particulièrement calmes.

Lancer la commande slonik SLONIK STORE PATH(7) pour indiquer comment les processus slon(1) doivent communiquer avec le nouveau nœud. Dans la version 1.1 et suivante, cette commande génère automatiquement des lignes de la table des voies d'écoute. Dans les versions précédentes, vous devez utiliser SLONIK STORE LISTEN(7) pour les générer manuellement.

À cet instant, lancer le script Section 5.1, « test_slony_state » est une excellente idée. Ce script parcourt le cluster tout entier et pointe les anomalies qu'il trouve. Il peut notamment identifier une grande variété de problèmes de communication.

Lancer commande slonik SLONIK SUBSCRIBE SET(7) pour abonner le nœud à l'ensemble de réplication.

Regarder les logs des processus slon(1).

Ils ne vous diront pas grand chose, même à un niveau de débogage élevé sur le nœud origine. Au niveau 2 de débogage, vous devriez voir sur les abonnés les événements SYNCs qui sont en cours de traitement. À partir de la version 1.2, les informations sur le traitement des SYNC incluent le nombre de tables traitées, ainsi que le nombre de lignes insérées, supprimées et mises à jour.

Regarder dans la vue sl_status sur le nœud origine.

Cette vue indique quel est le retard des différents nœuds abonnés. Cette information n'est pertinente que sur un nœud origine.

Lancer le script Section 5.1, « test_slony_state » qui se trouve dans le répertoire tools. Ce script parcourt le cluster tout entier et pointe les anomalies qu'il détecte, ainsi que des informations sur le statut de chaque nœud.