[Trad] [svn:pgfr] r1117 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Ven 8 Aou 09:46:52 CEST 2008
Author: daamien
Date: 2008-08-08 09:46:52 +0200 (Fri, 08 Aug 2008)
New Revision: 1117
Modified:
traduc/trunk/slony/failover.xml
Log:
slony : failover.xml : 1ere traduction (a relire)
Modified: traduc/trunk/slony/failover.xml
===================================================================
--- traduc/trunk/slony/failover.xml 2008-08-07 12:40:34 UTC (rev 1116)
+++ traduc/trunk/slony/failover.xml 2008-08-08 07:46:52 UTC (rev 1117)
@@ -5,104 +5,102 @@
révision $Revision$ -->
<sect1 id="failover">
-<title>Doing switchover and failover with &slony1;</title>
-<indexterm><primary>failover</primary>
- <secondary>switchover</secondary>
+<title>Effectuer une bascule d'urgence avec &slony1;</title>
+<indexterm><primary>bascule d'urgence</primary>
+ <secondary>reprise sur panne</secondary>
</indexterm>
-<sect2><title>Foreword</title>
+<sect2><title>Avant-propos</title>
-<para>&slony1; is an asynchronous replication system. Because of
-that, it is almost certain that at the moment the current origin of a
-set fails, the final transactions committed at the origin will have
-not yet propagated to the subscribers. Systems are particularly
-likely to fail under heavy load; that is one of the corollaries of
-Murphy's Law. Therefore the principal goal is to
-<emphasis>prevent</emphasis> the main server from failing. The best
-way to do that is frequent maintenance.</para>
+<para>&slony1; est un système de réplication asynchrone. À cause de cela,
+ il est presque certain qu'au moment ou le noeud origine d'un ensemble de réplication
+ tombe en panne, la dernière transaction <quote>committée</quote> sur
+ l'origine ne soit pas encore propagée aux abonnés. Les systèmes qui tombent
+ en panne souvent soumis à une forte charge; c'est une des corollaires de la
+ loi de Murphy. Ainsi le but principal est d'<emphasis>éviter</emphasis> que le serveur principal
+ tombe en panne. La meilleur façon d'éviter cela est d'effectuer une
+ maintenance fréquente.</para>
-<para> Opening the case of a running server is not exactly what we
-should consider a <quote>professional</quote> way to do system
-maintenance. And interestingly, those users who found it valuable to
-use replication for backup and failover purposes are the very ones
-that have the lowest tolerance for terms like <quote>system
-downtime.</quote> To help support these requirements, &slony1; not
-only offers failover capabilities, but also the notion of controlled
-origin transfer.</para>
+<para> Ouvrir le capot d'un serveur à chaud n'est pas ce qu'on peut
+ une façon <quote>professionelle</quote> d'assurer la maintenance d'un système.
+ En général, les utilisateurs qui ont besoin de réplication pour
+ leur sauvegarde ou leur plan de reprise sur panne, ont également des critères
+ très stricts en matière de <quote> temps d'arrêt du système</quote>.
+ Pour répondre à ces critères, &slony1; ne se contente de fournir des
+ méthodes de reprise sur panne, il intègre également la notion de
+ transfert d'origine.</para>
-<para> It is assumed in this document that the reader is familiar with
-the <xref linkend="slonik"/> utility and knows at least how to set up a
-simple 2 node replication system with &slony1;.</para></sect2>
+<para> On suppose dans cette partie que le lecteur est familier avec l'utilitaire <xref linkend="slonik"/>
+ et qu'il sait comment mettre en place une système de réplication &slony1; composé de deux noeuds.
+</para></sect2>
-<sect2><title> Controlled Switchover</title>
+<sect2><title>Bascule contrôlée</title>
<indexterm>
- <primary>controlled switchover</primary>
+ <primary>bascule contrôlée</primary>
</indexterm>
-<para> We assume a current <quote>origin</quote> as node1 with one
-<quote>subscriber</quote> as node2 (<emphasis>e.g.</emphasis> -
-slave). A web application on a third server is accessing the database
-on node1. Both databases are up and running and replication is more
-or less in sync. We do controlled switchover using <xref
-linkend="stmtmoveset"/>.
+<para> Imaginons un noeud <quote>origine</quote>, appelé noeud1, avec un
+ <quote>abonné</quote> appelé noeud2 (l'esclave). Une application web, placée
+ sur un troisième serveur, accède à la base de données sur noeud1.
+ Les deux bases sont actives et fonctionnelles, la réplication est
+ est à peu près synchronisée. On contrôle la bascule avec la commande
+ <xref linkend="stmtmoveset"/>.
</para>
<itemizedlist>
-<listitem><para> At the time of this writing switchover to another
-server requires the application to reconnect to the new database. So
-in order to avoid any complications, we simply shut down the web
-server. Users who use <application>pg_pool</application> for the
-applications database connections merely have to shut down the
-pool.</para>
+<listitem><para> Au moment ou nous écrivons ces lignes, basculer
+ vers un autre serveur nécessite que l'application se reconnecte
+ à la nouvelle base de donnée. Donc pour éviter toute complication,
+ nous éteignons le serveur web. Les utilisateurs qui ont installé
+ <application>pg_pool</application> pour gérer les connexions peuvent
+ simplement éteindre le pool.</para>
-<para> What needs to be done, here, is highly dependent on the way
-that the application(s) that use the database are configured. The
-general point is thus: Applications that were connected to the old
-database must drop those connections and establish new connections to
-the database that has been promoted to the <quote>/master/</quote> role. There
-are a number of ways that this may be configured, and therefore, a
-number of possible methods for accomplishing the change:
+<para> Les actions à mener dépendent beaucoup de la configuration des applications qui utilisent
+ la base de données. En général, les applications qui étaient connectées à
+ l'ancienne base doivent détruire leurs connexions et en établir de nouvelles
+ vers la base qui vient d'être promue dans le rôle du <quote>/maître/</quote> rôle.
+ Il y a différentes façon de configurer cela, et donc différentes façon d'effectuer
+ la bascule :
</para>
</listitem>
<itemizedlist>
-<listitem><para> The application may store the name of the database in
-a file.</para>
+<listitem><para> L'application stocke le nom de la base de donnée dans un fichier.</para>
-<para> In that case, the reconfiguration may require changing the
-value in the file, and stopping and restarting the application to get
-it to point to the new location.
+<para> Dans ce cas, la reconfiguration nécessite de changer la valeur dans ce fichier, d'arrêter
+ puis de relancer l'application pour qu'elle pointe vers le nouvel emplacement des données.
</para> </listitem>
-<listitem><para> A clever usage of DNS might involve creating a CNAME
-<ulink url="http://www.iana.org/assignments/dns-parameters"> DNS
-record </ulink> that establishes a name for the application to use to
-reference the node that is in the <quote>master</quote> role.</para>
+<listitem><para> Une utilisation pertinente de DNS consiste à créer
+<ulink url="http://www.iana.org/assignments/dns-parameters"> champs DNS </ulink>
+CNAME qui permet à l'application d'utiliser un nom pour référencer le noeud
+qui joue le rôle du noeud <quote>maître</quote>.</para>
-<para> In that case, reconfiguration would require changing the CNAME
-to point to the new server, and possibly restarting the application to
-refresh database connections.
+<para> Dans ce cas, la reconfiguration nécessite de changer le CNAME
+pour point et vers le nouveau serveur, de plus il faut probablement relancer
+l'application pour rafraîchir les connexions à la base.
</para> </listitem>
-<listitem><para> If you are using <application>pg_pool</application> or some
-similar <quote>connection pool manager,</quote> then the reconfiguration
-involves reconfiguring this management tool, but is otherwise similar
-to the DNS/CNAME example above. </para> </listitem>
+<listitem><para> si vous utilisez <application>pg_pool</application> ou
+ un <quote>gestionnaire de connexion</quote> similaire, alors la reconfiguration
+ implique de modifier le paramètre de cet outil, à part cela la procédure est similaire
+ à l'exemple DNS/CNAME ci-dessus. </para> </listitem>
</itemizedlist>
-<para> Whether or not the application that accesses the database needs
-to be restarted depends on how it is coded to cope with failed
-database connections; if, after encountering an error it tries
-re-opening them, then there may be no need to restart it. </para>
+<para> Le nécessité de redémarrer l'application qui se connecte à la base dépend
+ de la manière dont elle a été conçu et des mécanismes de gestion d'erreurs de
+ connexion qui ont été implémentés; si à la suite d'une erreur elle tente
+ d'ouvrir à nouveau un connexion, alors il n'est pas nécessaire de la relancer.
+ </para>
-<listitem><para> A small <xref linkend="slonik"/> script executes the
-following commands:
-
+<listitem><para> Un petit script <xref linkend="slonik"/> exécute les commandes
+ suivantes :
+
<programlisting>
lock set (id = 1, origin = 1);
wait for event (origin = 1, confirmed = 2);
@@ -110,240 +108,244 @@
wait for event (origin = 1, confirmed = 2);
</programlisting></para>
-<para> After these commands, the origin (master role) of data set 1
-has been transferred to node2. And it is not simply transferred; it
-is done in a fashion such that node1 becomes a fully synchronized
-subscriber, actively replicating the set. So the two nodes have
-switched roles completely.</para></listitem>
+<para> Après ces commandes, l'origine ( le rôle du maître) de l'ensemble de réplication 1
+est transféré sur le noeud 2. En fait elle n'est pas simplement transférée; le noeud1 devient
+un abonné parfaitement synchronisé et actif. En clair, les deux noeuds ont échangé
+leurs rôles respectifs.</para></listitem>
-<listitem><para> After reconfiguring the web application (or
-<application><link linkend="pgpool"> pgpool </link></application>) to
-connect to the database on node2, the web server is restarted and
-resumes normal operation.</para>
+<listitem><para> Après la reconfiguration de l'application web (ou
+de <application><link linkend="pgpool"> pgpool </link></application>) pour
+qu'elle se connecte à la base du noeud 2, le serveur web est redémarré et
+reprend son activité normale.</para>
-<para> Done in one shell script, that does the application shutdown,
-<application>slonik</application>, move config files and startup all
-together, this entire procedure is likely to take less than 10
-seconds.</para></listitem>
+<para> Lorsqu'on utilise un script shell, pour stopper l'application,
+ lancer le script <application>slonik</application>, déplacer les fichiers de configuration
+ et relancer l'ensemble, toute la procédure prend en général moins de 10
+secondes.</para></listitem>
</itemizedlist>
-<para> You may now simply shutdown the server hosting node1 and do
-whatever is required to maintain the server. When <xref
-linkend="slon"/> node1 is restarted later, it will start replicating
-again, and soon catch up. At this point the procedure to switch
-origins is executed again to restore the original
-configuration.</para>
+<para> Vous pouvez désormais éteindre le serveur qui héberge le noeud 1 et
+ effectuer les opérations de maintenance requise. Lorsque le démon <xref
+linkend="slon"/> du noeud 1 est redémarré, il reprend la réplication,
+ et rattrape son retard. Une fois synchronisé, on peut exécuter la procédure
+ à nouveau pour restaurer la configuration originale.</para>
-<para> This is the preferred way to handle things; it runs quickly,
-under control of the administrators, and there is no need for there to
-be any loss of data.</para>
+<para> Ceci est la meilleure méthode pour ce genre d'opération de maintenance;
+ Elle s'effectue rapidement, sous le contrôle d'un administrateur, et elle
+ n'implique aucune perte de données.</para>
</sect2>
-<sect2><title> Failover</title>
+<sect2><title>Bascule d'urgence</title>
<indexterm>
- <primary>failover due to system failure</primary>
+ <primary>Bascule suite à une panne du système</primary>
</indexterm>
-<para> If some more serious problem occurs on the
-<quote>origin</quote> server, it may be necessary to <xref
-linkend="stmtfailover"/> to a backup server. This is a highly
-undesirable circumstance, as transactions <quote>committed</quote> on
-the origin, but not applied to the subscribers, will be lost. You may
-have reported these transactions as <quote>successful</quote> to
-outside users. As a result, failover should be considered a
-<emphasis>last resort</emphasis>. If the <quote>injured</quote>
-origin server can be brought up to the point where it can limp along
-long enough to do a controlled switchover, that is
-<emphasis>greatly</emphasis> preferable.</para>
+<para> Lorsque de graves problèmes apparaissent sur le serveur
+<quote>origine</quote>, il est parfois nécessaire d'effectuer une
+bascule ( <xref linkend="stmtfailover"/> ) vers le serveur de sauvegarde.
+C'est cas de figure qui n'a rien de souhaitable, car les transactions
+<quote>committées</quote> sur le serveur mais pas sur les abonnés, seront
+perdues. Certaines de ces transactions auront peut-être été annoncées
+à l'utilisateur final comme <quote>validées</quote>. En conséquence, les
+bascules d'urgence doivent être considérées comme un
+<emphasis>dernier recours</emphasis>. Le serveur origine
+qui subit <quote>l'avarie</quote> peut être maintenu assez longtemps, il est
+<emphasis>nettement</emphasis>
+préférable d'effectuer une bascule contrôlée.</para>
-<para> &slony1; does not provide any automatic detection for failed
-systems. Abandoning committed transactions is a business decision
-that cannot be made by a database system. If someone wants to put the
-commands below into a script executed automatically from the network
-monitoring system, well ... it's <emphasis>your</emphasis> data, and
-it's <emphasis>your</emphasis> failover policy. </para>
+<para> &slony1; ne fournit pas de moyen de détection des pannes du système.
+ Abandonner des transactions <quote>committées</quote> est une décision
+ commerciale qui ne peut pas être prise par un système de gestion de base de données.
+ Si vous voulez placer les commandes ci-dessous dans un script exécuté
+ automatiquement par un système de surveillance, et bien .... ce sont
+ <emphasis>vos</emphasis> données, et <emphasis>votre</emphasis> politique
+ de bascule d'urgence. </para>
<itemizedlist>
<listitem>
-<para>The <xref linkend="slonik"/> command
+<para>La commande <xref linkend="slonik"/>
<programlisting>
failover (id = 1, backup node = 2);
</programlisting>
</para>
-<para> causes node2 to assume the ownership (origin) of all sets that
-have node1 as their current origin. If there should happen to be
-additional nodes in the &slony1; cluster, all direct subscribers of
-node1 are instructed that this is happening.
-<application>Slonik</application> will also query all direct
-subscribers in order to determine out which node has the highest
-replication status (<emphasis>e.g.</emphasis> - the latest committed
-transaction) for each set, and the configuration will be changed in a
-way that node2 first applies those final before actually allowing
-write access to the tables.</para>
+<para> ordonne au noeud 2 de se considérer comme le propriétaire
+ (l'origine) de tous les sets que le noeud 1 possédait. Si il
+ existe des noeuds supplémentaire dans le cluster &slony1;
+ Tous les noeuds abonnés au noeud 1 sont avertis du changement.
+ <application>Slonik</application> va aussi envoyer une requête
+ à chaque abonné pour déterminer quel noeud à le plus haut niveau
+ de synchronisation (<emphasis>c'est à dire</emphasis> - la dernière
+ transaction <quote>committée</quote>) pour chaque ensemble de réplication.
+ et la configuration sera changé de façon à ce que le noeud 2 applique
+ d'abord ces transactions finales, avant d'autoriser l'accès en écriture
+ sur les tables.</para>
-<para> In addition, all nodes that subscribed directly to node1 will
-now use node2 as data provider for the set. This means that after the
-failover command succeeded, no node in the entire replication setup
-will receive anything from node1 any more.</para>
+<para> De plus, tous les noeuds qui étaient abonnés directement au noeud 1
+ considéreront désormais le noeud 2 comme leur fournisseur de données
+ pour cet ensemble de replication. Cela signifie qu'une fois que la
+ commande de bascule d'urgence est complétée, plus aucun noeud du cluster ne
+ reçoit d'information de la part du noeud 1.</para>
</listitem>
<listitem>
-<para> Reconfigure and restart the application (or
-<application>pgpool</application>) to cause it to reconnect to
-node2.</para>
+<para> Reconfigurer et relancer l'application ( ou
+<application>pgpool</application>) pour qu'elle se reconnecte
+au noeud 2.</para>
</listitem>
-<listitem> <para> Purge out the abandoned node </para>
+<listitem> <para> Purger le noeud abandonné </para>
-<para> You will find, after the failover, that there are still a full
-set of references to node 1 in <xref linkend="table.sl-node"/>, as well
-as in referring tables such as <xref linkend="table.sl-confirm"/>;
-since data in <xref linkend="table.sl-log-1"/> is still present,
-&slony1; cannot immediately purge out the node. </para>
+<para> Vous découvrirez, après la bascule, qu'il existe encore
+ beaucoup de références au noeud 1 dans la table <xref linkend="table.sl-node"/>,
+ ainsi que ses tables associées telle que <xref linkend="table.sl-confirm"/>;
+ puisque des données sont toujours présentes dans <xref linkend="table.sl-log-1"/>,
+ &slony1; ne peut pas purger immédiatement le noeud. </para>
-<para> After the failover is complete and node2 accepts
-write operations against the tables, remove all remnants of node1's
-configuration information with the <xref linkend="stmtdropnode"/>
-command:
+<para> Une fois que la bascule sera complète et que le noeud 2 accepte
+ les opérations d'écriture sur les tables répliquées, il faut supprimer
+ toutes informations de configuration rémanentes avec la commande
+ <xref linkend="stmtdropnode"/> :
<programlisting>
drop node (id = 1, event node = 2);
</programlisting>
</para>
-<para> Supposing the failure resulted from some catastrophic failure
-of the hardware supporting node 1, there might be no
-<quote>remains</quote> left to look at. If the failure was not
-<quote>total</quote>, as might be the case if the node had to be
-abandoned due to a network communications failure, you will find that
-node 1 still <quote>imagines</quote> itself to be as it was before the
-failure. See <xref linkend="rebuildnode1"/> for more details on the
-implications.</para>
+<para> Supposons que la panne résulte d'un problème matériel catastrophique
+ sur le noeud 1, il est possible qu'il ne <quote>reste</quote> plus
+ rien sur le noeud 1. Si la panne n'est pas <quote>totale</quote>,
+ ce qui est souvent le cas lors d'une coupure réseau, vous découvrirez
+ que le noeud 1 <quote>imagine</quote> toujours que rien n'a changé
+ et qu'il est dans le même état qu'avant la panne. Reportez-vous à la
+ section <xref linkend="rebuildnode1"/> pour plus de détails sur ce
+ que cela implique.</para>
</listitem>
</itemizedlist>
</sect2>
-<sect2><title> Automating <command> FAIL OVER </command> </title>
+<sect2><title> Automatisation de la commande <command> FAIL OVER </command> </title>
-<indexterm><primary>automating failover</primary></indexterm>
+<indexterm><primary>automatisation des bascules d'urgence</primary></indexterm>
-<para> If you do choose to automate <command>FAIL OVER </command>, it
-is important to do so <emphasis>carefully.</emphasis> You need to have
-good assurance that the failed node is well and truly failed, and you
-need to be able to assure that the failed node will not accidentally
-return into service, thereby allowing there to be two nodes out there
-able to respond in a <quote>master</quote> role. </para>
+<para> Si vous choisissez d'automatiser la commande <command>FAIL OVER </command>,
+ il est important de le faire <emphasis>avec soin</emphasis>. Vous
+ devez être sur que le noeud en panne est réellement en panne, et vous
+ être capable de vous assurer que le noeud en panne ne redémarre pas,
+ ce qui entraînerait un conflit entre deux noeuds capables
+ de jouer le rôle du <quote>maître</quote>. </para>
-<note> <para> The problem here requiring that you <quote>shoot the
-failed node in the head</quote> is not fundamentally about replication
-or &slony1;; &slony1; handles this all reasonably gracefully, as once
-the node is marked as failed, the other nodes will <quote>shun</quote>
-it, effectively ignoring it. The problem is instead with
-<emphasis>your application.</emphasis> Supposing the failed node can
-come back up sufficiently that it can respond to application requests,
-<emphasis>that</emphasis> is likely to be a problem, and one that
-hasn't anything to do with &slony1;. The trouble is if there are two
-databases that can respond as if they are <quote>master</quote>
-systems. </para> </note>
+<note> <para> Le fait de <quote>tirer une balle dans la
+ tête du serveur en panne</quote> ne pose pas directement
+de problème à la réplication ou à &slony1;; &slony1; supporte
+cela de manière assez gravieuse, car une fois qu'une est marqué
+comme étant en panne, les autres noeuds <quote>l'oublier</quote>
+et l'ignorer. Le problème se situe plutôt au niveau de
+<emphasis>votre application</emphasis>.
+Supposons que le noeud en panne soit capable de répondre
+aux requêtes de votre application, <emphasis>cela</emphasis>
+va certainement poser un problème qui n'a rien à voir avec &slony1;.
+Le problème est que deux bases de données sont en mesure de répondre
+en tant que <quote>maître</quote>. </para> </note>
-<para> When failover occurs, there therefore needs to be a mechanism
-to forcibly knock the failed node off the network in order to prevent
-applications from getting confused. This could take place via having
-an SNMP interface that does some combination of the following:
+<para> Lorsqu'une bascule d'urgence est effectuée, il faut un
+ mécanisme pour dégager de force le noeud en panne hors du réseau
+ afin d'éviter toute confusion au niveau des applications.
+ Cela peut être fait via une interface SNMP qui effectue
+ une partie des opérations suivantes :
<itemizedlist>
-<listitem><para> Turns off power on the failed server. </para>
+<listitem><para> Éteindre l'alimentation du serveur en panne. </para>
-<para> If care is not taken, the server may reappear when system
-administrators power it up. </para>
+<para> Si l'on en fait attention, le serveur peut réapparaître dans le
+ système de réplication lorsque les administrateurs le rallume. </para>
</listitem>
-<listitem><para> Modify firewall rules or other network configuration
-to drop the failed server's IP address from the network. </para>
+<listitem><para> Modifier de règles de pare-feu ou d'autres configuration
+ pour exclure du réseau l'adresse IP du serveur en panne. </para>
-<para> If the server has multiple network interfaces, and therefore
-multiple IP addresses, this approach allows the
-<quote>application</quote> addresses to be dropped/deactivated, but
-leave <quote>administrative</quote> addresses open so that the server
-would remain accessible to system administrators. </para> </listitem>
+<para> Si le serveur a de multiples interfaces, et donc de multiple adresses IP,
+ cette approche permet de supprimer/désactiver les adresses utilisées l'application,
+ tout en conservant les adresses <quote>administratives</quote> afin
+ que le serveur reste accessible par les administrateurs systèmes.
+</para> </listitem>
</itemizedlist>
</para>
</sect2>
-<sect2 id="rebuildnode1"><title>After Failover, Reconfiguring
-Former Origin</title>
+<sect2 id="rebuildnode1"><title>Après la bascule d'urgence, reconfiguration
+de l'ancienne origine</title>
-<indexterm><primary>rebuilding after failover</primary></indexterm>
+<indexterm><primary>reconstruction après une bascule d'urgence</primary></indexterm>
-<para> What happens to the failed node will depend somewhat on the
-nature of the catastrophe that lead to needing to fail over to another
-node. If the node had to be abandoned because of physical destruction
-of its disk storage, there will likely not be anything of interest
-left. On the other hand, a node might be abandoned due to the failure
-of a network connection, in which case the former
-<quote>provider</quote> can appear be functioning perfectly well.
-Nonetheless, once communications are restored, the fact of the
-<command>FAIL OVER</command> makes it mandatory that the failed node
-be abandoned. </para>
+<para> Ce qui arrive au noeud en panne dépend beaucoup de la nature de la catastrophe
+ qui a conduit à la bascule d'urgence vers un autre noeud. Si le noeud
+ a été abandonné à cause de la destruction physique des disques de stockage,
+ il n'y a plus grand-chose à faire. D'un autre coté, si un noeud a été abandonné
+ à cause d'une coupure réseau, qui n'a pas perturbé le fonctionnement normal
+ du noeud <quote>fournisseur</quote>. Toutefois une fois que les communications
+ sont restaurées, le fait est que le commande <command>FAIL OVER</command>
+ rend obligatoire l'abandon du noeud qui était en panne.</para>
-<para> After the above failover, the data stored on node 1 will
-rapidly become increasingly out of sync with the rest of the nodes,
-and must be treated as corrupt. Therefore, the only way to get node 1
-back and transfer the origin role back to it is to rebuild it from
-scratch as a subscriber, let it catch up, and then follow the
-switchover procedure.</para>
+<para> Après ce genre de bascule d'urgence, les données stockées sur le
+ noeud 1 seront rapidement et de plus en plus désynchronisées.
+ par rapport aux autres noeuds. Elles doivent être considérées comme
+ corrompues. Ainsi le seul moyen pour que le noeud 1 retourne dans
+ le cluster de réplication et qu'il redevienne le noeud origine est de
+ le reconstruire à partir de zéro comme un abonné, de le laisser rattraper
+ son retard, puis d'effectuer la procédure de bascule contrôlée.
+ </para>
-<para> A good reason <emphasis>not</emphasis> to do this automatically
-is the fact that important updates (from a
-<emphasis>business</emphasis> perspective) may have been
-<command>commit</command>ted on the failing system. You probably want
-to analyze the last few transactions that made it into the failed node
-to see if some of them need to be reapplied on the <quote>live</quote>
-cluster. For instance, if someone was entering bank deposits
-affecting customer accounts at the time of failure, you wouldn't want
-to lose that information.</para>
+<para> Une bonne raison de <emphasis>ne pas</emphasis> faire cela
+ automatiquement est que d'importante mises à jour ( d'un point de
+ vue <emphasis>commercial</emphasis> ) ont pu être
+<quote>committée</quote> sur le système en panne.
+Vous souhaiterez probablement analyser les dernières transactions que
+le noeud a réalisé avant de tomber en panne, afin de voir si certaines
+doivent être ré-appliquer sur le cluster <quote>actif</quote>.
+Par exemple, si quelqu'un réalisait des opérations bancaires impactant
+des comptes clients au moment de la panne, il est souhaitable de
+ne pas perdre cette information.</para>
-<warning> <para> It has been observed that there can be some very
-confusing results if a node is <quote>failed</quote> due to a
-persistent network outage as opposed to failure of data storage. In
-such a scenario, the <quote>failed</quote> node has a database in
-perfectly fine form; it is just that since it was cut off, it
-<quote>screams in silence.</quote> </para>
+<warning> <para> On a observé certains résultats étranges lorsqu'un
+ noeud <quote>tombe en panne</quote> à cause d'une coupure réseau persistante,
+ par opposition aux pannes du système de stockage. Dans de tel scénarios,
+ le noeud <quote>en panne</quote> dispose d'une base de données en
+ parfait état de marche; le fait est qu'ayant été coupé des autres noeuds,
+ il <quote>crie en silence</quote>. </para>
-<para> If the network connection is repaired, that node could
-reappear, and as far as <emphasis>its</emphasis> configuration is
-concerned, all is well, and it should communicate with the rest of its
-&slony1; cluster. </para>
+<para> Lorsque la connexion réseau est réparée, ce noeud peut réapparaître
+ et conformément <emphasis>sa</emphasis> configuration, il va communiquer avec les
+ autres noeuds du cluster &slony1;. </para>
-<para> In <emphasis>fact</emphasis>, the only confusion taking place
-is on that node. The other nodes in the cluster are not confused at
-all; they know that this node is <quote>dead,</quote> and that they
-should ignore it. But there is not a way to know this by looking at
-the <quote>failed</quote> node.
+<para> En <emphasis>fait</emphasis>, la confusion se trouve uniquement sur
+ ce noeud. Les autres noeud du cluster ne sont pas du tout perturbés;
+ ils savent que ce noeud est <quote>mort</quote>, et qu'ils doivent
+ l'ignorer. Mais il est impossible de savoir cela en regardent le noeud
+ qui a était <quote>en panne</quote>.
</para>
-<para> This points back to the design point that &slony1; is not a
-network monitoring tool. You need to have clear methods of
-communicating to applications and users what database hosts are to be
-used. If those methods are lacking, adding replication to the mix
-will worsen the potential for confusion, and failover will be a point
-at which there is enormous potential for confusion. </para>
+<para> Ceci nous ramène au fait que &slony1; n'est pas un outil de surveillance
+ de réseau. Vous devez avoir des méthodes claires pour signaler aux applications et
+ aux utilisateurs quels bases de données doivent être utilisées. En l'absence
+ de telles méthodes, la réplication ne fera qu'empirer le potentiel de confusion,
+ et les bascules d'urgence seront un énorme potentiel de confusion.
+</para>
</warning>
-<para> If the database is very large, it may take many hours to
-recover node1 as a functioning &slony1; node; that is another reason
-to consider failover as an undesirable <quote>final
-resort.</quote></para>
+<para> Si la base de données est très volumineuse, la construction du noeud 1
+ peut prendre plusieurs heures; ceci est une autre raison de considérer
+ les bascules d'urgence comme un <quote>dernier recours</quote> non souhaitable.
+</para>
</sect2>
More information about the Trad
mailing list