Il y a plusieurs objets que vous pouvez supprimer de la réplication Slony-I™.
Si vous voulez retirer un nœud entier de la replication, la commande SLONIK DROP NODE(7) de slonik(1) fera l'affaire.
Cela provoque la suppression des triggers (en général ceux qui empêchent la mise à jour des données), la restauration des triggers « originels », la suppression du schéma utilisé par Slony-I™ et l'arrêt du processus slon(1) lui-même.
La base de données sera alors disponible pour toute utilisation standard.
Il s'agit d'une opération majeure, avec un potentiel de destruction de données considérable ; assurez-vous de retirer le bon nœud !
L'opération échouera s'il y a des nœuds abonnés au nœud que vous voulez retirer, ce qui constitue une petite sécurité contre les erreurs.
Le paragraphe « sl_log_1 n'est pas purgée » de la FAQ décrit des tâches supplémentaires de maintenance que vous devez effectuer sur sl_confirm si vous utilisez une version antérieure à la version 1.0.5.
Si vous souhaitez arrêter la réplication d'un ensemble de réplication particulier, la commande SLONIK DROP SET(7) de slonik(1) est faite pour vous.
Comme avec SLONIK DROP NODE(7), cela provoque le retrait des triggers Slony-I™ sur les tables et la restauration des triggers « originels ». La différence est que cela se produit sur tous les nœuds du cluster, plutôt que sur un seul. Une autre différence est que cela ne nettoie pas les autres schémas du cluster car ils sont toujours utilisés.
Cette opération est nettement plus dangereuse que SLONIK DROP NODE(7) car il n'y a pas de « sécurités » équivalentes. Si vous demandez à SLONIK DROP SET(7) de retirer le mauvais ensemble de réplication, il n'y a rien qui vous empêchera de réaliser une opération qui pourrait avoir des effets « malencontreux » sur les données et sur votre carrière. À manipuler avec précaution...
L'opération SLONIK UNSUBSCRIBE SET(7) est un peu moins puissante que SLONIK DROP SET(7) ou SLONIK DROP NODE(7) ; elle implique la suppression des triggers Slony-I™ et la restauration des triggers « originels » sur un seul nœud, pour un seul ensemble de réplication.
Tout comme SLONIK DROP NODE(7), cette opération échouera si un nœud est abonné à l'ensemble de réplication via le nœud que vous voulez retirer.
Pour toutes les opérations ci-dessus, « revenir en arrière » nécessitera une copie du nœud à partir d'un ensemble de données complet en provenance d'un fournisseur. Le fait que les données aient été répliquées encore récemment ne suffit pas ; Slony-I™ voudra des données reconstituées à partir de zéro.
Si les outils altperl sont installés, vous pouvez utiliser les scripts d'aide slonik_drop_table et slonik_drop_sequence pour supprimer une table ou une séquence de la réplication. Exécutez simplement slonik_drop_table (ou slonik_drop_sequence) sans arguments pour afficher la syntaxe d'exécution du script. Après avoir supprimé la table, vous devez aussi la supprimer du fichier de configuration slon_tools.conf.
À partir de Slony-I™ 1.0.5, il existe une commande Slonik SLONIK SET DROP TABLE(7) qui permet de supprimer une table de la réplication sans forcer l'utilisateur à supprimer la totalité de l'ensemble de réplication.
Si vous utiliser une version antérieure, il y a une « astuce » pour réaliser cela :
Vous pouvez réaliser cela « à la main » en trouvant l'identifiant de la table dont vous voulez vous débarrasser, que vous pouvez trouver dans sl_table et exécuter les trois requêtes suivantes sur chaque hôte :
select _slonyschema.alterTableRestore(40); select _slonyschema.tableDropKey(40); delete from _slonyschema.sl_table where tab_id = 40;
Bien entendu, le nom du schéma dépend de celui qui a été défini pour le cluster Slony-I™. L'identifiant de la table, dans ce cas 40, doit être remplacé par l'identifiant de la table que vous souhaitez retirer.
Vous devrez exécuter ces trois requêtes sur tous les nœuds, de préférence en commençant par le nœud d'origine, afin que l'événement se propage correctement. Réaliser cette opération avec une commande slonik(1) pour un nouvel événement Slony-I™ permet de faire cela. Soumettre les trois requêtes en utilisant SLONIK EXECUTE SCRIPT(7) permet cela également ; se reporter au chapitre Section 17, « Changements du schéma de la base (DDL) » pour plus de détails. Il est également possible de se connecter à chaque base de données et de soumettre manuellement les requêtes.
À l'image de SLONIK SET DROP TABLE(7), la version 1.0.5 introduit l'opération SLONIK SET DROP SEQUENCE(7).
Si vous utilisez une version antérieure, voici les instructions pour retirer des séquences :
Ci-dessous les données nécessaires pour supprimer les séquence numérotées de 93 à 59 :
delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59); delete from _oxrsorg.sl_sequence where seq_id in (93,59);
Ces deux requêtes doivent être soumises à tous les nœuds via schemadocddlscript_complete( integer, text, integer ) / SLONIK EXECUTE SCRIPT(7), afin d'éliminer la séquence partout en « même temps ». Elles peuvent également être appliquées à la main sur chaque nœud.
Après avoir exécuté ces procédures, exécuter le script Section 5.1, « test_slony_state » du répertoire tools est une excellente idée. Il parcourt tout le cluster, pointant toutes les anomalies qu'il trouve. Parmi celles-ci se trouvent aussi des tests sur les problèmes de communication.