Changeset 527

Show
Ignore:
Timestamp:
12/13/06 17:22:52 (2 years ago)
Author:
sas
Message:

Corrections suite à remarques tigrou3tac

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/manuel/high-availability.xml

    r508 r527  
    203203 
    204204 <varlistentry> 
    205   <term>Réplication synchrone à plusieurs maîtres</term> 
    206   <listitem> 
    207  
    208    <para> 
    209     Dans les réplication synchrone à plusieurs maîtres, chaque serveur peut 
    210     accepter les requêtes en écriture et les données modifiées sont transmises 
     205  <term>Réplication synchrone multi-maîtres</term> 
     206  <listitem> 
     207 
     208<!-- Je corrige l'erreur relevée par tigrou3tac, mais le passage est à 
     209reprendre. Les phrases sont un peu lourdes --> 
     210   <para> 
     211    Dans les réplications synchrones multi-maîtres, chaque serveur peut 
     212    accepter les requêtes en écriture. Les données modifiées sont transmises 
    211213    du serveur original à tous les autres serveurs avant validation de chaque 
    212214    transaction. Une activité importante en écriture peut être la cause d'un 
    213     verrouillage excessif amenant des performances pauvres. En fait, la 
    214     performance en écriture est souvent pire que celle d'un simple serveur. Les 
     215    verrouillage excessif conduisant à un effondrement des performances. En fait, la 
     216    performance en écriture est souvent pis que celle d'un simple serveur. Les 
    215217    requêtes en lecture peuvent être envoyées à tous les serveurs. Certaines 
    216     implémentations utilisent les disques partagés pour réduire la surcharge 
    217     de communication. La réplication synchrone multi-maître est bien meilleure 
    218     principalement pour grosses charges de travail en lecture bien que son gros 
     218    implantations utilisent les disques partagés pour réduire la surcharge 
     219    de communication. La réplication synchrone multi-maîtres est bien meilleure 
     220    principalement pour de grosses charges de travail en lecture bien que son gros 
    219221    avantage est que tout serveur peut accepter des requêtes d'écriture &mdash; 
    220222    il n'est pas nécessaire de partitionner les travaux entre les serveurs 
    221     maître et esclaves et, comme les modifications de données sont envoyées 
     223    maîtres et esclaves et, comme les modifications de données sont envoyées 
    222224    d'un serveur à un autre, il n'y a pas de problème avec les fonctions 
    223225    non déterministiques comme <function>random()</function>.