root/traduc/trunk/slony/ddlchanges.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- DerniÚre modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<sect1 id="ddlchanges">
<title>Changements du schéma de la base (DDL)</title>

<indexterm>
 <primary>Changements DDL</primary>
 <secondary>changements du schéma de la base</secondary>
</indexterm>

<para>Lorsque des changements sont faits sur la base,
<emphasis>tels que</emphasis> - l'ajout de champs à une table, il est nécessaire
de la faire prudemment, pour éviter que certains noeuds
ne soient bloqués lors de la création de certaines tables
.</para>

<para>Si vous opérez les changements à travers &slony1; via <xref
linkend="stmtddlscript"/> (slonik) / &funddlscript; (fonction stockée),
cela vous garantie que les changements prendront effets
au même niveau dans les flux de transactions sur tous les noeuds. Cela n'est pas aussi vital
si vous pouvez arrêter votre systÚme pour appliquer vos modifications de schéma,
mais si vous voulez faire vos mises à jour en même temps que vos transactions continuent de processer à travers votre systÚme,
cela est nécessaire.  </para>

<para>Il est essentiel d'utiliser <command>EXECUTE SCRIPT</command> si vous
modifiez des tables pour changer leurs schémas.  Si vous ne le faites pas, vous pouvez rencontrer
des problÚmes <link linkend="neededexecddl"> décrits
ici </link> où les triggers des tables modifiées ne tiennent pas compte des changements
de schéma faits. Cela peut conduire à une corruption de données sur le
noeud abonné.</para>

<para>Il est utile de faire quelques <quote>recommandations</quote> sur
 <xref linkend="stmtddlscript"/>:</para>

<itemizedlist>

<listitem><para>Le script <emphasis>ne doit pas</emphasis> contenir
de transaction <command>BEGIN</command> ou <command>END</command>
, car il s'exécute déjà dans une transaction.
Avec la version 8 de &postgres;, l'introduction des transactions imbriquées
change cela quelque peu, mais vous devez rester attentif au fait que
les actions du script sont exécutées comme une transaction simple
dans laquelle on ne maîtrise pas le <command>BEGIN</command> et le <command>END</command>
.</para></listitem>

<listitem><para>Si il y a une erreur<emphasis>quelconque</emphasis> dans le script
, ou un problÚme quelconque sur la maniÚre dont il s'éxécute sur un noeud particulier,
cela conduira le démon <xref linkend="slon"/> de ce noeud à paniquer et à tomber.
Vous pouvez consulter plusieurs types de messages attendus lors d'un déroulement normal ou anormal
à <xref linkend="ddllogs"/>.  Si vous redémarrez le &lslon;, il tentera,
de maniÚre trÚs probable, de
<emphasis>rejouer</emphasis> le script DDL, ce qui conduira certainement au même échec que la premiÚre tentative.
J'ai eu un tel scénario, m'obligeant à supprimer du noeud
<quote>maître</quote> l'évÚnement de la table
<envar>sl_event</envar> pour arrêter de le voir tomber en échec.</para>

<para> La conséquence de cela est qu'il est
<emphasis>vital</emphasis> que les modifications ne soient pas faites
de maniÚre hasardeuse sur un noeud ou un autre. Les schémas doivent toujours 
rester synchronisés.</para> 
</listitem>

<listitem><para> Pour &lslon; aussi, Ã  ce niveau, <quote>panic</quote>
est probablement la réponse
<emphasis>correcte</emphasis>, car il permet au DBA de sortir la base du noeud défecteux,
de fixer manuellement le problÚme en supprimant l'évÚnement incorrect et de redémarrer
&lslon;.  Vous pouvez être certain que les mises à jour faites 
<emphasis>aprÚs</emphasis> le changement DDL sur le noeud maître sont enregistrées
dans une file d'attente, en attente d'être traitées par l'abonné.
Vous ne courrez ainsi pas le risque que des updates non centralisés par DDL

You don't run the
risk of there being updates made that depended on the DDL changes in
order to be correct.</para></listitem>

<listitem><para> Lorsque vous exécutez <xref linkend="stmtddlscript"/>, cela
conduit &lslonik; à poser, <emphasis>pour chaque table faisant partie du jeu de réplication</emphasis>,
un verrou exclusif table.</para>

<para> Cela commence par la pose du lock, l'altération de la table pour supprimer les
&slony1; triggers, et la restauration de tous les triggers qui ont étés cachés

<screen>
BEGIN;
LOCK TABLE table_name;
SELECT _oxrsorg.altertablerestore(tab_id);
--tab_id is _slony_schema.sl_table.tab_id
</screen></para>

<para> AprÚs l'exécution du script, chaque table est
<quote>restorée</quote> dans le but d'ajouter en fin soit le trigger qui collecte
les mises à jour sur le noeud origine soit celui qui rejette les mises à jour sur l'abonné.

<screen>
SELECT _oxrsorg.altertableforreplication(tab_id);
--tab_id is _slony_schema.sl_table.tab_id
COMMIT;
</screen></para>

