Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
230 lines (185 sloc) 7.9 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="dropthings">
<title>Supprimer des éléments de la réplication</title>
<indexterm><primary>retirer des objets de la réplication</primary></indexterm>
<para>
Il y a plusieurs objets que vous pouvez supprimer de la réplication &slony1;.
</para>
<sect2>
<title>Retirer un n&oelig;ud entier</title>
<indexterm><primary>retirer un n&oelig;ud de la réplication</primary></indexterm>
<para>
Si vous voulez retirer un n&oelig;ud entier de la replication, la commande
<xref linkend="stmtdropnode"/> de <xref linkend="slonik"/> fera l'affaire.
</para>
<para>
Cela provoque la suppression des triggers (en général ceux qui empêchent la
mise à jour des données), la restauration des triggers
<quote>originels</quote>, la suppression du schéma utilisé par &slony1; et
l'arrêt du processus <xref linkend="slon"/> lui-même.
</para>
<para>
La base de données sera alors disponible pour toute utilisation standard.
</para>
<para>
Il s'agit d'une opération majeure, avec un potentiel de destruction de données
considérable&nbsp;; assurez-vous de retirer le bon n&oelig;ud&nbsp;!
</para>
<para>
L'opération échouera s'il y a des n&oelig;uds abonnés au n&oelig;ud que vous
voulez retirer, ce qui constitue une petite sécurité contre les erreurs.
</para>
<para>
Le paragraphe «&nbsp;<link linkend="faq17"><envar>sl_log_1</envar> n'est pas
purgée</link>&nbsp;» de la FAQ décrit des tâches supplémentaires de
maintenance que vous devez effectuer sur <xref linkend="table.sl-confirm"/>
si vous utilisez une version antérieure à la version 1.0.5.
</para>
</sect2>
<sect2>
<title>Retirer un ensemble de réplication</title>
<indexterm><primary>retirer un ensemble de réplication</primary></indexterm>
<para>
Si vous souhaitez arrêter la réplication d'un ensemble de réplication
particulier, la commande <xref linkend="stmtdropset"/> de <xref
linkend="slonik"/> est faite pour vous.
</para>
<para>
Comme avec <xref linkend="stmtdropnode"/>, cela provoque le retrait des
triggers &slony1; sur les tables et la restauration des triggers
<quote>originels</quote>. La différence est que cela se produit sur
<emphasis>tous</emphasis> les n&oelig;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.
</para>
<para>
Cette opération est nettement plus dangereuse que <xref
linkend="stmtdropnode"/> car <emphasis>il n'y a pas</emphasis> de
<quote>sécurités</quote> équivalentes. Si vous demandez à <xref
linkend="stmtdropset"/> de retirer le <emphasis>mauvais</emphasis>
ensemble de réplication, il n'y a rien qui vous empêchera de réaliser
une opération qui pourrait avoir des effets <quote>malencontreux</quote>
sur les données et sur votre carrière. À manipuler avec précaution...
</para>
</sect2>
<sect2>
<title>Désabonner un n&oelig;ud d'un ensemble de réplication</title>
<indexterm><primary>désabonner un n&oelig;ud d'un ensemble de réplication</primary></indexterm>
<para>
L'opération <xref linkend="stmtunsubscribeset"/> est un peu moins puissante
que <xref linkend="stmtdropset"/> ou <xref linkend="stmtdropnode"/>&nbsp;;
elle implique la suppression des triggers &slony1; et la restauration des
triggers <quote>originels</quote> sur un seul n&oelig;ud, pour un seul
ensemble de réplication.
</para>
<para>
Tout comme <xref linkend="stmtdropnode"/>, cette opération échouera si un
n&oelig;ud est abonné à l'ensemble de réplication via le n&oelig;ud que vous
voulez retirer.
<warning>
<para>
Pour toutes les opérations ci-dessus, <quote>revenir en arrière</quote>
nécessitera une copie du n&oelig;ud à partir d'un ensemble de données
<emphasis>complet</emphasis> en provenance d'un fournisseur. Le fait que
les données aient été répliquées encore récemment ne suffit pas&nbsp;;
&slony1; voudra des données reconstituées à partir de zéro.
</para>
</warning>
</para>
</sect2>
<sect2>
<title> Retirer une table de la réplication</title>
<indexterm><primary>retirer une table de la réplication</primary></indexterm>
<sect3>
<title>En utilisant les outils altperl</title>
<para>
Si les outils <link linkend="altperl">altperl</link> sont installés, vous
pouvez utiliser le script d'aide <link
linkend="slonik-drop-table">slonik_drop_table</link> pour supprimer une table
dans un ensemble de réplication. Lancez simplement
<command>slonik_drop_table</command> sans arguments pour afficher la méthode
d'utilisation du script. Après avoir retiré la table, vous devez également la
retirer du fichier <filename>slon_tools.conf</filename>.
</para>
</sect3>
<sect3>
<title>En utilisant directement les commandes slonik</title>
<para>
À partir de &slony1; 1.0.5, il existe une commande Slonik <xref
linkend="stmtsetdroptable"/> qui permet de supprimer une table de la
réplication sans forcer l'utilisateur à supprimer la totalité de l'ensemble
de réplication.
</para>
<para>
Si vous utiliser une version antérieure, il y a une <quote>astuce</quote>
pour réaliser cela&nbsp;:
</para>
<para>
Vous pouvez réaliser cela <quote>à la main</quote> en trouvant l'identifiant
de la table dont vous voulez vous débarrasser, que vous pouvez trouver dans
<xref linkend="table.sl-table"/> et exécuter les trois requêtes suivantes sur
chaque hôte&nbsp;:
<programlisting>
select _slonyschema.alterTableRestore(40);
select _slonyschema.tableDropKey(40);
delete from _slonyschema.sl_table where tab_id = 40;
</programlisting>
</para>
<para>
Bien entendu, le nom du schéma dépend de celui qui a été défini pour le
cluster &slony1;. L'identifiant de la table, dans ce cas 40, doit être
remplacé par l'identifiant de la table que vous souhaitez retirer.
</para>
<para>
Vous devrez exécuter ces trois requêtes sur tous les n&oelig;uds, de
préférence en commençant par le n&oelig;ud d'origine, afin que l'événement
se propage correctement. Réaliser cette opération avec une commande <xref
linkend="slonik"/> pour un nouvel événement &slony1; permet de faire cela.
Soumettre les trois requêtes en utilisant <xref linkend="stmtddlscript"/>
permet cela également&nbsp;; se reporter au chapitre <xref
linkend="ddlchanges"/> pour plus de détails. Il est également possible de
se connecter à chaque base de données et de soumettre manuellement les
requêtes.
</para>
</sect3>
</sect2>
<sect2>
<title>Retirer une séquence de la réplication</title>
<indexterm><primary>retirer une séquence de la réplication</primary></indexterm>
<para>
À l'image de <xref linkend="stmtsetdroptable"/>, la version 1.0.5 introduit
l'opération <xref linkend="stmtsetdropsequence"/>.
</para>
<para>
Si vous utilisez une version antérieure, voici les instructions pour retirer
des séquences&nbsp;:
</para>
<para>
Ci-dessous les données nécessaires pour supprimer les séquence numérotées de
93 à 59&nbsp;:
<programlisting>
delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
delete from _oxrsorg.sl_sequence where seq_id in (93,59);
</programlisting>
</para>
<para>
Ces deux requêtes doivent être soumises à tous les n&oelig;uds via
&funddlscript; / <xref linkend="stmtddlscript"/>, afin d'éliminer la
séquence partout en <quote>même temps</quote>. Elles peuvent également être
appliquées à la main sur chaque n&oelig;ud.
</para>
</sect2>
<sect2>
<title>Vérifier la santé du cluster</title>
<para>
Après avoir exécuté ces procédures, exécuter le script &lteststate; du
répertoire <filename>tools</filename> 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.
</para>
</sect2>
</sect1>