Changeset 1073

Show
Ignore:
Timestamp:
06/11/08 21:24:03 (3 months ago)
Author:
daamien
Message:

1ere traduction, à relire

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/locking.xml

    r901 r1073  
    55     révision $Revision$ --> 
    66 
    7 <sect1 id="locking"> <title>Locking Issues</title> 
     7<sect1 id="locking"> <title>ProblÚmes de verrous</title> 
    88 
    9 <indexterm><primary>locking issues</primary></indexterm> 
     9<indexterm><primary>problÚmes de verrous</primary></indexterm> 
    1010 
    11 <para> One of the usual merits the use, by &postgres;, of 
    12 Multi-Version Concurrency Control (<acronym>MVCC</acronym>) is that 
    13 this eliminates a whole host of reasons to need to lock database 
    14 objects.  On some other database systems, you need to acquire a table 
    15 lock in order to insert data into the table; that can 
    16 <emphasis>severely</emphasis> hinder performance.  On other systems, 
    17 read locks can impede writes; with <acronym>MVCC</acronym>, &postgres; 
    18 eliminates that whole class of locks in that <quote>old reads</quote> 
    19 can access <quote>old tuples.</quote> Most of the time, this allows 
    20 the gentle user of &postgres; to not need to worry very much about 
    21 locks. </para> 
     11<para> L'un des avantages de &postgres; et de son contrÃŽleur de concurrence de  
     12  multiple version ( "Multi-Version Concurrency Control", nommé  
     13  <acronym>MVCC</acronym> par la suite ) est qu'il élimine de nombreuses 
     14  raison de verrouiller les objets de base de données. Sur certains  
     15  systÚmes de gestion de bases de données, vous devez verrouiller une table 
     16  lorsque vous souhaitez insérer des données dans celle-ci; cela peut entraver 
     17  <emphasis>sévÚrement</emphasis> les performances. Sur d'autres systÚmes, 
     18  les lectures bloque les écritures concurrentes. Avec <acronym>MVCC</acronym>, &postgres; 
     19  supprime tous une catégorie de verrous, dans le sens ou les  
     20  <quote>vieilles lectures</quote> peuvent accéder aux <quote>anciens tuples</quote>. 
     21  La pluspart du temps, cela évite aux aimables utilisateurs de  
     22  &postgres; de trop se préoccuper des verrous.</para> 
    2223 
    23 <para> Unfortunately, there are several sorts of &slony1; events that 
    24 do require exclusive locks on &postgres; tables, with the result that 
    25 modifying &slony1; configuration can bring back some of those 
    26 <quote>locking irritations.</quote>  In particular:</para> 
     24<para> Malheureusement, il existe plusieurs sortes d'événements &slony1;  
     25  qui nécessite des verrous exclusifs sur les tables  &postgres;, 
     26  ce qui entraine que la modification de la configuration &slony1;, 
     27  peut provoquer des <quote>verrous génants</quote>. 
     28  En particulier:</para> 
    2729 
    2830<itemizedlist> 
    …… 
    3133table</command> </link></para> 
    3234 
    33 <para> A momentary exclusive table lock must be acquired on the 
    34 <quote>origin</quote> node in order to add the trigger that collects 
    35 updates for that table.  It only needs to be acquired long enough to 
    36 establish the new trigger.</para> 
     35<para> Un verrou exclusif et momentané doit être posé sur 
     36  une table du noeud <quote>origine</quote> afin de d'ajouter le trigger 
     37  qui collecte les mises à jour de cette table. I doit simplement être 
     38  posé assez longtemps pour établir le nouveau trigger.</para> 
    3739</listitem> 
    3840 
    …… 
    4042set</command> </link></para> 
    4143 
    42 <para> When a set origin is shifted from one node to another, 
    43 exclusive locks must be acquired on each replicated table on both the 
    44 old origin and the new origin in order to change the triggers on the 
    45 tables.  </para></listitem> 
     44<para> Lorsqu'un ensemble sur un noeud origine est déplacé vers un autre noeud, 
     45  des verrous exclusifs sont posé sur chaque table répliquée à la fois sur  
     46  l'ancien et le nouveau noeud origine afin de modifier les triggers sur ces tables. 
     47  </para></listitem> 
    4648 
    4749<listitem><para><link linkend="stmtlockset"> <command> lock set 
    4850</command> </link> </para> 
    4951 
    50 <para> This operation expressly requests locks on each of the tables in a 
    51 given replication set on the origin node.</para> 
     52<para> Cette opération demande explicitement des verrous sur chaque 
     53  table dans un ensemble de réplication donné sur le noeud origine. 
     54  </para> 
    5255</listitem> 
    5356 
    …… 
    5558script</command> </link> </para> 
    5659 
    57 <para> This operation runs a set of SQL queries; in order for it to 
    58 work, the &slony1; triggers must be removed, followed by the query 
    59 (which potentially updates the data) running, followed by triggers 
    60 being restored.  The operation therefore must acquire table locks on 
    61 all replicated tables on each node. </para> 
     60<para> Cette opération lance un ensemble de requête SQL; 
     61  pour qu'elle fonctionne, les triggers  &slony1; doivent être 
     62  retirés, ensuite les requêtes sont exécutées ( ce qui peut modifier 
     63  les données ), enfin les triggers sont restaurés. Pour cela,  
     64  l'opération doit acquérir des verrous sur toutes les tables de 
     65  chaque noeuds. </para> 
    6266</listitem> 
    6367 
    64 <listitem><para> During the <command>SUBSCRIBE_SET</command> event on 
    65 a new subscriber </para> 
     68<listitem><para> Pendant un événement <command>SUBSCRIBE_SET</command> sur  
     69    un nouvel abonné </para> 
    6670 
    67 <para> In a sense, this is the least provocative scenario, since, 
    68 before the replication set has been populated, it is pretty reasonable 
    69 to say that the node is <quote>unusable</quote> and that &slony1; 
    70 could reasonably demand exclusive access to the node. </para> 
     71<para> Dans un sens, c'est le scénario le moins perturbant, car 
     72  avant que l'ensemble de réplication soit complet, on peut 
     73  penser que le noeud <quote>inutilisable</quote> et que  
     74   &slony1; peut raisonnablement demander l'accÚs exclusif sur le noeud. 
     75    </para> 
    7176 
    72 <para> A change in version 1.2 is that an express <command>LOCK 
    73 TABLE</command> SQL request is submitted in the loop that validates 
    74 that all of the tables are there.  This means that 
    75 <emphasis>all</emphasis> tables in the replication set will be locked 
    76 via an exclusive lock for the entire duration of the process of 
    77 subscription.  By locking the tables early, this means that the 
    78 subscription cannot fail after copying some of the data due to some 
    79 other process having held on to a table. </para> 
     77<para> Un changement dans la version 1.2 provoque une requête SQL <command>LOCK 
     78TABLE</command> explicite qui est placé dans la boucle qui valide que toutes les 
     79tables sont présentes. Cela signifie que  
     80<emphasis>toutes</emphasis> les tables de l'ensemble de réplication 
     81sont verrouiller avec un verrou exclusif pour la durée totale du processus 
     82de souscription. En verrouillant les tables trÚs tÃŽt, on s'assure que 
     83le souscription n'échouera pas à cause d'un autre processus ayant un  
     84verrou sur une table. 
     85</para> 
    8086 
    81 <para> In any case, note that this one began with the wording 
    82 <quote>on a new subscriber.</quote> The locks are applied <emphasis>on 
    83 the new subscriber.</emphasis> They are <emphasis>not</emphasis> 
    84 applied on the provider or on the origin. </para> 
     87<para> Dans tous les cas, notez que ce script opÚre  
     88<quote>sur un nouveau noeud abonné</quote>. Les verrous sont posés 
     89<quote>sur un nouveau noeud abonné</quote>. Ils s'appliquent <emphasis>pas</emphasis>   
     90au noeud fournisseur ou au noeud origine. </para> 
    8591 
    8692</listitem> 
    8793 
    88 <listitem><para> <application>pg_autovacuum</application> may not be 
    89 part of &slony1;, but those that run it find that it wakes up roughly 
    90 once per minute and may, at any time, start vacuuming a table, thereby 
    91 taking out a <envar>ShareUpdateExclusiveLock</envar> lock.  This may 
    92 block the other events for an unpredictable period of time.</para> 
     94<listitem><para> <application>pg_autovacuum</application> ne fait pas partie 
     95de &slony1;, mais il se réveille une fois par minute et peut, à tout moment, 
     96se lancer dans le nettoyage d'une table, et ainsi poser un verrou 
     97<envar>ShareUpdateExclusiveLock</envar>. Ceci peut bloquer les autres événements 
     98pendant un période imprévisible.</para> 
    9399</listitem> 
    94100 
    95101</itemizedlist> 
    96102 
    97 <para> Each of these actions requires, at some point, modifying each 
    98 of the tables in the affected replication set, which requires 
    99 acquiring an exclusive lock on the table.  Some users that have tried 
    100 running these operations on &slony1; nodes that were actively 
    101 servicing applications have experienced difficulties with deadlocks 
    102 and/or with the operations hanging up. </para> 
     103<para> Chacune de ces actions nécessite, à un certain de point, de  
     104  modifier chaque table de l'ensemble de réplication, ce qui implique 
     105  l'acquisition d'un verrou exclusif sur les tables. Certains utilisateurs 
     106  ont tenté d'effectuer ces opérations sur des noeuds qui étaient activement 
     107  sollicités par la couche applicative; ils ont rencontré des problÚmes 
     108  d'inter-blocages ("deadlocks") et/ou des arrêts de réplication. </para> 
    103109 
    104 <para> The obvious question: <quote>What to do about such 
    105 deadlocks?</quote> </para> 
     110<para> La question évident est : <quote>Que faire pour éviter ces inter-blocages ?</quote> </para> 
    106111 
    107 <para> Several possibilities admit themselves: </para> 
     112<para> Plusieurs possibilités sont envisageables : </para> 
    108113 
    109114<itemizedlist> 
    110115 
    111 <listitem><para> Announce an application outage to avoid deadlocks 
    112 </para> 
     116<listitem><para> Annoncer une coupure de service pour éviter les inter-blocages  
     117    </para> 
    113118 
    114 <para> If you can temporarily block applications from using the 
    115 database, that will provide a window of time during which there is 
    116 nothing running against the database other than administrative 
    117 processes under your control. </para> </listitem> 
     119<para>Si vous pouvez empêcher temporairement les applications  
     120  d'accéder à la base de données, cela vous offrira une fenêtre de temps 
     121  pendant laquelle aucune opération ne sera effectuée sur la base de données, 
     122  à l'exception des processus d'administration que vous controllerez. 
     123  </para> </listitem> 
    118124 
    119 <listitem><para> Try the operation, hoping for things to work </para>  
     125<listitem><para> Tenter l'operation, en espérant que cela fonctionne </para>  
    120126 
    121 <para> Since nothing prevents applications from leaving access locks 
    122 in your way, you may find yourself deadlocked.  But if the number of 
    123 remaining locks are small, you may be able to negotiate with users to 
    124 <quote>get in edgewise.</quote> </para> 
     127<para> Puisque rien n'empêche les application de laisser de verrous sur 
     128  votre chemin, vous pourrez vous retrouver dans une situation de blocage. 
     129  Mais si le nombre de verrous restant est faible, vous pouvez négocier  
     130  avec les utilisateurs pour <quote>avoir la priorité</quote>. </para> 
    125131</listitem> 
    126132 
    127 <listitem><para> Use pgpool </para>  
     133<listitem><para> Utiliser pgpool </para>  
    128134 
    129 <para> If you can use this or some similar <quote>connection 
    130 broker</quote>, you may be able to tell the connection manager to stop 
    131 using the database for a little while, thereby letting it 
    132 <quote>block</quote> the applications for you.  What would be ideal 
    133 would be for the connection manager to hold up user queries for a 
    134 little while so that the brief database outage looks, to them, like a 
    135 period where things were running slowly. </para></listitem> 
     135<para> Si vous pouvez utiliser pgpool ou un <quote>gestionnaire de connexion 
     136</quote> similaire, vous pouvez configurer le programme pour 
     137qu'il n'utilise plus la base pendant un petit moment, et ainsi  
     138le laisser <quote>bloquer</quote> les applications pour vous. 
     139L'idéal étant que le gestionnaire de connexion retiennent les requêtes 
     140assez longtemps pour que la coupure de service apparaisse comme un 
     141simple ralentissement. </para></listitem> 
    136142 
    137 <listitem><para> Rapid Outage Management </para>  
     143<listitem><para> Gestion rapide de coupure de service </para>  
    138144 
    139 <para> The following procedure may minimize the period of the outage: 
     145<para> La procédure suivante minimisera le temps de coupure de service: 
    140146 
    141147<itemizedlist> 
    142148 
    143 <listitem><para> Modify <filename>pg_hba.conf</filename> so that only 
    144 the <link linkend="slonyuser"> <command>slony</command> user </link> 
    145 will have access to the database. </para> </listitem> 
     149<listitem><para> Modifier <filename>pg_hba.conf</filename> afin que seul 
     150<link linkend="slonyuser">l'utilisateur <command>slony</command> user </link> 
     151ait accÚs à la base de données.</para> </listitem> 
    146152 
    147 <listitem><para> Issue a <command>kill -SIGHUP</command> to the 
    148 &postgres; postmaster.</para> 
     153<listitem><para> Envoyer un  <command>kill -SIGHUP</command> au postmaster de 
     154&postgres;.</para> 
    149155 
    150 <para> This will not kill off existing possibly-long-running queries, 
    151 but will prevent new ones from coming in.  There is an application 
    152 impact in that incoming queries will be rejected until the end of the 
    153 process. 
     156<para> Ceci ne tuera pas les longues requêtes qui pourraient être en cours d'exécution 
     157  mais cela empêchera les nouvelles d'entrer. Cela a un impact sur l'application 
     158  puisque les requêtes entrantes seront rejetées jusqu'à la fin de la procédure. 
    154159</para> 
    155160</listitem> 
    156161 
    157 <listitem><para> If <quote>all looks good,</quote> then it should be 
    158 safe to proceed with the &slony1; operation. </para> </listitem> 
     162<listitem><para> Si <quote>tout va bien</quote>, alors on peut 
     163    effectuer sans danger l'opération &slony1;. </para> </listitem> 
    159164 
    160 <listitem><para> If some old query is lingering around, you may need 
    161 to <command>kill -SIGQUIT</command> one of the &postgres; processes. 
    162 This will restart the backend and kill off any lingering queries.  You 
    163 probably need to restart the <xref linkend="slon"/> processes that 
    164 attach to the node. </para>  
     165<listitem><para> si une requête est toujours en cours, vous devrez peut-être 
     166    effectuer un  <command>kill -SIGQUIT</command> sur un des processus 
     167    &postgres;. Cela relancera le moteur et tuera toutes les requêtes  
     168    en attente. Vous devrez probablement relancer les processus   
     169    <xref linkend="slon"/> qui sont attachés à ce noeud. </para>  
    165170 
    166 <para> At that point, it will be safe to proceed with the &slony1; 
    167 operation; there will be no competing processes.</para></listitem> 
     171<para> A ce point, l'opération &slony1; peut être effectuée sans danger; 
     172  Il n'y aura aucun autre processus concurrent. 
     173  </para></listitem> 
    168174 
    169 <listitem><para> Reset <filename>pg_hba.conf</filename> to allow other 
    170 users in, and <command>kill -SIGHUP</command> the postmaster to make 
    171 it reload the security configuration. </para> </listitem> 
     175<listitem><para> Recharger l'ancienne version du fichier <filename>pg_hba.conf</filename> 
     176    pour autoriser les utilisateurs, et envoyer un <command>kill -SIGHUP</command> 
     177    au processus postmaster pour qu'il recharge la configuration de sécurité. </para> </listitem> 
    172178</itemizedlist> 
    173179 
    …… 
    175181</listitem> 
    176182 
    177 <listitem><para> The section  &rddlchanges; suggests some additional 
    178 techniques that may be useful, such as moving tables between 
    179 replication sets in such a way that you minimize the set of tables 
    180 that need to be locked. </para></listitem> 
     183<listitem><para> La section  &rddlchanges; suggÚre des techniques 
     184    supplémentaires qui peuvent être utiles, telles que le déplacement 
     185    des tables vers d'autres ensemble de réplication afin de minimiser 
     186    le nombre de tables qu'il faut verrouiller.</para></listitem> 
    181187 
    182188</itemizedlist> 
    183189 
    184 <para> Regrettably, there is no perfect answer to this.  If it is 
    185 <emphasis>necessary</emphasis> to submit a <xref 
    186 linkend="stmtmoveset"/> request, then it is presumably 
    187 <emphasis>necessary</emphasis> to accept the brief application outage. 
    188 As &slony1;/<link linkend="pgpool"> pgpool </link> linkages improve, 
    189 that may become a better way to handle this.</para> 
    190  
     190<para> Malheureusement, il n'y a pas de solution miracle.  
     191  Si il est <emphasis>nécessaire</emphasis> de soumettre une requête 
     192  <xref linkend="stmtmoveset"/>, alors il est probablement 
     193<emphasis>nécessaire</emphasis> d'accepter une courte coupure de service. 
     194Au fur et à mesure que les relations entre &slony1; et <link linkend="pgpool"> pgpool </link>, 
     195s'améliore, ce couple semble être la meilleure méthode pour éviter les inter-blocages.  
     196</para> 
    191197</sect1>