<para>Notez que c'est ce qui permet à &slony1; de prendre connaissance de
l'altération de tables: <emphasis>avant</emphasis>
ce <command>SYNC</command>, &slony1; réplique des tuples suivant le
 <emphasis>vieux</emphasis>
schéma; <emphasis>aprÚs</emphasis> le script <command>DDL_SCRIPT</command>,
les tuples sont répliqués suivant le <emphasis>nouveau</emphasis>
schéma. </para>

<para> Sur un systÚme réalisant de nombreuses mises à jour, il peut être
difficile <quote>d'obtenir</quote> tous les verrous nécéssaires.
 Les verrous peuvent conduire à des deadlocks.
Vous pouvez régler le problÚme de 2 maniÚres différentes :
</para></listitem>

<listitem><para> Vous devez envisager de <link linkend="definesets"> définir des jeux de réplication </link>
 représentant un plus petit nombre de tables
de maniÚre à ce que moins de verrous soient posés et permettent au script DDL d'être joué.</para>

<para> Si un script DDL affecte une seule table, il ne devrait pas
être nécessaire de verrouiller <emphasis>toutes</emphasis> les tables de
l'application.</para>

<note><para> Véritablement, à partir de la version 1.1.5 ou plus, ce
n'est <emphasis>plus vrai.</emphasis> Le danger que quelqu'un opÚre des changements
DDL interférant avec le jeux de réplication est suffisamment évident pour que 
&lslon; verrouille  <emphasis>toutes</emphasis> les tables
répliquées, qu'elles soient ou pas dans le jeu de réplication
. </para></note></listitem>

<listitem><para> Vous pouvez avoir besoin de faire un arrêt de votre systÚme
pour vous assurer que vos applications ne demandent pas des verrous
qui rentreraient en conflit avec ceux dont vous auriez besoin pour faire les changements de schéma de base.
.</para></listitem>

<listitem><para> Dans les versions 1.0 à 1.1.5 de &slony1; le script s'exécute
comme une simple requête, ce qui peut poser problÚme si vous réaliser des modifications
complexes. A partir de la version 1.2, le script est découpé en traitements SQL individuels,
et chaque requête est soumise séparemment, ce qui est préférable.</para>

<para> Le problÚme avec une requête traitant une <quote>requête imbriquée</quote> est que le parser SQL
réalise son plan d'exécution pour le jeu entier de requête <emphasis>avant même</emphasis>
 l'exécution de la requête.</para>   

<para> Cela ne pose pas de problÚme particulier si les requêtes
sont indépendantes les unes des autres, tel que 2 requêtes d'ajout de 2 colonnes
à une table.</para>

<para> <command> alter table t1 add column c1 integer; alter table t1 add
column c2 integer; </command></para>

<para> Par contre, les problÚmes se rencontrent si vous devez référencer une requête précédente.
Considérer la requête DDL suivante ...</para>

<para><command> alter table t1 add column c1 integer; create sequence s1;
update t1 set c1=nextval('s1'); alter table t1 alter column c1 set not
null; alter table t1 add primary key(c1); </command></para>

<para> Jusqu'à la version 1.2 de  &slony1; cette requête aurait <emphasis> échouée
</emphasis>, lors de l'atteinte de la conditon
<command>UPDATE</command> , indiquant l'inexistence de la colonne
<envar>c1</envar>.  Cela est dû au fait que <emphasis>toutes</emphasis> ces requêtes sont découpées
 et analysées avant même l'exécution de l'une d'entre elles.
Ainsi, l'<command>UPDATE</command> est évalué sur une table avant que la colonne n'ai été ajoutée.
 Oops. </para>

<para>Si vous avez des versions antérieures, vous pouvez contourner cela en
invoquant une requête séparée <xref linkend="stmtddlscript"/> dans un script distinct
, 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.
. </para>

<para> Dans le version 1.2 de &slony1; , il y a un mécanisme qui sépare
le script DDL en requêtes individuelles.  Chaque requête est soumise par une requête
<function>PQexec()</function> séparée, ce qui ne pose plus de problÚme. </para>
</listitem>

</itemizedlist>

<para>Malheureusement, cela conduit à une vulnérabilité du script DDL, suivant la maniÚre
dont les changements DDL sont écrits.
Si vos applications n'ont pas de schémas SQL suffisamment stables,
l'utilisation de &slony1; pour le mécanisme de réplication peut ne
pas être adaptée. Voir la section <link linkend="locking"> questions de verrous </link>
pour plus de discussion sur le sujet.</para>


<para>Voici un article sur l'administration des changements de schémas avec &slony1;:
 <ulink url="http://www.varlena.com/varlena/GeneralBits/88.php">
Varlena General Bits</ulink></para>

<sect2><title> Changements <emphasis>hors</emphasis> utilisation de
 <command>EXECUTE SCRIPT</command></title>


<para> Alors qu'il est <emphasis> vital </emphasis> d'utiliser
<command>EXECUTE SCRIPT</command> pour propager des modifications DDL sur des tables répliquées,
il y a plusieurs autres modifications que vous pouvez vouloir réaliser d'une autre façon :

