 Utiliser Slony-I pour les
mises à jour PostgreSQL
|
 
|
Analyses des traces
|
Jusqu'à la version 1.1.5, Slony-I™ 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 pgbench (ce qui n'est pas une mauvaise chose en soi) mais étaient difficiles à automatiser car ils devaient être déployés sur chaque slon(1) dans un xterm afin que l'utilisateur puisse surveiller.
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 tests.
À présent, presque tous les tests font appel à seulement deux bases de données qui par défaut sont sur un postmaster PostgreSQL™ unique sur un seul serveur hôte. Ceci est parfait pour les tests qui impliquent la vérification des fonctions Slony-I™ 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.
Il est également possible de configurer des variables d'environnement afin que les nœ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 PostgreSQL™.
Voici quelques-uns des fichiers vitaux :
run_test.sh
Ceci est le script central pour exécuter les tests. Son utilisation typique est la suivante :
./run_test.sh
usage ./run_test.sh nom_du_test
Vous devez spécifier le nom du sous-répertoire dans lequel l'ensemble du test sera réalisé ; chaque ensemble est stocké dans un sous-répertoire de tests.
Vous pouvez définir une ou plusieurs variables d'environnement pour préciser votre configuration locale. Par exemple, on exécute « test1 » sur PostgreSQL™ 8.0.x en utilisant la commande suivante :
PGBINDIR=/opt/OXRS/dbs/pgsql8/bin PGPORT=5532 PGUSER=cbbrowne ./run_test.sh test1
Ceci détermine où les scripts de tests doivent chercher les binaires PostgreSQL™ et Slony-I™. La valeur par défaut est /usr/local/pgsql/bin.
Il existe également les variables PGBINDIR1 jusqu'à PGBINDIR13 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 Slony-I™ sur différentes versions de PostgreSQL™ et sur différentes plates-formes. Afin de créer une base de données de chaque version respective, vous devez pointer vers un initdb de la version appropriée.
Ceci indique sur quel port le processus postmaster écoute. Par défaut, le port 5432 est utilisé.
Il existe également des variables PORT1 jusqu'à PORT13 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 Slony-I™ sur différentes versions de PostgreSQL™.
Par défaut, l'utilisateur postgres est utilisé ; ceci est utilisé comme l'identifiant par défaut à utiliser sur toutes les bases de données.
Il existe également des variables USER1 jusqu'à USER13 qui permettent de spécifier un nom d'utilisateur différent pour chaque instance. Comme toujours avec Slony-I™, l'utilisateur doit être un « super-utilisateur » PostgreSQL™.
Par défaut, l'utilisateur postgres est utilisé ; c'est utilisé par défaut comme l'identifiant de l'utilisateur pour les connexions SLONIK STORE PATH(7) sur toutes les bases de données.
Il existe également des variables WEAKUSER1 jusqu'à WEAKUSER13 qui permettent de spécifier différents noms d'utilisateur pour chaque instance. Cet utilisateur doit être un « super-utilisateur » PostgreSQL™. Cet utilisateur peut commencer sans droits ; il obtient les droits de lecture sur les tables que le test utilise, ainsi que les droits d'accès sur le schéma Slony-I™, et les droits d'écriture sur la table et la séquence utilisées pour gérer les verrous sur les nœuds.
Par défaut, localhost est utilisé.
Il existe également les variables HOST1 jusqu'à HOST13 qui permettent de spécifier un hôte différent pour chaque instance de base de données.
Par défaut, les valeursslonyregress1 jusqu'à slonyregress13 sont utilisées.
Vous pouvez surcharger cela depuis l'environnement si vous avez de bonnes raisons d'utiliser des noms différents.
Par défaut, UNICODE est utilisé, afin que les tests puissent créer des tables UTF8 et tester les capacités multibyte.
Si votre version de Linux utilise une version de mktemp qui ne génère pas un chemin absolu vers l'emplacement du fichier/répertoire temporaire, alors modifiez cette valeur.
Par défaut, les tests créeront des fichiers résultats dans /tmp, /usr/tmp ou /var/tmp, sauf si vous configurez cette variable autrement.
Emplacement des outils Slony-I™ tels que slony1_dump.sh.
Si cette option est positionnée à « true » pour un nœud donné, qui est normalement configurée automatiquement dans le fichier settings.ik, alors ce nœud sera utilisé comme source de données pour du Section 16, « Log Shipping », et cela impliquera que les outils de tests créeront le répertoire archive_dir.
Si cette option est positionnée à « true » pour un nœud donné, qui est normalement configurée automatiquement dans le fichier settings.ik, alors ce nœud est créé via Section 16, « Log Shipping », et slon(1) n'est pas nécessaire pour ce nœud.
Si cette valeur est positionnée à « true » pour un nœud donnée qui est généralement configurée dans le fichier settings.ik pour un test donné, alors la configuration sera placée dans un un fichier de configuration slon.conf spécifique pour chaque nœud.
Adresse e-mail de la personne qui reçoit les résultats des tests. Ceci est stocké dans SLONYTESTFILE et peut être agrégé dans un registre comparable à une ferme de compilation.
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.
Si vous exécutez make dans le répertoire de test, les programmes C random_number et random_string 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.
Pour chaque test, vous trouverez les fichiers suivants :
README
Ce fichier contient une description du test et est affiché au lecteur lorsque le test est invoqué.
generate_dml.sh
Contient le code du script qui génère le SQL pour réaliser les mises à jour.
init_add_tables.ik
Script slonik(1) pour ajouter les tables pour le test de réplication.
init_cluster.ik
init_create_set.ik
Script slonik(1) pour initialiser les nœuds supplémentaires qui seront utilisés dans le test.
init_schema.sql
Script SQL pour créer les tables et les séquences nécessaires au démarrage du test.
init_data.sql
Script SQL pour initialiser le schéma dans l'état nécessaire sur le nœud « maître ».
init_subscribe_set.ik
settings.ik
Script shell utilisé pour contrôler la taille du cluster, comment les nœuds seront créés, et où se trouve l'origine.
schema.diff
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œuds. Notez qu'afin d'éviter des échecs inutiles, les requêtes doivent utiliser des clauses ORDER BY non-ambigües.
Pour d'éventuels tests additionnels, tels que l'utilisation de SLONIK EXECUTE SCRIPT(7), des scripts slonik(1) et SQL supplémentaires pourront être nécessaires.