Find file
Fetching contributors…
Cannot retrieve contributors at this time
84 lines (73 sloc) 3.15 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="reshape">
<title>Restructurer un cluster</title>
<indexterm><primary>restructurer une réplication</primary></indexterm>
<para>
Si vous arrangez les n&oelig;uds afin qu'ils remplissent une fonction
différente, cela implique en général de modifier un peu les n&oelig;uds
abonnés.
</para>
<para>
Cela nécessitera plusieurs actions&nbsp;:
<itemizedlist>
<listitem>
<para>
Si vous voulez qu'un n&oelig;ud abonné devienne l'origine d'un
ensemble de réplication, vous devez effectuer une opération
<xref linkend="slonik"/> <command>MOVE SET</command>
appropriée.
</para>
</listitem>
<listitem>
<para>
Vous pouvez ensuite, ou à la place, modifier les abonnements des autres
n&oelig;uds. Vous pouvez modifier un n&oelig;ud pour obtenir les
données depuis un fournisseur différent, ou le modifier pour activer ou
désactiver le transfert des données. Cela s'accomplit en utilisant
l'opération slonik <xref linkend="stmtsubscribeset"/> avec les nouvelles
informations d'abonnement pour le n&oelig;ud;. &slony1; changera la
configuration&nbsp;; inutile de lancer <xref
linkend="stmtunsubscribeset"/>&nbsp;; inutile de recopier les données
depuis zéro&nbsp;; la requête modifiera l'abonnement <quote>à la
volée</quote> et préservera la cohérence des données entre les
n&oelig;uds.
</para>
</listitem>
<listitem>
<para>
Si les flux de données ont changé de direction, il est inévitable de
lancer une série d'opérations <xref linkend="stmtdroplisten"/> afin
de supprimer les chemins obsolètes entre les n&oelig;uds et <xref
linkend="stmtstorelisten"/> pour ajouter les nouveaux chemins.
Jusqu'à la version 1.1, ceci n'était pas modifié automatiquement&nbsp;;
depuis la version 1.1, <xref linkend="stmtmoveset"/> et <xref
linkend="stmtsubscribeset"/> changent les chemins automatiquement.
Voir <xref linkend="listenpaths"/> pour plus d'informations à ce propos.
Dans les versions 1.1 et suivantes, la génération des entrées de la
table <xref linkend="table.sl-listen"/> est entièrement automatisée,
elles sont donc regénérées lorsqu'une modification est effectuée sur
les tables <xref linkend="table.sl-path"/> ou
<xref linkend="table.sl-subscribe"/>, rendant ainsi inutile de se
préoccuper de <xref linkend="stmtstorelisten"/>.
</para>
</listitem>
<listitem>
<para>
Après avoir réalisé le changement de configuration, vous devriez, comme
<xref linkend="bestpractices"/>, exécuter les scripts &lteststate; pour
valider que l'état du cluster est resté bon après cette modification.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Les outils <filename>altperl</filename> incluent un script
<application>regenerate-listens</application> qui permet de créer les
nouvelles commandes <xref linkend="stmtstorelisten"/>&nbsp; cependant, il
n'est pas assez malin pour déterminer les chemins à supprimer.
</para>
</sect1>