Changeset 964

Show
Ignore:
Timestamp:
03/27/08 17:33:31 (10 months ago)
Author:
daamien
Message:

1ere trad , à relire !

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/testbed.xml

    r937 r964  
    55     révision $Revision$ --> 
    66 
    7 <sect1 id="testbed"><title> &slony1; Test Bed Framework </title> 
    8  
    9 <indexterm><primary>test bed framework</primary></indexterm> 
    10  
    11 <para> As of version 1.1.5, &slony1; has a common test bed framework 
    12 intended to better support running a comprehensive set of tests at 
    13 least somewhat automatically.  Older tests 
    14 used <application>pgbench</application> (not 
    15 a <emphasis>bad</emphasis> thing) but were troublesome to automate 
    16 because they were set up to spawn each &lslon; in 
    17 an <application>xterm</application> for the user 
    18 to <emphasis>watch</emphasis>.</para> 
    19  
    20 <para> The new test framework is mostly written in Bourne shell, and 
    21 is intended to be portable to both Bash (widely used on Linux) and 
    22 Korn shell (widely found on commercial UNIX systems).  The code lives 
    23 in the source tree under the <filename> tests 
    24 </filename> directory.</para> 
    25  
    26 <para> At present, nearly all of the tests make use of only two 
    27 databases that, by default, are on a single &postgres; postmaster on 
    28 one host.  This is perfectly fine for those tests that involve 
    29 verifying that &slony1; functions properly on various sorts of data. 
    30 Those tests do things like varying date styles, and creating tables 
    31 and sequences that involve unusual names to verify that quoting is 
    32 being handled properly. </para> 
    33  
    34 <para> It is also possible to configure environment variables so that 
    35 the replicated nodes will be placed on different database backends, 
    36 optionally on remote hosts, running varying versions of 
    37 &postgres;.</para> 
    38  
    39 <para>Here are some of the vital files...</para> 
     7<sect1 id="testbed"><title>Banc d'essai &slony1; </title> 
     8 
     9<indexterm><primary>plate-forme de tests</primary></indexterm> 
     10 
     11<para> Jusqu'à la version 1.1.5, &slony1; dispose d'une plate-forme  
     12  commune de test afin d'exécuter un ensemble compréhensible de tests 
     13  de maniÚre relativement automatique. Les anciens tests étaient réalisés  
     14  avec <application>pgbench</application> ( ce qui n'est pas une  
     15  <emphasis>mauvaise</emphasis> chose en soi ) mais étaient difficiles 
     16  à automatiser car ils devaient être déployés sur chaque &lslon;  
     17  dans un <application>xterm</application> afin que l'utilisateur 
     18  puisse <emphasis>surveiller</emphasis>.</para> 
     19 
     20<para> La nouvelle plate-forme de test est principalement écrite en Bourne shell,  
     21  et est destinée à être portable en bash ( largement répandu sous Linux ) et  
     22  en Korn shell ( que l'on retrouve souvent sur les systÚmes UNIX commerciaux ) 
     23  Le code se trouve dans l'arborescence des sources au sein du répertoire  
     24  <filename>tests</filename>.</para> 
     25 
     26<para>À présent, presque tous les tests font appel à seulement deux  
     27  bases de données qui par défaut sont sur un postmaster &postgres; unique 
     28  sur un seul serveur hÃŽte. Ceci est parfait pour les tests qui impliquent la 
     29  vérification des fonctions &slony1; pour divers types de données. 
     30  Ces tests font des choses tels que varier les styles de date, et créer des 
     31  tables et des séquences qui implique des noms inhabituels afin de vérifier 
     32  que les guillemets sont gérées correctement. </para> 
     33 
     34<para> Il est également possible de configurer des variables d'environnement 
     35  afin que les noeuds de la réplication soient placés sur différents serveurs  
     36  de base de données, éventuellement sur des serveurs hÃŽtes distants, utilisant  
     37  différentes versions de &postgres;.</para> 
     38 
     39<para>Voici quelque uns des fichiers vitaux...</para> 
    4040 
    4141<itemizedlist> 
    …… 
    4444 
    4545</itemizedlist> 
    46  
    47 <para> This is the central script for running tests.  Typical usage is 
    48 thus:</para> 
     46  
     47<para> Ceci est le script central pour exécuter les tests. Son utilisation 
     48  typique est la suivante :</para> 
    4949 
    5050<para> <command> ./run_test.sh </command></para> 
    5151<screen> 
    52 usage ./run_test.sh testname 
     52usage ./run_test.sh nom_du_test 
    5353</screen> 
    5454 
    55 <para> You need to specify the subdirectory name of the test set to be 
    56 run; each such set is stored in a subdirectory of 
    57 <filename>tests</filename>.</para> 
    58  
    59 <para> You may need to set one or more of the following environment 
    60 variables to reflect your local configuration.  For instance, the 
    61 writer runs <quote>test1</quote> against &postgres; 8.0.x using the 
    62 following command line:</para> 
     55<para> Vous devez spécifier le nom de sous-répertoire pour dans lequel  
     56  l'ensemble du test sera réalisé; chaque ensemble est stocké un dans  
     57  sous-répertoire de <filename>tests</filename>.</para> 
     58 
     59<para> Vous pouvez définir une ou plusieurs variables d'environnement 
     60  pour préciser votre configuration locale. Par exemple, on 
     61  exécute <quote>test1</quote> sur &postgres; 8.0.x en utilisant la commande 
     62   suivante :</para> 
    6363 
    6464<screen> PGBINDIR=/opt/OXRS/dbs/pgsql8/bin PGPORT=5532 PGUSER=cbbrowne ./run_test.sh test1 </screen> 
    …… 
    6767<glossentry><glossterm> <envar>PGBINDIR</envar> </glossterm> 
    6868 
    69 <glossdef><para> This determines where the test scripts look for 
    70 &postgres; and &slony1; binaries.  The default is <filename> 
    71 /usr/local/pgsql/bin</filename>.</para> 
    72  
    73 <para> There are also variables <envar>PGBINDIR1</envar> thru 
    74 <envar>PGBINDIR13</envar> which allows you to specify a separate path 
    75 for each database instance.  That will be particularly useful when 
    76 testing interoperability of &slony1; across different versions of 
    77 &postgres; on different platforms. In order to create a database of 
    78 each respective version, you need to point to 
    79 an <application>initdb</application> of the appropriate 
    80 version.</para> </glossdef> </glossentry> 
     69<glossdef><para> Ceci détermine où les scripts de tests doivent chercher 
     70    les binaires &postgres; et &slony1;. La valeur par défaut est  
     71    <filename>/usr/local/pgsql/bin</filename>.</para> 
     72 
     73<para> Il existe également les variables <envar>PGBINDIR1</envar> jusqu'à 
     74<envar>PGBINDIR13</envar> qui permettent de définir un chemin spécifique  
     75pour chaque instance de base de données. Cela est particuliÚrement utile  
     76lorsque l'on teste l'inter-opérabilité de &slony1; sur différent versions  
     77de &postgres; et sur différentes plates-formes. Afin de créer une base de  
     78données de chaque version respective, vous devez pointer vers un  
     79<application>initdb</application> de la version appropriée. 
     80</para> </glossdef> </glossentry> 
    8181 
    8282<glossentry><glossterm> <envar>PGPORT</envar> </glossterm> 
    83 <glossdef><para> This indicates what port the backend is on.  By 
    84 default, 5432 is used. </para>  
    85  
    86 <para> There are also variables <envar>PORT1</envar> thru 
    87 <envar>PORT13</envar> which allow you to specify a separate port 
    88 number for each database instance.  That will be particularly useful 
    89 when testing interoperability of &slony1; across different versions of 
    90 &postgres;. </para> </glossdef> </glossentry> 
     83<glossdef><para> Ceci indique quel port le processus postmater écoute.  
     84    Par défaut, le port 5432 est utilisé. </para>  
     85 
     86<para> Il existe également des variables <envar>PORT1</envar> jusqu'à 
     87  <envar>PORT13</envar> qui permet de spécifier un numéro de port pour 
     88  chaque instance de base de données. Cela sera particuliÚrement utile 
     89  lorsque que l'on teste l'inter-opérabilité de &slony1; sur différentes  
     90  versions de &postgres;. </para> </glossdef> </glossentry> 
    9191 
    9292<glossentry><glossterm> <envar>PGUSER</envar> </glossterm> 
    93 <glossdef><para> By default, the user <filename>postgres</filename> is 
    94 used; this is taken as the default user ID to use for all of the 
    95 databases. </para> 
    96  
    97 <para> There are also variables <envar>USER1</envar> thru 
    98 <envar>USER13</envar> which allow specifying a separate user name for 
    99 each database instance.  As always, with &slony1;, this needs 
    100 to be a &postgres; <quote>superuser.</quote> </para>  </glossdef> </glossentry> 
     93<glossdef><para> Par défaut, l'utilisateur <filename>postgres</filename>  
     94    est utilisé; Ceci est utilisé comme l'identifiant par défaut à utiliser 
     95    sur toutes les bases de données. </para> 
     96 
     97<para> Il existent également des variables <envar>USER1</envar> jusqu'à  
     98  <envar>USER13</envar> qui permettent de spécifier un nom d'utilisateur  
     99  différent pour chaque instance. Comme toujours, avec &slony1;, l'utilisateur 
     100  doit être un <quote>super-utilisateur</quote> &postgres; </para>   
     101</glossdef> </glossentry> 
    101102 
    102103<glossentry><glossterm> <envar>WEAKUSER</envar> </glossterm> 
    103 <glossdef><para> By default, the user <filename>postgres</filename> is 
    104 used; this is taken as the default user ID to use for the <xref linkend="stmtstorepath"/> connections to all of the 
    105 databases. </para> 
    106  
    107 <para> There are also variables <envar>WEAKUSER1</envar> thru 
    108 <envar>WEAKUSER13</envar> which allow specifying a separate user name 
    109 for each database instance.  This user <emphasis> does not </emphasis> 
    110 need to be a &postgres; <quote>superuser.</quote> This user can start 
    111 out with no permissions; it winds up granted read permissions on the 
    112 tables that the test uses, plus read access throughout the &slony1; 
    113 schema, plus write access to one table and sequence used to manage 
    114 node locks. </para> </glossdef> </glossentry> 
     104<glossdef><para> Par défaut, l'utilisateur <filename>postgres</filename>  
     105    est utilisé; Ceci est utilisé par défaut comme identifiant de l'utilisateur 
     106    pour les connexions  <xref linkend="stmtstorepath"/> sur toutes  
     107    les bases de données.</para> 
     108 
     109<para> Il existe également des variables <envar>WEAKUSER1</envar> jusqu'à 
     110  <envar>WEAKUSER13</envar> qui permettent de spécifier différents noms 
     111  d'utilisateur pour chaque instance. Cet utilisateur doit être un <quote> 
     112  super-utilisateur</quote> &postgres;. Cet utilisateur peut démarrer sans  
     113  permissions; il obtient les permissions de lecture sur les tables que le  
     114  test utilise, ainsi que les droits d'accÚs sur le schéma &slony1;, et les  
     115  droits d'écriture sur la table et la séquence utilisées pour gérer les verrous 
     116  sur les noeuds. 
     117 </para> </glossdef> </glossentry> 
    115118 
    116119<glossentry><glossterm> <envar>HOST</envar> </glossterm> 
    117 <glossdef><para> By default, <filename>localhost</filename> is used. 
     120<glossdef><para>Par défaut, <filename>localhost</filename> est utilisé. 
    118121</para> 
    119122 
    120 <para> There are also variables <envar>HOST1</envar> thru 
    121 <envar>HOST13</envar> which allow specifying a separate host for 
    122 each database instance.</para></glossdef> 
    123 </glossentry> 
    124  
    125 <glossentry><glossterm> <envar>DB1</envar> thru <envar>DB13 </envar> </glossterm>  
    126  
    127 <glossdef><para> By default, <filename>slonyregress1</filename> thru 
    128 <filename>slonyregress13</filename> are used. 
     123<para> Il existe également les variables <envar>HOST1</envar> jusqu'à 
     124<envar>HOST13</envar> qui permet de spécifier un hÃŽte différent pour 
     125chaque instance de base de données.</para></glossdef> 
     126</glossentry> 
     127 
     128<glossentry><glossterm> <envar>DB1</envar> jusqu'à <envar>DB13 </envar> </glossterm>  
     129 
     130<glossdef><para> Par défaut, les valeurs<filename>slonyregress1</filename> jusqu'à 
     131<filename>slonyregress13</filename> sont utilisées. 
    129132</para> 
    130133 
    131 <para> You may override these from the environment if you have some 
    132 reason to use different names. </para></glossdef> 
     134<para> Vous pouvez surcharger cela depuis l'environnement  
     135  si vous avez de bonne raisons d'utiliser des bonnes d'utiliser 
     136  des noms différents. </para></glossdef> 
    133137</glossentry> 
    134138 
    …… 
    136140<glossterm><envar>ENCODING</envar></glossterm> 
    137141 
    138 <glossdef><para> By default, <filename>UNICODE</filename> is used, so 
    139 that tests can create UTF8 tables and test the multibyte capabilities. 
     142<glossdef><para>Par défaut, <filename>UNICODE</filename> est utilisé, afin 
     143    que les tests puissent créer des tables UTF8 et tester les  
     144    capacités multibyte. 
    140145</para></glossdef> 
    141146 
    …… 
    145150<glossterm><envar>MY_MKTEMP_IS_DECREPIT</envar></glossterm> 
    146151 
    147 <glossdef><para> If your version of Linux uses a variation of 
    148 <application>mktemp</application> that does not generate a full path 
    149 to the location of the desired temporary file/directory, then set this 
    150 value. </para></glossdef> 
     152<glossdef><para> Si votre version de Linux utilise une version de 
     153<application>mktemp</application> qui ne génÚre pas un chemin absolu  
     154vers l'emplacement du fichier/répertoire temporaire, alors modifier cette 
     155valeur. </para></glossdef> 
    151156 
    152157</glossentry> 
    …… 
    155160<glossterm><envar>SLTOOLDIR</envar></glossterm> 
    156161 
    157 <glossdef><para> Where to look for &slony1; tools such as 
     162<glossdef><para> Où trouver les outils &slony1; tels que  
    158163<application>slony1_dump.sh</application>.  </para></glossdef> 
    159164 
    …… 
    163168<glossterm><envar>ARCHIVE[n]</envar></glossterm> 
    164169 
    165 <glossdef><para> If set to <quote>true</quote>, for a particular node, 
    166 which will normally get configured out of human sight in the 
    167 generic-to-a-particular-test file <filename>settings.ik</filename>, 
    168 then this node will be used as a data source for <xref 
    169 linkend="logshipping"/>, and this causes the test tools to set up a 
    170 directory for the <link linkend="slon-config-archive-dir"> 
    171 archive_dir</link> option.  </para></glossdef> 
     170<glossdef><para> Si cette option est positionnée à <quote>true</quote>, pour un noeud donné, 
     171    qui est normalement configuré automatiquement dans le fichier 
     172    <filename>settings.ik</filename>, alors ce noeud sera utilisé comme  
     173    source de données pour du <xref linkend="logshipping"/>, et cela impliquera  
     174    que les outils de tests créeront le répertoire  
     175    <link linkend="slon-config-archive-dir"> archive_dir</link>  
     176</para></glossdef> 
    172177 
    173178</glossentry> 
    …… 
    176181<glossterm><envar>LOGSHIP[n]</envar></glossterm> 
    177182 
    178 <glossdef><para> If set to <quote>true</quote>, for a particular node, 
    179 which will normally get configured out of human sight in 
    180 <filename>settings.ik</filename> for a particular test, then this 
    181 indicates that this node is being created via <xref 
    182 linkend="logshipping"/>, and a &lslon; is not required for this node. 
     183<glossdef><para> Si cette option est positionnée à <quote>true</quote>, pour un noeud donné, 
     184    qui est normalement configuré automatiquement dans le fichier 
     185    <filename>settings.ik</filename>, alors ce noeud est créé via     
     186 <xref linkend="logshipping"/>, et &lslon; n'est pas nécessaire pour ce noeud. 
    183187</para></glossdef> 
    184188 
    …… 
    188192<glossterm><envar>SLONCONF[n]</envar></glossterm> 
    189193 
    190 <glossdef><para> If set to <quote>true</quote>, for a particular node, 
    191 typically handled in <filename>settings.ik</filename> for a given 
    192 test, then configuration will be set up in a <link 
    193 linkend="runtime-config"> per-node <filename>slon.conf</filename> 
    194 runtime config file. </link> </para>  
     194<glossdef><para>Si cette valeur est positionnée à <quote>true</quote>, pour un noeud donnée, 
     195    qui est généralement configuré dans le fichier <filename>settings.ik</filename>  
     196    pour un test donné, alors la configuration sera placée dans un <link linkend="runtime-config">  
     197     un fichier de configuration <filename>slon.conf</filename> 
     198     spécifique pour chaque noeud.</link> </para>  
    195199</glossentry> 
    196200 
    …… 
    198202<glossterm><envar>SLONYTESTER</envar></glossterm> 
    199203 
    200 <glossdef><para> Email address of the person who might be 
    201 contacted about the test results. This is stored in the 
    202 <envar>SLONYTESTFILE</envar>, and may eventually be aggregated in some 
    203 sort of buildfarm-like registry. </para> </glossdef> 
     204<glossdef><para> Adresse e-mail de la personne qui reçoit les résultats des tests. 
     205    Ceci est stocké dans <envar>SLONYTESTFILE</envar>, et peut être agréger 
     206    dans un registre comparable à une ferme de compilation  
     207    </para> </glossdef> 
    204208</glossentry> 
    205209 
    …… 
    207211<glossterm><envar>SLONYTESTFILE</envar></glossterm> 
    208212 
    209 <glossdef><para> File in which to store summary results from tests. 
    210 Eventually, this may be used to construct a buildfarm-like repository of 
    211 aggregated test results. </para> </glossdef> 
    212 </glossentry> 
    213  
    214 <glossentry> 
    215 <glossterm><filename>random_number</filename> and <filename>random_string</filename> </glossterm> 
    216  
    217 <glossdef><para> If you run <command>make</command> in the 
    218 <filename>test</filename> directory, C programs 
    219 <application>random_number</application> and 
    220 <application>random_string</application> will be built which will then 
    221 be used when generating random data in lieu of using shell/SQL 
    222 capabilities that are much slower than the C programs.  </para> 
     213<glossdef><para> Fichier dans lequel sont stocké les résultats des tests. 
     214    Ces résultats peuvent être utilisés pour construire un dépÃŽt contenant  
     215    l'agrégation des résultats de test. 
     216    </para> </glossdef> 
     217</glossentry> 
     218 
     219<glossentry> 
     220<glossterm><filename>random_number</filename> et <filename>random_string</filename> </glossterm> 
     221 
     222<glossdef><para> Si vous exécuté <command>make</command> dans le répertoire de 
     223<filename>test</filename>, les programmes C  
     224<application>random_number</application> et  
     225<application>random_string</application> seront compilé et seront  
     226ensuite utilisé lors de la génération de données aléatoires au lieu d'utiliser 
     227les fonctions shell/SQL qui sont beaucoup plus lentes que les programmes C. 
     228 </para> 
    223229</glossdef> 
    224230</glossentry> 
    …… 
    226232</glosslist> 
    227233 
    228 <para> Within each test, you will find the following files: </para> 
     234<para> Pour chaque test, vous trouverez les fichiers suivants : </para> 
    229235 
    230236<itemizedlist> 
    231237<listitem><para> <filename>README</filename> </para>  
    232238 
    233 <para> This file contains a description of the test, and is displayed 
    234 to the reader when the test is invoked. </para> </listitem> 
     239<para> Ce fichier contient une description du test et est affiché 
     240  au lecteur lorsque le test est invoqué. </para> </listitem> 
    235241 
    236242<listitem><para> <filename>generate_dml.sh</filename> </para>  
    237 <para> This contains script code that generates SQL to perform updates. </para> </listitem> 
    238 <listitem><para> <filename>init_add_tables.ik</filename> </para>  
    239 <para>  This is a <xref linkend="slonik"/> script for adding the tables for the test to repliation. </para> </listitem> 
     243<para> contient le code du script qui génÚre le SQL pour réaliser les mises à jour. </para> </listitem> 
     244o<listitem><para> <filename>init_add_tables.ik</filename> </para>  
     245<para>  Script <xref linkend="slonik"/> pour ajouter les tables pour le test de réplication. </para> </listitem> 
    240246<listitem><para> <filename>init_cluster.ik</filename> </para>  
    241 <para> <xref linkend="slonik"/> to initialize the cluster for the test.</para> </listitem> 
     247<para> Script <xref linkend="slonik"/> pour initialiser le cluster pour le test.</para> </listitem> 
    242248<listitem><para> <filename>init_create_set.ik</filename> </para>  
    243 <para> <xref linkend="slonik"/> to initialize additional nodes to be used in the test. </para> </listitem> 
     249<para> Script <xref linkend="slonik"/> pour initialiser les noeuds supplémentaires qui seront utilisés dans le test. </para> </listitem> 
    244250<listitem><para> <filename>init_schema.sql</filename> </para>  
    245 <para> An SQL script to create the tables and sequences required at the start of the test.</para> </listitem> 
     251<para> Script SQL pour créer le stables et les séquences nécessaires au démarrage du test.</para> </listitem> 
    246252<listitem><para> <filename>init_data.sql</filename> </para>  
    247 <para> An SQL script to initialize the schema with whatever state is required for the <quote>master</quote> node.  </para> </listitem> 
     253<para> Script SQL pour initialiser le schéma dans l'état nécessaire sur le noeud<quote>maître</quote> node.  </para> </listitem> 
    248254<listitem><para> <filename>init_subscribe_set.ik</filename> </para>  
    249 <para> A <xref linkend="slonik"/> script to set up subscriptions.</para> </listitem> 
     255<para> Script <xref linkend="slonik"/> pour mettre en place les abonnements.</para> </listitem> 
    250256<listitem><para> <filename>settings.ik</filename> </para>  
    251 <para> A shell script that is used to control the size of the cluster, how many nodes are to be created, and where the origin is.</para> </listitem> 
     257<para> Script shell utilisé pour contrÃŽler la taille du cluster, comment les noeuds seront créés, et où se trouve l'origine.</para> </listitem> 
    252258<listitem><para> <filename>schema.diff</filename> </para>  
    253 <para> A series of SQL queries, one per line, that are to be used to validate that the data matches across all the nodes.  Note that in order to avoid spurious failures, the queries must use unambiguous <command>ORDER BY</command> clauses.</para> </listitem> 
     259<para> Série de requêtes SQL, une par ligne, qui sont utilisés pour valider que les données se correspondent sur tous les noeuds. Notez qu'afin d'éviter des échecs inutiles, les requêtes doivent utiliser des clauses <command>ORDER BY</command> non-ambigÃŒes.</para> </listitem> 
    254260</itemizedlist> 
    255261 
    256 <para> If there are additional test steps, such as 
    257 running <xref linkend="stmtddlscript"/>, 
    258 additional <xref linkend="slonik"/> and SQL scripts may be necessary.</para> 
     262<para> Pour d'éventuels tests additionnels, tels que l'utilisation de  
     263  <xref linkend="stmtddlscript"/>, 
     264des scripts <xref linkend="slonik"/> et SQL supplémentaires pourront être nécessaires. 
     265</para> 
    259266 
    260267</sect1>