Changeset 1111

Show
Ignore:
Timestamp:
07/27/08 13:34:18 (4 months ago)
Author:
daamien
Message:

Slony : Intro / 1ere trad ( à relire )

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/intro.xml

    r901 r1111  
    66 
    77<sect1 id="introduction"> 
    8 <title>Introduction to &slony1;</title> 
    9  
    10 <indexterm><primary> introduction to &slony1; </primary></indexterm> 
    11  
    12 <sect2> <title>What &slony1; is</title> 
    13  
    14 <para>&slony1; is a <quote>master to multiple slaves</quote> 
    15 replication system supporting cascading and slave promotion.  The big 
    16 picture for the development of &slony1; is as a master-slave system 
    17 that includes the sorts of capabilities needed to replicate large 
    18 databases to a reasonably limited number of slave systems. 
    19 <quote>Reasonable,</quote> in this context, is on the order of a dozen 
    20 servers.  If the number of servers grows beyond that, the cost of 
    21 communications increases prohibitively, and the incremental benefits 
    22 of having multiple servers will be falling off at that point.</para> 
    23  
    24 <para> See also <xref linkend="slonylistenercosts"/> for a further 
    25 analysis of costs associated with having many nodes.</para> 
    26  
    27 <para> &slony1; is a system intended for data centers and backup 
    28 sites, where the normal mode of operation is that all nodes are 
    29 available all the time, and where all nodes can be secured.  If you 
    30 have nodes that are likely to regularly drop onto and off of the 
    31 network, or have nodes that cannot be kept secure, &slony1; is 
    32 probably not the ideal replication solution for you.</para> 
    33  
    34 <para> Thus, examples of cases where &slony1; probably won't work out 
    35 well would include: 
     8<title>Introduction à &slony1;</title> 
     9 
     10<indexterm><primary> introduction à &slony1; </primary></indexterm> 
     11 
     12<sect2> <title>Qu'est ce que &slony1; ?</title> 
     13 
     14<para>&slony1; est systÚme de réplication entre <quote>un maître et de multiple esclaves</quote> 
     15qui supporte les cascades et la promotion d'un esclave en maître.   
     16Le schéma directeur du développement de &slony1; est la création  
     17d'un systÚme maître-esclave qui inclue les fonctionnalités nécessaire 
     18pour répliquer de grandes bases de données avec un nombre raisonnable 
     19d'esclaves. <quote>Raisonnable,</quote> dans ce contexte, signifie  
     20une douzaine de serveurs.  Si le nombre de serveurs évolue au-delà de 
     21cette limite, le coût des communications augmentent de maniÚre prohibitive,  
     22et le bénéfice d'avoir de multiple serveurs s'amenuise.</para> 
     23 
     24<para> Voir la section <xref linkend="slonylistenercosts"/> pour une  
     25  analyse plus détaillées des coûts associés à l'augmentation du  
     26  nombre de noeuds.</para> 
     27 
     28<para> &slony1; est un systÚme conçu pour les datacenters et sites de  
     29  sauvegardes, où le fonctionnement des opérations est que tous les 
     30  noeuds sont disponibles en permanence, et où tous les noeuds peuvent 
     31  être sécurisés. Si vous avez des noeuds qui risquent réguliÚrement d'être  
     32  coupés du réseau, ou si la sécurité de vos noeuds ne peut pas  
     33  être garantie,  &slony1; n'est probablement pas la solution de réplication 
     34  idéale pour vous.</para> 
     35 
     36<para> Voici notamment quelques exemples de cas où &slony1; ne sera probablement 
     37  pas adapté : 
    3638 
    3739<itemizedlist> 
    38 <listitem><para> Sites where connectivity is really <quote>flakey</quote> 
     40<listitem><para> Les sites dont la connectivité est <quote>instable</quote> 
    3941</para></listitem> 
    40 <listitem><para> Replication to nodes that are unpredictably connected.</para></listitem> 
    41  
    42 <listitem><para> Replicating a pricing database from a central server to sales 
    43 staff who connect periodically to grab updates.  </para></listitem> 
    44  
    45 <listitem><para> Sites where configuration changes are made in a 
    46 haphazard way.</para></listitem> 
    47  
    48 <listitem><para> A <quote>web hosting</quote> situation where customers can 
    49 independently make arbitrary changes to database schemas is not a good 
    50 candidate for &slony1; usage. </para></listitem> 
    51  
     42<listitem><para> La réplication entre des noeuds qui ne sont pas toujours interconnectés</para></listitem> 
     43 
     44<listitem><para> Répliquer une base de tarification à partir d'un serveur central vers  
     45    l'équipe commerciale qui s'y connecte périodiquement pour en extraire les mise à jour. 
     46  </para></listitem> 
     47 
     48<listitem><para> Les sites où les changements de configuration sont faits de 
     49    maniÚre hasardeuse.</para></listitem> 
     50 
     51<listitem><para> Un situation <quote>d'hébergement web</quote> où les  
     52    utilisateurs peuvent de maniÚre indépendante et arbitraire changer les 
     53    schémas des données. 
    5254</itemizedlist></para> 
    5355 
    54 <para> There is also a <link linkend="logshipping">file-based log 
    55 shipping</link> extension where updates would be serialized into 
    56 files.  Given that, log files could be distributed by any means 
    57 desired without any need of feedback between the provider node and 
    58 those nodes subscribing via <quote>log shipping.</quote> <quote>Log 
    59 shipped</quote> nodes do not add to the costs of communicating events 
    60 between &slony1; nodes.</para> 
    61  
    62 <para> But &slony1;, by only having a single origin for each set, is 
    63 quite unsuitable for <emphasis>really</emphasis> asynchronous multiway 
    64 replication.  For those that could use some sort of 
    65 <quote>asynchronous multimaster replication with conflict 
    66 resolution</quote> akin to what is provided by <productname>Lotus 
    67 <trademark>Notes</trademark></productname> or the 
    68 <quote>syncing</quote> protocols found on PalmOS systems, you will 
    69 really need to look elsewhere.  </para>  
    70  
    71 <para> These other sorts of replication models are not without merit, 
    72 but they represent <emphasis>different</emphasis> replication 
    73 scenarios that &slony1; does not attempt to address.</para> 
     56<para> Il existe une extension de <link linkend="logshipping"> log shipping par fichier</link> 
     57  qui permet de regrouper les mises à jour dans des fichiers. 
     58  Ainsi, les fichiers de mises à jours peuvent être distribués  
     59  par différents moyens sans avoir à attendre d'accusé de réception 
     60  entre les noeud fournisseur et les noeuds qui sont abonnés au  
     61  <quote>log shipping</quote>. Le noeuds abonnés au <quote>Log 
     62shipping</quote> n'augmente pas les coûts de communication être 
     63les noeuds &slony1;.</para> 
     64 
     65<para> Mais &slony1;, ayant une seule origine par ensemble de données répliqué, 
     66  n'est pas adapté pour effectuer de la réplication <emphasis>réellement</emphasis> asynchrone 
     67  et multi-directionnelle. Pour celles et ceux qui recherche une  
     68  <quote>réplication asynchrone multi-maîtres avec résolution des conflits</quote> 
     69  telle que ce que fournit <productname>Lotus 
     70<trademark>Notes</trademark></productname> ou les protocoles de <quote>synchronisation</quote> 
     71présents sur les systÚmes PalmOS, il est nécessaire de se tourner vers d'autres logiciels. 
     72</para>  
     73 
     74<para> Il existe également d'autres modÚles de réplication qui ne sont pas sans avantages, 
     75  mais qui permettent des scénarios de réplication <emphasis>différents</emphasis>  
     76  de ce que &slony1; propose.</para> 
    7477 
    7578</sect2> 
    7679 
    77 <sect2><title>Why yet another replication system?</title> 
    78  
    79 <para>&slony1; was born from an idea to create a replication system 
    80 that was not tied to a specific version of &postgres;, which is 
    81 allowed to be started and stopped on an existing database without the 
    82 need for a dump/reload cycle.</para> 
     80<sect2><title>Pourquoi proposer encore un autre systÚme de réplication ?</title> 
     81 
     82<para>&slony1; est né de l'idée de créer un systÚme de réplication qui ne soient 
     83  pas lié à une version spécifique de &postgres;, pour qu'il puisse être lancé 
     84  et arrêté sur une base existante sans besoin d'effectuer un cycle d'export/import 
     85  des données.</para> 
    8386 
    8487</sect2> 
    8588 
    86 <sect2><title> What &slony1; is not</title> 
     89<sect2><title> Ce que &slony1; n'est pas</title> 
    8790 
    8891<itemizedlist> 
    89 <listitem><para>&slony1; is not a network management system.</para></listitem> 
    90  
    91 <listitem><para> &slony1; does not have any functionality within it to detect a 
    92 node failure, nor to automatically promote a node to a master or other 
    93 data origin.</para> 
    94  
    95 <para> It is quite possible that you may need to do that; that will 
    96 require that you combine some network tools that evaluate <emphasis> 
    97 to your satisfaction </emphasis> which nodes you consider 
    98 <quote>live</quote> and which nodes you consider <quote>dead</quote> 
    99 along with some local policy to determine what to do under those 
    100 circumstances.  &slony1; does not dictate any of that policy to 
    101 you.</para></listitem> 
    102  
    103 <listitem><para>&slony1; is not a multi-master replication system; it 
    104 is not a connection broker, and it won't make you coffee and toast in 
    105 the morning.</para></listitem> 
     92<listitem><para>&slony1; n'est pas un systÚme de gestion de réseau.</para></listitem> 
     93 
     94<listitem><para> &slony1; n'a aucune fonctionnalité permettant de détecter 
     95    la perte d'un noeud, ni de transformer automatiquement un noeud en maître 
     96    ou en noeud origine.</para> 
     97 
     98<para> Il est toutefait possible que vous ayez besoin de ce type de mécanisme; 
     99  cela vous demandera de combiner des outils réseau qui évaluent  
     100 <emphasis>selon vos critÚres</emphasis> quels noeuds vous considérez comme 
     101<quote>actifs</quote> et quels noeuds vous considérez comme <quote>morts</quote>, 
     102ainsi qu'une politique locale pour déterminer ce qu'il faut faire dans telle ou telle circonstance. 
     103&slony1; ne vous impose aucune politique.</para></listitem> 
     104 
     105<listitem><para>&slony1; n'est pas un systÚme de réplication multi-maîtres;  
     106    ce n'est pas un gestionnaire de connexions, et il ne vous apportera pas  
     107    le café et les croissants le matin.</para></listitem> 
    106108 
    107109</itemizedlist> 
    108110 
    109 <para>All that being said, there are tools available to help with some 
    110 of these things, and there is a plan under way for a subsequent 
    111 system, <productname>Slony-II</productname>, to provide 
    112 <quote>multimaster</quote> capabilities.  But that represents a 
    113 different, separate project, being implemented in a rather different 
    114 fashion than &slony1;, and expectations for &slony1; should not be 
    115 based on hopes for future projects.</para></sect2> 
    116  
    117 <sect2><title> Why doesn't &slony1; do automatic fail-over/promotion? 
     111<para>Ceci étant dit, il existe des outils à votre disposition pour 
     112  simplifier certaines de ces opérations, et il existe un projet en cours 
     113  de développement, <productname>Slony-II</productname>, pour fournir 
     114  des mécanismes <quote>multi-maîtres</quote>. Mais cela constitue  
     115  un projet différent et séparé, implémenté de façon trÚs différente 
     116  de &slony1;, et attentes à propos de &slony1; ne doivent pas se baser  
     117  sur l'espoir placé dans de futurs projets.</para></sect2> 
     118 
     119<sect2><title> Pourquoi &slony1; ne fait pas de bascule automatique en cas de panne («fail over») ? 
    118120</title> 
    119121 
    120 <para>Determining whether a node has <quote>failed</quote> is properly 
    121 the responsibility of network management software, not &slony1;.  The 
    122 configuration, fail-over paths, and preferred policies will be 
    123 different for each site.  For example, keep-alive monitoring with 
    124 redundant NIC's and intelligent HA switches that guarantee 
    125 race-condition-free takeover of a network address and disconnecting 
    126 the <quote>failed</quote> node will vary based on network 
    127 configuration, vendor choices, and the combinations of hardware and 
    128 software in use.  This is clearly in the realm of network management 
    129 and not &slony1;.</para> 
    130  
    131 <para> Furthermore, choosing what to do based on the 
    132 <quote>shape</quote> of the cluster represents local business policy, 
    133 particularly in view of the fact that <link 
    134 linkend="stmtfailover"><command>FAIL OVER</command></link> requires 
    135 discarding the failed node. If &slony1; imposed failover policy on 
    136 you, that might conflict with business requirements, thereby making 
    137 &slony1; an unacceptable choice.</para> 
    138  
    139 <para>As a result, let &slony1; do what it does best: provide database 
    140 replication services.</para></sect2> 
    141  
    142 <sect2><title> Current Limitations</title> 
    143  
    144 <indexterm><primary>limitations to &slony1;</primary></indexterm> 
    145  
    146 <para>&slony1; does not automatically propagate schema changes, nor 
    147 does it have any ability to replicate large objects.  There is a 
    148 single common reason for these limitations, namely that &slony1; 
    149 collects updates using triggers, and neither schema changes, large 
    150 object operations, nor <command>TRUNCATE</command> requests are able 
    151 to have triggers suitable to inform &slony1; when those sorts of 
    152 changes take place.  As a result, the only database objects where 
    153 &slony1; can replicate updates are tables and sequences.  </para> 
    154  
    155 <para> Note that with the <emphasis>use</emphasis> of triggers comes 
    156 some additional <emphasis>fiddling around with triggers</emphasis>. 
    157 On the <quote>origin</quote> for each replicated table, an additional 
    158 trigger is added which runs the stored procedure <xref 
    159 linkend="function.logtrigger"/>.  On each subscriber, tables are 
    160 augmented with a trigger that runs the <xref 
    161 linkend="function.denyaccess"/> function; this function prevents 
    162 anything other than the <xref linkend="slon"/> process from updating 
    163 data in replicated tables.  In addition, any 
    164 <emphasis>other</emphasis> triggers and rules on replicated tables are 
    165 <emphasis>suppressed</emphasis> on the subscribers: This is done by 
    166 pointing them, in the system table, to the primary key index instead 
    167 of to the table itself.  This represents something of a 
    168 <quote>corruption</quote> of the data dictionary, and is why you 
    169 should not directly use <application>pg_dump</application> to dump 
    170 schemas on subscribers. </para> 
    171  
    172 <para>There is a capability for &slony1; to propagate other kinds of 
    173 database modifications, notably DDL changes, if you submit them as 
    174 scripts via the <application>slonik</application> <xref 
    175 linkend="stmtddlscript"/> operation.  That is not handled 
    176 <quote>automatically;</quote> you, as a database administrator, will 
    177 have to construct an SQL DDL script and submit it, via <xref 
    178 linkend="stmtddlscript"/> and there are a number of further <link 
    179 linkend="ddlchanges"> caveats.</link> </para> 
    180  
    181 <para>If you have those sorts of requirements, it may be worth 
    182 exploring the use of &postgres; 8.X <acronym>PITR</acronym> (Point In 
    183 Time Recovery), where <acronym>WAL</acronym> logs are replicated to 
    184 remote nodes.  Unfortunately, that has two attendant limitations: 
     122<para>Déterminer si un noeud est en  <quote>échec</quote> est de la responsabilité 
     123  d'un logiciel de surveillance de réseau, pas de &slony1;. La configuration, 
     124  les mécanismes de bascule et les politiques de reprise sur panne sont  
     125  différent selon les sites. Par exemple, la surveillance avec des NICs redondants 
     126  et les mécanismes de haute-disponibilité intelligents qui garantissent 
     127  un changement d'adresse réseau à la volée sans conflit et une isolation  
     128  du noeud <quote>en échec</quote>, dépendent de la configuration du réseau, 
     129  des choix matériels et de la combinaison entre les logiciels et les appareils 
     130  utilisés. Tout cela appartient clairement au domaine de la gestion de réseau, 
     131  pas à celui de  &slony1;.</para> 
     132 
     133<para> De plus, choisir comment se comporter selon  
     134<quote>l'état</quote> du cluster concerne la politique commerciale locale, 
     135en particulier si on considÚre qu'une <link 
     136linkend="stmtfailover"><command>bascule en cas de panne</command></link> ( « fail over » ) nécessite 
     137d'isoler le noeud en échec. Si &slony1; imposait une politique de bascule en cas de panne 
     138aux utilisateurs, cela entrerait parfois en conflit avec des 
     139intérêts commerciaux et &slony1; serait parfois une solution inadaptée.</para> 
     140 
     141<para>En conséquence, laissons &slony1; faire ce qu'il fait de mieux : fournir un service de 
     142  réplication de bases de données.</para></sect2> 
     143 
     144<sect2><title> Limitations actuelles</title> 
     145 
     146<indexterm><primary>limitations de &slony1;</primary></indexterm> 
     147 
     148<para>&slony1; ne propage pas les changements du schéma de données, 
     149  et ne réplique non plus les objets volumineux ( «large objects» ) 
     150  Il y a une raison unique et commune à ces limitations : 
     151  &slony1; collecte les mises à jours en utilisant des triggers, et 
     152  ni les changements de schéma, ni les opérations sur les objets volumineux, 
     153  ni les requêtes <command>TRUNCATE</command> ne sont capables de  
     154  déclencher des triggers pour informer &slony1; lorsque ce genre  
     155  de modification a lieu. Ainsi les seuls objets que &slony1; peut répliquer 
     156  sont les tables et les séquences.  </para> 
     157 
     158<para> Notons que <emphasis>l'utilisation</emphasis> de triggers implique 
     159  quelques <emphasis>retoucher</emphasis> supplémentaires sur ces triggers. 
     160Sur le noeud <quote>origine</quote> pour chaque table répliquée, on ajoute un trigger 
     161supplémentaire qui lance la procédure stockée  <xref 
     162linkend="function.logtrigger"/>.   
     163Sur chaque noeud abonné, les tables sont complétées avec un trigger qui lance  
     164la fonction  <xref 
     165linkend="function.denyaccess"/>; cette fonction empêche toute mise à jour 
     166sur les tables répliquées à l'exception de celles effectuées par 
     167le processus <xref linkend="slon"/>. 
     168De plus, toutes les <emphasis>autres</emphasis> triggers et rÚgles  
     169sur les tables répliquées sont <emphasis>supprimés</emphasis> sur 
     170les noeuds abonnés; Ceci est réalisé en faisant pointant ces tables, 
     171dans le catalogue systÚme, vers les index des clefs primaires  
     172plutÃŽt que sur la table elle-même. 
     173Cela s'apparente à une <quote>corruption</quote> du dictionnaire de données, 
     174et cela explique pourquoi on ne peut pas utiliser directement  
     175 <application>pg_dump</application> pour exporter le schéma sur les  
     176 noeuds abonnés. </para> 
     177 
     178<para>Il est possible de propager d'autres types de modifications des bases 
     179  avec &slony1;, notamment les ordres DDL, si vous les effectuer via la fonction 
     180  de <application>slonik</application> nommée <xref 
     181linkend="stmtddlscript"/>.  Ceci ne peut pas se faire  
     182<quote>automatiquement</quote>; en tant qu'administrateur de base de données, 
     183vous devez superviser les scripts SQL DDL et les soumettre via  <xref 
     184linkend="stmtddlscript"/> car il existe un certain nombre de  
     185piÚges à éviter concernant les <link 
     186linkend="ddlchanges">.</link> </para> 
     187 
     188<para>Si vous ne pouvez pas superviser ces modifications, vous devrez peut-être  
     189  envisager l'utilisation du mécanisme <acronym>PITR</acronym> (Point In 
     190Time Recovery) de &postgres; (version 8.x), avec lequel les journaux 
     191<acronym>WAL</acronym> sont répliqués sur des noeuds distants. 
     192Malheureusement cette solution à deux limitations majeures : 
    185193 
    186194<itemizedlist> 
    187195         
    188 <listitem><para> PITR replicates <emphasis>all</emphasis> changes in 
    189 <emphasis>all</emphasis> databases; you cannot exclude data that isn't 
    190 relevant;</para></listitem> 
    191  
    192 <listitem><para> A PITR replica remains dormant until you apply logs 
    193 and start up the database.  You cannot use the database and apply 
    194 updates simultaneously.  It is like having a <quote>standby 
    195 server</quote> which cannot be used without it ceasing to be 
    196 <quote>standby.</quote></para></listitem> 
     196<listitem><para> Le mécanisme PITR replique <emphasis>tous</emphasis> les changements de 
     197<emphasis>toutes</emphasis> les bases de données; vous ne pouvez pas  
     198exclure les données qui ne sont pas intéressantes;</para></listitem> 
     199 
     200<listitem><para> Un réplicat PITR reste endormi jusqu'à ce que les journaux 
     201    soient appliqués et que la base soit relancée. Vous ne pouvez pas 
     202    utiliser la base et appliquer les mises à jour simultanément. 
     203    Cela revient à avoir un <quote>serveur de secours</quote> que 
     204    vous ne pouvez utiliser sans stopper la réplication.</para></listitem> 
    197205 
    198206</itemizedlist></para> 
    199207</sect2> 
    200208 
    201 <sect2><title>Replication Models</title> 
    202  
    203 <indexterm><primary>replication models</primary></indexterm> 
    204  
    205 <para>There are a number of distinct models for database replication; 
    206 it is impossible for one replication system to be all things to all 
    207 people.</para> 
    208  
    209 <para> &slony1; implements a particular model, namely that of 
    210 asynchronous replication, using triggers to collect table updates, 
    211 where a single <quote>origin</quote> may be replicated to multiple 
    212 <quote>subscribers</quote> including cascaded subscribers.</para> 
    213  
    214 <para> There are a number of other replication models which are 
    215 <emphasis> different </emphasis>; it is worth pointing out other 
    216 approaches that exist.  &slony1; is certainly not the only approach, 
    217 and for some applications, it is <emphasis> not </emphasis> the 
    218 optimal approach. </para> 
     209<sect2><title>ModÚles de réplication</title> 
     210 
     211<indexterm><primary>modÚles de réplication</primary></indexterm> 
     212 
     213<para>%Il beaucoup de modÚles de réplication différents; il est  
     214  qu'un systÚme de réplication puisse répondre à toutes les attentes 
     215  de tous les utilisateurs.</para> 
     216 
     217<para> &slony1; implémente un modÚle particulier, la réplication asynchrone, 
     218  en utilisant des triggers pour collecter les mises à jour sur les tables, 
     219  sur une <quote>origine</quote> unique, puis réplique ces mises à jour 
     220  sur de multiple <quote>abonnés</quote>, y compris les abonnés en cascade.</para> 
     221 
     222<para> Il existe de de nombreaux autres modÚles de réplication 
     223  qui sont <emphasis> différent </emphasis> de celui-ci; il est  
     224  important de souligner que d'autres approches sont possibles.  
     225  &slony1; n'est certainement pas la seule approche, et pour certaines 
     226  applications, ce n'est <emphasis> pas </emphasis> la meilleur approche. </para> 
    219227 
    220228<itemizedlist>  
    221 <listitem><para> Synchronous single-origin multi-subscriber replication</para> 
    222  
    223 <para> In a synchronous system, updates cannot be committed at the 
    224 origin until they have also been accepted by subscriber nodes.  This 
    225 enhances the security property of nonrepudiation as updates will not 
    226 be committed until they can be confirmed elsewhere.  Unfortunately, 
    227 the requirement that changes be applied in multiple places introduces 
    228 a performance bottleneck. </para> 
    229  
    230 <para> This approach is similar to the two phase commit processing 
    231 model of the XA transaction processing protocol.</para> 
     229<listitem><para> Réplication synchrone entre une origine unique et plusieurs abonnés</para> 
     230 
     231<para> Dans un systÚme synchrone, les mises à jour ne peuvent pas être committées 
     232  sur l'origine tant qu'elles n'ont pas été acceptées par les noeuds abonnés. 
     233  Ceci renforce la sécurité en évitant les risques de répudiation, car les mises  
     234  à jour ne sont pas effectuées sans avoir été confirmées ailleurs. Malheureusement, 
     235  la nécessité d'appliquer simultanément les changements sur de multiple emplacement 
     236  constitue un frein sur les performances. </para> 
     237 
     238<para> Cette approche est similaire au modÚle basé sur le commit en deux phases ( NdT : « two phase commit » ) 
     239  implémenté dans le protocole de gestion de transaction XA.</para> 
    232240</listitem> 
    233241 
    234 <listitem><para> Synchronous multi-origin multi-subscriber replication </para>  
    235  
    236 <para> This is the model being used by the possibly-forthcoming 
    237 <productname>Slony-II</productname> system.  Synchronous replication 
    238 systems all <quote>suffer</quote> from the performance bottleneck that 
    239 updates must be accepted on all nodes before they can be 
    240 <command>commit</command>ted anywhere.  </para> 
    241  
    242 <para> That generally makes it impractical to run synchronous 
    243 replication across wide area networks. </para> 
     242<listitem><para> Réplication synchrone entre plusieurs origines et plusieurs abonnés </para>  
     243 
     244<para> Ceci est le modÚle implémenté dans l'hypothétique systÚme  
     245<productname>Slony-II</productname>.  Les systÚmes de réplication synchrones 
     246<quote>souffrent</quote> de problÚmes de performances, car les mises à jour doivent 
     247être acceptées par tous les noeuds avant d'être appliquées.</para> 
     248 
     249<para> En pratique, il est inutile de faire fonctionner un systÚme de réplication 
     250  synchrone sur un réseau longue distance (WAN).</para> 
    244251</listitem> 
    245252 
    246 <listitem><para> Asynchronous multimaster replication with conflict 
    247 avoidance/resolution</para> 
    248  
    249 <para> Perhaps the most widely used replication system of this sort is 
    250 the <productname>PalmOS HotSync</productname> system. 
    251 <trademark>Lotus Notes</trademark> also provides a replication system 
    252 that functions in much this manner.</para> 
    253  
    254 <para> The characteristic <quote>troublesome problem</quote> with this 
    255 style of replication is that it is possible for conflicts to arise 
    256 because users update the same record in different ways on different 
    257 nodes. </para> 
    258  
    259 <para> In the case of <productname>HotSync</productname>, if conflicts 
    260 arise due to records being updated on multiple nodes, the 
    261 <quote>resolution</quote> is to simply create a duplicate record to 
    262 reflect the two changes, and have the user resolve the conflict 
    263 manually. </para> 
    264  
    265 <para> Some async multimaster systems try to resolve conflicts by 
    266 finding ways to apply partial record updates.  For instance, with an 
    267 address update, one user, on one node, might update the phone number 
    268 for an address, and another user might update the street address, and 
    269 the conflict resolution system might try to apply these updates in a 
    270 non-conflicting order.  This can also be considered a form of 
    271 <quote>table partitioning</quote> where a database table is treated as 
    272 consisting of several <quote>sub-tables.</quote> </para> 
    273  
    274 <para> Conflict resolution systems almost always require some domain 
    275 knowledge of the application being used, which means that they can 
    276 only deal automatically with those conflicts where you have assigned a 
    277 policy.  If they run into conflicts for which no policy is available, 
    278 replication stops until someone applies some manual 
    279 intervention. </para> 
     253<listitem><para> Réplication asynchrone multi-maîtres avec résolution/prévention des conflits</para> 
     254 
     255<para> Le systÚme de réplication le plus répandu utilisant ce modÚle est probablement 
     256  le systÚme <productname>PalmOS HotSync</productname>. 
     257<trademark>Lotus Notes</trademark> fournit également un systÚme de réplication 
     258qui fonctionne de la même maniÚre.</para> 
     259 
     260<para> Le <quote>problÚme</quote> caractéristique avec ce  
     261style de réplication est que des conflits peuvent apparaître 
     262lorsque des utilisateurs mettent à jour le même enregistrement  
     263de différente maniÚre sur différents noeuds.</para> 
     264 
     265<para> Dans le cas de <productname>HotSync</productname>, si un conflit  
     266  est provoqué par la mise à jour simultanée d'un même enregistrement, 
     267  la <quote>résolution</quote> se résume à créer un deuxiÚme enregistrement 
     268  pour témoigner des deux mises à jours, puis laisser l'utilisateur résoudre 
     269  le conflit à la main. </para> 
     270 
     271<para> Certains systÚmes de réplication multi-maîtres asynchrones essaient 
     272  de résoudre les conflits en trouvant de moyens pour appliquer partiellement 
     273  les mises à jour. Par exemple, dans le cas de la mise à jour d'un adresse, 
     274  si un autre utilisateur tente de mettre à jour le nom de la rue, alors le 
     275  systÚme de résolution des conflits essaie d'appliquer les mises à jour 
     276  dans un ordre non-conflictuel. On peut considérer cette méthode comme 
     277  une forme de <quote>partitionnement de table</quote> où l'on considÚre la 
     278  base de données comme une table constituée de plusieurs <quote>sous-tables</quote>. </para> 
     279 
     280<para> Les systÚmes de résolution de conflit nécessaire presque toujours 
     281  une bonne connaissance du domaine de l'application, ce qui implique 
     282  qu'ils ne peuvent résoudre des conflits automatiquement uniquement si 
     283  vous leur indiquez une politique de résolution. S'ils rencontrent 
     284  un conflit et qu'il n'existe pas de politique définie, la réplication  
     285  s'arrête jusqu'à ce que quelqu'un résolve le conflit à la main.</para> 
    280286</listitem> 
    281287 
    …… 
    285291</sect1> 
    286292 
    287 <sect1 id="slonylistenercosts"><title> &slony1; Communications 
    288 Costs</title> 
    289  
    290 <para>The cost of communications grows in a quadratic fashion in 
    291 several directions as the number of replication nodes in a cluster 
    292 increases.  Note the following relationships: 
     293<sect1 id="slonylistenercosts"><title> Coûts de communications avec &slony1;</title> 
     294 
     295<para>Le coût de communications augmente de façon quadratique dans plusieurs  
     296directions lorsque le nombre de noeuds de réplication du cluster 
     297grandit.  Notons les relations suivantes : 
    293298 
    294299<itemizedlist> 
    295300 
    296 <listitem><para> It is necessary to have <xref 
    297 linkend="table.sl-listen"/> entries allowing connection from each node 
    298 to every other node.  Most will normally not need to be very heavily, 
    299 but it still means that there needs to be n(n-1) paths. 
     301<listitem><para> Il est nécessaire que les entrées de la table <xref 
     302linkend="table.sl-listen"/> autorise toutes les connexions entre tous les noeuds. 
     303Dans le pluspart des cas, cela n'est pas trÚs volumineux, mais cela signifie tout 
     304de même qu'il faut définir n(n-1) voies de communications. 
    300305</para></listitem> 
    301306 
    302 <listitem><para> Each SYNC applied needs to be reported back to all of 
    303 the other nodes participating in the set so that the nodes all know 
    304 that it is safe to purge <xref linkend="table.sl-log-1"/> and <xref 
    305 linkend="table.sl-log-2"/> data, as any <quote>forwarding</quote> node 
    306 could potentially take over as <quote>master</quote> at any time.  One 
    307 might expect SYNC messages to need to travel through n/2 nodes to get 
    308 propagated to their destinations; this means that each SYNC is 
    309 expected to get transmitted n(n/2) times.  Again, this points to a 
    310 quadratic growth in communications costs as the number of nodes 
    311 increases.</para></listitem> 
     307<listitem><para> Chaque événement SYNC appliqué doit être annoncé à  
     308    tous les noeuds participants à la réplication de l'ensemble de  
     309    données, afin que chaque noeud sache qu'il est possible de  
     310    purger les données des tables  <xref linkend="table.sl-log-1"/> et <xref 
     311linkend="table.sl-log-2"/>, car n'importe quel noeud <quote>fournisseur</quote> 
     312    peut potentiellement devenir un <quote>maître</quote> à tout moment. 
     313    On peut s'attendre à que les messages SYNC ne soient propagés que sur  
     314    n/2 noeuds pour atteindre leur destination; ce qui implique que 
     315    chaque SYNC est transmis n(n/2) fois.  A nouveau, cela montre 
     316    que la croissance des coûts de communication est quadratique selon 
     317    le nombre de noeuds dans le cluster.</para></listitem> 
    312318 
    313319</itemizedlist></para> 
    314320 
    315 <para>This points to it being a bad idea to have the large 
    316 communications network resulting from the number of nodes being large. 
    317 Up to a half dozen nodes seems pretty reasonable; every time the 
    318 number of nodes doubles, this can be expected to quadruple 
    319 communications overheads.</para> 
     321<para>Tout ceci prouve qu'il n'est pas judicieux de bâtir un grand réseau de communication  
     322  pour supporter un systÚme de réplication contenant beaucoup de noeuds. 
     323  Jusqu'à une demi-douzaine de noeuds cela semble raisonnable; à chaque fois que  
     324  le nombre de noeuds double, les temps de communications quadruplent.</para> 
    320325</sect1>