Changeset 981

Show
Ignore:
Timestamp:
04/13/08 11:30:34 (9 months ago)
Author:
daamien
Message:

1ere trad , à relire

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/firstdb.xml

    r937 r981  
    55     révision $Revision$ --> 
    66 
    7 <sect1 id="firstdb"><title>Replicating Your First Database</title> 
    8  
    9 <indexterm><primary>replicating your first database</primary></indexterm> 
    10  
    11 <para>In this example, we will be replicating a brand new 
    12 <application>pgbench</application> database.  The mechanics of 
    13 replicating an existing database are covered here, however we 
    14 recommend that you learn how &slony1; functions by using a fresh new 
    15 non-production database.</para> 
    16  
    17 <para> Note that <application>pgbench</application> is a 
    18 <quote>benchmark</quote> tool that is in the &postgres; set of 
    19 <filename>contrib</filename> tools. If you build &postgres; from 
    20 source, you can readily head to <filename>contrib/pgbench</filename> 
    21 and do a <command>make install</command> to build and install it; you 
    22 may discover that included in packaged binary &postgres; 
    23 installations.</para> 
    24  
    25 <para>The &slony1; replication engine is trigger-based, allowing us to 
    26 replicate databases (or portions thereof) running under the same 
    27 postmaster.</para> 
    28  
    29 <para>This example will show how to replicate the 
    30 <application>pgbench</application> database running on localhost 
    31 (master) to the <application>pgbench</application> slave database also running on localhost 
    32 (slave).  We make a couple of assumptions about your &postgres; 
    33 configuration: 
    34  
     7<sect1 id="firstdb"><title>Répliquer votre premiÚre base de données</title> 
     8 
     9<indexterm><primary>Répliquer votre premiÚre base de données</primary></indexterm> 
     10 
     11<para>Dans cet exemple, nous allons répliquer une base de donnée 
     12  <application>pgbench</application> neuve.  Les mécanismes de réplications 
     13  d'une base existante sont abordé ici, cependant nous vous recommandons d'apprendre  
     14  comment utiliser les fonctions &slony1; en utilisant une base fraîchement créée, 
     15  placée sur un serveur qui n'est pas en production.</para> 
     16 
     17<para> Notez que <application>pgbench</application> est une outil de <quote>tests</quote> ( "benchmark" ) 
     18  qui se trouve parmi les outils <filename>contrib</filename> de &postgres; Si vous compilez &postgres; 
     19  depuis les sources, vous devez vous rendre dans le répertoire <filename>contrib/pgbench</filename> 
     20  et exécuter la commande <command>make install</command> pour le compiler et l'installer; 
     21  Vous pouvez par ailleurs le trouver inclus dans les paquets binaires de  &postgres;. 
     22</para> 
     23 
     24<para>Le moteur de réplication de &slony1; est basée sur les triggers, ce qui permet  
     25  répliquer des bases de données ( ou des parties de celles-ci ) hébergées par le  
     26  même postmaster.</para> 
     27 
     28<para>Cet exemple montre comment répliquer la base <application>pgbench</application>  
     29  hébergées sur localhost (maître) vers la base <application>pgbench</application> esclave  
     30  hébergée elle aussi sur localhost (esclave). Nous nous basons sur deux suppositions 
     31  à propos de votre configuration de &postgres; : 
    3532<itemizedlist> 
    3633 
    37 <listitem><para> You have <option>tcpip_socket=true</option> in your 
    38 <filename>postgresql.conf</filename> and</para></listitem> 
    39  
    40 <listitem><para> You have enabled access in your cluster(s) via 
     34<listitem><para> Vous avez la ligne <option>tcpip_socket=true</option> dans votre  
     35<filename>postgresql.conf</filename> et </para></listitem> 
     36 
     37<listitem><para> Vous avez activer les accÚs à votre cluster via  
    4138<filename>pg_hba.conf</filename></para></listitem> 
    4239 
    4340</itemizedlist></para> 
    4441 
    45 <para> The <envar>REPLICATIONUSER</envar> needs to be a &postgres; 
    46 superuser.  This is typically postgres or pgsql, although in complex 
    47 environments it is quite likely a good idea to define a 
    48 <command>slony</command> user to distinguish between the roles.</para> 
    49  
    50 <para>You should also set the following shell variables: 
     42<para> L'utilisateur <envar>REPLICATIONUSER</envar> doit être un super-utilisateur  
     43  &postgres;.  C'est en général, postgres ou pgsql, cependant au sein d'environnements 
     44  complexes, il est parfois judicieux de définir un utilisateur <command>slony</command>  
     45  pour distinguer les différents rÃŽles.</para> 
     46 
     47<para>Vous devez également définir les variables shell suivantes : 
    5148 
    5249<itemizedlist> 
    53 <listitem><para> <envar>CLUSTERNAME</envar>=slony_example</para></listitem> 
     50<listitem><para> <envar>CLUSTERNAME</envar>=exemple_slony</para></listitem> 
    5451<listitem><para> <envar>MASTERDBNAME</envar>=pgbench</para></listitem> 
    55 <listitem><para> <envar>SLAVEDBNAME</envar>=pgbenchslave</para></listitem> 
     52<listitem><para> <envar>SLAVEDBNAME</envar>=pgbench_esclave</para></listitem> 
    5653<listitem><para> <envar>MASTERHOST</envar>=localhost</para></listitem> 
    5754<listitem><para> <envar>SLAVEHOST</envar>=localhost</para></listitem> 
    …… 
    6057</itemizedlist> 
    6158</para> 
    62 <para>Here are a couple of examples for setting variables in common shells: 
     59<para>Voici deux maniÚres de paramétrer ces variables avec un shell standard : 
    6360 
    6461<itemizedlist> 
    6562<listitem> 
    6663  <para>bash, sh, ksh 
    67   <command>export CLUSTERNAME=slony_example</command></para> 
     64  <command>export CLUSTERNAME=exemple_slony</command></para> 
    6865</listitem> 
    6966<listitem> 
    7067  <para>(t)csh: 
    71   <command>setenv CLUSTERNAME slony_example</command></para> 
     68  <command>setenv CLUSTERNAME exemple_slony</command></para> 
    7269</listitem> 
    7370</itemizedlist> 
    7471</para> 
    7572 
    76 <para><warning><para> If you're changing these variables to use 
    77 different hosts for <envar>MASTERHOST</envar> and <envar>SLAVEHOST</envar>, be sure 
    78 <emphasis>not</emphasis> to use localhost for either of them.  This will result 
    79 in an error similar to the following:</para> 
     73<para><warning><para> Si vous changez vos variables afin d'utiliser différents hÃŽtes  
     74      pour <envar>MASTERHOST</envar> et <envar>SLAVEHOST</envar>, soyez certain de  
     75<emphasis>ne pas</emphasis> utiliser localhost pour aucun des deux. Ceci provoquerait 
     76une erreur similaire à celle-ci :</para> 
    8077 
    8178<para><command> 
    …… 
    8582 
    8683 
    87 <sect2><title>Creating the <application>pgbench</application> user</title> 
     84<sect2><title>Créer l'utilisateur <application>pgbench</application></title> 
    8885 
    8986<para><command> 
    …… 
    9289</para> 
    9390</sect2> 
    94 <sect2><title>Preparing the databases</title> 
     91<sect2><title>Préparer les bases</title> 
    9592 
    9693<programlisting> 
    …… 
    10097</programlisting> 
    10198 
    102 <para> One of the tables created by 
    103 <application>pgbench</application>, <envar>history</envar>, does not 
    104 have a primary key.  In earlier versions of &slony1;, a &lslonik; 
    105 command called <xref linkend="stmttableaddkey"/> could be used to 
    106 introduce one.  This caused a number of problems, and so this feature 
    107 has been removed in version 2 of &slony1;.  It now 
    108 <emphasis>requires</emphasis> that there is a suitable candidate 
    109 primary key. </para> 
    110  
    111 <para> The following SQL requests will establish a proper primary key on this table: </para> 
     99<para> Une des tables crées par <application>pgbench</application>, <envar>history</envar>, 
     100  n'a pas de clé primaire. Dans les versions antérieurs de &slny1;, un commande 
     101  &slonik; nommée  <xref linkend="stmttableaddkey"/> pouvait être utilisées pour 
     102  en introduire une. Ceci provoquait de nombreux problÚmes si bien que cette  
     103  fonctionnalités fut supprimée dans la version 2 &slony1;. Il est désormais  
     104<emphasis>nécessaires</emphasis> d'avoir une ensemble éligible en tant que  
     105 clé primaire. </para> 
     106 
     107<para> Les requêtes SQL suivantes établissent une clé primaire cohérente pour cette table.: </para> 
    112108 
    113109<programlisting> 
    …… 
    118114</programlisting> 
    119115 
    120 <para>Because &slony1; depends on the databases having the pl/pgSQL 
    121 procedural language installed, we better install it now.  It is 
    122 possible that you have installed pl/pgSQL into the template1 database 
    123 in which case you can skip this step because it's already installed 
    124 into the <envar>$MASTERDBNAME</envar>. 
     116<para>Puisque &slony1; dépend de la présence du langage procédural pl/pgSQL 
     117, nous devons l'installer maintenant. Il est possible que vous ayez installé  
     118pl/pgSQL dans la base template1, auquel cas vous pouvez sauter cette étape 
     119car le langage est installé par défaut dans la base  <envar>$MASTERDBNAME</envar>. 
    125120 
    126121<programlisting> 
    …… 
    129124</para> 
    130125 
    131 <para>&slony1; does not automatically copy table definitions from a 
    132 master when a slave subscribes to it, so we need to import this data. 
    133 We do this with <application>pg_dump</application>. 
     126<para>&slony1; ne copie pas automatiquement les définitions de tables  
     127  du maître lorsqu'un esclave s'y connecte à lui, ainsi nous devons importer 
     128  ces données. Nous réalisons cette opération avec <application>pg_dump</application>. 
    134129 
    135130<programlisting> 
    …… 
    138133</para> 
    139134 
    140 <para>To illustrate how &slony1; allows for on the fly replication 
    141 subscription, let's start up <application>pgbench</application>.  If 
    142 you run the <application>pgbench</application> application in the 
    143 foreground of a separate terminal window, you can stop and restart it 
    144 with different parameters at any time.  You'll need to re-export the 
    145 variables again so they are available in this session as well. 
    146 </para> 
    147  
    148 <para>The typical command to run <application>pgbench</application> would look like: 
     135<para>Pour illustrer comment &slony1; permet une réplication à la volée,  
     136  nous lançons l'application <application>pgbench</application>.  
     137  Si vous exécutez <application>pgbench</application> en tache de premier plan 
     138  dans une fenêtre de terminal séparée, vous pouvez l'arrêter et la relancer  
     139  à tout moment avec des paramÚtres différents. Vous devrez exporter les  
     140  variables d'environnement pour qu'elles soient également disponibles dans cette session. 
     141</para> 
     142 
     143<para>La commande habituelle pour exécuter <application>pgbench</application> est : 
    149144 
    150145<programlisting> 
    …… 
    153148</para> 
    154149 
    155 <para>This will run <application>pgbench</application> with 5 concurrent clients 
    156 each processing 1000 transactions against the <application>pgbench</application> 
    157 database running on localhost as the pgbench user. 
     150<para>Ceci lancera <application>pgbench</application> avec 5 clients concurrents, 
     151  exécutant chacun 1000 transactions sur la base <application>pgbench</application> 
     152  hébergées sur localhost, en utilisant l'utilisateur pgbench. 
    158153</para></sect2> 
    159154 
    160 <sect2><title>Configuring the Database for Replication.</title> 
    161  
    162 <para>Creating the configuration tables, stored procedures, triggers 
    163 and configuration is all done through the <xref linkend="slonik"/> 
    164 tool. It is a specialized scripting aid that mostly calls stored 
    165 procedures in the master/slave (node) databases. </para> 
    166  
    167 <sect3><title>Using the altperl scripts</title> 
    168  
    169 <indexterm><primary> altperl script usage </primary></indexterm> 
     155<sect2><title>Configurer la base de donnée pour la réplication.</title> 
     156 
     157<para>La création des tables de configuration, des procédures stockées, des triggers, 
     158  et la configuration sont prises en charges par l'outil <xref linkend="slonik"/>.  
     159  Il s'agit d'un script d'aide spécialisé, qui appelle principalement des procédures stockées 
     160  sur les noeuds maître et esclaves.</para> 
     161 
     162<sect3><title>Utiliser les scripts altperl</title> 
     163 
     164<indexterm><primary> Utilisation des scripts altperl</primary></indexterm> 
    170165 
    171166<para> 
    172 Using the <xref linkend="altperl"/> scripts is an easy way to get started.  The 
    173 <command>slonik_build_env</command> script will generate output providing 
    174 details you need to  omplete building a <filename>slon_tools.conf</filename>.  
    175 An example <filename>slon_tools.conf</filename> is provided in the distribution 
    176 to get you started.  The altperl scripts will all reference 
    177 this central configuration file in the future to ease administration. Once  
    178 slon_tools.conf has been created, you can proceed as follows: 
    179 </para> 
    180  
    181 <programlisting> 
    182 # Initialize cluster: 
     167L'utilisation des scripts <xref linkend="altperl"/> est une façon simple de  
     168faire ses premiers pas.  Le script <command>slonik_build_env</command>  
     169génÚre une sortie fournissant les détails nécessaires à la construction  
     170complÚte d'un fichier <filename>rslon_tools.conf</filename>. 
     171Un exemple de fichier <filename>slon_tools.conf</filename> est fournit dans la distribution 
     172afin d'aider à la prise en main. Les script altperl font tous référence à ce  
     173fichier central de configuration afin de simplifier l'administration.  
     174Une fois le fichier slon_tools.conf créé, vous pouvez poursuivre comme ceci : 
     175</para> 
     176 
     177<programlisting> 
     178# Initialisation du cluster: 
    183179$ slonik_init_cluster  | slonik  
    184180 
    185 # Start slon  (here 1 and 2 are node numbers) 
     181# Démarrage de slon  (ici 1 et 2 sont les numéros de noeuds) 
    186182$ slon_start 1     
    187183$ slon_start 2 
    188184 
    189 # Create Sets (here 1 is a set number) 
     185# Création des ensemble (ici 1 est le numéro de l'ensemble) 
    190186$ slonik_create_set 1              
    191187 
    192 # subscribe set to second node (1= set ID, 2= node ID) 
    193 $ slonik_subscribe_set  2 | slonik 
    194 </programlisting> 
    195  
    196 <para> You have now replicated your first database.  You can skip the following section 
    197 of documentation if you'd like, which documents more of a <quote>bare-metal</quote> approach.</para> 
     188# Abonner l'ensemble dans le second noeud (1= n° d'ensemble, 2= n° de noeud) 
     189$ slonik_subscribe_set  1 2 | slonik 
     190</programlisting> 
     191 
     192<para> Vous avez répliqué votre premiÚre base de données.  
     193  Vous pouvez sauter la section suivante de la documentation  
     194  si vous le souhaitez, car il s'agit d'une approche plus  
     195   <quote>rustre</quote>.</para> 
    198196</sect3> 
    199197 
    200 <sect3><title>Using slonik command directly</title> 
    201  
    202 <para>The traditional approach to administering slony is to craft 
    203 slonik commands directly. An example of this given here. </para> 
    204  
    205 <para> The script to create 
    206 the initial configuration for the simple master-slave setup of our 
    207 <application>pgbench</application> database looks like this:</para> 
     198<sect3><title>Utiliser directement les commandes slonik</title> 
     199 
     200<para>L'approche traditionnelle pour administrer slony consiste à utiliser directement  
     201  les commandes slonik. En voici un exemple </para> 
     202 
     203<para> Le script de création de la configuration initiale  
     204  pour une simple configuration maître-esclave de la base 
     205  <application>pgbench</application> est le suivant :</para> 
    208206 
    209207<programlisting><![CDATA[ 
    …… 
    212210slonik <<_EOF_ 
    213211        #-- 
    214         # define the namespace the replication system uses in our example it is 
    215         # slony_example 
     212        # défintion de l'espace de nom du systÚme de réplication 
     213        # dans notre exemple il s'agit de exemple_slony 
    216214        #-- 
    217215        cluster name = $CLUSTERNAME; 
    218216 
    219217        #-- 
    220         # admin conninfo's are used by slonik to connect to the nodes one for each 
    221         # node on each side of the cluster, the syntax is that of PQconnectdb in 
    222         # the C-API 
     218        # les paramÚtres "admin conninfo" sont utilisé par slonik pour se connecter 
     219        # aux noeuds. Une ligne par noeud. La syntaxe est celle de PQconnectdb dans la  
     220        # C-API 
    223221        # -- 
    224222        node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER'; 
    …… 
    226224 
    227225        #-- 
    228         # init the first node.  Its id MUST be 1.  This creates the schema 
    229         # _$CLUSTERNAME containing all replication system specific database 
    230         # objects. 
    231  
     226        # initialisation du premier noeud. Son identifiant DOIT être 1.  Cela provoque la création 
     227        # du schema _$CLUSTERNAME contenant tous les objets spécifiques du systÚme 
     228        # de réplication 
    232229        #-- 
    233230        init cluster ( id=1, comment = 'Master Node'); 
    234231  
    235232        #-- 
    236         # Because the history table does not have a primary key or other unique 
    237         # constraint that could be used to identify a row, we need to add one. 
    238         # The following command adds a bigint column named 
    239         # _Slony-I_$CLUSTERNAME_rowID to the table.  It will have a default value 
    240         # of nextval('_$CLUSTERNAME.s1_rowid_seq'), and have UNIQUE and NOT NULL 
    241         # constraints applied.  All existing rows will be initialized with a 
    242         # number 
     233        # Puisque la table history n'a pas de clé primaire, ni de contrainte unique 
     234        # qui pourrait être utilisée pour identifier une ligne, nous devons en ajouter 
     235        # une. 
     236        # La commande suivante ajoute à la table une colonne bigint nommée  
     237        # _Slony-I_$CLUSTERNAME_rowID. Elle comme valeur par défaut  
     238        # nextval('_$CLUSTERNAME.s1_rowid_seq'), et dispose des contraintes 
     239        # UNIQUE et NOT NULL. Toutes les lignes existantes seront initialisées 
     240        # avec un dentifiant. 
    243241        #-- 
    244242        table add key (node id = 1, fully qualified name = 'public.history'); 
    245243 
    246244        #-- 
    247         # Slony-I organizes tables into sets.  The smallest unit a node can 
    248         # subscribe is a set.  The following commands create one set containing 
    249         # all 4 pgbench tables.  The master or origin of the set is node 1. 
     245        # Slony-I regroupe les tables dans des ensembles. 
     246        # La plus petite unité qu'un noeud peut répliquer est un ensemble  
     247        # Les commandes suivantes créée un ensemble contenant 4 tables pgbench. 
     248        # Le maître (ou origine) de l'ensemble est le noeud 1. 
    250249        #-- 
    251250        create set (id=1, origin=1, comment='All pgbench tables'); 
    …… 
    256255 
    257256        #-- 
    258         # Create the second node (the slave) tell the 2 nodes how to connect to 
    259         # each other and how they should listen for events. 
    260         #-- 
    261  
     257        # Création du second noeud (l'esclave)  
     258        # décrit comment les 2 noeuds vont se connecter l'un à l'autre 
     259        # et quelle maniÚre ils vont écouter les événements.. 
     260        #-- 
    262261        store node (id=2, comment = 'Slave node'); 
    263262        store path (server = 1, client = 2, conninfo='dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER'); 
    …… 
    266265]]></programlisting> 
    267266 
    268 <para>Is the <application>pgbench</application> still running?  If 
    269 not, then start it again.</para> 
    270  
    271 <para>At this point we have 2 databases that are fully prepared.  One 
    272 is the master database in which <application>pgbench</application> is 
    273 busy accessing and changing rows.  It's now time to start the 
    274 replication daemons.</para> 
    275  
    276 <para>On $MASTERHOST the command to start the replication engine is 
     267<para>L'application <application>pgbench</application> est-elle toujours exécutée ? 
     268  Si ce n'est pas le cas, redémarrez-la. 
     269</para> 
     270 
     271<para>A ce moment, nous avons 2 bases de données qui sont complÚtement préparées. 
     272  Une d'elle est la base maître, celle que l'application <application>pgbench</application> 
     273  utilise pour lire et modifier des lignes. Le temps est donc venu de lancer les  
     274  démons de réplication.</para> 
     275 
     276<para>Sur $MASTERHOST, la commande pour démarrer le moteur de réplication est : 
    277277 
    278278<programlisting> 
    …… 
    280280</programlisting> 
    281281</para> 
    282 <para>Likewise we start the replication system on node 2 (the slave) 
     282<para>De la même façon, nous démarrons le systÚme de réplication sur le noeud 2 (l'esclave) 
    283283 
    284284<programlisting> 
    …… 
    286286</programlisting> 
    287287</para> 
    288 <para>Even though we have the <xref linkend="slon"/> running on both 
    289 the master and slave, and they are both spitting out diagnostics and 
    290 other messages, we aren't replicating any data yet.  The notices you 
    291 are seeing is the synchronization of cluster configurations between 
    292 the 2 <xref linkend="slon"/> processes.</para> 
    293  
    294 <para>To start replicating the 4 <application>pgbench</application> 
    295 tables (set 1) from the master (node id 1) the the slave (node id 2), 
    296 execute the following script. 
     288<para>Même si nous avons désormais le démon <xref linkend="slon"/> exécuté sur 
     289  à la fois sur le maître et l'esclave, et qu'ils sont tous les deux en train de 
     290  cracher des diagnostiques et d'autres messages, les données ne sommes toujours  
     291  pas répliquées. L'activité que vous constatez est la synchronisation de la 
     292  configuration du cluster entre les 2 processus <xref linkend="slon"/>. 
     293  </para> 
     294 
     295<para>Pour démarrer la réplication des 4 tables <application>pgbench</application> 
     296 (l'ensemble 1) depuis le maître (le noeud 1) vers l'esclave (le noeud 2), 
     297 lancez le script suivant : 
    297298 
    298299<programlisting><![CDATA[ 
    …… 
    300301slonik <<_EOF_ 
    301302         # ---- 
    302          # This defines which namespace the replication system uses 
     303         # Définition de l'espace de nom du cluster 
    303304         # ---- 
    304305         cluster name = $CLUSTERNAME; 
    305306 
    306307         # ---- 
    307          # Admin conninfo's are used by the slonik program to connect 
    308          # to the node databases.  So these are the PQconnectdb arguments 
    309          # that connect from the administrators workstation (where 
    310          # slonik is executed). 
     308         # Les paramÚtres conninfo sont utilisés par le programme slonik 
     309         # pour se connecter aux noeuds. Ce sont donc les arguments  
     310         # PQconnectdb pour se connecter depuis la station de travail 
     311         # d'administration (où les scripts slonik sont exécutés). 
    311312         # ---- 
    312313         node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER'; 
    …… 
    314315 
    315316         # ---- 
    316          # Node 2 subscribes set 1 
     317         # Le noeud 2 s'abonne à l'ensemble 1 
    317318         # ---- 
    318319         subscribe set ( id = 1, provider = 1, receiver = 2, forward = no); 
    …… 
    321322</para> 
    322323 
    323 <para>Any second now, the replication daemon on 
    324 <envar>$SLAVEHOST</envar> will start to copy the current content of 
    325 all 4 replicated tables.  While doing so, of course, the 
    326 <application>pgbench</application> application will continue to modify 
    327 the database.  When the copy process is finished, the replication 
    328 daemon on <envar>$SLAVEHOST</envar> will start to catch up by applying 
    329 the accumulated replication log.  It will do this in little steps, 10 
    330 seconds worth of application work at a time.  Depending on the 
    331 performance of the two systems involved, the sizing of the two 
    332 databases, the actual transaction load and how well the two databases 
    333 are tuned and maintained, this catchup process can be a matter of 
    334 minutes, hours, or eons.</para> 
    335  
    336 <para>You have now successfully set up your first basic master/slave 
    337 replication system, and the 2 databases should, once the slave has 
    338 caught up, contain identical data.  That's the theory, at least.  In 
    339 practice, it's good to build confidence by verifying that the datasets 
    340 are in fact the same.</para> 
    341  
    342 <para>The following script will create ordered dumps of the 2 
    343 databases and compare them.  Make sure that 
    344 <application>pgbench</application> has completed, so that there are no 
    345 new updates hitting the origin node, and that your slon sessions have 
    346 caught up.</para> 
     324<para>Désormais, le démon de réplication sur<envar>$SLAVEHOST</envar>  se déclenchera à tout moment 
     325  pour copier les changements d'états sur les 4 tables répliquées. 
     326  Pendant ce temps, l'application <application>pgbench</application>  
     327  va continuer à modifier la base de données. 
     328  Lorsque le processus de copie est terminée, le démon de réplication sur le noeud 
     329  <envar>$SLAVEHOST</envar> commencera à se synchroniser en appliquant les journaux  
     330  de réplications qui auront été accumulés. 
     331  Cela se fera par petit à petit, par tranches de 10 secondes de travail applicatifs. 
     332  Selon les performances des 2 systÚmes impliqués, la taille des deux bases de données, 
     333  la charge de transaction et la qualité de l'optimisation et de la maintenance effectuées 
     334  sur les deux bases de données, ce processus de synchronisation peut durer quelques  
     335  minutes, quelques heures ou quelques siÚcles.</para> 
     336 
     337<para>Vous avez maintenant configuré avec un succÚs votre premier systÚme de  réplication  
     338  maître-esclave basique, et les deux bases de données devraient, une fois que l'esclave 
     339  sera synchronisé, contenir des données identiques. Ça c'est la théorie, tout du moins.  
     340  En pratique, il est bon de vérifier que les ensembles de données sont bien identiques.  
     341  </para> 
     342 
     343<para>Le script ci-dessous crée des sauvegardes ordonnées des deux bases et les  
     344  compares. Assurez-vous que le test <application>pgbench</application> est terminé,  
     345  qu'il n'y pas d'autres mises à jour en cours sur le noeud origine, et que les sessions 
     346  slons se sont synchronisées.</para> 
    347347 
    348348<programlisting><![CDATA[ 
    …… 
    381381]]></programlisting> 
    382382 
    383 <para>Note that there is somewhat more sophisticated documentation of 
    384 the process in the &slony1; source code tree in a file called 
    385 <filename>slony-I-basic-mstr-slv.txt</filename>.</para> 
    386  
    387 <para>If this script returns <command>FAILED</command> please contact the 
    388 developers at <ulink url="http://slony.info/"> 
    389 http://slony.info/</ulink></para></sect3> 
     383<para>Notez qu'il existe une documentation un peu plus sophistiquée 
     384  concernant ce processus dans l'arborescence du code source de   
     385  &slony1; au sein d'un fichier nommé <filename>slony-I-basic-mstr-slv.txt</filename>.</para> 
     386 
     387<para>Si ce script retourne <command>FAILED</command>, merci de contacter les développeurs sur  
     388<ulink url="http://slony.info/">http://slony.info/</ulink></para></sect3> 
    390389</sect2> 
    391390</sect1>