[Trad] [svn:pgfr] r1111 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Dim 27 Juil 13:34:19 CEST 2008
Author: daamien
Date: 2008-07-27 13:34:18 +0200 (Sun, 27 Jul 2008)
New Revision: 1111
Modified:
traduc/trunk/slony/intro.xml
Log:
Slony : Intro / 1ere trad ( ?\195?\160 relire )
Modified: traduc/trunk/slony/intro.xml
===================================================================
--- traduc/trunk/slony/intro.xml 2008-07-27 11:33:44 UTC (rev 1110)
+++ traduc/trunk/slony/intro.xml 2008-07-27 11:34:18 UTC (rev 1111)
@@ -5,278 +5,284 @@
révision $Revision$ -->
<sect1 id="introduction">
-<title>Introduction to &slony1;</title>
+<title>Introduction à &slony1;</title>
-<indexterm><primary> introduction to &slony1; </primary></indexterm>
+<indexterm><primary> introduction à &slony1; </primary></indexterm>
-<sect2> <title>What &slony1; is</title>
+<sect2> <title>Qu'est ce que &slony1; ?</title>
-<para>&slony1; is a <quote>master to multiple slaves</quote>
-replication system supporting cascading and slave promotion. The big
-picture for the development of &slony1; is as a master-slave system
-that includes the sorts of capabilities needed to replicate large
-databases to a reasonably limited number of slave systems.
-<quote>Reasonable,</quote> in this context, is on the order of a dozen
-servers. If the number of servers grows beyond that, the cost of
-communications increases prohibitively, and the incremental benefits
-of having multiple servers will be falling off at that point.</para>
+<para>&slony1; est système de réplication entre <quote>un maître et de multiple esclaves</quote>
+qui supporte les cascades et la promotion d'un esclave en maître.
+Le schéma directeur du développement de &slony1; est la création
+d'un système maître-esclave qui inclue les fonctionnalités nécessaire
+pour répliquer de grandes bases de données avec un nombre raisonnable
+d'esclaves. <quote>Raisonnable,</quote> dans ce contexte, signifie
+une douzaine de serveurs. Si le nombre de serveurs évolue au-delà de
+cette limite, le coût des communications augmentent de manière prohibitive,
+et le bénéfice d'avoir de multiple serveurs s'amenuise.</para>
-<para> See also <xref linkend="slonylistenercosts"/> for a further
-analysis of costs associated with having many nodes.</para>
+<para> Voir la section <xref linkend="slonylistenercosts"/> pour une
+ analyse plus détaillées des coûts associés à l'augmentation du
+ nombre de noeuds.</para>
-<para> &slony1; is a system intended for data centers and backup
-sites, where the normal mode of operation is that all nodes are
-available all the time, and where all nodes can be secured. If you
-have nodes that are likely to regularly drop onto and off of the
-network, or have nodes that cannot be kept secure, &slony1; is
-probably not the ideal replication solution for you.</para>
+<para> &slony1; est un système conçu pour les datacenters et sites de
+ sauvegardes, où le fonctionnement des opérations est que tous les
+ noeuds sont disponibles en permanence, et où tous les noeuds peuvent
+ être sécurisés. Si vous avez des noeuds qui risquent régulièrement d'être
+ coupés du réseau, ou si la sécurité de vos noeuds ne peut pas
+ être garantie, &slony1; n'est probablement pas la solution de réplication
+ idéale pour vous.</para>
-<para> Thus, examples of cases where &slony1; probably won't work out
-well would include:
+<para> Voici notamment quelques exemples de cas où &slony1; ne sera probablement
+ pas adapté :
<itemizedlist>
-<listitem><para> Sites where connectivity is really <quote>flakey</quote>
+<listitem><para> Les sites dont la connectivité est <quote>instable</quote>
</para></listitem>
-<listitem><para> Replication to nodes that are unpredictably connected.</para></listitem>
+<listitem><para> La réplication entre des noeuds qui ne sont pas toujours interconnectés</para></listitem>
-<listitem><para> Replicating a pricing database from a central server to sales
-staff who connect periodically to grab updates. </para></listitem>
+<listitem><para> Répliquer une base de tarification à partir d'un serveur central vers
+ l'équipe commerciale qui s'y connecte périodiquement pour en extraire les mise à jour.
+ </para></listitem>
-<listitem><para> Sites where configuration changes are made in a
-haphazard way.</para></listitem>
+<listitem><para> Les sites où les changements de configuration sont faits de
+ manière hasardeuse.</para></listitem>
-<listitem><para> A <quote>web hosting</quote> situation where customers can
-independently make arbitrary changes to database schemas is not a good
-candidate for &slony1; usage. </para></listitem>
-
+<listitem><para> Un situation <quote>d'hébergement web</quote> où les
+ utilisateurs peuvent de manière indépendante et arbitraire changer les
+ schémas des données.
</itemizedlist></para>
-<para> There is also a <link linkend="logshipping">file-based log
-shipping</link> extension where updates would be serialized into
-files. Given that, log files could be distributed by any means
-desired without any need of feedback between the provider node and
-those nodes subscribing via <quote>log shipping.</quote> <quote>Log
-shipped</quote> nodes do not add to the costs of communicating events
-between &slony1; nodes.</para>
+<para> Il existe une extension de <link linkend="logshipping"> log shipping par fichier</link>
+ qui permet de regrouper les mises à jour dans des fichiers.
+ Ainsi, les fichiers de mises à jours peuvent être distribués
+ par différents moyens sans avoir à attendre d'accusé de réception
+ entre les noeud fournisseur et les noeuds qui sont abonnés au
+ <quote>log shipping</quote>. Le noeuds abonnés au <quote>Log
+shipping</quote> n'augmente pas les coûts de communication être
+les noeuds &slony1;.</para>
-<para> But &slony1;, by only having a single origin for each set, is
-quite unsuitable for <emphasis>really</emphasis> asynchronous multiway
-replication. For those that could use some sort of
-<quote>asynchronous multimaster replication with conflict
-resolution</quote> akin to what is provided by <productname>Lotus
-<trademark>Notes</trademark></productname> or the
-<quote>syncing</quote> protocols found on PalmOS systems, you will
-really need to look elsewhere. </para>
+<para> Mais &slony1;, ayant une seule origine par ensemble de données répliqué,
+ n'est pas adapté pour effectuer de la réplication <emphasis>réellement</emphasis> asynchrone
+ et multi-directionnelle. Pour celles et ceux qui recherche une
+ <quote>réplication asynchrone multi-maîtres avec résolution des conflits</quote>
+ telle que ce que fournit <productname>Lotus
+<trademark>Notes</trademark></productname> ou les protocoles de <quote>synchronisation</quote>
+présents sur les systèmes PalmOS, il est nécessaire de se tourner vers d'autres logiciels.
+</para>
-<para> These other sorts of replication models are not without merit,
-but they represent <emphasis>different</emphasis> replication
-scenarios that &slony1; does not attempt to address.</para>
+<para> Il existe également d'autres modèles de réplication qui ne sont pas sans avantages,
+ mais qui permettent des scénarios de réplication <emphasis>différents</emphasis>
+ de ce que &slony1; propose.</para>
</sect2>
-<sect2><title>Why yet another replication system?</title>
+<sect2><title>Pourquoi proposer encore un autre système de réplication ?</title>
-<para>&slony1; was born from an idea to create a replication system
-that was not tied to a specific version of &postgres;, which is
-allowed to be started and stopped on an existing database without the
-need for a dump/reload cycle.</para>
+<para>&slony1; est né de l'idée de créer un système de réplication qui ne soient
+ pas lié à une version spécifique de &postgres;, pour qu'il puisse être lancé
+ et arrêté sur une base existante sans besoin d'effectuer un cycle d'export/import
+ des données.</para>
</sect2>
-<sect2><title> What &slony1; is not</title>
+<sect2><title> Ce que &slony1; n'est pas</title>
<itemizedlist>
-<listitem><para>&slony1; is not a network management system.</para></listitem>
+<listitem><para>&slony1; n'est pas un système de gestion de réseau.</para></listitem>
-<listitem><para> &slony1; does not have any functionality within it to detect a
-node failure, nor to automatically promote a node to a master or other
-data origin.</para>
+<listitem><para> &slony1; n'a aucune fonctionnalité permettant de détecter
+ la perte d'un noeud, ni de transformer automatiquement un noeud en maître
+ ou en noeud origine.</para>
-<para> It is quite possible that you may need to do that; that will
-require that you combine some network tools that evaluate <emphasis>
-to your satisfaction </emphasis> which nodes you consider
-<quote>live</quote> and which nodes you consider <quote>dead</quote>
-along with some local policy to determine what to do under those
-circumstances. &slony1; does not dictate any of that policy to
-you.</para></listitem>
+<para> Il est toutefait possible que vous ayez besoin de ce type de mécanisme;
+ cela vous demandera de combiner des outils réseau qui évaluent
+ <emphasis>selon vos critères</emphasis> quels noeuds vous considérez comme
+<quote>actifs</quote> et quels noeuds vous considérez comme <quote>morts</quote>,
+ainsi qu'une politique locale pour déterminer ce qu'il faut faire dans telle ou telle circonstance.
+&slony1; ne vous impose aucune politique.</para></listitem>
-<listitem><para>&slony1; is not a multi-master replication system; it
-is not a connection broker, and it won't make you coffee and toast in
-the morning.</para></listitem>
+<listitem><para>&slony1; n'est pas un système de réplication multi-maîtres;
+ ce n'est pas un gestionnaire de connexions, et il ne vous apportera pas
+ le café et les croissants le matin.</para></listitem>
</itemizedlist>
-<para>All that being said, there are tools available to help with some
-of these things, and there is a plan under way for a subsequent
-system, <productname>Slony-II</productname>, to provide
-<quote>multimaster</quote> capabilities. But that represents a
-different, separate project, being implemented in a rather different
-fashion than &slony1;, and expectations for &slony1; should not be
-based on hopes for future projects.</para></sect2>
+<para>Ceci étant dit, il existe des outils à votre disposition pour
+ simplifier certaines de ces opérations, et il existe un projet en cours
+ de développement, <productname>Slony-II</productname>, pour fournir
+ des mécanismes <quote>multi-maîtres</quote>. Mais cela constitue
+ un projet différent et séparé, implémenté de façon très différente
+ de &slony1;, et attentes à propos de &slony1; ne doivent pas se baser
+ sur l'espoir placé dans de futurs projets.</para></sect2>
-<sect2><title> Why doesn't &slony1; do automatic fail-over/promotion?
+<sect2><title> Pourquoi &slony1; ne fait pas de bascule automatique en cas de panne («fail over») ?
</title>
-<para>Determining whether a node has <quote>failed</quote> is properly
-the responsibility of network management software, not &slony1;. The
-configuration, fail-over paths, and preferred policies will be
-different for each site. For example, keep-alive monitoring with
-redundant NIC's and intelligent HA switches that guarantee
-race-condition-free takeover of a network address and disconnecting
-the <quote>failed</quote> node will vary based on network
-configuration, vendor choices, and the combinations of hardware and
-software in use. This is clearly in the realm of network management
-and not &slony1;.</para>
+<para>Déterminer si un noeud est en <quote>échec</quote> est de la responsabilité
+ d'un logiciel de surveillance de réseau, pas de &slony1;. La configuration,
+ les mécanismes de bascule et les politiques de reprise sur panne sont
+ différent selon les sites. Par exemple, la surveillance avec des NICs redondants
+ et les mécanismes de haute-disponibilité intelligents qui garantissent
+ un changement d'adresse réseau à la volée sans conflit et une isolation
+ du noeud <quote>en échec</quote>, dépendent de la configuration du réseau,
+ des choix matériels et de la combinaison entre les logiciels et les appareils
+ utilisés. Tout cela appartient clairement au domaine de la gestion de réseau,
+ pas à celui de &slony1;.</para>
-<para> Furthermore, choosing what to do based on the
-<quote>shape</quote> of the cluster represents local business policy,
-particularly in view of the fact that <link
-linkend="stmtfailover"><command>FAIL OVER</command></link> requires
-discarding the failed node. If &slony1; imposed failover policy on
-you, that might conflict with business requirements, thereby making
-&slony1; an unacceptable choice.</para>
+<para> De plus, choisir comment se comporter selon
+<quote>l'état</quote> du cluster concerne la politique commerciale locale,
+en particulier si on considère qu'une <link
+linkend="stmtfailover"><command>bascule en cas de panne</command></link> ( « fail over » ) nécessite
+d'isoler le noeud en échec. Si &slony1; imposait une politique de bascule en cas de panne
+aux utilisateurs, cela entrerait parfois en conflit avec des
+intérêts commerciaux et &slony1; serait parfois une solution inadaptée.</para>
-<para>As a result, let &slony1; do what it does best: provide database
-replication services.</para></sect2>
+<para>En conséquence, laissons &slony1; faire ce qu'il fait de mieux : fournir un service de
+ réplication de bases de données.</para></sect2>
-<sect2><title> Current Limitations</title>
+<sect2><title> Limitations actuelles</title>
-<indexterm><primary>limitations to &slony1;</primary></indexterm>
+<indexterm><primary>limitations de &slony1;</primary></indexterm>
-<para>&slony1; does not automatically propagate schema changes, nor
-does it have any ability to replicate large objects. There is a
-single common reason for these limitations, namely that &slony1;
-collects updates using triggers, and neither schema changes, large
-object operations, nor <command>TRUNCATE</command> requests are able
-to have triggers suitable to inform &slony1; when those sorts of
-changes take place. As a result, the only database objects where
-&slony1; can replicate updates are tables and sequences. </para>
+<para>&slony1; ne propage pas les changements du schéma de données,
+ et ne réplique non plus les objets volumineux ( «large objects» )
+ Il y a une raison unique et commune à ces limitations :
+ &slony1; collecte les mises à jours en utilisant des triggers, et
+ ni les changements de schéma, ni les opérations sur les objets volumineux,
+ ni les requêtes <command>TRUNCATE</command> ne sont capables de
+ déclencher des triggers pour informer &slony1; lorsque ce genre
+ de modification a lieu. Ainsi les seuls objets que &slony1; peut répliquer
+ sont les tables et les séquences. </para>
-<para> Note that with the <emphasis>use</emphasis> of triggers comes
-some additional <emphasis>fiddling around with triggers</emphasis>.
-On the <quote>origin</quote> for each replicated table, an additional
-trigger is added which runs the stored procedure <xref
-linkend="function.logtrigger"/>. On each subscriber, tables are
-augmented with a trigger that runs the <xref
-linkend="function.denyaccess"/> function; this function prevents
-anything other than the <xref linkend="slon"/> process from updating
-data in replicated tables. In addition, any
-<emphasis>other</emphasis> triggers and rules on replicated tables are
-<emphasis>suppressed</emphasis> on the subscribers: This is done by
-pointing them, in the system table, to the primary key index instead
-of to the table itself. This represents something of a
-<quote>corruption</quote> of the data dictionary, and is why you
-should not directly use <application>pg_dump</application> to dump
-schemas on subscribers. </para>
+<para> Notons que <emphasis>l'utilisation</emphasis> de triggers implique
+ quelques <emphasis>retoucher</emphasis> supplémentaires sur ces triggers.
+Sur le noeud <quote>origine</quote> pour chaque table répliquée, on ajoute un trigger
+supplémentaire qui lance la procédure stockée <xref
+linkend="function.logtrigger"/>.
+Sur chaque noeud abonné, les tables sont complétées avec un trigger qui lance
+la fonction <xref
+linkend="function.denyaccess"/>; cette fonction empêche toute mise à jour
+sur les tables répliquées à l'exception de celles effectuées par
+le processus <xref linkend="slon"/>.
+De plus, toutes les <emphasis>autres</emphasis> triggers et règles
+sur les tables répliquées sont <emphasis>supprimés</emphasis> sur
+les noeuds abonnés; Ceci est réalisé en faisant pointant ces tables,
+dans le catalogue système, vers les index des clefs primaires
+plutôt que sur la table elle-même.
+Cela s'apparente à une <quote>corruption</quote> du dictionnaire de données,
+et cela explique pourquoi on ne peut pas utiliser directement
+ <application>pg_dump</application> pour exporter le schéma sur les
+ noeuds abonnés. </para>
-<para>There is a capability for &slony1; to propagate other kinds of
-database modifications, notably DDL changes, if you submit them as
-scripts via the <application>slonik</application> <xref
-linkend="stmtddlscript"/> operation. That is not handled
-<quote>automatically;</quote> you, as a database administrator, will
-have to construct an SQL DDL script and submit it, via <xref
-linkend="stmtddlscript"/> and there are a number of further <link
-linkend="ddlchanges"> caveats.</link> </para>
+<para>Il est possible de propager d'autres types de modifications des bases
+ avec &slony1;, notamment les ordres DDL, si vous les effectuer via la fonction
+ de <application>slonik</application> nommée <xref
+linkend="stmtddlscript"/>. Ceci ne peut pas se faire
+<quote>automatiquement</quote>; en tant qu'administrateur de base de données,
+vous devez superviser les scripts SQL DDL et les soumettre via <xref
+linkend="stmtddlscript"/> car il existe un certain nombre de
+pièges à éviter concernant les <link
+linkend="ddlchanges">.</link> </para>
-<para>If you have those sorts of requirements, it may be worth
-exploring the use of &postgres; 8.X <acronym>PITR</acronym> (Point In
-Time Recovery), where <acronym>WAL</acronym> logs are replicated to
-remote nodes. Unfortunately, that has two attendant limitations:
+<para>Si vous ne pouvez pas superviser ces modifications, vous devrez peut-être
+ envisager l'utilisation du mécanisme <acronym>PITR</acronym> (Point In
+Time Recovery) de &postgres; (version 8.x), avec lequel les journaux
+<acronym>WAL</acronym> sont répliqués sur des noeuds distants.
+Malheureusement cette solution à deux limitations majeures :
<itemizedlist>
-<listitem><para> PITR replicates <emphasis>all</emphasis> changes in
-<emphasis>all</emphasis> databases; you cannot exclude data that isn't
-relevant;</para></listitem>
+<listitem><para> Le mécanisme PITR replique <emphasis>tous</emphasis> les changements de
+<emphasis>toutes</emphasis> les bases de données; vous ne pouvez pas
+exclure les données qui ne sont pas intéressantes;</para></listitem>
-<listitem><para> A PITR replica remains dormant until you apply logs
-and start up the database. You cannot use the database and apply
-updates simultaneously. It is like having a <quote>standby
-server</quote> which cannot be used without it ceasing to be
-<quote>standby.</quote></para></listitem>
+<listitem><para> Un réplicat PITR reste endormi jusqu'à ce que les journaux
+ soient appliqués et que la base soit relancée. Vous ne pouvez pas
+ utiliser la base et appliquer les mises à jour simultanément.
+ Cela revient à avoir un <quote>serveur de secours</quote> que
+ vous ne pouvez utiliser sans stopper la réplication.</para></listitem>
</itemizedlist></para>
</sect2>
-<sect2><title>Replication Models</title>
+<sect2><title>Modèles de réplication</title>
-<indexterm><primary>replication models</primary></indexterm>
+<indexterm><primary>modèles de réplication</primary></indexterm>
-<para>There are a number of distinct models for database replication;
-it is impossible for one replication system to be all things to all
-people.</para>
+<para>%Il beaucoup de modèles de réplication différents; il est
+ qu'un système de réplication puisse répondre à toutes les attentes
+ de tous les utilisateurs.</para>
-<para> &slony1; implements a particular model, namely that of
-asynchronous replication, using triggers to collect table updates,
-where a single <quote>origin</quote> may be replicated to multiple
-<quote>subscribers</quote> including cascaded subscribers.</para>
+<para> &slony1; implémente un modèle particulier, la réplication asynchrone,
+ en utilisant des triggers pour collecter les mises à jour sur les tables,
+ sur une <quote>origine</quote> unique, puis réplique ces mises à jour
+ sur de multiple <quote>abonnés</quote>, y compris les abonnés en cascade.</para>
-<para> There are a number of other replication models which are
-<emphasis> different </emphasis>; it is worth pointing out other
-approaches that exist. &slony1; is certainly not the only approach,
-and for some applications, it is <emphasis> not </emphasis> the
-optimal approach. </para>
+<para> Il existe de de nombreaux autres modèles de réplication
+ qui sont <emphasis> différent </emphasis> de celui-ci; il est
+ important de souligner que d'autres approches sont possibles.
+ &slony1; n'est certainement pas la seule approche, et pour certaines
+ applications, ce n'est <emphasis> pas </emphasis> la meilleur approche. </para>
<itemizedlist>
-<listitem><para> Synchronous single-origin multi-subscriber replication</para>
+<listitem><para> Réplication synchrone entre une origine unique et plusieurs abonnés</para>
-<para> In a synchronous system, updates cannot be committed at the
-origin until they have also been accepted by subscriber nodes. This
-enhances the security property of nonrepudiation as updates will not
-be committed until they can be confirmed elsewhere. Unfortunately,
-the requirement that changes be applied in multiple places introduces
-a performance bottleneck. </para>
+<para> Dans un système synchrone, les mises à jour ne peuvent pas être committées
+ sur l'origine tant qu'elles n'ont pas été acceptées par les noeuds abonnés.
+ Ceci renforce la sécurité en évitant les risques de répudiation, car les mises
+ à jour ne sont pas effectuées sans avoir été confirmées ailleurs. Malheureusement,
+ la nécessité d'appliquer simultanément les changements sur de multiple emplacement
+ constitue un frein sur les performances. </para>
-<para> This approach is similar to the two phase commit processing
-model of the XA transaction processing protocol.</para>
+<para> Cette approche est similaire au modèle basé sur le commit en deux phases ( NdT : « two phase commit » )
+ implémenté dans le protocole de gestion de transaction XA.</para>
</listitem>
-<listitem><para> Synchronous multi-origin multi-subscriber replication </para>
+<listitem><para> Réplication synchrone entre plusieurs origines et plusieurs abonnés </para>
-<para> This is the model being used by the possibly-forthcoming
-<productname>Slony-II</productname> system. Synchronous replication
-systems all <quote>suffer</quote> from the performance bottleneck that
-updates must be accepted on all nodes before they can be
-<command>commit</command>ted anywhere. </para>
+<para> Ceci est le modèle implémenté dans l'hypothétique système
+<productname>Slony-II</productname>. Les systèmes de réplication synchrones
+<quote>souffrent</quote> de problèmes de performances, car les mises à jour doivent
+être acceptées par tous les noeuds avant d'être appliquées.</para>
-<para> That generally makes it impractical to run synchronous
-replication across wide area networks. </para>
+<para> En pratique, il est inutile de faire fonctionner un système de réplication
+ synchrone sur un réseau longue distance (WAN).</para>
</listitem>
-<listitem><para> Asynchronous multimaster replication with conflict
-avoidance/resolution</para>
+<listitem><para> Réplication asynchrone multi-maîtres avec résolution/prévention des conflits</para>
-<para> Perhaps the most widely used replication system of this sort is
-the <productname>PalmOS HotSync</productname> system.
-<trademark>Lotus Notes</trademark> also provides a replication system
-that functions in much this manner.</para>
+<para> Le système de réplication le plus répandu utilisant ce modèle est probablement
+ le système <productname>PalmOS HotSync</productname>.
+<trademark>Lotus Notes</trademark> fournit également un système de réplication
+qui fonctionne de la même manière.</para>
-<para> The characteristic <quote>troublesome problem</quote> with this
-style of replication is that it is possible for conflicts to arise
-because users update the same record in different ways on different
-nodes. </para>
+<para> Le <quote>problème</quote> caractéristique avec ce
+style de réplication est que des conflits peuvent apparaître
+lorsque des utilisateurs mettent à jour le même enregistrement
+de différente manière sur différents noeuds.</para>
-<para> In the case of <productname>HotSync</productname>, if conflicts
-arise due to records being updated on multiple nodes, the
-<quote>resolution</quote> is to simply create a duplicate record to
-reflect the two changes, and have the user resolve the conflict
-manually. </para>
+<para> Dans le cas de <productname>HotSync</productname>, si un conflit
+ est provoqué par la mise à jour simultanée d'un même enregistrement,
+ la <quote>résolution</quote> se résume à créer un deuxième enregistrement
+ pour témoigner des deux mises à jours, puis laisser l'utilisateur résoudre
+ le conflit à la main. </para>
-<para> Some async multimaster systems try to resolve conflicts by
-finding ways to apply partial record updates. For instance, with an
-address update, one user, on one node, might update the phone number
-for an address, and another user might update the street address, and
-the conflict resolution system might try to apply these updates in a
-non-conflicting order. This can also be considered a form of
-<quote>table partitioning</quote> where a database table is treated as
-consisting of several <quote>sub-tables.</quote> </para>
+<para> Certains systèmes de réplication multi-maîtres asynchrones essaient
+ de résoudre les conflits en trouvant de moyens pour appliquer partiellement
+ les mises à jour. Par exemple, dans le cas de la mise à jour d'un adresse,
+ si un autre utilisateur tente de mettre à jour le nom de la rue, alors le
+ système de résolution des conflits essaie d'appliquer les mises à jour
+ dans un ordre non-conflictuel. On peut considérer cette méthode comme
+ une forme de <quote>partitionnement de table</quote> où l'on considère la
+ base de données comme une table constituée de plusieurs <quote>sous-tables</quote>. </para>
-<para> Conflict resolution systems almost always require some domain
-knowledge of the application being used, which means that they can
-only deal automatically with those conflicts where you have assigned a
-policy. If they run into conflicts for which no policy is available,
-replication stops until someone applies some manual
-intervention. </para>
+<para> Les systèmes de résolution de conflit nécessaire presque toujours
+ une bonne connaissance du domaine de l'application, ce qui implique
+ qu'ils ne peuvent résoudre des conflits automatiquement uniquement si
+ vous leur indiquez une politique de résolution. S'ils rencontrent
+ un conflit et qu'il n'existe pas de politique définie, la réplication
+ s'arrête jusqu'à ce que quelqu'un résolve le conflit à la main.</para>
</listitem>
</itemizedlist>
@@ -284,37 +290,36 @@
</sect2>
</sect1>
-<sect1 id="slonylistenercosts"><title> &slony1; Communications
-Costs</title>
+<sect1 id="slonylistenercosts"><title> Coûts de communications avec &slony1;</title>
-<para>The cost of communications grows in a quadratic fashion in
-several directions as the number of replication nodes in a cluster
-increases. Note the following relationships:
+<para>Le coût de communications augmente de façon quadratique dans plusieurs
+directions lorsque le nombre de noeuds de réplication du cluster
+grandit. Notons les relations suivantes :
<itemizedlist>
-<listitem><para> It is necessary to have <xref
-linkend="table.sl-listen"/> entries allowing connection from each node
-to every other node. Most will normally not need to be very heavily,
-but it still means that there needs to be n(n-1) paths.
+<listitem><para> Il est nécessaire que les entrées de la table <xref
+linkend="table.sl-listen"/> autorise toutes les connexions entre tous les noeuds.
+Dans le pluspart des cas, cela n'est pas très volumineux, mais cela signifie tout
+de même qu'il faut définir n(n-1) voies de communications.
</para></listitem>
-<listitem><para> Each SYNC applied needs to be reported back to all of
-the other nodes participating in the set so that the nodes all know
-that it is safe to purge <xref linkend="table.sl-log-1"/> and <xref
-linkend="table.sl-log-2"/> data, as any <quote>forwarding</quote> node
-could potentially take over as <quote>master</quote> at any time. One
-might expect SYNC messages to need to travel through n/2 nodes to get
-propagated to their destinations; this means that each SYNC is
-expected to get transmitted n(n/2) times. Again, this points to a
-quadratic growth in communications costs as the number of nodes
-increases.</para></listitem>
+<listitem><para> Chaque événement SYNC appliqué doit être annoncé à
+ tous les noeuds participants à la réplication de l'ensemble de
+ données, afin que chaque noeud sache qu'il est possible de
+ purger les données des tables <xref linkend="table.sl-log-1"/> et <xref
+linkend="table.sl-log-2"/>, car n'importe quel noeud <quote>fournisseur</quote>
+ peut potentiellement devenir un <quote>maître</quote> à tout moment.
+ On peut s'attendre à que les messages SYNC ne soient propagés que sur
+ n/2 noeuds pour atteindre leur destination; ce qui implique que
+ chaque SYNC est transmis n(n/2) fois. A nouveau, cela montre
+ que la croissance des coûts de communication est quadratique selon
+ le nombre de noeuds dans le cluster.</para></listitem>
</itemizedlist></para>
-<para>This points to it being a bad idea to have the large
-communications network resulting from the number of nodes being large.
-Up to a half dozen nodes seems pretty reasonable; every time the
-number of nodes doubles, this can be expected to quadruple
-communications overheads.</para>
+<para>Tout ceci prouve qu'il n'est pas judicieux de bâtir un grand réseau de communication
+ pour supporter un système de réplication contenant beaucoup de noeuds.
+ Jusqu'à une demi-douzaine de noeuds cela semble raisonnable; à chaque fois que
+ le nombre de noeuds double, les temps de communications quadruplent.</para>
</sect1>
More information about the Trad
mailing list