<itemizedlist>

<listitem><para> Il y a plusieurs types d'objets n'ayant pas de trigger que
&slony1; <emphasis>ne</emphasis> peut répliquer, tels que les fonctions
stockées. Et il est assez probable que cela vous posera problÚme de propager ces mises à jour
en association avec un jeu de réplication où <command>EXECUTE SCRIPT</command> 
va vérouiller tout un jeu de tables qui n'ont pas réellement besoin de l'être.</para>

<para> Si vous propagez une procédure stockée qui n'est pas utilisée tout le temps
(de telle sorte que vous acceptiez une petite desynchronisation entre les noeuds), alors vous pouvez
simplement la soumettre à chaque noeud par l'intermédiare d'une commande <application>psql</application>,
ne faisant pas d'utilisation particuliÚre de &slony1;</para>

<para>Si vous <emphasis>avez</emphasis> besoin d'une parfaite synchronisation sur l'ensemble des noeuds,
a ce moment là , vous devez utiliser <command>EXECUTE SCRIPT</command>
 pour verrouiller vos travaux.</para></listitem>

<listitem><para> Vous pouvez avoir besoin d'index suplémentaires sur quelques
noeuds répliqués pour accroître les performances.</para>

<para> For instance, a table consisting of transactions may only need
indices related to referential integrity on the <quote>origin</quote>
node, and maximizing performance there dictates adding no more indices
than are absolutely needed.  But nothing prevents you from adding
additional indices to improve the performance of reports that run
against replicated nodes.</para>

<para> Il serait imprudent d'ajouter des indicateurs qui 
<emphasis>contraindraient</emphasis> les évÚnements sur les noeuds répliqués,
en cas de problÚme, cela conduirait la réplication à s'arrêter
car le ou les  noeuds abonnés ne pourraient appliquer les changements provenant
 du noeud origine violant la contrainte.</para>

<para> Cela ne pose pas de difficultes d'ajouter quelques mesures d'ameliorations de performances.
Il ne faut pratiquement <emphasis>jamais</emphasis> utiliser
<command>EXECUTE SCRIPT</command> dans ce cadre; cela conduit certains jeux de replication a 
verrouiller/deverouiller des tables et potentiellement échouer à appliquer l'evenement a cause de verrous en cours
sur les objets, puis devoir reessayer un certain nombre de fois avant de pouvoir effectuer le changement.
.  


A la place, si vous appliquer l'index <quote>directement</quote>, au travers de 
<application>psql</application>, vous pouvez determiner le moment auquel 
le verrou s'exerce sur la table.

Ajouter un index a une table necessite un verrou exlusif pour la duree
de creation de cet index: cela va implicitement stopper la replication, pendant la duree
de construction de l'index, mais sans causer de problemes particuliers.


Si vous ajoutez un index sur une table et que sa construction dure 20 minutes, la replication sera stoppee
pendant 20 minutes, mais repartira juste apres la fin de la creation.
.</para></listitem>

<listitem><para> &slony1; stocke le nom de l'<quote>index primaire</quote> dans
 <xref linkend="table.sl-table"/>, et utilise ce nom pour controler les colonnes considérées 
 comme les <quote>colonnes cles"</quote> lorsque le declencheur de log est present.
 Il pourrait etre envisageable de supprimer cet index et de le remplacer
par une autre cle primaire potentielle, mais un changement de nom de cette cle primaire
casserait certainement certaines choses.</para> </listitem>

</itemizedlist></para></sect2>

<sect2><title> Tester les changements DDL </title>

<indexterm><primary> tester les changements DDL </primary></indexterm>


<para> Une methode de test des changements DDL a ete validee
 comme <quote>bonne pratique.</quote></para>
 
<para> Vous <emphasis>devez</emphasis>
 tester les scripts DDL de facon non destructrice.</para>


<para> Si les noeuds sont, pour une raison ou une autre, totalement desynchonisés,
la replication va tres certainement echouer, et cela a lieu la plupart du temps 
au plus mauvais moment: celui ou vous vouliez que cela
 <emphasis> fonctionne. </emphasis></para>


<para> Vous pouvez verifier si vos scripts DDL fonctionnent bien ou pas en les executant manuellement
en ajoutant <command>BEGIN; </command>  au debut et <command> ROLLBACK; </command> a la fin.
 De cette facon, les changements effectuent un retour arriere.</para>

<para> Si le script s'effectue correctement sur tous les noeuds, cela semble dire 
qu'il devrait s'executer également correctement via &lslonik;.
Si des problÚmes apparaissent sur certains noeuds, cela devrait vous permettre
de remettre ces machines a niveau, de facon a ce que le script
 <emphasis> s'exécute</emphasis>  sans erreur.

  <warning><para>Attention Si le script contient un  <command> COMMIT;
  </command> n'importe ou avant le <command> ROLLBACK; </command>, cela va 
  effectuer des changements auxquels vous ne vous attendiez pas.</para></warning></para>
  </sect2>
</sect1>