Find file
Fetching contributors…
Cannot retrieve contributors at this time
442 lines (366 sloc) 13.5 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="testbed">
<title>Banc d'essai &slony1;</title>
<indexterm><primary>plate-forme de tests</primary></indexterm>
<para>
Jusqu'à la version 1.1.5, &slony1; dispose d'une plate-forme commune de tests
afin d'exécuter un ensemble compréhensible de tests de manière relativement
automatique. Les anciens tests étaient réalisés avec
<application>pgbench</application> (ce qui n'est pas une
<emphasis>mauvaise</emphasis> chose en soi) mais étaient difficiles à
automatiser car ils devaient être déployés sur chaque &lslon; dans un
<application>xterm</application> afin que l'utilisateur puisse
<emphasis>surveiller</emphasis>.
</para>
<para>
La nouvelle plate-forme de test est principalement écrite en shell Bourne.
Elle est conçue pour être portable sous bash (largement répandu sous Linux)
et en Korn shell (que l'on retrouve souvent sur les systèmes UNIX
commerciaux). Le code se trouve dans l'arborescence des sources au sein du
répertoire <filename>tests</filename>.
</para>
<para>
À présent, presque tous les tests font appel à seulement deux bases de
données qui par défaut sont sur un postmaster &postgres; unique sur un seul
serveur hôte. Ceci est parfait pour les tests qui impliquent la vérification
des fonctions &slony1; pour divers types de données. Ces tests font des
choses tels que varier les styles de date, et créer des tables et des
séquences qui impliquent des noms inhabituels afin de vérifier que les
guillemets sont gérés correctement.
</para>
<para>
Il est également possible de configurer des variables d'environnement afin
que les n&oelig;uds de la réplication soient placés sur différents serveurs
de base de données, éventuellement sur des serveurs hôtes distants, utilisant
différentes versions de &postgres;.
</para>
<para>
Voici quelques-uns des fichiers vitaux&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
<filename>run_test.sh</filename>
</para>
</listitem>
</itemizedlist>
<para>
Ceci est le script central pour exécuter les tests. Son utilisation typique
est la suivante&nbsp;:
</para>
<para>
<command>./run_test.sh</command>
</para>
<screen>
usage ./run_test.sh nom_du_test
</screen>
<para>
Vous devez spécifier le nom du sous-répertoire dans lequel l'ensemble du test
sera réalisé&nbsp;; chaque ensemble est stocké dans un sous-répertoire de
<filename>tests</filename>.
</para>
<para>
Vous pouvez définir une ou plusieurs variables d'environnement pour préciser
votre configuration locale. Par exemple, on exécute <quote>test1</quote> sur
&postgres; 8.0.x en utilisant la commande suivante&nbsp;:
</para>
<screen>PGBINDIR=/opt/OXRS/dbs/pgsql8/bin PGPORT=5532 PGUSER=cbbrowne ./run_test.sh test1</screen>
<glosslist>
<glossentry>
<glossterm><envar>PGBINDIR</envar></glossterm>
<glossdef>
<para>
Ceci détermine où les scripts de tests doivent chercher les binaires
&postgres; et &slony1;. La valeur par défaut est
<filename>/usr/local/pgsql/bin</filename>.
</para>
<para>
Il existe également les variables <envar>PGBINDIR1</envar> jusqu'à
<envar>PGBINDIR13</envar> qui permettent de définir un chemin spécifique
pour chaque instance de base de données. C'est particulièrement utile
lorsqu'on teste l'inter-opérabilité de &slony1; sur différentes versions
de &postgres; et sur différentes plates-formes. Afin de créer une base de
données de chaque version respective, vous devez pointer vers un
<application>initdb</application> de la version appropriée.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>PGPORT</envar></glossterm>
<glossdef>
<para>
Ceci indique sur quel port le processus postmaster écoute. Par défaut,
le port 5432 est utilisé.
</para>
<para>
Il existe également des variables <envar>PORT1</envar> jusqu'à
<envar>PORT13</envar> qui permettent de spécifier un numéro de port
pour chaque instance de base de données. Cela sera particulièrement
utile lorsqu'on teste l'inter-opérabilité de &slony1; sur différentes
versions de &postgres;.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>PGUSER</envar></glossterm>
<glossdef>
<para>
Par défaut, l'utilisateur <filename>postgres</filename> est
utilisé&nbsp;; ceci est utilisé comme l'identifiant par défaut à
utiliser sur toutes les bases de données.
</para>
<para>
Il existe également des variables <envar>USER1</envar> jusqu'à
<envar>USER13</envar> qui permettent de spécifier un nom d'utilisateur
différent pour chaque instance. Comme toujours avec &slony1;, l'utilisateur
doit être un <quote>super-utilisateur</quote> &postgres;.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>WEAKUSER</envar></glossterm>
<glossdef>
<para>
Par défaut, l'utilisateur <filename>postgres</filename> est
utilisé&nbsp;; c'est utilisé par défaut comme l'identifiant de
l'utilisateur pour les connexions <xref linkend="stmtstorepath"/>
sur toutes les bases de données.
</para>
<para>
Il existe également des variables <envar>WEAKUSER1</envar> jusqu'à
<envar>WEAKUSER13</envar> qui permettent de spécifier différents noms
d'utilisateur pour chaque instance. Cet utilisateur doit être un
<quote>super-utilisateur</quote> &postgres;. Cet utilisateur peut
commencer sans droits&nbsp;; il obtient les droits de lecture sur les
tables que le test utilise, ainsi que les droits d'accès sur le schéma
&slony1;, et les droits d'écriture sur la table et la séquence
utilisées pour gérer les verrous sur les n&oelig;uds.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>HOST</envar></glossterm>
<glossdef>
<para>
Par défaut, <filename>localhost</filename> est utilisé.
</para>
<para>
Il existe également les variables <envar>HOST1</envar> jusqu'à
<envar>HOST13</envar> qui permettent de spécifier un hôte différent
pour chaque instance de base de données.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>DB1</envar> jusqu'à <envar>DB13</envar></glossterm>
<glossdef>
<para>
Par défaut, les valeurs<filename>slonyregress1</filename> jusqu'à
<filename>slonyregress13</filename> sont utilisées.
</para>
<para>
Vous pouvez surcharger cela depuis l'environnement si vous avez de
bonnes raisons d'utiliser des noms différents.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>ENCODING</envar></glossterm>
<glossdef>
<para>
Par défaut, <filename>UNICODE</filename> est utilisé, afin que les
tests puissent créer des tables UTF8 et tester les capacités multibyte.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>MY_MKTEMP_IS_DECREPIT</envar></glossterm>
<glossdef>
<para>
Si votre version de Linux utilise une version de
<application>mktemp</application> qui ne génère pas un chemin absolu
vers l'emplacement du fichier/répertoire temporaire, alors modifiez
cette valeur.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>TMPDIR</envar></glossterm>
<glossdef>
<para>
Par défaut, les tests créeront des fichiers résultats dans
<filename>/tmp</filename>, <filename>/usr/tmp</filename> ou
<filename>/var/tmp</filename>, sauf si vous configurez cette variable
autrement.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>SLTOOLDIR</envar></glossterm>
<glossdef>
<para>
Emplacement des outils &slony1; tels que
<application>slony1_dump.sh</application>.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>ARCHIVE[n]</envar></glossterm>
<glossdef>
<para>
Si cette option est positionnée à <quote>true</quote> pour un
n&oelig;ud donné, qui est normalement configurée automatiquement dans
le fichier <filename>settings.ik</filename>, alors ce n&oelig;ud sera
utilisé comme source de données pour du <xref linkend="logshipping"/>,
et cela impliquera que les outils de tests créeront le répertoire
<link linkend="slon-config-archive-dir">archive_dir</link>.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>LOGSHIP[n]</envar></glossterm>
<glossdef>
<para>
Si cette option est positionnée à <quote>true</quote> pour un
n&oelig;ud donné, qui est normalement configurée automatiquement dans
le fichier <filename>settings.ik</filename>, alors ce n&oelig;ud est
créé via <xref linkend="logshipping"/>, et &lslon; n'est pas nécessaire
pour ce n&oelig;ud.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>SLONCONF[n]</envar></glossterm>
<glossdef>
<para>
Si cette valeur est positionnée à <quote>true</quote> pour un n&oelig;ud
donnée qui est généralement configurée dans le fichier
<filename>settings.ik</filename> pour un test donné, alors la
<link linkend="runtime-config">configuration</link> sera placée dans un
un fichier de configuration <filename>slon.conf</filename> spécifique
pour chaque n&oelig;ud.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>SLONYTESTER</envar></glossterm>
<glossdef>
<para>
Adresse e-mail de la personne qui reçoit les résultats des tests.
Ceci est stocké dans <envar>SLONYTESTFILE</envar> et peut être agrégé
dans un registre comparable à une ferme de compilation.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm><envar>SLONYTESTFILE</envar></glossterm>
<glossdef>
<para>
Fichier dans lequel sont stockés les résultats des tests. Ces résultats
peuvent être utilisés pour construire un dépôt contenant l'agrégation
des résultats de test.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>
<filename>random_number</filename> et <filename>random_string</filename>
</glossterm>
<glossdef>
<para>
Si vous exécutez <command>make</command> dans le répertoire de
<filename>test</filename>, les programmes C
<application>random_number</application> et
<application>random_string</application> seront compilés et seront
ensuite utilisés lors de la génération de données aléatoires au lieu
d'utiliser les fonctions shell/SQL qui sont beaucoup plus lentes que
les programmes C.
</para>
</glossdef>
</glossentry>
</glosslist>
<para>
Pour chaque test, vous trouverez les fichiers suivants&nbsp;:
</para>
<itemizedlist>
<listitem>
<para><filename>README</filename></para>
<para>
Ce fichier contient une description du test et est affiché au lecteur
lorsque le test est invoqué.
</para>
</listitem>
<listitem>
<para><filename>generate_dml.sh</filename></para>
<para>
Contient le code du script qui génère le SQL pour réaliser les mises à
jour.
</para>
</listitem>
<listitem>
<para><filename>init_add_tables.ik</filename></para>
<para>
Script <xref linkend="slonik"/> pour ajouter les tables pour le test de
réplication.
</para>
</listitem>
<listitem>
<para><filename>init_cluster.ik</filename></para>
<para>
Script <xref linkend="slonik"/> pour initialiser le cluster pour le test.
</para>
</listitem>
<listitem>
<para><filename>init_create_set.ik</filename></para>
<para>
Script <xref linkend="slonik"/> pour initialiser les n&oelig;uds
supplémentaires qui seront utilisés dans le test.
</para>
</listitem>
<listitem>
<para><filename>init_schema.sql</filename></para>
<para>
Script SQL pour créer les tables et les séquences nécessaires au démarrage
du test.
</para>
</listitem>
<listitem>
<para><filename>init_data.sql</filename></para>
<para>
Script SQL pour initialiser le schéma dans l'état nécessaire sur le
n&oelig;ud <quote>maître</quote>.
</para>
</listitem>
<listitem>
<para><filename>init_subscribe_set.ik</filename></para>
<para>
Script <xref linkend="slonik"/> pour mettre en place les abonnements.
</para>
</listitem>
<listitem>
<para><filename>settings.ik</filename></para>
<para>
Script shell utilisé pour contrôler la taille du cluster, comment les
n&oelig;uds seront créés, et où se trouve l'origine.
</para>
</listitem>
<listitem>
<para><filename>schema.diff</filename></para>
<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 n&oelig;uds. Notez qu'afin
d'éviter des échecs inutiles, les requêtes doivent utiliser des clauses
<command>ORDER BY</command> non-ambigües.
</para>
</listitem>
</itemizedlist>
<para>
Pour d'éventuels tests additionnels, tels que l'utilisation de <xref
linkend="stmtddlscript"/>, des scripts <xref linkend="slonik"/> et SQL
supplémentaires pourront être nécessaires.
</para>
</sect1>