Avant d'enregistrer un serveur à un ensemble, assurez-vous d'avoir un processus slon(1) pour chacune des deux parties à savoir le fournisseur et pour le nouveau nœud de souscription. Si les démons slon respectifs ne sont pas en cours d'exécution, alors il ne se passera rien et vous vous éverturez à comprendre pourquoi cela ne fonctionne pas.

Ajouter un serveur à un ensemble de serveurs est fait en exécutant la commande SLONIK SUBSCRIBE SET(7) de slonik(1) . Il peut sembler tentant d'essayer de souscrire plusieurs nœuds à un ensemble dans un bloc d'essai simple comme celui-ci :

try {
  echo 'Subscribing sets';
  subscrifbe set (id = 1, provider=1, receiver=2, forward=yes);
  subscribe set (id = 1, provider=1, receiver=3, forward=yes);
  subscribe set (id = 1, provider=1, receiver=4, forward=yes);
} on error {
  echo 'Enregistrement du jeu des serveurs : impossible!';
  exit -1;
}

Mais vous êtes juste en train de vous demander quel est le souci en enregistrant les ensembles de serveurs de cette façon. La méthode appropriée exige de procéder à l'enregistrement des serveurs, à raison d'un seul à la fois, tout en examinant le journal de l'instance de la base de donnée, avant de vous occuper du prochain enregistrement. Il est également intéressant de noter que le « succès » dans l'essai slonik(1) ci-dessus, n'implique pas que les nœuds 2, 3, et 4 soient tous enregistrés avec succès. Il indique simplement que les commandes de slonik ont été reçues avec succès le démon slon fonctionnant sur le nœud d'origine.

Un cas typique de problème pouvant surgir est qu'un abonné en cascade, recherche un fournisseur qui n'est pas encore prêt. Dans ce cas d'échec, le nœud souscripteur ne deviendra jamais l'abonné. Il sera « bloquée » en attente d'un évènement déjà survenu. Les autres nœuds seront persuadés que, ce nœud bloqué s'est enregistré correctement (parce qu'aucune erreur ne leur est parvenu) ; la demande pour désabonner le nœud sera « bloqué » car le nœud en question est coincé en attente d'enregistrement.

Lorsque vous enregistrez un nœud à un ensemble de nœuds, vous devez voir quelque chose de ce genre dans les traces du démon slon pour le nœud fournisseur :

DEBUG2 remoteWorkerThread_3: Received event 3,1059 SUBSCRIBE_SET

Vous devriez également commencer à voir des messages de ce genre dans les traces du démon slon pour le nœud de souscription :

DEBUG2 remoteWorkerThread_1: copy table public.my_table

La copie de grandes tables entre le nœud de fournisseur et le nouvel abonné peut prendre un certain temps. Si vous vérifiez la table pg_stat_activity sur le nœud du fournisseur, vous devriez voir une requête qui copie la table vers stdout.

La table sl_subscribe pour le fournisseur comme pour le nouveau souscripteur, doit contenir un enregistrement pour le nouveau abonnement :

 sub_set | sub_provider | sub_receiver | sub_forward | sub_active
---------+--------------+--------------+-------------+------------
      1  |            1 |            2 |           t |         t

Un ultime test est d'insérer un enregistrement dans une des tables répliquées depuis le nœud d'origine, et de vérifier que cet enregistrement est bien répliqué chez le souscripteur.