Changeset 1117

Show
Ignore:
Timestamp:
08/08/08 09:46:52 (4 months ago)
Author:
daamien
Message:

slony : failover.xml : 1ere traduction (a relire)

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/failover.xml

    r969 r1117  
    66 
    77<sect1 id="failover"> 
    8 <title>Doing switchover and failover with &slony1;</title> 
    9 <indexterm><primary>failover</primary> 
    10            <secondary>switchover</secondary> 
     8<title>Effectuer une bascule d'urgence avec &slony1;</title> 
     9<indexterm><primary>bascule d'urgence</primary> 
     10           <secondary>reprise sur panne</secondary> 
    1111</indexterm> 
    1212 
    13 <sect2><title>Foreword</title> 
    14  
    15 <para>&slony1; is an asynchronous replication system.  Because of 
    16 that, it is almost certain that at the moment the current origin of a 
    17 set fails, the final transactions committed at the origin will have 
    18 not yet propagated to the subscribers.  Systems are particularly 
    19 likely to fail under heavy load; that is one of the corollaries of 
    20 Murphy's Law.  Therefore the principal goal is to 
    21 <emphasis>prevent</emphasis> the main server from failing.  The best 
    22 way to do that is frequent maintenance.</para> 
    23  
    24 <para> Opening the case of a running server is not exactly what we 
    25 should consider a <quote>professional</quote> way to do system 
    26 maintenance.  And interestingly, those users who found it valuable to 
    27 use replication for backup and failover purposes are the very ones 
    28 that have the lowest tolerance for terms like <quote>system 
    29 downtime.</quote> To help support these requirements, &slony1; not 
    30 only offers failover capabilities, but also the notion of controlled 
    31 origin transfer.</para> 
    32  
    33 <para> It is assumed in this document that the reader is familiar with 
    34 the <xref linkend="slonik"/> utility and knows at least how to set up a 
    35 simple 2 node replication system with &slony1;.</para></sect2> 
    36  
    37 <sect2><title> Controlled Switchover</title> 
     13<sect2><title>Avant-propos</title> 
     14 
     15<para>&slony1; est un systÚme de réplication asynchrone.  À cause de cela, 
     16  il est presque certain qu'au moment ou le noeud origine d'un ensemble de réplication 
     17  tombe en panne, la derniÚre transaction <quote>committée</quote> sur 
     18  l'origine ne soit pas encore propagée aux abonnés. Les systÚmes qui tombent 
     19  en panne souvent soumis à une forte charge; c'est une des corollaires de la 
     20  loi de Murphy. Ainsi le but principal est d'<emphasis>éviter</emphasis> que le serveur principal 
     21  tombe en panne. La meilleur façon d'éviter cela est d'effectuer une  
     22  maintenance fréquente.</para> 
     23 
     24<para> Ouvrir le capot d'un serveur à chaud n'est pas ce qu'on peut 
     25  une façon <quote>professionelle</quote> d'assurer la maintenance d'un systÚme. 
     26  En général, les utilisateurs qui ont besoin de réplication pour 
     27  leur sauvegarde ou leur plan de reprise sur panne, ont également des critÚres 
     28  trÚs stricts en matiÚre de  <quote> temps d'arrêt du systÚme</quote>. 
     29  Pour répondre à ces critÚres, &slony1; ne se contente de fournir des 
     30  méthodes de reprise sur panne, il intÚgre également la notion de  
     31  transfert d'origine.</para> 
     32 
     33<para> On suppose dans cette partie que le lecteur est familier avec l'utilitaire  <xref linkend="slonik"/> 
     34  et qu'il sait comment mettre en place une systÚme de réplication &slony1; composé de deux noeuds. 
     35</para></sect2> 
     36 
     37<sect2><title>Bascule contrÃŽlée</title> 
    3838 
    3939<indexterm> 
    40  <primary>controlled switchover</primary> 
     40 <primary>bascule contrÃŽlée</primary> 
    4141</indexterm> 
    4242 
    43 <para> We assume a current <quote>origin</quote> as node1 with one 
    44 <quote>subscriber</quote> as node2 (<emphasis>e.g.</emphasis> - 
    45 slave).  A web application on a third server is accessing the database 
    46 on node1.  Both databases are up and running and replication is more 
    47 or less in sync.  We do controlled switchover using <xref 
    48 linkend="stmtmoveset"/>. 
     43<para> Imaginons un noeud <quote>origine</quote>, appelé noeud1, avec un  
     44  <quote>abonné</quote> appelé noeud2 (l'esclave).  Une application web, placée 
     45  sur un troisiÚme serveur, accÚde à la base de données sur noeud1. 
     46  Les deux bases sont actives et fonctionnelles, la réplication est  
     47  est à peu prÚs synchronisée. On contrÃŽle la bascule avec la commande 
     48  <xref linkend="stmtmoveset"/>. 
    4949</para> 
    5050<itemizedlist> 
    5151 
    52 <listitem><para> At the time of this writing switchover to another 
    53 server requires the application to reconnect to the new database.  So 
    54 in order to avoid any complications, we simply shut down the web 
    55 server.  Users who use <application>pg_pool</application> for the 
    56 applications database connections merely have to shut down the 
    57 pool.</para> 
    58  
    59 <para> What needs to be done, here, is highly dependent on the way 
    60 that the application(s) that use the database are configured.  The 
    61 general point is thus: Applications that were connected to the old 
    62 database must drop those connections and establish new connections to 
    63 the database that has been promoted to the <quote>/master/</quote> role.  There 
    64 are a number of ways that this may be configured, and therefore, a 
    65 number of possible methods for accomplishing the change: 
     52<listitem><para> Au moment ou nous écrivons ces lignes, basculer 
     53    vers un autre serveur nécessite que l'application se reconnecte 
     54    à la nouvelle base de donnée. Donc pour éviter toute complication, 
     55    nous éteignons le serveur web. Les utilisateurs qui ont installé 
     56    <application>pg_pool</application> pour gérer les connexions peuvent  
     57    simplement éteindre le pool.</para> 
     58 
     59<para> Les actions à mener dépendent beaucoup de la configuration des applications qui utilisent 
     60  la base de données. En général, les applications qui étaient connectées à  
     61  l'ancienne base doivent détruire leurs connexions et en établir de nouvelles 
     62  vers la base qui vient d'être promue dans le rÃŽle du  <quote>/maître/</quote> rÃŽle. 
     63  Il y a différentes façon de configurer cela, et donc différentes façon d'effectuer  
     64  la bascule : 
    6665</para> 
    6766</listitem> 
    6867<itemizedlist> 
    6968 
    70 <listitem><para> The application may store the name of the database in 
    71 a file.</para> 
    72  
    73 <para> In that case, the reconfiguration may require changing the 
    74 value in the file, and stopping and restarting the application to get 
    75 it to point to the new location. 
     69<listitem><para> L'application stocke le nom de la base de donnée dans un fichier.</para> 
     70 
     71<para> Dans ce cas, la reconfiguration nécessite de changer la valeur dans ce fichier, d'arrêter 
     72  puis de relancer l'application pour qu'elle pointe vers le nouvel emplacement des données. 
    7673</para> </listitem> 
    7774 
    78 <listitem><para> A clever usage of DNS might involve creating a CNAME 
    79 <ulink url="http://www.iana.org/assignments/dns-parameters"> DNS 
    80 record </ulink> that establishes a name for the application to use to 
    81 reference the node that is in the <quote>master</quote> role.</para> 
    82  
    83 <para> In that case, reconfiguration would require changing the CNAME 
    84 to point to the new server, and possibly restarting the application to 
    85 refresh database connections. 
     75<listitem><para> Une utilisation pertinente de DNS consiste à créer  
     76<ulink url="http://www.iana.org/assignments/dns-parameters"> champs DNS </ulink>  
     77CNAME qui permet à l'application d'utiliser un nom pour référencer le noeud 
     78qui joue le rÃŽle du noeud <quote>maître</quote>.</para> 
     79 
     80<para> Dans ce cas, la reconfiguration nécessite de changer le CNAME 
     81pour point et vers le nouveau serveur, de plus il faut probablement relancer 
     82l'application pour rafraîchir les connexions à la base. 
    8683</para> </listitem> 
    8784 
    88 <listitem><para> If you are using <application>pg_pool</application> or some 
    89 similar <quote>connection pool manager,</quote> then the reconfiguration 
    90 involves reconfiguring this management tool, but is otherwise similar 
    91 to the DNS/CNAME example above.  </para> </listitem> 
     85<listitem><para> si vous utilisez <application>pg_pool</application> ou  
     86    un <quote>gestionnaire de connexion</quote> similaire, alors la reconfiguration 
     87    implique de modifier le paramÚtre de cet outil, à part cela  la procédure est similaire 
     88    à l'exemple DNS/CNAME ci-dessus.  </para> </listitem> 
    9289 
    9390</itemizedlist> 
    9491 
    95 <para> Whether or not the application that accesses the database needs 
    96 to be restarted depends on how it is coded to cope with failed 
    97 database connections; if, after encountering an error it tries 
    98 re-opening them, then there may be no need to restart it. </para> 
    99  
    100  
    101  
    102  
    103 <listitem><para> A small <xref linkend="slonik"/> script executes the 
    104 following commands: 
    105  
     92<para> Le nécessité de redémarrer l'application qui se connecte à la base dépend 
     93  de la maniÚre dont elle a été conçu et des mécanismes de gestion d'erreurs de  
     94  connexion qui ont été implémentés; si à la suite d'une erreur elle tente  
     95  d'ouvrir à nouveau un connexion, alors il n'est pas nécessaire de la relancer. 
     96   </para> 
     97 
     98 
     99 
     100 
     101<listitem><para> Un petit script <xref linkend="slonik"/> exécute les commandes 
     102    suivantes : 
     103     
    106104<programlisting> 
    107105lock set (id = 1, origin = 1); 
    …… 
    111109</programlisting></para> 
    112110 
    113 <para> After these commands, the origin (master role) of data set 1 
    114 has been transferred to node2.  And it is not simply transferred; it 
    115 is done in a fashion such that node1 becomes a fully synchronized 
    116 subscriber, actively replicating the set.  So the two nodes have 
    117 switched roles completely.</para></listitem> 
    118  
    119 <listitem><para> After reconfiguring the web application (or 
    120 <application><link linkend="pgpool"> pgpool </link></application>) to 
    121 connect to the database on node2, the web server is restarted and 
    122 resumes normal operation.</para> 
    123  
    124 <para> Done in one shell script, that does the application shutdown, 
    125 <application>slonik</application>, move config files and startup all 
    126 together, this entire procedure is likely to take less than 10 
    127 seconds.</para></listitem> 
     111<para> AprÚs ces commandes, l'origine ( le rÃŽle du maître) de l'ensemble de réplication 1 
     112est transféré sur le noeud 2. En fait elle n'est pas simplement transférée; le noeud1 devient 
     113un abonné parfaitement synchronisé et actif. En clair, les deux noeuds ont échangé 
     114leurs rÃŽles respectifs.</para></listitem> 
     115 
     116<listitem><para> AprÚs la reconfiguration de l'application web (ou 
     117de <application><link linkend="pgpool"> pgpool </link></application>) pour 
     118qu'elle se connecte à la base du noeud 2, le serveur web est redémarré et  
     119reprend son activité normale.</para> 
     120 
     121<para> Lorsqu'on utilise un script shell, pour stopper l'application, 
     122  lancer le script <application>slonik</application>, déplacer les fichiers de configuration 
     123  et relancer l'ensemble, toute la procédure prend en général moins de 10 
     124secondes.</para></listitem> 
    128125 
    129126</itemizedlist> 
    130127 
    131 <para> You may now simply shutdown the server hosting node1 and do 
    132 whatever is required to maintain the server.  When <xref 
    133 linkend="slon"/> node1 is restarted later, it will start replicating 
    134 again, and soon catch up.  At this point the procedure to switch 
    135 origins is executed again to restore the original 
    136 configuration.</para> 
    137  
    138 <para> This is the preferred way to handle things; it runs quickly, 
    139 under control of the administrators, and there is no need for there to 
    140 be any loss of data.</para> 
     128<para> Vous pouvez désormais éteindre le serveur qui héberge le noeud 1 et  
     129  effectuer les opérations de maintenance requise. Lorsque le démon <xref 
     130linkend="slon"/> du noeud 1 est redémarré, il reprend la réplication, 
     131  et rattrape son retard. Une fois synchronisé, on peut exécuter la procédure 
     132  à nouveau pour restaurer la configuration originale.</para> 
     133 
     134<para> Ceci est la meilleure méthode pour ce genre d'opération de maintenance; 
     135  Elle s'effectue rapidement, sous le contrÃŽle d'un administrateur, et elle 
     136  n'implique aucune perte de données.</para> 
    141137 
    142138</sect2> 
    143 <sect2><title> Failover</title> 
     139<sect2><title>Bascule d'urgence</title> 
    144140 
    145141<indexterm> 
    146  <primary>failover due to system failure</primary> 
     142 <primary>Bascule suite à une panne du systÚme</primary> 
    147143</indexterm> 
    148144 
    149 <para> If some more serious problem occurs on the 
    150 <quote>origin</quote> server, it may be necessary to <xref 
    151 linkend="stmtfailover"/> to a backup server.  This is a highly 
    152 undesirable circumstance, as transactions <quote>committed</quote> on 
    153 the origin, but not applied to the subscribers, will be lost.  You may 
    154 have reported these transactions as <quote>successful</quote> to 
    155 outside users.  As a result, failover should be considered a 
    156 <emphasis>last resort</emphasis>.  If the <quote>injured</quote> 
    157 origin server can be brought up to the point where it can limp along 
    158 long enough to do a controlled switchover, that is 
    159 <emphasis>greatly</emphasis> preferable.</para> 
    160  
    161 <para> &slony1; does not provide any automatic detection for failed 
    162 systems.  Abandoning committed transactions is a business decision 
    163 that cannot be made by a database system.  If someone wants to put the 
    164 commands below into a script executed automatically from the network 
    165 monitoring system, well ... it's <emphasis>your</emphasis> data, and 
    166 it's <emphasis>your</emphasis> failover policy. </para> 
     145<para> Lorsque de graves problÚmes apparaissent sur le serveur  
     146<quote>origine</quote>, il est parfois nécessaire d'effectuer une 
     147bascule ( <xref linkend="stmtfailover"/> ) vers le serveur de sauvegarde.  
     148C'est cas de figure qui n'a rien de souhaitable, car les transactions 
     149<quote>committées</quote> sur le serveur mais pas sur les abonnés, seront  
     150perdues. Certaines de ces transactions auront peut-être été annoncées  
     151à l'utilisateur final comme <quote>validées</quote>. En conséquence, les 
     152bascules d'urgence doivent être considérées comme un  
     153<emphasis>dernier recours</emphasis>.  Le serveur origine  
     154qui subit <quote>l'avarie</quote> peut être maintenu assez longtemps, il est  
     155<emphasis>nettement</emphasis> 
     156préférable d'effectuer une bascule contrÃŽlée.</para> 
     157 
     158<para> &slony1; ne fournit pas de moyen de détection des pannes du systÚme. 
     159  Abandonner des transactions <quote>committées</quote> est une décision  
     160  commerciale qui ne peut pas être prise par un systÚme de gestion de base de données. 
     161  Si vous voulez placer les commandes ci-dessous dans un script exécuté 
     162  automatiquement par un systÚme de surveillance, et bien .... ce sont  
     163  <emphasis>vos</emphasis> données, et <emphasis>votre</emphasis> politique 
     164  de bascule d'urgence. </para> 
    167165 
    168166<itemizedlist> 
    169167 
    170168<listitem> 
    171 <para>The <xref linkend="slonik"/> command 
     169<para>La commande <xref linkend="slonik"/>  
    172170<programlisting> 
    173171failover (id = 1, backup node = 2); 
    …… 
    175173</para> 
    176174 
    177 <para> causes node2 to assume the ownership (origin) of all sets that 
    178 have node1 as their current origin.  If there should happen to be 
    179 additional nodes in the &slony1; cluster, all direct subscribers of 
    180 node1 are instructed that this is happening. 
    181 <application>Slonik</application> will also query all direct 
    182 subscribers in order to determine out which node has the highest 
    183 replication status (<emphasis>e.g.</emphasis> - the latest committed 
    184 transaction) for each set, and the configuration will be changed in a 
    185 way that node2 first applies those final before actually allowing 
    186 write access to the tables.</para> 
    187  
    188 <para> In addition, all nodes that subscribed directly to node1 will 
    189 now use node2 as data provider for the set.  This means that after the 
    190 failover command succeeded, no node in the entire replication setup 
    191 will receive anything from node1 any more.</para> 
     175<para>  ordonne au noeud 2 de se considérer comme le propriétaire  
     176  (l'origine) de tous les sets que le noeud 1 possédait. Si il  
     177  existe des noeuds supplémentaire dans le cluster  &slony1; 
     178  Tous les noeuds abonnés au noeud 1 sont avertis du changement. 
     179  <application>Slonik</application> va aussi envoyer une requête  
     180  à chaque abonné pour déterminer quel noeud à le plus haut niveau  
     181  de synchronisation (<emphasis>c'est à dire</emphasis> - la derniÚre 
     182  transaction <quote>committée</quote>) pour chaque ensemble de réplication. 
     183  et la configuration sera changé de façon à ce que le noeud 2 applique 
     184  d'abord ces transactions finales, avant d'autoriser l'accÚs en écriture 
     185  sur les tables.</para> 
     186 
     187<para> De plus, tous les noeuds qui étaient abonnés directement au noeud 1 
     188  considéreront désormais le noeud 2 comme leur fournisseur de données 
     189  pour cet ensemble de replication. Cela signifie qu'une fois que la  
     190  commande de bascule d'urgence est complétée, plus aucun noeud du cluster ne  
     191  reçoit d'information de la part du noeud 1.</para> 
    192192 
    193193</listitem> 
    194194 
    195195<listitem> 
    196 <para> Reconfigure and restart the application (or 
    197 <application>pgpool</application>) to cause it to reconnect to 
    198 node2.</para> 
    199 </listitem> 
    200  
    201 <listitem> <para> Purge out the abandoned node </para> 
    202  
    203 <para> You will find, after the failover, that there are still a full 
    204 set of references to node 1 in <xref linkend="table.sl-node"/>, as well 
    205 as in referring tables such as <xref linkend="table.sl-confirm"/>; 
    206 since data in <xref linkend="table.sl-log-1"/> is still present, 
    207 &slony1; cannot immediately purge out the node. </para> 
    208  
    209 <para> After the failover is complete and node2 accepts 
    210 write operations against the tables, remove all remnants of node1's 
    211 configuration information with the <xref linkend="stmtdropnode"/> 
    212 command: 
     196<para> Reconfigurer et relancer l'application ( ou 
     197<application>pgpool</application>) pour qu'elle se reconnecte 
     198au noeud 2.</para> 
     199</listitem> 
     200 
     201<listitem> <para> Purger le noeud abandonné </para> 
     202 
     203<para> Vous découvrirez, aprÚs la bascule, qu'il existe encore 
     204  beaucoup de références au noeud 1 dans la table <xref linkend="table.sl-node"/>, 
     205  ainsi que ses tables associées telle que <xref linkend="table.sl-confirm"/>; 
     206  puisque des données sont toujours présentes dans <xref linkend="table.sl-log-1"/>, 
     207  &slony1; ne peut pas purger immédiatement le noeud. </para> 
     208 
     209<para> Une fois que la bascule sera complÚte et que le noeud 2 accepte 
     210  les opérations d'écriture sur les tables répliquées, il faut supprimer 
     211  toutes informations de configuration rémanentes avec la commande  
     212   <xref linkend="stmtdropnode"/> : 
    213213 
    214214<programlisting> 
    …… 
    217217</para> 
    218218 
    219 <para> Supposing the failure resulted from some catastrophic failure 
    220 of the hardware supporting node 1, there might be no 
    221 <quote>remains</quote> left to look at.  If the failure was not 
    222 <quote>total</quote>, as might be the case if the node had to be 
    223 abandoned due to a network communications failure, you will find that 
    224 node 1 still <quote>imagines</quote> itself to be as it was before the 
    225 failure.  See <xref linkend="rebuildnode1"/> for more details on the 
    226 implications.</para> 
     219<para> Supposons que la panne résulte d'un problÚme matériel catastrophique 
     220  sur le noeud 1, il est possible qu'il ne <quote>reste</quote> plus 
     221  rien sur le noeud 1. Si la panne n'est pas <quote>totale</quote>, 
     222  ce qui est souvent le cas lors d'une coupure réseau, vous découvrirez 
     223  que le noeud 1  <quote>imagine</quote> toujours que rien n'a changé  
     224  et qu'il est dans le même état qu'avant la panne. Reportez-vous à la  
     225  section <xref linkend="rebuildnode1"/> pour plus de détails sur ce 
     226  que cela implique.</para> 
    227227 
    228228</listitem> 
    …… 
    231231</sect2> 
    232232 
    233 <sect2><title> Automating <command> FAIL OVER </command> </title> 
    234  
    235 <indexterm><primary>automating failover</primary></indexterm> 
    236  
    237 <para> If you do choose to automate <command>FAIL OVER </command>, it 
    238 is important to do so <emphasis>carefully.</emphasis> You need to have 
    239 good assurance that the failed node is well and truly failed, and you 
    240 need to be able to assure that the failed node will not accidentally 
    241 return into service, thereby allowing there to be two nodes out there 
    242 able to respond in a <quote>master</quote> role. </para> 
    243  
    244 <note> <para> The problem here requiring that you <quote>shoot the 
    245 failed node in the head</quote> is not fundamentally about replication 
    246 or &slony1;; &slony1; handles this all reasonably gracefully, as once 
    247 the node is marked as failed, the other nodes will <quote>shun</quote> 
    248 it, effectively ignoring it.  The problem is instead with 
    249 <emphasis>your application.</emphasis> Supposing the failed node can 
    250 come back up sufficiently that it can respond to application requests, 
    251 <emphasis>that</emphasis> is likely to be a problem, and one that 
    252 hasn't anything to do with &slony1;.  The trouble is if there are two 
    253 databases that can respond as if they are <quote>master</quote> 
    254 systems. </para> </note> 
    255  
    256 <para> When failover occurs, there therefore needs to be a mechanism 
    257 to forcibly knock the failed node off the network in order to prevent 
    258 applications from getting confused.  This could take place via having 
    259 an SNMP interface that does some combination of the following: 
     233<sect2><title> Automatisation de la commande <command> FAIL OVER </command> </title> 
     234 
     235<indexterm><primary>automatisation des bascules d'urgence</primary></indexterm> 
     236 
     237<para> Si vous choisissez d'automatiser la commande <command>FAIL OVER </command>, 
     238  il est important de le faire <emphasis>avec soin</emphasis>. Vous 
     239  devez être sur que le noeud en panne est réellement en panne, et vous 
     240  être capable de vous assurer que le noeud en panne ne redémarre pas,  
     241  ce qui entraînerait un conflit entre deux noeuds capables  
     242  de jouer le rÃŽle du <quote>maître</quote>. </para> 
     243 
     244<note> <para> Le fait de <quote>tirer une balle dans la  
     245      tête du serveur en panne</quote> ne pose pas directement 
     246de problÚme à la réplication ou à &slony1;; &slony1; supporte 
     247cela de maniÚre assez gravieuse, car une fois qu'une est marqué 
     248comme étant en panne, les autres noeuds <quote>l'oublier</quote> 
     249et l'ignorer. Le problÚme se situe plutÃŽt au niveau de 
     250<emphasis>votre application</emphasis>.  
     251Supposons que le noeud en panne soit capable de répondre 
     252aux requêtes de votre application, <emphasis>cela</emphasis>  
     253va certainement poser un problÚme qui n'a rien à voir avec &slony1;. 
     254Le problÚme est que deux bases de données sont en mesure de répondre 
     255en tant que <quote>maître</quote>. </para> </note> 
     256 
     257<para> Lorsqu'une bascule d'urgence est effectuée, il faut un  
     258  mécanisme pour dégager de force le noeud en panne hors du réseau 
     259  afin d'éviter toute confusion au niveau des applications. 
     260  Cela peut être fait via une interface SNMP qui effectue 
     261  une partie des opérations suivantes : 
    260262 
    261263<itemizedlist> 
    262264 
    263 <listitem><para> Turns off power on the failed server. </para>  
    264  
    265 <para> If care is not taken, the server may reappear when system 
    266 administrators power it up. </para> 
    267  
    268 </listitem> 
    269  
    270 <listitem><para> Modify firewall rules or other network configuration 
    271 to drop the failed server's IP address from the network. </para> 
    272  
    273 <para> If the server has multiple network interfaces, and therefore 
    274 multiple IP addresses, this approach allows the 
    275 <quote>application</quote> addresses to be dropped/deactivated, but 
    276 leave <quote>administrative</quote> addresses open so that the server 
    277 would remain accessible to system administrators.  </para> </listitem> 
     265<listitem><para> Éteindre l'alimentation du serveur en panne. </para>  
     266 
     267<para> Si l'on en fait attention, le serveur peut réapparaître dans le 
     268  systÚme de réplication lorsque les administrateurs le rallume. </para> 
     269 
     270</listitem> 
     271 
     272<listitem><para> Modifier de rÚgles de pare-feu ou d'autres configuration 
     273    pour exclure du réseau l'adresse IP du serveur en panne. </para> 
     274 
     275<para> Si le serveur a de multiples interfaces, et donc de multiple adresses IP, 
     276  cette approche permet de supprimer/désactiver les adresses utilisées l'application, 
     277  tout en conservant les adresses <quote>administratives</quote> afin  
     278  que le serveur reste accessible par les administrateurs systÚmes. 
     279</para> </listitem> 
    278280 
    279281</itemizedlist> 
    …… 
    281283</sect2> 
    282284 
    283 <sect2 id="rebuildnode1"><title>After Failover, Reconfiguring 
    284 Former Origin</title> 
    285  
    286 <indexterm><primary>rebuilding after failover</primary></indexterm> 
    287  
    288 <para> What happens to the failed node will depend somewhat on the 
    289 nature of the catastrophe that lead to needing to fail over to another 
    290 node.  If the node had to be abandoned because of physical destruction 
    291 of its disk storage, there will likely not be anything of interest 
    292 left.  On the other hand, a node might be abandoned due to the failure 
    293 of a network connection, in which case the former 
    294 <quote>provider</quote> can appear be functioning perfectly well. 
    295 Nonetheless, once communications are restored, the fact of the 
    296 <command>FAIL OVER</command> makes it mandatory that the failed node 
    297 be abandoned. </para> 
    298  
    299 <para> After the above failover, the data stored on node 1 will 
    300 rapidly become increasingly out of sync with the rest of the nodes, 
    301 and must be treated as corrupt.  Therefore, the only way to get node 1 
    302 back and transfer the origin role back to it is to rebuild it from 
    303 scratch as a subscriber, let it catch up, and then follow the 
    304 switchover procedure.</para> 
    305  
    306 <para> A good reason <emphasis>not</emphasis> to do this automatically 
    307 is the fact that important updates (from a 
    308 <emphasis>business</emphasis> perspective) may have been 
    309 <command>commit</command>ted on the failing system.  You probably want 
    310 to analyze the last few transactions that made it into the failed node 
    311 to see if some of them need to be reapplied on the <quote>live</quote> 
    312 cluster.  For instance, if someone was entering bank deposits 
    313 affecting customer accounts at the time of failure, you wouldn't want 
    314 to lose that information.</para> 
    315  
    316 <warning> <para> It has been observed that there can be some very 
    317 confusing results if a node is <quote>failed</quote> due to a 
    318 persistent network outage as opposed to failure of data storage.  In 
    319 such a scenario, the <quote>failed</quote> node has a database in 
    320 perfectly fine form; it is just that since it was cut off, it 
    321 <quote>screams in silence.</quote> </para> 
    322  
    323 <para> If the network connection is repaired, that node could 
    324 reappear, and as far as <emphasis>its</emphasis> configuration is 
    325 concerned, all is well, and it should communicate with the rest of its 
    326 &slony1; cluster. </para> 
    327  
    328 <para> In <emphasis>fact</emphasis>, the only confusion taking place 
    329 is on that node.  The other nodes in the cluster are not confused at 
    330 all; they know that this node is <quote>dead,</quote> and that they 
    331 should ignore it.  But there is not a way to know this by looking at 
    332 the <quote>failed</quote> node. 
     285<sect2 id="rebuildnode1"><title>AprÚs la bascule d'urgence, reconfiguration 
     286de l'ancienne origine</title> 
     287 
     288<indexterm><primary>reconstruction aprÚs une bascule d'urgence</primary></indexterm> 
     289 
     290<para> Ce qui arrive au noeud en panne dépend beaucoup de la nature de la catastrophe 
     291  qui a conduit à la bascule d'urgence vers un autre noeud. Si le noeud 
     292  a été abandonné à cause de la destruction physique des disques de stockage, 
     293  il n'y a plus grand-chose à faire. D'un autre coté, si un noeud a été abandonné 
     294  à cause d'une coupure réseau, qui n'a pas perturbé le fonctionnement normal 
     295  du noeud <quote>fournisseur</quote>. Toutefois une fois que les communications  
     296  sont restaurées, le fait est que le commande <command>FAIL OVER</command>  
     297  rend obligatoire l'abandon du noeud qui était en panne.</para> 
     298 
     299<para> AprÚs ce genre de bascule d'urgence, les données stockées sur le  
     300  noeud 1 seront rapidement et de plus en plus désynchronisées.  
     301  par rapport aux autres noeuds. Elles doivent être considérées comme  
     302  corrompues. Ainsi le seul moyen pour que le noeud 1 retourne dans  
     303  le cluster de réplication et qu'il redevienne le noeud origine est de 
     304  le reconstruire à partir de zéro comme un abonné, de le laisser rattraper 
     305  son retard, puis d'effectuer la procédure de bascule contrÃŽlée. 
     306  </para> 
     307 
     308<para> Une bonne raison de <emphasis>ne pas</emphasis> faire cela  
     309  automatiquement est que d'importante mises à jour ( d'un point de 
     310  vue <emphasis>commercial</emphasis> ) ont pu être  
     311<quote>committée</quote> sur le systÚme en panne. 
     312Vous souhaiterez probablement analyser les derniÚres transactions que  
     313le noeud a réalisé avant de tomber en panne, afin de voir si certaines 
     314doivent être ré-appliquer sur le cluster <quote>actif</quote>. 
     315Par exemple, si quelqu'un réalisait des opérations bancaires impactant 
     316des comptes clients au moment de la panne, il est souhaitable de  
     317ne pas perdre cette information.</para> 
     318 
     319<warning> <para> On a observé certains résultats étranges lorsqu'un  
     320    noeud <quote>tombe en panne</quote> à cause d'une coupure réseau persistante, 
     321    par opposition aux pannes du systÚme de stockage. Dans de tel scénarios, 
     322    le noeud <quote>en panne</quote> dispose d'une base de données en  
     323    parfait état de marche; le fait est qu'ayant été coupé des autres noeuds, 
     324    il <quote>crie en silence</quote>. </para> 
     325 
     326<para> Lorsque la connexion réseau est réparée, ce noeud peut réapparaître 
     327  et conformément <emphasis>sa</emphasis> configuration, il va communiquer avec les  
     328  autres noeuds du cluster &slony1;. </para> 
     329 
     330<para> En <emphasis>fait</emphasis>, la confusion se trouve uniquement sur  
     331  ce noeud. Les autres noeud du cluster ne sont pas du tout perturbés; 
     332  ils savent que ce noeud est  <quote>mort</quote>, et qu'ils doivent  
     333  l'ignorer. Mais il est impossible de savoir cela en regardent le noeud  
     334  qui a était <quote>en panne</quote>. 
    333335</para>  
    334336 
    335 <para> This points back to the design point that &slony1; is not a 
    336 network monitoring tool.  You need to have clear methods of 
    337 communicating to applications and users what database hosts are to be 
    338 used.  If those methods are lacking, adding replication to the mix 
    339 will worsen the potential for confusion, and failover will be a point 
    340 at which there is enormous potential for confusion. </para> 
     337<para> Ceci nous ramÚne au fait que &slony1; n'est pas un outil de surveillance 
     338  de réseau. Vous devez avoir des méthodes claires pour signaler aux applications et 
     339  aux utilisateurs quels bases de données doivent être utilisées. En l'absence 
     340  de telles méthodes, la réplication ne fera qu'empirer le potentiel de confusion, 
     341  et les bascules d'urgence seront un énorme potentiel de confusion. 
     342</para> 
    341343</warning> 
    342344 
    343 <para> If the database is very large, it may take many hours to 
    344 recover node1 as a functioning &slony1; node; that is another reason 
    345 to consider failover as an undesirable <quote>final 
    346 resort.</quote></para> 
     345<para> Si la base de données est trÚs volumineuse, la construction du noeud 1  
     346  peut prendre plusieurs heures; ceci est une autre raison de considérer  
     347  les bascules d'urgence comme un <quote>dernier recours</quote> non souhaitable. 
     348</para> 
    347349 
    348350</sect2>