Changeset 1093

Show
Ignore:
Timestamp:
07/08/08 14:08:52 (5 months ago)
Author:
daamien
Message:

Slony : ddlchanges traduit par Marie (à relire)

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/ddlchanges.xml

    r901 r1093  
    66 
    77<sect1 id="ddlchanges"> 
    8 <title>Database Schema Changes (DDL)</title> 
     8<title>Changements du schéma de la base (DDL)</title> 
    99 
    1010<indexterm> 
    11  <primary>DDL changes</primary> 
    12  <secondary>database schema changes</secondary> 
     11 <primary>Changements DDL</primary> 
     12 <secondary>changements du schéma de la base</secondary> 
    1313</indexterm> 
    1414 
    15 <para>When changes are made to the database schema, 
    16 <emphasis>e.g.</emphasis> - adding fields to a table, it is necessary 
    17 for this to be handled rather carefully, otherwise different nodes may 
    18 get rather deranged because they disagree on how particular tables are 
    19 built.</para> 
    20  
    21 <para>If you pass the changes through &slony1; via <xref 
    22 linkend="stmtddlscript"/> (slonik) / &funddlscript; (stored function), 
    23 this allows you to be certain that the changes take effect at the same 
    24 point in the transaction streams on all of the nodes.  That may not be 
    25 so important if you can take something of an outage to do schema 
    26 changes, but if you want to do upgrades that take place while 
    27 transactions are still winding their way through your systems, this is 
    28 necessary.  </para> 
    29  
    30 <para>It is essential to use <command>EXECUTE SCRIPT</command> if you 
    31 alter tables so as to change their schemas.  If you do not, then you 
    32 may run into the problems <link linkend="neededexecddl"> described 
    33 here </link> where triggers on modified tables do not take account of 
    34 the schema change.  This has the potential to corrupt data on 
    35 subscriber nodes.</para> 
    36  
    37 <para>It's worth making a couple of comments on <quote>special 
    38 things</quote> about <xref linkend="stmtddlscript"/>:</para> 
     15<para>Lorsque des changements sont faits sur la base, 
     16<emphasis>tels que</emphasis> - l'ajout de champs à une table, il est nécessaire 
     17de la faire prudemment, pour éviter que certains noeuds 
     18ne soient bloqués lors de la création de certaines tables 
     19.</para> 
     20 
     21<para>Si vous opérez les changements à travers &slony1; via <xref 
     22linkend="stmtddlscript"/> (slonik) / &funddlscript; (fonction stockée), 
     23cela vous garantie que les changements prendront effets 
     24au même niveau dans les flux de transactions sur tous les noeuds. Cela n'est pas aussi vital 
     25si vous pouvez arrêter votre systÚme pour appliquer vos modifications de schéma, 
     26mais si vous voulez faire vos mises à jour en même temps que vos transactions continuent de processer à travers votre systÚme, 
     27cela est nécessaire.  </para> 
     28 
     29<para>Il est essentiel d'utiliser <command>EXECUTE SCRIPT</command> si vous 
     30modifiez des tables pour changer leurs schémas.  Si vous ne le faites pas, vous pouvez rencontrer 
     31des problÚmes <link linkend="neededexecddl"> décrits 
     32ici </link> où les triggers des tables modifiées ne tiennent pas compte des changements 
     33de schéma faits. Cela peut conduire à une corruption de données sur le 
     34noeud abonné.</para> 
     35 
     36<para>Il est utile de faire quelques <quote>recommandations</quote> sur 
     37 <xref linkend="stmtddlscript"/>:</para> 
    3938 
    4039<itemizedlist> 
    4140 
    42 <listitem><para>The script <emphasis>must not</emphasis> contain 
    43 transaction <command>BEGIN</command> or <command>END</command> 
    44 statements, as the script is already executed inside a transaction. 
    45 In &postgres; version 8, the introduction of nested transactions 
    46 changes this somewhat, but you must still remain aware that the 
    47 actions in the script are processed within the scope of a single 
    48 transaction whose <command>BEGIN</command> and <command>END</command> 
    49 you do not control.</para></listitem> 
    50  
    51 <listitem><para>If there is <emphasis>anything</emphasis> broken about 
    52 the script, or about how it executes on a particular node, this will 
    53 cause the <xref linkend="slon"/> daemon for that node to panic and 
    54 crash.  You may see various expected messages (positive and negative) 
    55 in <xref linkend="ddllogs"/>.  If you restart the &lslon;, it will, 
    56 more likely than not, try to 
    57 <emphasis>repeat</emphasis> the DDL script, which will, almost 
    58 certainly, fail the second time in the same way it did the first time. 
    59 I have found this scenario to lead to a need to go to the 
    60 <quote>master</quote> node to delete the event from the 
    61 table <envar>sl_event</envar> in order to stop it from continuing to 
    62 fail.</para> 
    63  
    64 <para> The implication of this is that it is 
    65 <emphasis>vital</emphasis> that modifications not be made in a 
    66 haphazard way on one node or another.  The schemas must always stay in 
    67 sync.</para> </listitem> 
    68  
    69 <listitem><para> For &lslon; to, at that point, <quote>panic</quote> 
    70 is probably the 
    71 <emphasis>correct</emphasis> answer, as it allows the DBA to head over 
    72 to the database node that is broken, and manually fix things before 
    73 cleaning out the defective event and restarting 
    74 &lslon;.  You can be certain that the updates 
    75 made <emphasis>after</emphasis> the DDL change on the provider node 
    76 are queued up, waiting to head to the subscriber.  You don't run the 
     41<listitem><para>Le script <emphasis>ne doit pas</emphasis> contenir 
     42de transaction <command>BEGIN</command> ou <command>END</command> 
     43, car il s'exécute déjà dans une transaction. 
     44Avec la version 8 de &postgres;, l'introduction des transactions imbriquées 
     45change cela quelque peu, mais vous devez rester attentif au fait que 
     46les actions du script sont exécutées comme une transaction simple 
     47dans laquelle on ne maîtrise pas le <command>BEGIN</command> et le <command>END</command> 
     48.</para></listitem> 
     49 
     50<listitem><para>Si il y a une erreur<emphasis>quelconque</emphasis> dans le script 
     51, ou un problÚme quelconque sur la maniÚre dont il s'éxécute sur un noeud particulier, 
     52cela conduira le démon <xref linkend="slon"/> de ce noeud à paniquer et à tomber. 
     53Vous pouvez consulter plusieurs types de messages attendus lors d'un déroulement normal ou anormal 
     54à <xref linkend="ddllogs"/>.  Si vous redémarrez le &lslon;, il tentera, 
     55de maniÚre trÚs probable, de 
     56<emphasis>rejouer</emphasis> le script DDL, ce qui conduira certainement au même échec que la premiÚre tentative. 
     57J'ai eu un tel scénario, m'obligeant à supprimer du noeud 
     58<quote>maître</quote> l'évÚnement de la table 
     59<envar>sl_event</envar> pour arrêter de le voir tomber en échec.</para> 
     60 
     61<para> La conséquence de cela est qu'il est 
     62<emphasis>vital</emphasis> que les modifications ne soient pas faites 
     63de maniÚre hasardeuse sur un noeud ou un autre. Les schémas doivent toujours  
     64rester synchronisés.</para> </listitem> 
     65 
     66<listitem><para> Pour &lslon; aussi, à ce niveau, <quote>panic</quote> 
     67est probablement la réponse 
     68<emphasis>correcte</emphasis>, car il permet au DBA de sortir la base du noeud défecteux, 
     69de fixer manuellement le problÚme en supprimant l'évÚnement incorrect et de redémarrer 
     70&lslon;.  Vous pouvez être certain que les mises à jour faites  
     71<emphasis>aprÚs</emphasis> le changement DDL sur le noeud maître sont enregistrées 
     72dans une file d'attente, en attente d'être traitées par l'abonné. 
     73Vous ne courrez ainsi pas le risque que des updates non centralisés par DDL 
     74 
     75You don't run the 
    7776risk of there being updates made that depended on the DDL changes in 
    7877order to be correct.</para></listitem> 
    7978 
    80 <listitem><para> When you run <xref linkend="stmtddlscript"/>, this 
    81 causes the &lslonik; to request, <emphasis>for each table in the 
    82 specified set</emphasis>, an exclusive table lock.</para> 
    83  
    84 <para> It starts by requesting the lock, altering the table to remove 
    85 &slony1; triggers, and restoring any triggers that had been hidden: 
     79<listitem><para> Lorsque vous exécutez <xref linkend="stmtddlscript"/>, cela 
     80conduit &lslonik; à poser, <emphasis>pour chaque table faisant partie du jeu de réplication</emphasis>, 
     81un verrou exclusif table.</para> 
     82 
     83<para> Cela commence par la pose du lock, l'altération de la table pour supprimer les 
     84&slony1; triggers, et la restauration de tous les triggers qui ont étés cachés 
    8685 
    8786<screen> 
    …… 
    9291</screen></para> 
    9392 
    94 <para> After the script executes, each table is 
    95 <quote>restored</quote> to add back either the trigger that collects 
    96 updates at the origin or that denies updates on subscribers: 
     93<para> AprÚs l'exécution du script, chaque table est 
     94<quote>restorée</quote> dans le but d'ajouter en fin soit le trigger qui collecte 
     95les mises à jour sur le noeud origine soit celui qui rejette les mises à jour sur l'abonné. 
    9796 
    9897<screen> 
    …… 
    102101</screen></para> 
    103102 
    104 <para>Note that this is what allows &slony1; to take notice of 
    105 alterations to tables: <emphasis>before</emphasis> 
    106 that <command>SYNC</command>, &slony1; has been replicating tuples 
    107 based on the <emphasis>old</emphasis> 
    108 schema; <emphasis>after</emphasis> the <command>DDL_SCRIPT</command>, 
    109 tuples are being replicated based on the <emphasis>new</emphasis> 
    110 schema. </para> 
    111  
    112 <para> On a system which is busily taking updates, it may be 
    113 troublesome to <quote>get in edgewise</quote> to actually successfully 
    114 engage all the required locks.  The locks may run into deadlocks. 
    115 This points to two ways to address this: 
     103<para>Notez que c'est ce qui permet à &slony1; de prendre connaissance de 
     104l'altération de tables: <emphasis>avant</emphasis> 
     105ce <command>SYNC</command>, &slony1; réplique des tuples suivant le 
     106 <emphasis>vieux</emphasis> 
     107schéma; <emphasis>aprÚs</emphasis> le script <command>DDL_SCRIPT</command>, 
     108les tuples sont répliqués suivant le <emphasis>nouveau</emphasis> 
     109schéma. </para> 
     110 
     111<para> Sur un systÚme réalisant de nombreuses mises à jour, il peut être 
     112difficile <quote>d'obtenir</quote> tous les verrous nécéssaires. 
     113 Les verrous peuvent conduire à des deadlocks. 
     114Vous pouvez régler le problÚme de 2 maniÚres différentes : 
    116115</para></listitem> 
    117116 
    118 <listitem><para> You may be able to <link linkend="definesets"> define 
    119 replication sets </link> that consist of smaller sets of tables so 
    120 that fewer locks need to be taken in order for the DDL script to make 
    121 it into place.</para> 
    122  
    123 <para> If a particular DDL script only affects one table, it should be 
    124 unnecessary to lock <emphasis>all</emphasis> application 
    125 tables.</para> 
    126  
    127 <note><para> Actually, as of version 1.1.5 and later, this 
    128 is <emphasis>NOT TRUE.</emphasis> The danger of someone making DDL 
    129 changes that crosses replication sets seems sufficiently palpable that 
    130 &lslon; has been changed to lock <emphasis>ALL</emphasis> replicated 
    131 tables, whether they are in the specified replication set or 
    132 not. </para></note></listitem> 
    133  
    134 <listitem><para> You may need to take a brief application outage in 
    135 order to ensure that your applications are not demanding locks that 
    136 will conflict with the ones you need to take in order to update the 
    137 database schema.</para></listitem> 
    138  
    139 <listitem><para> In &slony1; versions 1.0 thru 1.1.5, the script is 
    140 processed as a single query request, which can cause problems if you 
    141 are making complex changes.  Starting in version 1.2, the script is 
    142 properly parsed into individual SQL statements, and each statement is 
    143 submitted separately, which is a preferable handling of this.  </para> 
    144  
    145 <para> The trouble with one query processing a <quote>compound 
    146 statement</quote> is that the SQL parser does its planning for that 
    147 entire set of queries based on the state of the database at the 
    148 <emphasis>beginning</emphasis> of the query.</para>    
    149  
    150 <para> This causes no particular trouble if those statements are 
    151 independent of one another, such as if you have two statements to add 
    152 two columns to a table.</para> 
     117<listitem><para> Vous devez envisager de <link linkend="definesets"> définir des jeux de réplication </link> 
     118 représentant un plus petit nombre de tables 
     119de maniÚre à ce que moins de verrous soient posés et permettent au script DDL d'être joué. 
     120.</para> 
     121 
     122<para> Si un script DDL affecte une seule table, il ne devrait pas 
     123être nécessaire de verrouiller <emphasis>toutes</emphasis> les tables de 
     124l'application.</para> 
     125 
     126<note><para> Véritablement, à partir de la version 1.1.5 ou plus, ce 
     127n'est <emphasis>plus vrai.</emphasis> Le danger que quelqu'un opÚre des changements 
     128DDL interférant avec le jeux de réplication est suffisamment évident pour que  
     129&lslon; verrouille  <emphasis>toutes</emphasis> les tables 
     130répliquées, qu'elles soient ou pas dans le jeu de réplication 
     131. </para></note></listitem> 
     132 
     133<listitem><para> Vous pouvez avoir besoin de faire un arrêt de votre systÚme 
     134pour vous assurer que vos applications ne demandent pas des verrous 
     135qui rentreraient en conflit avec ceux dont vous auriez besoin pour faire les changements de schéma de base. 
     136.</para></listitem> 
     137 
     138<listitem><para> Dans les versions 1.0 à 1.1.5 de &slony1; le script s'exécute 
     139comme une simple requête, ce qui peut poser problÚme si vous réaliser des modifications 
     140complexes. A partir de la version 1.2, le script est découpé en traitements SQL individuels, 
     141et chaque requête est soumise séparemment, ce qui est préférable.</para> 
     142 
     143<para> Le problÚme avec une requête traitant une <quote>requête imbriquée</quote> est que le parser SQL 
     144réalise son plan d'exécution pour le jeu entier de requête <emphasis>avant même</emphasis> 
     145 l'exécution de la requête.</para>    
     146 
     147<para> Cela ne pose pas de problÚme particulier si les requêtes 
     148sont indépendantes les unes des autres, tel que 2 requêtes d'ajout de 2 colonnes 
     149à une table.</para> 
    153150 
    154151<para> <command> alter table t1 add column c1 integer; alter table t1 add 
    155152column c2 integer; </command></para> 
    156153 
    157 <para> Trouble arises if a subsequent query needs to reference an 
    158 earlier one.  Consider the following DDL statements...  </para> 
     154<para> Par contre, les problÚmes se rencontrent si vous devez référencer une requête précédente. 
     155Considérer la requête DDL suivante ...</para> 
    159156 
    160157<para><command> alter table t1 add column c1 integer; create sequence s1; 
    …… 
    162159null; alter table t1 add primary key(c1); </command></para> 
    163160 
    164 <para> Up until &slony1; version 1.2, this query would <emphasis> fail 
    165 </emphasis>.  It would specifically fail upon reaching the 
    166 <command>UPDATE</command> statement, complaining that column 
    167 <envar>c1</envar> doesn't exist.  This happens because 
    168 <emphasis>all</emphasis> of those queries are parsed based on the 
    169 state of things immediately before the query.  So, the 
    170 <command>UPDATE</command> is evaluated based on a table definition 
    171 <emphasis>before</emphasis> the new column was added. Oops. </para> 
    172  
    173 <para>If you are running one of the earlier versions, the workaround 
    174 is that you invoke a separate <xref linkend="stmtddlscript"/> request 
    175 with a separate script, cutting off to a new script each time a 
    176 statement refers to something created in previous statements. </para> 
    177  
    178 <para> In &slony1; version 1.2, there is a state machine that pulls 
    179 apart the DDL script into individual statements.  Each statement is 
    180 submitted as a separate <function>PQexec()</function> request, with 
    181 the result that this is no longer an issue. </para> 
     161<para> Jusqu'à la version 1.2 de  &slony1; cette requête aurait <emphasis> échouée 
     162</emphasis>, lors de l'atteinte de la conditon 
     163<command>UPDATE</command> , indiquant l'inexistence de la colonne 
     164<envar>c1</envar>.  Cela est dû au fait que <emphasis>toutes</emphasis> ces requêtes sont découpées 
     165 et analysées avant même l'exécution de l'une d'entre elles. 
     166Ainsi, l'<command>UPDATE</command> est évalué sur une table avant que la colonne n'ai été ajoutée. 
     167 Oops. </para> 
     168 
     169<para>Si vous avez des versions antérieures, vous pouvez contourner cela en 
     170invoquant une requête séparée <xref linkend="stmtddlscript"/> dans un script distinct 
     171, en générant un nouveau script pour chaque requête qui  référence un objet créé dans une requête précédente. 
     172. </para> 
     173 
     174<para> Dans le version 1.2 de &slony1; , il y a un mécanisme qui sépare 
     175le script DDL en requêtes individuelles.  Chaque requête est soumise par une requête 
     176<function>PQexec()</function> séparée, ce qui ne pose plus de problÚme. </para> 
    182177</listitem> 
    183178 
    184179</itemizedlist> 
    185180 
    186 <para>Unfortunately, this nonetheless implies that the use of the DDL 
    187 facility is somewhat fragile and fairly dangerous.  Making DDL changes 
    188 must not be done in a sloppy or cavalier manner.  If your applications 
    189 do not have fairly stable SQL schemas, then using &slony1; for 
    190 replication is likely to be fraught with trouble and frustration.  See 
    191 the section on <link linkend="locking"> locking issues </link> for 
    192 more discussion of related issues.</para> 
    193  
    194 <para>There is an article on how to manage &slony1; schema changes 
    195 here: <ulink url="http://www.varlena.com/varlena/GeneralBits/88.php"> 
     181<para>Malheureusement, cela conduit à une vulnérabilité du script DDL, suivant la maniÚre 
     182dont les changements DDL sont écrits. 
     183Si vos applications n'ont pas de schémas SQL suffisamment stables, 
     184l'utilisation de &slony1; pour le mécanisme de réplication peut ne 
     185pas être adaptée. Voir la section <link linkend="locking"> questions de verrous </link> 
     186pour plus de discussion sur le sujet.</para> 
     187 
     188 
     189<para>Voici un article sur l'administration des changements de schémas avec &slony1;: 
     190 <ulink url="http://www.varlena.com/varlena/GeneralBits/88.php"> 
    196191Varlena General Bits</ulink></para> 
    197192 
    198 <sect2><title> Changes that you might <emphasis>not</emphasis> want to 
    199 process using <command>EXECUTE SCRIPT</command></title> 
    200  
    201 <para> While it is <emphasis> vitally necessary </emphasis> to use 
    202 <command>EXECUTE SCRIPT</command> to propagate DDL modifications to 
    203 tables that are being replicated, there are several sorts of changes 
    204 that you might wish to handle some other way: 
     193<sect2><title> Changements <emphasis>hors</emphasis> utilisation de 
     194 <command>EXECUTE SCRIPT</command></title> 
     195 
     196 
     197<para> Alors qu'il est <emphasis> vital </emphasis> d'utiliser 
     198<command>EXECUTE SCRIPT</command> pour propager des modifications DDL sur des tables répliquées, 
     199il y a plusieurs autres modifications que vous pouvez vouloir réaliser d'une autre façon : 
    205200 
    206201<itemizedlist> 
    207202 
    208 <listitem><para> There are various sorts of objects that don't have 
    209 triggers that &slony1; <emphasis>doesn't</emphasis> replicate, such as 
    210 stored functions, and it is quite likely to cause you grief if you 
    211 propagate updates to them associated with a replication set where 
    212 <command>EXECUTE SCRIPT</command> will lock a whole lot of tables that 
    213 didn't really need to be locked.</para> 
    214  
    215 <para> If you are propagating a stored procedure that 
    216 <emphasis>isn't</emphasis> used all the time (such that you'd care if 
    217 it was briefly out of sync between nodes), then you could simply 
    218 submit it to each node using <application>psql</application>, making 
    219 no special use of &slony1;.</para> 
    220  
    221 <para> If it <emphasis>does</emphasis> matter that the object be 
    222 propagated at the same location in the transaction stream on all the 
    223 nodes, then you but no tables need to be locked, then you need to use 
    224 <command>EXECUTE SCRIPT</command>, locking challenges or 
    225 no.</para></listitem> 
    226  
    227 <listitem><para> You may want an extra index on some replicated 
    228 node(s) in order to improve performance there.</para> 
     203<listitem><para> Il y a plusieurs types d'objets n'ayant pas de trigger que 
     204&slony1; <emphasis>ne</emphasis> peut répliquer, tels que les fonctions 
     205stockées. Et il est assez probable que cela vous posera problÚme de propager ces mises à jour 
     206en association avec un jeu de réplication où <command>EXECUTE SCRIPT</command>  
     207va vérouiller tout un jeu de tables qui n'ont pas réellement besoin de l'être. 
     208 
     209<para> Si vous propagez une procédure stockée qui n'est pas utilisée tout le temps 
     210(de telle sorte que vous acceptiez une petite desynchronisation entre les noeuds), alors vous pouvez 
     211simplement la soumettre à chaque noeud par l'intermédiare d'une commande <application>psql</application>, 
     212ne faisant pas d'utilisation particuliÚre de &slony1; 
     213 
     214<para>Si vous <emphasis>avez</emphasis> besoin d'une parfaite synchronisation sur l'ensemble des noeuds, 
     215a ce moment là, vous devez utiliser <command>EXECUTE SCRIPT</command> 
     216 pour verouiller vos travaux.</para></listitem> 
     217 
     218<listitem><para> Vous pouvez avoir besoin d'index suplémentaires sur quelques 
     219noeuds répliqués pour accroître les performances.</para> 
    229220 
    230221<para> For instance, a table consisting of transactions may only need 
    …… 
    235226against replicated nodes.</para> 
    236227 
    237 <para> It would be unwise to add additional indices that 
    238 <emphasis>constrain</emphasis> things on replicated nodes, as if they 
    239 find problems, this leads to replication breaking down as the 
    240 subscriber(s) will be unable to apply changes coming from the origin 
    241 that violate the constraints.</para> 
    242  
    243 <para> But it's no big deal to add some performance-enhancing indices. 
    244 You should almost certainly <emphasis>not</emphasis> use 
    245 <command>EXECUTE SCRIPT</command> to add them; that leads to some 
    246 replication set locking and unlocking tables, and possibly failing to 
    247 apply the event due to some locks outstanding on objects and having to 
    248 retry a few times before it gets the change in.  If you instead apply 
    249 the index <quote>directly</quote> such as with 
    250 <application>psql</application>, you can determine the time at which 
    251 the table lock is introduced.  Adding an index to a table will require 
    252 an exclusive lock for the time it takes to build the index; that will 
    253 implicitly stop replication, while the index builds, but shouldn't 
    254 cause any particular problems.  If you add an index on a table that 
    255 takes 20 minutes to build, replication will block for 20 minutes, but 
    256 should catch up quickly enough once the index is 
    257 created.</para></listitem> 
    258  
    259 <listitem><para> &slony1; stores the <quote>primary index</quote> name 
    260 in <xref linkend="table.sl-table"/>, and uses that name to control what 
    261 columns are considered the <quote>key columns</quote> when the log 
    262 trigger is attached.  It would be plausible to drop that index and 
    263 replace it with another primary key candidate, but changing the name 
    264 of the primary key candidate would break things. </para> </listitem> 
     228<para> Il serait imprudent d'ajouter des indicateurs qui  
     229<emphasis>contraindraient</emphasis> les évÚnements sur les noeuds répliqués, 
     230en cas de problÚme, cela conduirait la réplication à s'arrêter 
     231car le ou les  noeuds abonnés ne pourraient appliquer les changements provenant 
     232 du noeud origine violant la contrainte.</para> 
     233 
     234<para> Cela ne pose pas de difficultes d'ajouter quelques mesures d'ameliorations de performances. 
     235Il ne faut pratiquement <emphasis>jamais</emphasis> utiliser 
     236<command>EXECUTE SCRIPT</command> dans ce cadre; cela conduit certains jeux de replication a  
     237verrouiller/deverouiller des tables et potentiellement échouer à appliquer l'evenement a cause de verrous en cours 
     238sur les objets, puis devoir reessayer un certain nombre de fois avant de pouvoir effectuer le changement. 
     239.   
     240 
     241 
     242A la place, si vous appliquer l'index <quote>directement</quote>, au travers de  
     243<application>psql</application>, vous pouvez determiner le moment auquel  
     244le verrou s'exerce sur la table. 
     245 
     246Ajouter un index a une table necessite un verrou exlusif pour la duree 
     247de creation de cet index: cela va implicitement stopper la replication, pendant la duree 
     248de construction de l'index, mais sans causer de problemes particuliers. 
     249 
     250 
     251Si vous ajoutez un index sur une table et que sa construction dure 20 minutes, la replication sera stoppee 
     252pendant 20 minutes, mais repartira juste apres la fin de la creation. 
     253.</para></listitem> 
     254 
     255<listitem><para> &slony1; stocke le nom de l'<quote>index primaire</quote> dans 
     256 <xref linkend="table.sl-table"/>, et utilise ce nom pour controler les colonnes considérées  
     257 comme les <quote>colonnes cles"</quote> lorsque le declencheur de log est present. 
     258 Il pourrait etre envisageable de supprimer cet index et de le remplacer 
     259par une autre cle primaire potentielle, mais un changement de nom de cette cle primaire 
     260casserait certainement certaines choses.</para> </listitem> 
    265261 
    266262</itemizedlist></para></sect2> 
    267263 
    268 <sect2><title> Testing DDL Changes </title> 
    269  
    270 <indexterm><primary> testing DDL changes </primary></indexterm> 
    271  
    272 <para> A method for testing DDL changes has been pointed out as a 
    273 likely <quote>best practice.</quote></para> 
    274  
    275 <para> You <emphasis>need</emphasis> to test DDL scripts in a 
    276 non-destructive manner.</para> 
    277  
    278 <para> The problem is that if nodes are, for whatever reason, at all 
    279 out of sync, replication is likely to fall over, and this takes place 
    280 at what is quite likely one of the most inconvenient times, namely the 
    281 moment when you wanted it to <emphasis> work. </emphasis></para> 
    282  
    283 <para> You may indeed check to see if schema scripts work well or 
    284 badly, by running them by hand, against each node, adding <command> 
    285 BEGIN; </command> at the beginning, and <command> ROLLBACK; </command> 
    286 at the end, so that the would-be changes roll back.</para> 
    287  
    288 <para> If this script works OK on all of the nodes, that suggests that 
    289 it should work fine everywhere if executed via &lslonik;.  If problems 
    290 are encountered on some nodes, that will hopefully allow you to fix 
    291 the state of affairs on those nodes so that the script 
    292 <emphasis>will</emphasis> run without error. 
    293  
    294 <warning> <para> If the SQL script contains a <command> COMMIT; 
    295 </command> somewhere before the <command> ROLLBACK; </command>, that 
    296 may allow changes to go in unexpectedly.  </para> 
     264<sect2><title> Tester les changements DDL </title> 
     265 
     266<indexterm><primary> tester les changements DDL </primary></indexterm> 
     267 
     268 
     269<para> Une methode de test des changements DDL a ete validee 
     270 comme <quote>bonne pratique.</quote></para> 
     271  
     272<para> Vous <emphasis>devez</emphasis> 
     273 tester les scripts DDL de facon non destructrice.</para> 
     274 
     275 
     276<para> Si les noeuds sont, pour une raison ou une autre, totalement desynchonisés, 
     277la replication va tres certainement echouer, et cela a lieu la plupart du temps  
     278au plus mauvais moment: celui ou vous vouliez que cela 
     279 <emphasis> fonctionne. </emphasis></para> 
     280 
     281 
     282<para> Vous pouvez verifier si vos scripts DDL fonctionnent bien ou pas en les executant manuellement 
     283en ajoutant <command>BEGIN; </command>  au debut et <command> ROLLBACK; </command> a la fin. 
     284 De cette facon, les changements effectuent un retour arriere.</para> 
     285 
     286<para> Si le script s'effectue correctement sur tous les noeuds, cela semble dire  
     287qu'il devrait s'executer également correctement via &lslonik;. 
     288Si des problÚmes apparaissent sur certains noeuds, cela devrait vous permettre 
     289de remettre ces machines a niveau, de facon a ce que le script 
     290 <emphasis> s'exécute</emphasis>  sans erreur. 
     291 
     292Attention <para> Si le script contient un  <command> COMMIT; 
     293</command> n'importe ou avant le <command> ROLLBACK; </command>, cela va  
     294effectuer des changements auxquels vous ne vous attendiez pas.  </para> 
    297295</warning></para> 
    298296</sect2>