Bienvenue sur la page de pgpool-II |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
pgpool-IIpgpool-II est un middleware qui se place entre les serveurs PostgreSQL et les clients de ces derniers. Voici ses différentes fonctionalités:
pgpool-II maintient les connexions établies aux serveurs PostgreSQL et les réutilise dès qu'une nouvelle connexion partageant les mêmes propriétés (c'est-à-dire même utilisateur, même base de données et même version de protocole) arrive. Il réduit ainsi le coût de la connexion et améliore les performances générales du système. pgpool-II peut gérer plusieurs serveurs PostgreSQL. En activant le mode réplication, il devient possible de créer une sauvegarde continue sur d'autres instances PostgreSQL, afin que le service puisse continuer sans interruption si l'une de ces instances était défaillante. Si une base de données est répliquée, exécuter une requête en SELECT sur n'importe lequel de ceux-ci retournera le même résultat. pgpool-II profite ainsi avantageusement de la réplication pour réduire la charge sur chacun des serveurs PostgreSQL. Il parvient à cela en distribuant les requêtes SELECT entre tous les serveurs disponibles, ce qui qui améliore les performances générales du système. Dans un scénario idéal, les performances en lecture s'améliorent proportionnellement au nombre de serveurs PostgreSQL. La répartition de charge avec pgpool-II fonctionne au mieux dans un scénario où il y a beaucoup d'utilisateurs qui exécutent beaucoup de requêtes en lecture au même moment. Dans PostgreSQL, il y a une limite maximum du nombre de connexions concurrentes au serveur (NDT: paramètre max_connections), et toutes les nouvelles connexions sont rejettées une fois que ce nombre est atteint. Augmenter ce nombre est possible mais accroît la consommation de ressources par le serveur et a un impact négatif sur les performances générales du système. Bien que pgpool-II ait aussi une limite sur le nombre de connexions maximum, il va mettre toute connexion excédentaire dans une file d'attente au lieu de retourner immédiatement une erreur. En utilisant la fonctionalité des requêtes parallèlisées, les données peuvent être réparties sur plusieurs serveurs afin que les requêtes puissent être exécutées sur tous les serveurs à la fois, en réduisant ainsi le temps d'exécution global de la requête. Cette fonctionalité donne les meilleurs résultats lorsqu'on cherche à extraire un très grand ensemble de données. pgpool-II utilise le même protocole que le serveur et les clients PostgreSQL, et relaie les messages entre les deux. Ainsi, une application cliente va prendre pgpool-II pour le serveur, et ce dernier va voir pgpool-II comme une application cliente. Puisque pgpool-II est complètement transparent, il peut-être utilisé pour une application sans pratiquement rien changer de son code source. Il y a cependant quelques restrictions à l'utilisation du SQL via pgpool-II. Veuillez vous reporter à la section Restrictions pour plus de détails. Plates-formes supportéespgpool-II fonctionne sous Linux, Solaris, FreeBSD et la plupart des architectures UNIX. Windows n'est pas supporté. Les versions 6.4 et ultérieures de PostgreSQL sont supportées. Cependant, pour utiliser la fonctionalité de requêtage en parallèle, vous devez avoir un serveur en version 7.4 ou supérieure. Si vous utilisez PostgreSQL en version 7.3 ou inférieure, certaines fonctionnalités de pgpool-II ne seront pas disponibles. Cependant, vous ne devriez pas utiliser une si vieille version de toute façons. Vous devez aussi être certain que vos serveurs PostgreSQL sont tous dans la même version majeure. De plus, les architectures matérielles et logicielles (systèmes d'exploitation) doivent-être identiques si vous voulez utiliser la technologie « online recovery ». Installation de pgpool-IIpgpool-II est téléchargeable sur la page de développement de pgpool. Plusieurs packages sont aussi fournis pour diverses plates-formes incluant CentOS, RedHat Enterprise Linux, Fedora et Debian. Le code source de pgpool-II est téléchargeable sur la page de développement de pgpool. Pour installer pgpool-II depuis son code source, vous aurez besoin de gcc, en version 2.9 ou supérieure, et de GNU make. pgpool-II utilisant la bibliothèque libpq de PostgreSQL, celle-ci doit aussi être installée ainsi que les fichiers d'en-tête sur la machine utilisée pour compiler pgpool-II. Si vous souhaitez activer le support d'OpenSSL dans pgpool-II, il vous faudra aussi avoir cette bibliothèque ainsi que les fichiers d'en-tête relatifs installés sur la machine de compilation.
Configuration de pgpool-IILes fichiers de configuration par défaut de pgpool-II sont
Configuration de
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Caractère spécial | Description |
| %d | ID du processus serveur correspondant au nœud détaché |
| %h | Nom d'hôte du nœud détaché |
| %p | Numéro de port du nœud détaché |
| %D | Répertoire de l'instance PostgreSQL du nœud détaché |
| %M | ID du nœud de l'ancien maître |
| %m | ID du nœud du nouveau maître |
| %H | Nom d'hôte du nouveau nœud maître |
| %P | ID de l'ancien nœud primaire |
| %% | Caractère '%' |
Vous devez recharger pgpool.conf si vous changez la valeur de
failover_command.
Lorsqu'une commande failover est exécutée, pgpool tue tous ses processus fils,
ce qui fermera toutes les sessions actives à pgpool. Alors, pgpool invoque la
commande failover_command et attend son exécution complète. Après
cela, pgpool démarre de nouveaux processus fils et est alors à nouveau
disponible pour accepter des connexions depuis les clients.
Ce paramètre contient une commande à exécuter lors qu'un nœud est attaché. pgpool-II remplace les caractères spéciaux suivants avec les informations associées.
Caractère spécial Description %d ID du processus serveur d'un nœud attaché %h Nom d'hôte d'un nœud attaché %p Numéro de port d'un nœud attaché %D Répertoire de l'instance PostgreSQL d'un nœud attaché %M Ancien nœud maître %m Nouveau nœud maître %H Nom d'hôte du nouveau nœud maître %P ID de l'ancien nœud primaire %% Caractère '%'
Vous devez recharger pgpool.conf si vous changez le contenu de la
commande failback_command.
Si ce paramètre est à true et qu'une erreur apparaît lors d'une écriture sur le canal de communication d'un processus serveur, pgpool-II déclenchera une procédure de failover. C'est le même comportement qu'avec les versions 2.2.x ou précédentes de pgpool-II. Si ce paramètre est à false, pgpool reportera une erreur dans ses fichiers de traces et déconnectera la session. Notez cependant que si ce paramètre est activé, pgpool effectuera aussi un failover lorsque la connexion à un processus serveur échoue ou lorsqu'il détecte l'arrêt du serveur PostgreSQL par un administrateur. Vous devez recharger pgpool.conf si vous changez cette valeur.
Si ce paramètre est activé, pgpool-II ignorera les espaces en début de requête SQL lorsqu'il est dans le mode de répartition de charge. C'est particulièrement intéressant lorsqu'il est utilisé avec des API comme DBI/DBD::Pg qui ajoutent des espaces sans que l'utilisateur le demande. Vous aurez besoin de demander à pgpool-II de recharger sa configuration pour que ce paramètre soit pris en compte.
Lorsque ce paramètre est activé, pgpool-II tracera les requêtes SQL qu'il reçoit dans son fichier de traces. Cela va produire des traces même si l'option debug n'est pas passée à pgpool-II au démarrage. Vous aurez besoin de recharger pgpool.conf pour que ce paramètre soit pris en compte.
Similaire à log_statement, à l'exception qu'il écrit les traces de manière séparée par nœud. Cela peut se révéler très utile si vous voulez vous assurer, par exemple, que votre réplication fonctionne. Vous aurez besoin de recharger pgpool.conf pour que ce paramètre soit pris en compte.
Si ce paramètre est positionné à true, le nom de la commande affichée dans la sortie de ps sera le nom de l'hôte plutôt que son IP. De même, si log_connections est activé, le nom de l'hôte sera écrit dans les fichiers de trace plutôt que son IP. Ce paramètre est pris en compte au rechargement de pgpool.conf.
Si ce paramètre est à true, toutes les connexions entrantes seront tracées dans les journaux applicatifs. Ce paramètre est pris en compte au rechargement de pgpool.conf.
Si ce paramètre est à vrai, on utilisera le fichier pool_hba.conf pour l'authentification des clients. Voir la configuration de pool_hba.conf pour l'authentification des clients. Ce paramètre est pris en compte au rechargement de pgpool-II.
Permet de spécifier à quel serveur PostgreSQL on se connecte. C'est utilisé par pgpool-II pour communiquer avec le serveur. Ce paramètre n'est lu qu'au démarrage du serveur pgpool-II.
Pour les communications TCP/IP, ce paramètre accepte soit un nom
d'hôte, soit une adresse IP. Si ce dernier commence avec un slash,
il spécifie un socket Unix plutôt qu'une adresse IP ; la valeur est
alors le nom du répertoire dans lequel le fichier de socket UNIX est
stocké. Si ce paramètre est vide (''), le comportement par
défaut de pgpool-II est de se connecter à un socket UNIX stocké dans le
répertoire /tmp.
On peut spécifier ici plusieurs serveurs en ajoutant un nombre à la
fin du nom du paramète (par exemple backend_hostname0).
Ce nombre est l'identifiant du nœud au sein de pgpool-II. Le premier
nœud est toujours le nœud 0. Le serveur PostgreSQL qui se voit
attribuer l'identifiant 0 sera appelé le serveur maître. Lorsque plusieurs
serveurs sont définis et seulement pour certains modes, le service peut
continuer même si le serveur maître est arrêté. Dans ce
cas, c'est toujours le serveur qui a le plus petit identifiant de nœud
et qui est encore disponible qui est alors promu serveur maître.
Si vous pensez n'utiliser qu'un seul serveur PostgreSQL, spécifiez-le
avec backend_hostname0.
De nouveaux serveurs PostgreSQL peuvent être ajoutés grâce à ce paramètre mais Vous devez recharger le fichier de configuration. Par contre, les valeurs de ces paramètres ne pouvant être mises à jour, si vous les changez, vous devrez alors redémarrer pgpool-II.
Spécifie le numéro de port des serveurs. Comme précédemment, on peut
spécifier le port de plusieurs serveurs en ajoutant à la fin du nom du
paramètre l'identifiant du nœud (par exemple backend_port0).
Si vous n'utilisez qu'un seul serveur, vous devrez le spécifier par
backend_port0.
Comme précédemment, vous pouvez ajouter de nouveaux paramètres concernant de nouveaux nœuds, et alors, un rechargement de la configuration suffira. Cependant, si vous mettez à jour des valeurs de paramètres existant, vous devrez redémarrer le serveur pgpool-II.
Spécifie le poids des serveurs pour la répartition de charge.
On peut indiquer une valeur pour chacun des serveurs. Il suffit
pour cela d'ajouter le numéro du serveur à la fin du nom du
paramètre (par exemple backend_weight0). Si vous
n'utilisez qu'un seul serveur PostgreSQL, utilisez le paramètre
backend_weight0. Si vous êtes dans le mode RAW de pgpool-II,
mettez toujours cette valeur à 1.
De nouveaux poids pour les backends peuvent être ajoutés pour de nouveaux nœuds. Cependant, si vous mettez à jour des valeurs de paramètres existant, vous devrez redémarrer le serveur pgpool-II.
À partir de pgpool-II 2.2.6/2.3, vous pouvez changer cette valeur par rechargement du fichier de configuration. Le nouveau paramétrage prendra alors effet uniquement pour les nouvelles sessions clientes. C'est très pratique si vous voulez empêcher toute requête envoyée aux serveurs esclaves de réaliser des tâches administratives en mode maître/esclave.
Précise le répertoire des données des serveurs PostgreSQL.
Plusieurs serveurs peuvent être spécifiés en ajoutant
un nombre à la fin du nom de paramètre (par exemple
backend_data_directory0).
Si vous ne pensez pas utiliser « online recovery », vous n'avez pas
besoin de spécifier ce paramètre.
Des spécifications de répertoires de données PostgreSQL additionnels peuvent être ajoutés par rechargement du fichier de configuration. En revanche, leur valeur ne peut pas être mise à jour de cette façon. Du coup, vous devrez redémarrer pgpool-II si vous modifiez la valeur d'un paramètre déjà configuré.
Si ce paramètre est à "true", le support de SSL est activé à la fois pour
les connexions clientes et les connexions aux serveurs PostgreSQL.
Notez que ssl_key et ssl_cert
doivent être renseignés pour que les connexions clientes puissent
fonctionner en SSL.
SSL est désactivé par défaut. Notez que le support d'OpenSSL doit aussi avoir été configuré au moment de la compilation, comme c'est mentionné dans la section installation.
Le démon de pgpool-II doit être redémarré lorsqu'on met à jour les paramètres relatifs à SSL.
Chemin du fichier de clé privée pour les connexions clientes entrantes.
Il n'y a aucune valeur par défaut pour ce paramètre. S'il n'est pas modifié, le support de SSL sera désactivé pour les connexions clientes entrantes.
Chemin complet vers le certificat public x509 à utiliser pour les connexions clientes entrantes.
Il n'y a aucune valeur par défaut pour ce paramètre. S'il n'est pas modifié, le support de SSL sera désactivé pour les connexions clientes entrantes.
Niveau de verbosité des messages de débogage. 0 signifie aucun message, plus grand que 1 engendre des messages plus verbeux. La valeur par défaut est 0.
Durée de vie en secondes d'une relation en cache. 0 signifie qu'il n'y a pas d'expiration (valeur par défaut). Ce cache de relations est utilisé pour cacher le résultat de requêtes effectuées sur le catalogue système de PostgreSQL pour obtenir diverses informations comme la structure des tables ou pour savoir si telle ou telle table est temporaire. Ce cache est maintenu dans une mémoire locale au processus fils de pgpool et est gardé aussi longtemps que le processus est en vie. Si un utilisateur modifie une table avec un ALTER TABLE, par exemple, ce cache n'est alors plus cohérent. À cet effet, le paramète relcache_expiration contrôle la durée de vie du cache.
La manipulation des certificats n'est pas couvert dans ce document. La page Secure TCP/IP Connections with SSL (en anglais) sur le site PostgreSQL.org référence des documents qui expliquent en détail les commandes à taper pour engendrer des certificats auto-signés.
Le failover peut être accompli dans le mode Raw si plusieurs serveurs
sont définis. pgpool-II accède en général au serveur spécifié par
backend_hostname0 pendant son fonctionnement normal.
Si le backend_hostname0 est en échec, quel que soit la raison, pgpool-II
essaie d'accéder au serveur spécifié par backend_hostname1. En cas d'échec,
pgpool-II essaie alors backend_hostname2, et ainsi de suite.
Dans le mode pooling de connexions, toutes les fonctions du mode raw et du mode pooling de connexions peuvent être utilisées. Pour activer ce mode, configurez les paramètres du mode raw ainsi que les autres paramètres ci-après.
Nombre maximum de connexions en cache dans les processus
fils de pgpool-II. pgpool-II réutilise les connexions en cache si une
connexion entrante se connecte à la même base de données avec le
même nom d'utilisateur. Sinon, pgpool-II crée une nouvelle connexion
au serveur PostgreSQL. Si le nombre de connexions en cache dépasse
max_pool, la plus vieille des connexions sera supprimée et on utilisera
cet emplacement ainsi libéré pour la nouvelle connexion.
La valeur par défaut est 4. Faites bien attention au fait que le nombre
total de connexions des processus pgpool-II aux serveurs PostgreSQL
pourraient atteindre ainsi :
num_init_children * max_pool.
Ce paramètre n'est pris en compte qu'au démarrage du serveur
pgpool-II.
Durée de vie en seconde d'une connexion en cache. Une connexion en cache dont la durée de vie expire sera alors déconnectée. La valeur par défaut est 0, ce qui signifie que les connexions en cache ne seront jamais déconnectées.
Spécifie les requêtes SQL envoyées à la connexion au serveur PostgreSQL lorsqu'une session se termine, côté client de pgpool-II. Plusieurs commandes peuvent être spécifiées en les séparant par un point-virgule. La valeur ci-dessous est la valeur par défault, mais elle peut être adaptée pour satisfaire vos besoins.
reset_query_list = 'ABORT; DISCARD ALL'
Les commandes diffèrent dans chaque version de PostgreSQL. Voici les paramètres recommandés par version.
| Version de PostgreSQL | reset_query_list value |
|---|---|
| 7.1 ou précédentes | ABORT |
| 7.2 à 8.2 | ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT |
| 8.3 et suivantes | ABORT; DISCARD ALL |
Vous aurez besoin de recharger pgpool.conf après toute modification de ce paramètre pour que sa nouvelle valeur soit prise en compte.
Le failover dans le mode pooling de connexions
Le failover dans le mode pooling de connexions est identique à celui du mode raw.
Ce mode permet la réplication des données entre les serveurs PostgreSQL. Les paramètres de configuration ci-dessous doivent être renseignés, en plus de tout ce qui a été vu plus haut.
Mettre ce paramètre à true active le mode de
réplication. La valeur par défaut est false.
Lorsque ce paramètre est à true, les requêtes de
type SELECT sont distribuées à chaque serveur PostgreSQL pour
obtenir une répartition de la charge entre les serveurs. La valeur
par défaut est false.
Lorsque ce paramètre est positionné à true,
si les serveurs PostgreSQL ne retournent pas le même nombre de
lignes affectées lors d'un INSERT, UPDATE ou DELETE, les serveurs
qui diffèrent de la valeur la plus fréquente sont « dégénérés »
(NDT: ils ne sont alors plus jamais utilisés par pgpool-II, qui les
considère comme incohérents).
Si ce paramètre est à false, la session est terminée
et les serveurs PostgreSQL ne sont pas « dégénérés ». La valeur par
défaut est à false.
Si ce paramètre est à true et si tous les serveurs
PostgreSQL ne retournent pas le même type de paquet, les serveurs
dont la valeur diffère du résultat le plus fréquent sont « dégénérés ».
Un cas d'utilisation typique est une requête SELECT dans une
transaction, avec replicate_select à true, qui
retournerait un nombre d'enregistrements différent suivant les
serveurs PostgreSQL.
Les requêtes qui ne sont pas en SELECT pourraient aussi déclencher
cette action. Par exemple, si un serveur PostgreSQL réussit un
UPDATE alors que les autres échouent.
Notez que pgpool-II n'examine pas le contenu des
enregistrements retournés par un SELECT.
Si ce paramètre est à false, la session est terminée
et les serveurs PostgreSQL ne sont pas « dégénérés ». La valeur par
défaut est false.
Permet de spécifier une liste de noms de fonctions, séparées par des virgules, qui ne font pas d'écritures dans la base de données. Tous les SELECTs qui font appel à des fonctions qui ne sont pas spécifiées dans cette liste ne seront ainsi jamais répartis entre les serveurs PostgreSQL, ni même répliqués dans le mode réplication. Dans le mode maître/esclave, de tels SELECTs sont envoyés au maître (ou primaire) uniquement.
Vous pouvez utiliser des expressions régulières dans la liste pour établir une correspondance à une famille de fonctions. Par exemple, si vous avez eu la bonne idée de préfixer toutes les fonctions de votre base qui ne font que des lectures avec 'get_' ou 'select_' par exemple, vous pourrez ainsi vous limiter à n'écrire que les deux expressions régulières dans ce paramètre :
white_function_list = 'get_.*,select_.*'
Permet de spécifier une liste de noms de fonctions, séparées par des virgules, qui font des écritures dans la base de données. Les SELECT qui utilisent les fonctions spécifiées dans cette liste ne seront jamais répartis entre les serveurs PostgreSQL, ni répliqués dans le mode de réplication. Dans le mode maître/esclave, de tels SELECT sont envoyés uniquement au maître.
Vous pouvez utiliser des expressions régulières dans la liste pour établir une correspondance avec une famille de fonctions. Par exemple, si vous avez eu la bonne idée de préfixer toutes les fonctions de votre base qui font des écritures avec 'set_','update_','delete_' ou 'insert_' par exemple, vous pourrez ainsi vous limiter à n'écrire que les expressions régulières suivantes dans ce paramètre :
black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'
Attention, une seule de ces deux listes ne peut être renseignée dans la configuration de pgpool-II. Autrement dit, vous devez opter pour l'un ou l'autre des paramètres : autoriser de manière explicite, ou interdire de manière explicite. De préférence, optez pour la sécurité d'autoriser explicitement, c'est-à-dire utiliser le paramètre white_function_list. En effet, en cas d'oubli d'une fonction en écriture dans le paramètre black_function_list, vous risquez de demander l'exécution d'une fonction en écriture sur un serveur en lecture seule, dans le mode maître/esclave par exemple.
Avant la version 3.0 de pgpool-II, les fonctions nextval() et setval() étaient connues pour leurs écritures dans la base de données. Vous pouvez émuler ce comportement en utilisant les deux paramètres vus précédemment de la façon suivante :
white_function_list = '' black_function_list = 'nextval,setval,lastval,currval'
Notez que l'on a lastval() et currval() en plus des nextval() et setval(). Bien que lastval() et currval() ne soient pas des fonctions qui provoquent des écritures, il vaux mieux les ajouter pour éviter toute erreur dans le cas où ces fonctions seraient accidentellement réparties entre les différents nœuds. Ainsi, les ajouter à la black_function_list permettra d'éviter qu'elles soient réparties.
Lorsque ce paramètre est à true, pgpool-II va répliquer
les SELECT dans le mode de réplication. Si c'est à false,
pgpool-II va les envoyer uniquement au serveur maître (primaire). La valeur
par défaut est false.
Si une requête SELECT est à l'intérieur d'un bloc de transaction explicite, replicate_select et load_balance_mode auront un effet sur le fonctionnement de la réplication. Les détails sont expliqués ci-dessous.
| Le SELECT est à l'intérieur d'un bloc de transaction | O | O | O | N | N | N | O | N |
| replicate_select = true | O | O | N | N | O | O | N | N |
| load_balance_mode = true | O | N | N | N | O | N | O | O |
| resultats (R:réplication, M:envoyé au maître uniquement, L:réparti) | R | R | M | M | R | R | M | L |
Si on réplique une table qui utilise le type de données SERIAL, la valeur du SERIAL pourrait être différente entre les serveurs PostgreSQL. On peut éviter ce problème en verrouillant la table de manière explicite (bien que le parallélisme des transactions sera alors sévèrement dégradé). Pour arriver à cela, les changements suivants doivent être faits :
INSERT INTO ...
à
BEGIN;
LOCK TABLE ...
INSERT INTO ...
COMMIT;
Lorsque insert_lock est à
true, pgpool-II ajoute automatiquement
les requêtes ci-dessus à chaque fois qu'un INSERT est
exécuté. Si on est alors déjà dans une transaction, il ajoute
alors simplement un LOCK TABLE.
À partir de pgpool-II 2.2, la détection des tables qui ont un SERIAL ou non est automatique. Ainsi, seules les tables qui ont un SERIAL sont verrouillées de manière exclusive.
pgpool-II 3.0 utilise désormais un verrou de ligne sur la relation de la séquence, plutôt qu'un verrou de table exclusif. Cela minimise les conflits sur les verrous, comme par exemple VACUUM (direct ou via autovacuum).
Si vous souhaitez un contrôle plus fin (par requête) :
insert_lock à true, et
ajoutez /*NO INSERT LOCK*/ au début d'une requête
INSERT pour laquelle vous ne voulez pas qu'un verrou exclusif de
table ne soit ajouté.insert_lock à false, et
ajoutez /*INSERT LOCK*/ au début d'une requête
INSERT pour laquelle vous voulez provoquer un verrouillage
exclusif de la table.
La valeur par défaut est false. Si
insert_lock est activé, les tests de régression pour
PostgreSQL 8.0 échoueront dans les transactions, droits, règles
(rules) et ALTER TABLE. La raison en est que pgpool-II essaie de
verrouiller une vue pour le test sur les règles, ce qui a pour conséquence
l'erreur suivante :
! ERROR: current transaction is aborted, commands ignored until
end of transaction block
Par exemple, le test sur les transactions essaie un INSERT dans une table qui n'existe pas, et pgpool-II essaie d'acquérir un verrou exclusif avant cela. La transaction sera alors interrompue et la requête d'INSERT qui suit produira le message ci-dessus.
Ce paramètre permet de spécifier l'utilisateur PostgreSQL à utiliser pour le « online recovery ». Il peut être changé sans avoir besoin de redémarrer pgpool-II.
Ce paramètre permet de spécifier le mot de passe de l'utilisateur spécifié dans
le paramètre ci-dessus, à savoir recovery_user, qui est utilisé
lors du « online recovery ». Comme le paramètre précédent, il peut être changé
sans avoir à redémarrer le serveur pgpool-II.
Ce paramètre permet de préciser une commande à exécuter pour la première
phase du « online recovery ». Le fichier de commandes spécifié ici doit être placé
à la racine du répertoire des données de l'instance PostgreSQL, pour des
raisons de sécurité.
Par exemple, si recovery_1st_stage_command = 'sync-command',
alors pgpool-II exécute $PGDATA/sync-command.
Notez que pgpool-II accepte les connexions et les requêtes alors que
recovery_1st_stage command est en cours d'exécution. On peut
ainsi lire et écrire dans la base de données pendant cette première phase du
« online recovery ».
Ce paramètre peut être changé sans avoir à redémarrer pgpool-II.
Ce paramètre spécifie une commande à exécuter lors de la deuxième phase
du « online recovery ». Ce fichier de commandes doit être placé à la racine
du répertoire des données de l'instance PostgreSQL pour des raisons de sécurité.
Par exemple, si recovery_2nd_stage_command = 'sync-command',
alors pgpool-II exécute $PGDATA/sync-command.
Notez que pgpool-II n'accepte pas de connexions ou d'exécution de
requêtes pendant que recovery_2nd_stage_command est en
cours d'exécution. Ainsi, si un client reste connecté pendant une longue période,
rien ne sera exécuté. En effet, pgpool-II attends que tous les clients aient
fermé leurs connexions pour exécuter cette seconde phase du « online recovery ».
La commande n'est donc exécutée que lorsqu'il n'y a plus aucun client de
connecté.
Ce paramètre peut être changé sans redémarrer pgpool-II.
pgpool n'accepte plus de nouvelle connexion pendant la seconde phase du « online recovery ». Si un client essaie de se connecter à pgpool-II pendant un « online recovery », il devra attendre la fin de ce dernier.
Ce paramètre spécifie un délai au terme duquel le « online recovery » sera annulé
s'il n'est pas terminé. Après l'annulation, pgpool-II acceptera alors de nouveau
les connexions. La valeur 0 désactive cette fonctionnalité.
Ce paramètre peut être changé sans avoir à redémarrer pgpool-II.
Similaire à client_idle_limit. Cependant, il n'agit
que lors de la seconde phase du « online recovery ». Un client qui aura
été inactif pendant client_idle_limit_in_recovery
secondes depuis sa dernière requête sera déconnecté.
Ce paramètre permet d'éviter que le « online recovery » ne soit perturbé
par un client inactif, ou si la connexion TCP/IP entre le client et
pgpool tombe de manière accidentelle (un câble réseau défectueux
par exemple). Si ce paramètre est à -1, le client
est déconnecté immédiatement. La valeur par défaut de ce paramètre
est 0, ce qui signifie que cette fonctionalité est
désactivée.
Si vos clients sont très actifs, pgpool-II ne pourra jamais entrer dans
la seconde phase du « online recovery », quelle que soit la valeur de
client_idle_limit_in_recovery que vous aurez choisie.
Dans ce cas, vous pouvez paramétrer client_idle_limit_in_recovery
à -1 afin que pgpool-II puisse déconnecter immédiatement
des clients aussi actifs avant de passer à la seconde phase du « online
recovery ».
Vous devez recharger la configuration de pgpool-II si vous changer la
valeur de client_idle_limit_in_recovery.
Ce paramètre spécifie un nom de table utilisé pour le contrôle de la réplication des « large objects ». Si elle est spécifiée, pgpool-II verrouillera cette table, et génèrera un identifiant de « large object » en regardant dans la table pg_largeobject du catalogue système, et enfin, appellera lo_create pour créer le « large object ». Cette procédure garantie que pgpool-II obtiendra le même identifiant de « large object » sur tous les serveurs PostgreSQL lorsque pgpool-II est dans le mode réplication. Notez que PostgreSQL 8.0 et ultérieur n'a plus de fonction lo_create. Du coup, cette fonctionalité est pas utilisable pour ces versions.
Un appel à la fonction de la libpq lo_creat() utilisera cette fonctionalité. De même, la création de « large objects » via l'API Java (driver JDBC) devrait fonctionner, tout comme l'API PHP (pg_lo_create, ou API similaire dans la bibliothèque de PHP, comme PDO), et ce genre d'API similaires dans plusieurs langages de programmation qui sont réputées pour utiliser un protocole similaire.
Les opérations suivantes de création d'un « large object » ne fonctionneront pas :
Peu importe le schéma où est stockée la table lobj_lock_table,
celle-ci doit en revanche être accessible en écriture à tous les utilisateurs.
Voici un exemple de création d'une telle table :
CREATE TABLE public.my_lock_table (); GRANT ALL ON public.my_lock_table TO PUBLIC;
La table spécifiée par lobj_lock_table doit être créée à
l'avance. Vous pouvez par exemple la créer dans la base template1
afin que toute base de données créée par la suite en dispose.
Si lobj_lock_table contient une chaîne vide (''),
la fonctionalité est désactivée. Du coup, la réplication des « large objects »
ne fonctionnera pas.
La valeur par défaut de ce paramètre est justement la chaîne vide ('').
Pré-requis pour la répartition de charge
Pour qu'une requête soit répartie, les pré-requis suivants doivent être respectés :
ignore_leading_white_space = true permettra
d'ignorer tous les éventuels espaces présents avant la requête.
Notez que vous pouvez interdire de manière explicite la répartition d'une charge sur une requête SELECT en ajoutant un commentaire au début de la requête SELECT (quel que ce soit ce commentaire). Par exemple :
/*REPLICATION*/ SELECT ...
Merci de lire attentivement la page replicate_select au sujet de la réplication. De même, étudiez attentivement ce schéma qui explique comment pgpool-II détermine à quel serveur PostgreSQL envoyer telle ou telle requête.
Attention : le connecteur JDBC a une option autocommit. Si autocommit est à
false, le connecteur JDBC envoie un BEGIN et un COMMIT
lui-même. Ainsi, pgpool-II ne pourra faire aucune répartition de charge. Vous devez
alors appeler setAutoCommit(true) pour activer
l'autocommit.
Failover dans le mode Réplication
pgpool-II désactive un serveur « mort » et le service continue, à condition qu'il y ait au moins un serveur PostgreSQL en vie.
Ce mode est utilisé lorsque pgpool-II est couplé avec un autre outil
de réplication de type maître/esclave(s) (comme Slony-I ou le Streaming
Réplication intégré à PostgreSQL). Cet outil est alors responsable de la
réplication des données.
L'information sur les serveurs PostgreSQL doit être renseignée (les paramètres
backend_hostname, backend_port, backend_weight et backend_data_directory),
de la même façon que dans le mode réplication.
De plus, il faut paramétrer master_slave_mode et
load_balance_mode à true.
pgpool-II enverra alors les requêtes qui doivent être répliquées au serveur
PostgreSQL maître, et les autres requêtes seront réparties parmi les différents
serveurs lorsque c'est possible.
L'algorithme de pgpool-II prend bien sûr en compte les requêtes qui ne peuvent être
réparties ; elles sont alors systématiquement envoyées au serveur maître.
Dans le mode maître-esclave, les DDL et DML pour une table temporaire ne
peuvent être exécutées que sur le serveur maître.
Vous pouvez forcer un SELECT à ne s'exécuter que sur le maître en ajoutant un
commentaire /*NO LOAD BALANCE*/ devant le SELECT.
Dans le mode maître-esclave, vous devez positionner
replication_mode à false et
master_slave_mode à true.
Le mode maître-esclave a un sous-mode piloté par le paramètre
'master_slave_sub_mode'. Il vaut par défaut
slony et convient si vous utilisez Slony-I.
Vous pouvez aussi le paramétrer à stream si
vous utilisez le système de réplication intégré à PostgreSQL (le
Streaming Replication).
Le fichier de configuration d'exemple pour le sous-mode Slony-I
est pgpool.conf.sample-master-slave, et celui
concernant la Streaming Replication est
pgpool.conf.sample-stream.
Vous devez redémarrer pgpool-II si vous changez l'un des paramètres vu précédemment.
Vous devrez probablement aussi renseigner les paramètres
white_function_list et
black_function_list si vous voulez contrôler plus finement
la répartition de charge dans le mode maître-esclave.
Reportez-vous à white_function_list
pour plus de détails.
Comme nous l'avons vu précédemment, pgpool-II peut fonctionner de pair avec la Streaming Replication, qui est disponible depuis la version 9.0 de PostgreSQL. Pour l'utiliser, il faut activer le paramètre master_slave et positionner le paramètre master_slave_sub_mode1 à stream. pgpool-II suppose que le Streaming Replication fonctionne et que les serveurs PostgreSQL esclaves sont en Hot Standby, ce qui signifie que les bases de données sont ouvertes en lecture seule sur ces derniers. Les directives suivantes peuvent être utilisées dans ce mode :
Permet de spécifier le décalage maximum toléré entre le serveur maître et
un serveur esclave dans une réplication, exprimé en octets de journaux de
transactions.
Si le décalage dépasse delay_threshold, pgpool-II n'envoie
alors plus de SELECT au serveur(s) esclave(s). Tout est alors envoyé au serveur
maître, même si la répartition de charge est activée, jusqu'à ce que le(s) serveur(s)
esclave(s) soit(soient) en deçà du décalage maximum autorisé.
Si delay_threshold est à 0 ou si le test
de vie est désactivé, ce test de décalage n'est jamais fait. Ce dernier est
effectué tous les health_check_period. La valeur par défaut
pour delay_threshold est 0.
Vous devez recharger la configuration de pgpool-II si vous changez cette
directive.
Permet de spécifier comment le décalage de réplication est tracé dans le
journal applicatif de pgpool-II. Si none est spécifié ici,
rien n'est écrit. Si always est spécifié, alors le décalage
sera tracé à chaque fois que le test est effectué.
Si if_over_threshold est spécifié, alors le décalage est
tracé uniquement lorsqu'il dépasse le delay_threshold.
La valeur par défaut pour log_standby_delay est
none.
Vous devez recharger la configuration de pgool-II si vous changez ce
paramètre.
Vous pouvez aussi superviser le décalage éventuel de la réplication en utilisant la commande "show pool_status".
Dans le mode maître/esclave avec la Streaming Replication, si le nœud primaire ou le nœud en attente s'arrête, pgpool-II peut être configuré pour exécuter un Failover. Les nœuds peuvent alors être attachés automatiquement sans configuration ou opérations complémentaires. Alors qu'il est en pleine réplication [~], le nœud en attente vérifie régulièrement si un fichier de déclenchement existe. S'il le trouve, le nœud en attente sort de son mode réplication et s'ouvre en mode lecture/écriture. En utilisant ce mécanisme, on peut avoir une base de données en attente qui prends le relais quand le nœud primaire tombe.
Attention : si vous pensez utiliser plusieurs nœuds en mode standby, il est recommandé de définir le paramètre delay_threshold pour empêcher tout requête dirigée vers d'autres nœuds en standby de récupérer des données plus vieilles.
Si un second nœud en standby prends le relais quand le premier nœud en standby avait déjà pris le relais, vous pourriez avoir des données erronnées en provenance du second standby. Nous vous recommandons de ne pas utiliser ce genre de configuration.
Voici commment configurer un mécanisme de Failover.
$ cd /usr/loca/pgsql/bin $ cat failover_stream.sh #! /bin/sh # Commandes pour faire un Failover en mode Streaming Replication # Ce script suppose que le nœud Maitre est le 0 et 1 le standby # # Si le Standby s'arrête, ne rien faire. Si le Primaire s'arrête, créer # un fichier de déclenchement afin que le standby prenne le relais sur le # nœud Primaire. # # Arguments: # $1: identifiant du nœud qui ne répond plus # $2: nom d'hôte du nouveau maître # $3: chemin vers le fichier trigger failed_node=$1 new_master=$2 trigger_file=$3 # Ne rien faire si c'est le standby qui tombe if [ $failed_node = 1 ]; then exit 0; fi # Créer un fichier de déclenchement /usr/bin/ssh -T $new_master /bin/touch $trigger_file exit 0; chmod 755 failover_stream.sh
failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
standby_mode = 'on' primary_conninfo = 'host=nom_du_nœud_primaire user=postgres' trigger_file = '/tmp/trigger_file0'
wal_level = hot_standby max_wal_senders = 1
host replication postgres 192.168.0.10/32 trust
Démarrez PostgreSQL sur les nœuds primaire et secondaire pour initialiser la réplication. Si le nœud primaire venait à tomber, le nœud secondaire prendra automatiquement le relais, en tant que nouveau nœud primaire, et sera alors prêt à recevoir les requêtes en écriture.
Lorsqu'on utilise la Streaming Replication et le Hot Standby, il est important de déterminer les requêtes pouvant être envoyées sur le nœud principal ou sur le nœud en standby (secondaire), et les requêtes qui ne peuvent pas l'être. Le mode Streaming Replication de pgpool-II se charge complètement de cette problématique. Dans ce chapitre, nous expliquerons comment pgpool-II parvient à cela.
Nous distinguons les requêtes qui devraient être envoyées à tel ou tel nœud en les examinant.
Dans une transaction explicite :
Toute commande qui ne peut être exécutée sur un nœud en standby (secondaire) comme un INSERT sont envoyées uniquement au primaire. Après toute commande de ce type, absolument tous les ordres SQL sont envoyés au nœud primaire. En effet, les SELECT suivant pourraient vouloir voir les résultats d'un INSERT immédiatement. Ce comportement continue jusqu'à ce que la transaction se ferme ou soit interrompue.
Dans le protocole étendu, il est possible de déterminer si la requête peut être envoyée au nœud en standby ou pas dans le mode de répartition de charge au moment où on analyse la requête. Les rêgles sont les mêmes que dans le protocole non-étendu. Par exemple, les INSERT sont envoyés au primaire, ainsi que toute requête qui suivra.
Note : si l'analyse d'une requête en SELECT est envoyée sur le standby à cause de la répartition de charge et qu'une requête en modification de données, comme un INSERT est envoyé à pgpool-II, alors le SELECT analysé devra être exécuté sur le nœud primaire. Cependant, on analyse de nouveau le SELECT sur le nœud primaire.
Enfin, les requêtes qui semblent douteuses ou possiblement en erreur sont envoyées sur le nœud primaire.
Dans le mode maître/esclave avec la Streaming Replication, on peut procéder à une restauration à chaud (« Online recovery »). Cependant, seul un nœud en standby peut être ainsi récupéré. On ne peut pas reconstruire un nœud primaire. Pour ce faire, il faudra stopper toutes les bases de données, ainsi que pgpool-II, puis restaurer le nœud primaire à partir d'une sauvegarde.
Voici les étapes.
Un appel à la fonction de la libpq lo_creat() utilisera cette fonctionalité. De même, la création de « large objects » via l'API Java (driver JDBC) devrait fonctionner, tout comme l'API PHP (pg_lo_create, ou API similaire dans la bibliothèque de PHP, comme PDO), et ce genre d'API similaires dans plusieurs langages de programmation qui sont réputées pour utiliser un protocole similaire.
Les opérations suivantes de création d'un « large object » ne fonctionneront pas :
Peu importe le schéma où est stockée la table lobj_lock_table,
celle-ci doit en revanche être accessible en écriture à tous les utilisateurs.
Voici un exemple de création d'une telle table :
CREATE TABLE public.my_lock_table (); GRANT ALL ON public.my_lock_table TO PUBLIC;
La table spécifiée par lobj_lock_table doit être créée à
l'avance. Vous pouvez par exemple la créer dans la base template1
afin que toute base de données créée par la suite en dispose.
Si lobj_lock_table contient une chaîne vide (''),
la fonctionalité est désactivée. Du coup, la réplication des « large objects »
ne fonctionnera pas.
La valeur par défaut de ce paramètre est justement la chaîne vide ('').
Pré-requis pour la répartition de charge
Pour qu'une requête soit répartie, les pré-requis suivants doivent être respectés :
ignore_leading_white_space = true permettra
d'ignorer tous les éventuels espaces présents avant la requête.
Notez que vous pouvez interdire de manière explicite la répartition d'une charge sur une requête SELECT en ajoutant un commentaire au début de la requête SELECT (quel que ce soit ce commentaire). Par exemple :
/*REPLICATION*/ SELECT ...
Merci de lire attentivement la page replicate_select au sujet de la réplication. De même, étudiez attentivement ce schéma qui explique comment pgpool-II détermine à quel serveur PostgreSQL envoyer telle ou telle requête.
Attention : le connecteur JDBC a une option autocommit. Si autocommit est à
false, le connecteur JDBC envoie un BEGIN et un COMMIT
lui-même. Ainsi, pgpool-II ne pourra faire aucune répartition de charge. Vous devez
alors appeler setAutoCommit(true) pour activer
l'autocommit.
Failover dans le mode Réplication
pgpool-II désactive un serveur « mort » et le service continue, à condition qu'il y ait au moins un serveur PostgreSQL en vie.
Ce mode est utilisé lorsque pgpool-II est couplé avec un autre outil
de réplication de type maître/esclave(s) (comme Slony-I ou le Streaming
Réplication intégré à PostgreSQL). Cet outil est alors responsable de la
réplication des données.
L'information sur les serveurs PostgreSQL doit être renseignée (les paramètres
backend_hostname, backend_port, backend_weight et backend_data_directory),
de la même façon que dans le mode réplication.
De plus, il faut paramétrer master_slave_mode et
load_balance_mode à true.
pgpool-II enverra alors les requêtes qui doivent être répliquées au serveur
PostgreSQL maître, et les autres requêtes seront réparties parmi les différents
serveurs lorsque c'est possible.
L'algorithme de pgpool-II prend bien sûr en compte les requêtes qui ne peuvent être
réparties ; elles sont alors systématiquement envoyées au serveur maître.
Dans le mode maître-esclave, les DDL et DML pour une table temporaire ne
peuvent être exécutées que sur le serveur maître.
Vous pouvez forcer un SELECT à ne s'exécuter que sur le maître en ajoutant un
commentaire /*NO LOAD BALANCE*/ devant le SELECT.
Dans le mode maître-esclave, vous devez positionner
replication_mode à false et
master_slave_mode à true.
Le mode maître-esclave a un sous-mode piloté par le paramètre
'master_slave_sub_mode'. Il vaut par défaut
slony et convient si vous utilisez Slony-I.
Vous pouvez aussi le paramétrer à stream si
vous utilisez le système de réplication intégré à PostgreSQL (le
Streaming Replication).
Le fichier de configuration d'exemple pour le sous-mode Slony-I
est pgpool.conf.sample-master-slave, et celui
concernant la Streaming Replication est
pgpool.conf.sample-stream.
Vous devez redémarrer pgpool-II si vous changez l'un des paramètres vu précédemment.
Vous devrez probablement aussi renseigner les paramètres
white_function_list et
black_function_list si vous voulez contrôler plus finement
la répartition de charge dans le mode maître-esclave.
Reportez-vous à white_function_list
pour plus de détails.
Comme nous l'avons vu précédemment, pgpool-II peut fonctionner de pair avec la Streaming Replication, qui est disponible depuis la version 9.0 de PostgreSQL. Pour l'utiliser, il faut activer le paramètre master_slave et positionner le paramètre master_slave_sub_mode1 à stream. pgpool-II suppose que le Streaming Replication fonctionne et que les serveurs PostgreSQL esclaves sont en Hot Standby, ce qui signifie que les bases de données sont ouvertes en lecture seule sur ces derniers. Les directives suivantes peuvent être utilisées dans ce mode :
Permet de spécifier le décalage maximum toléré entre le serveur maître et
un serveur esclave dans une réplication, exprimé en octets de journaux de
transactions.
Si le décalage dépasse delay_threshold, pgpool-II n'envoie
alors plus de SELECT au serveur(s) esclave(s). Tout est alors envoyé au serveur
maître, même si la répartition de charge est activée, jusqu'à ce que le(s) serveur(s)
esclave(s) soit(soient) en deçà du décalage maximum autorisé.
Si delay_threshold est à 0 ou si le test
de vie est désactivé, ce test de décalage n'est jamais fait. Ce dernier est
effectué tous les health_check_period. La valeur par défaut
pour delay_threshold est 0.
Vous devez recharger la configuration de pgpool-II si vous changez cette
directive.
Permet de spécifier comment le décalage de réplication est tracé dans le
journal applicatif de pgpool-II. Si none est spécifié ici,
rien n'est écrit. Si always est spécifié, alors le décalage
sera tracé à chaque fois que le test est effectué.
Si if_over_threshold est spécifié, alors le décalage est
tracé uniquement lorsqu'il dépasse le delay_threshold.
La valeur par défaut pour log_standby_delay est
none.
Vous devez recharger la configuration de pgool-II si vous changez ce
paramètre.
Vous pouvez aussi superviser le décalage éventuel de la réplication en utilisant la commande "show pool_status".
Dans le mode maître/esclave avec la Streaming Replication, si le nœud primaire ou le nœud en attente s'arrête, pgpool-II peut être configuré pour exécuter un Failover. Les nœuds peuvent alors être attachés automatiquement sans configuration ou opérations complémentaires. Alors qu'il est en pleine réplication [~], le nœud en attente vérifie régulièrement si un fichier de déclenchement existe. S'il le trouve, le nœud en attente sort de son mode réplication et s'ouvre en mode lecture/écriture. En utilisant ce mécanisme, on peut avoir une base de données en attente qui prends le relais quand le nœud primaire tombe.
Attention : si vous pensez utiliser plusieurs nœuds en mode standby, il est recommandé de définir le paramètre delay_threshold pour empêcher tout requête dirigée vers d'autres nœuds en standby de récupérer des données plus vieilles.
Si un second nœud en standby prends le relais quand le premier nœud en standby avait déjà pris le relais, vous pourriez avoir des données erronnées en provenance du second standby. Nous vous recommandons de ne pas utiliser ce genre de configuration.
Voici commment configurer un mécanisme de Failover.
$ cd /usr/loca/pgsql/bin $ cat failover_stream.sh #! /bin/sh # Commandes pour faire un Failover en mode Streaming Replication # Ce script suppose que le nœud Maitre est le 0 et 1 le standby # # Si le Standby s'arrête, ne rien faire. Si le Primaire s'arrête, créer # un fichier de déclenchement afin que le standby prenne le relais sur le # nœud Primaire. # # Arguments: # $1: identifiant du nœud qui ne répond plus # $2: nom d'hôte du nouveau maître # $3: chemin vers le fichier trigger failed_node=$1 new_master=$2 trigger_file=$3 # Ne rien faire si c'est le standby qui tombe if [ $failed_node = 1 ]; then exit 0; fi # Créer un fichier de déclenchement /usr/bin/ssh -T $new_master /bin/touch $trigger_file exit 0; chmod 755 failover_stream.sh
failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
standby_mode = 'on' primary_conninfo = 'host=nom_du_nœud_primaire user=postgres' trigger_file = '/tmp/trigger_file0'
wal_level = hot_standby max_wal_senders = 1
host replication postgres 192.168.0.10/32 trust
Démarrez PostgreSQL sur les nœuds primaire et secondaire pour initialiser la réplication. Si le nœud primaire venait à tomber, le nœud secondaire prendra automatiquement le relais, en tant que nouveau nœud primaire, et sera alors prêt à recevoir les requêtes en écriture.
Lorsqu'on utilise la Streaming Replication et le Hot Standby, il est important de déterminer les requêtes pouvant être envoyées sur le nœud principal ou sur le nœud en standby (secondaire), et les requêtes qui ne peuvent pas l'être. Le mode Streaming Replication de pgpool-II se charge complètement de cette problématique. Dans ce chapitre, nous expliquerons comment pgpool-II parvient à cela.
Nous distinguons les requêtes qui devraient être envoyées à tel ou tel nœud en les examinant.
Dans une transaction explicite :
Toute commande qui ne peut être exécutée sur un nœud en standby (secondaire) comme un INSERT sont envoyées uniquement au primaire. Après toute commande de ce type, absolument tous les ordres SQL sont envoyés au nœud primaire. En effet, les SELECT suivant pourraient vouloir voir les résultats d'un INSERT immédiatement. Ce comportement continue jusqu'à ce que la transaction se ferme ou soit interrompue.
Dans le protocole étendu, il est possible de déterminer si la requête peut être envoyée au nœud en standby ou pas dans le mode de répartition de charge au moment où on analyse la requête. Les rêgles sont les mêmes que dans le protocole non-étendu. Par exemple, les INSERT sont envoyés au primaire, ainsi que toute requête qui suivra.
Note : si l'analyse d'une requête en SELECT est envoyée sur le standby à cause de la répartition de charge et qu'une requête en modification de données, comme un INSERT est envoyé à pgpool-II, alors le SELECT analysé devra être exécuté sur le nœud primaire. Cependant, on analyse de nouveau le SELECT sur le nœud primaire.
Enfin, les requêtes qui semblent douteuses ou possiblement en erreur sont envoyées sur le nœud primaire.
Dans le mode maître/esclave avec la Streaming Replication, on peut procéder à une restauration à chaud (« Online recovery »). Cependant, seul un nœud en standby peut être ainsi récupéré. On ne peut pas reconstruire un nœud primaire. Pour ce faire, il faudra stopper toutes les bases de données, ainsi que pgpool-II, puis restaurer le nœud primaire à partir d'une sauvegarde.
Voici les étapes.
Un appel à la fonction de la libpq lo_creat() utilisera cette fonctionalité. De même, la création de « large objects » via l'API Java (driver JDBC) devrait fonctionner, tout comme l'API PHP (pg_lo_create, ou API similaire dans la bibliothèque de PHP, comme PDO), et ce genre d'API similaires dans plusieurs langages de programmation qui sont réputées pour utiliser un protocole similaire.
Les opérations suivantes de création d'un « large object » ne fonctionneront pas :
Peu importe le schéma où est stockée la table lobj_lock_table,
celle-ci doit en revanche être accessible en écriture à tous les utilisateurs.
Voici un exemple de création d'une telle table :
CREATE TABLE public.my_lock_table (); GRANT ALL ON public.my_lock_table TO PUBLIC;
La table spécifiée par lobj_lock_table doit être créée à
l'avance. Vous pouvez par exemple la créer dans la base template1
afin que toute base de données créée par la suite en dispose.
Si lobj_lock_table contient une chaîne vide (''),
la fonctionalité est désactivée. Du coup, la réplication des « large objects »
ne fonctionnera pas.
La valeur par défaut de ce paramètre est justement la chaîne vide ('').
Pré-requis pour la répartition de charge
Pour qu'une requête soit répartie, les pré-requis suivants doivent être respectés :
ignore_leading_white_space = true permettra
d'ignorer tous les éventuels espaces présents avant la requête.
Notez que vous pouvez interdire de manière explicite la répartition d'une charge sur une requête SELECT en ajoutant un commentaire au début de la requête SELECT (quel que ce soit ce commentaire). Par exemple :
/*REPLICATION*/ SELECT ...
Merci de lire attentivement la page replicate_select au sujet de la réplication. De même, étudiez attentivement ce schéma qui explique comment pgpool-II détermine à quel serveur PostgreSQL envoyer telle ou telle requête.
Attention : le connecteur JDBC a une option autocommit. Si autocommit est à
false, le connecteur JDBC envoie un BEGIN et un COMMIT
lui-même. Ainsi, pgpool-II ne pourra faire aucune répartition de charge. Vous devez
alors appeler setAutoCommit(true) pour activer
l'autocommit.
Failover dans le mode Réplication
pgpool-II désactive un serveur « mort » et le service continue, à condition qu'il y ait au moins un serveur PostgreSQL en vie.
Ce mode est utilisé lorsque pgpool-II est couplé avec un autre outil
de réplication de type maître/esclave(s) (comme Slony-I ou le Streaming
Réplication intégré à PostgreSQL). Cet outil est alors responsable de la
réplication des données.
L'information sur les serveurs PostgreSQL doit être renseignée (les paramètres
backend_hostname, backend_port, backend_weight et backend_data_directory),
de la même façon que dans le mode réplication.
De plus, il faut paramétrer master_slave_mode et
load_balance_mode à true.
pgpool-II enverra alors les requêtes qui doivent être répliquées au serveur
PostgreSQL maître, et les autres requêtes seront réparties parmi les différents
serveurs lorsque c'est possible.
L'algorithme de pgpool-II prend bien sûr en compte les requêtes qui ne peuvent être
réparties ; elles sont alors systématiquement envoyées au serveur maître.
Dans le mode maître-esclave, les DDL et DML pour une table temporaire ne
peuvent être exécutées que sur le serveur maître.
Vous pouvez forcer un SELECT à ne s'exécuter que sur le maître en ajoutant un
commentaire /*NO LOAD BALANCE*/ devant le SELECT.
Dans le mode maître-esclave, vous devez positionner
replication_mode à false et
master_slave_mode à true.
Le mode maître-esclave a un sous-mode piloté par le paramètre
'master_slave_sub_mode'. Il vaut par défaut
slony et convient si vous utilisez Slony-I.
Vous pouvez aussi le paramétrer à stream si
vous utilisez le système de réplication intégré à PostgreSQL (le
Streaming Replication).
Le fichier de configuration d'exemple pour le sous-mode Slony-I
est pgpool.conf.sample-master-slave, et celui
concernant la Streaming Replication est
pgpool.conf.sample-stream.
Vous devez redémarrer pgpool-II si vous changez l'un des paramètres vu précédemment.
Vous devrez probablement aussi renseigner les paramètres
white_function_list et
black_function_list si vous voulez contrôler plus finement
la répartition de charge dans le mode maître-esclave.
Reportez-vous à white_function_list
pour plus de détails.
Comme nous l'avons vu précédemment, pgpool-II peut fonctionner de pair avec la Streaming Replication, qui est disponible depuis la version 9.0 de PostgreSQL. Pour l'utiliser, il faut activer le paramètre master_slave et positionner le paramètre master_slave_sub_mode1 à stream. pgpool-II suppose que le Streaming Replication fonctionne et que les serveurs PostgreSQL esclaves sont en Hot Standby, ce qui signifie que les bases de données sont ouvertes en lecture seule sur ces derniers. Les directives suivantes peuvent être utilisées dans ce mode :
Permet de spécifier le décalage maximum toléré entre le serveur maître et
un serveur esclave dans une réplication, exprimé en octets de journaux de
transactions.
Si le décalage dépasse delay_threshold, pgpool-II n'envoie
alors plus de SELECT au serveur(s) esclave(s). Tout est alors envoyé au serveur
maître, même si la répartition de charge est activée, jusqu'à ce que le(s) serveur(s)
esclave(s) soit(soient) en deçà du décalage maximum autorisé.
Si delay_threshold est à 0 ou si le test
de vie est désactivé, ce test de décalage n'est jamais fait. Ce dernier est
effectué tous les health_check_period. La valeur par défaut
pour delay_threshold est 0.
Vous devez recharger la configuration de pgpool-II si vous changez cette
directive.
Permet de spécifier comment le décalage de réplication est tracé dans le
journal applicatif de pgpool-II. Si none est spécifié ici,
rien n'est écrit. Si always est spécifié, alors le décalage
sera tracé à chaque fois que le test est effectué.
Si if_over_threshold est spécifié, alors le décalage est
tracé uniquement lorsqu'il dépasse le delay_threshold.
La valeur par défaut pour log_standby_delay est
none.
Vous devez recharger la configuration de pgool-II si vous changez ce
paramètre.
Vous pouvez aussi superviser le décalage éventuel de la réplication en utilisant la commande "show pool_status".
Dans le mode maître/esclave avec la Streaming Replication, si le nœud primaire ou le nœud en attente s'arrête, pgpool-II peut être configuré pour exécuter un Failover. Les nœuds peuvent alors être attachés automatiquement sans configuration ou opérations complémentaires. Alors qu'il est en pleine réplication [~], le nœud en attente vérifie régulièrement si un fichier de déclenchement existe. S'il le trouve, le nœud en attente sort de son mode réplication et s'ouvre en mode lecture/écriture. En utilisant ce mécanisme, on peut avoir une base de données en attente qui prends le relais quand le nœud primaire tombe.
Attention : si vous pensez utiliser plusieurs nœuds en mode standby, il est recommandé de définir le paramètre delay_threshold pour empêcher tout requête dirigée vers d'autres nœuds en standby de récupérer des données plus vieilles.
Si un second nœud en standby prends le relais quand le premier nœud en standby avait déjà pris le relais, vous pourriez avoir des données erronnées en provenance du second standby. Nous vous recommandons de ne pas utiliser ce genre de configuration.
Voici commment configurer un mécanisme de Failover.
$ cd /usr/loca/pgsql/bin $ cat failover_stream.sh #! /bin/sh # Commandes pour faire un Failover en mode Streaming Replication # Ce script suppose que le nœud Maitre est le 0 et 1 le standby # # Si le Standby s'arrête, ne rien faire. Si le Primaire s'arrête, créer # un fichier de déclenchement afin que le standby prenne le relais sur le # nœud Primaire. # # Arguments: # $1: identifiant du nœud qui ne répond plus # $2: nom d'hôte du nouveau maître # $3: chemin vers le fichier trigger failed_node=$1 new_master=$2 trigger_file=$3 # Ne rien faire si c'est le standby qui tombe if [ $failed_node = 1 ]; then exit 0; fi # Créer un fichier de déclenchement /usr/bin/ssh -T $new_master /bin/touch $trigger_file exit 0; chmod 755 failover_stream.sh
failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
standby_mode = 'on' primary_conninfo = 'host=nom_du_nœud_primaire user=postgres' trigger_file = '/tmp/trigger_file0'
wal_level = hot_standby max_wal_senders = 1
host replication postgres 192.168.0.10/32 trust
Démarrez PostgreSQL sur les nœuds primaire et secondaire pour initialiser la réplication. Si le nœud primaire venait à tomber, le nœud secondaire prendra automatiquement le relais, en tant que nouveau nœud primaire, et sera alors prêt à recevoir les requêtes en écriture.
Lorsqu'on utilise la Streaming Replication et le Hot Standby, il est important de déterminer les requêtes pouvant être envoyées sur le nœud principal ou sur le nœud en standby (secondaire), et les requêtes qui ne peuvent pas l'être. Le mode Streaming Replication de pgpool-II se charge complètement de cette problématique. Dans ce chapitre, nous expliquerons comment pgpool-II parvient à cela.
Nous distinguons les requêtes qui devraient être envoyées à tel ou tel nœud en les examinant.
Dans une transaction explicite :
Toute commande qui ne peut être exécutée sur un nœud en standby (secondaire) comme un INSERT sont envoyées uniquement au primaire. Après toute commande de ce type, absolument tous les ordres SQL sont envoyés au nœud primaire. En effet, les SELECT suivant pourraient vouloir voir les résultats d'un INSERT immédiatement. Ce comportement continue jusqu'à ce que la transaction se ferme ou soit interrompue.
Dans le protocole étendu, il est possible de déterminer si la requête peut être envoyée au nœud en standby ou pas dans le mode de répartition de charge au moment où on analyse la requête. Les rêgles sont les mêmes que dans le protocole non-étendu. Par exemple, les INSERT sont envoyés au primaire, ainsi que toute requête qui suivra.
Note : si l'analyse d'une requête en SELECT est envoyée sur le standby à cause de la répartition de charge et qu'une requête en modification de données, comme un INSERT est envoyé à pgpool-II, alors le SELECT analysé devra être exécuté sur le nœud primaire. Cependant, on analyse de nouveau le SELECT sur le nœud primaire.
Enfin, les requêtes qui semblent douteuses ou possiblement en erreur sont envoyées sur le nœud primaire.
Dans le mode maître/esclave avec la Streaming Replication, on peut procéder à une restauration à chaud (« Online recovery »). Cependant, seul un nœud en standby peut être ainsi récupéré. On ne peut pas reconstruire un nœud primaire. Pour ce faire, il faudra stopper toutes les bases de données, ainsi que pgpool-II, puis restaurer le nœud primaire à partir d'une sauvegarde.
Voici les étapes.
Un appel à la fonction de la libpq lo_creat() utilisera cette fonctionalité. De même, la création de « large objects » via l'API Java (driver JDBC) devrait fonctionner, tout comme l'API PHP (pg_lo_create, ou API similaire dans la bibliothèque de PHP, comme PDO), et ce genre d'API similaires dans plusieurs langages de programmation qui sont réputées pour utiliser un protocole similaire.
Les opérations suivantes de création d'un « large object » ne fonctionneront pas :
Peu importe le schéma où est stockée la table lobj_lock_table,
celle-ci doit en revanche être accessible en écriture à tous les utilisateurs.
Voici un exemple de création d'une telle table :
CREATE TABLE public.my_lock_table (); GRANT ALL ON public.my_lock_table TO PUBLIC;
La table spécifiée par lobj_lock_table doit être créée à
l'avance. Vous pouvez par exemple la créer dans la base template1
afin que toute base de données créée par la suite en dispose.
Si lobj_lock_table contient une chaîne vide (''),
la fonctionalité est désactivée. Du coup, la réplication des « large objects »
ne fonctionnera pas.
La valeur par défaut de ce paramètre est justement la chaîne vide ('').
Pré-requis pour la répartition de charge
Pour qu'une requête soit répartie, les pré-requis suivants doivent être respectés :
ignore_leading_white_space = true permettra
d'ignorer tous les éventuels espaces présents avant la requête.
Notez que vous pouvez interdire de manière explicite la répartition d'une charge sur une requête SELECT en ajoutant un commentaire au début de la requête SELECT (quel que ce soit ce commentaire). Par exemple :
/*REPLICATION*/ SELECT ...
Merci de lire attentivement la page replicate_select au sujet de la réplication. De même, étudiez attentivement ce schéma qui explique comment pgpool-II détermine à quel serveur PostgreSQL envoyer telle ou telle requête.
Attention : le connecteur JDBC a une option autocommit. Si autocommit est à
false, le connecteur JDBC envoie un BEGIN et un COMMIT
lui-même. Ainsi, pgpool-II ne pourra faire aucune répartition de charge. Vous devez
alors appeler setAutoCommit(true) pour activer
l'autocommit.
Failover dans le mode Réplication
pgpool-II désactive un serveur « mort » et le service continue, à condition qu'il y ait au moins un serveur PostgreSQL en vie.
Ce mode est utilisé lorsque pgpool-II est couplé avec un autre outil
de réplication de type maître/esclave(s) (comme Slony-I ou le Streaming
Réplication intégré à PostgreSQL). Cet outil est alors responsable de la
réplication des données.
L'information sur les serveurs PostgreSQL doit être renseignée (les paramètres
backend_hostname, backend_port, backend_weight et backend_data_directory),
de la même façon que dans le mode réplication.
De plus, il faut paramétrer master_slave_mode et
load_balance_mode à true.
pgpool-II enverra alors les requêtes qui doivent être répliquées au serveur
PostgreSQL maître, et les autres requêtes seront réparties parmi les différents
serveurs lorsque c'est possible.
L'algorithme de pgpool-II prend bien sûr en compte les requêtes qui ne peuvent être
réparties ; elles sont alors systématiquement envoyées au serveur maître.
Dans le mode maître-esclave, les DDL et DML pour une table temporaire ne
peuvent être exécutées que sur le serveur maître.
Vous pouvez forcer un SELECT à ne s'exécuter que sur le maître en ajoutant un
commentaire /*NO LOAD BALANCE*/ devant le SELECT.
Dans le mode maître-esclave, vous devez positionner
replication_mode à false et
master_slave_mode à true.
Le mode maître-esclave a un sous-mode piloté par le paramètre
'master_slave_sub_mode'. Il vaut par défaut
slony et convient si vous utilisez Slony-I.
Vous pouvez aussi le paramétrer à stream si
vous utilisez le système de réplication intégré à PostgreSQL (le
Streaming Replication).
Le fichier de configuration d'exemple pour le sous-mode Slony-I
est pgpool.conf.sample-master-slave, et celui
concernant la Streaming Replication est
pgpool.conf.sample-stream.
Vous devez redémarrer pgpool-II si vous changez l'un des paramètres vu précédemment.
Vous devrez probablement aussi renseigner les paramètres
white_function_list et
black_function_list si vous voulez contrôler plus finement
la répartition de charge dans le mode maître-esclave.
Reportez-vous à white_function_list
pour plus de détails.
Comme nous l'avons vu précédemment, pgpool-II peut fonctionner de pair avec la Streaming Replication, qui est disponible depuis la version 9.0 de PostgreSQL. Pour l'utiliser, il faut activer le paramètre master_slave et positionner le paramètre master_slave_sub_mode1 à stream. pgpool-II suppose que le Streaming Replication fonctionne et que les serveurs PostgreSQL esclaves sont en Hot Standby, ce qui signifie que les bases de données sont ouvertes en lecture seule sur ces derniers. Les directives suivantes peuvent être utilisées dans ce mode :
Permet de spécifier le décalage maximum toléré entre le serveur maître et
un serveur esclave dans une réplication, exprimé en octets de journaux de
transactions.
Si le décalage dépasse delay_threshold, pgpool-II n'envoie
alors plus de SELECT au serveur(s) esclave(s). Tout est alors envoyé au serveur
maître, même si la répartition de charge est activée, jusqu'à ce que le(s) serveur(s)
esclave(s) soit(soient) en deçà du décalage maximum autorisé.
Si delay_threshold est à 0 ou si le test
de vie est désactivé, ce test de décalage n'est jamais fait. Ce dernier est
effectué tous les health_check_period. La valeur par défaut
pour delay_threshold est 0.
Vous devez recharger la configuration de pgpool-II si vous changez cette
directive.
Permet de spécifier comment le décalage de réplication est tracé dans le
journal applicatif de pgpool-II. Si none est spécifié ici,
rien n'est écrit. Si always est spécifié, alors le décalage
sera tracé à chaque fois que le test est effectué.
Si if_over_threshold est spécifié, alors le décalage est
tracé uniquement lorsqu'il dépasse le delay_threshold.
La valeur par défaut pour log_standby_delay est
none.
Vous devez recharger la configuration de pgool-II si vous changez ce
paramètre.
Vous pouvez aussi superviser le décalage éventuel de la réplication en utilisant la commande "show pool_status".
Dans le mode maître/esclave avec la Streaming Replication, si le nœud primaire ou le nœud en attente s'arrête, pgpool-II peut être configuré pour exécuter un Failover. Les nœuds peuvent alors être attachés automatiquement sans configuration ou opérations complémentaires. Alors qu'il est en pleine réplication [~], le nœud en attente vérifie régulièrement si un fichier de déclenchement existe. S'il le trouve, le nœud en attente sort de son mode réplication et s'ouvre en mode lecture/écriture. En utilisant ce mécanisme, on peut avoir une base de données en attente qui prends le relais quand le nœud primaire tombe.
Attention : si vous pensez utiliser plusieurs nœuds en mode standby, il est recommandé de définir le paramètre delay_threshold pour empêcher tout requête dirigée vers d'autres nœuds en standby de récupérer des données plus vieilles.
Si un second nœud en standby prends le relais quand le premier nœud en standby avait déjà pris le relais, vous pourriez avoir des données erronnées en provenance du second standby. Nous vous recommandons de ne pas utiliser ce genre de configuration.
Voici commment configurer un mécanisme de Failover.
$ cd /usr/loca/pgsql/bin $ cat failover_stream.sh #! /bin/sh # Commandes pour faire un Failover en mode Streaming Replication # Ce script suppose que le nœud Maitre est le 0 et 1 le standby # # Si le Standby s'arrête, ne rien faire. Si le Primaire s'arrête, créer # un fichier de déclenchement afin que le standby prenne le relais sur le # nœud Primaire. # # Arguments: # $1: identifiant du nœud qui ne répond plus # $2: nom d'hôte du nouveau maître # $3: chemin vers le fichier trigger failed_node=$1 new_master=$2 trigger_file=$3 # Ne rien faire si c'est le standby qui tombe if [ $failed_node = 1 ]; then exit 0; fi # Créer un fichier de déclenchement /usr/bin/ssh -T $new_master /bin/touch $trigger_file exit 0; chmod 755 failover_stream.sh
failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
standby_mode = 'on' primary_conninfo = 'host=nom_du_nœud_primaire user=postgres' trigger_file = '/tmp/trigger_file0'
wal_level = hot_standby max_wal_senders = 1
host replication postgres 192.168.0.10/32 trust
Démarrez PostgreSQL sur les nœuds primaire et secondaire pour initialiser la réplication. Si le nœud primaire venait à tomber, le nœud secondaire prendra automatiquement le relais, en tant que nouveau nœud primaire, et sera alors prêt à recevoir les requêtes en écriture.
Lorsqu'on utilise la Streaming Replication et le Hot Standby, il est important de déterminer les requêtes pouvant être envoyées sur le nœud principal ou sur le nœud en standby (secondaire), et les requêtes qui ne peuvent pas l'être. Le mode Streaming Replication de pgpool-II se charge complètement de cette problématique. Dans ce chapitre, nous expliquerons comment pgpool-II parvient à cela.
Nous distinguons les requêtes qui devraient être envoyées à tel ou tel nœud en les examinant.
Dans une transaction explicite :
Toute commande qui ne peut être exécutée sur un nœud en standby (secondaire) comme un INSERT sont envoyées uniquement au primaire. Après toute commande de ce type, absolument tous les ordres SQL sont envoyés au nœud primaire. En effet, les SELECT suivant pourraient vouloir voir les résultats d'un INSERT immédiatement. Ce comportement continue jusqu'à ce que la transaction se ferme ou soit interrompue.
Dans le protocole étendu, il est possible de déterminer si la requête peut être envoyée au nœud en standby ou pas dans le mode de répartition de charge au moment où on analyse la requête. Les rêgles sont les mêmes que dans le protocole non-étendu. Par exemple, les INSERT sont envoyés au primaire, ainsi que toute requête qui suivra.
Note : si l'analyse d'une requête en SELECT est envoyée sur le standby à cause de la répartition de charge et qu'une requête en modification de données, comme un INSERT est envoyé à pgpool-II, alors le SELECT analysé devra être exécuté sur le nœud primaire. Cependant, on analyse de nouveau le SELECT sur le nœud primaire.
Enfin, les requêtes qui semblent douteuses ou possiblement en erreur sont envoyées sur le nœud primaire.
Dans le mode maître/esclave avec la Streaming Replication, on peut procéder à une restauration à chaud (« Online recovery »). Cependant, seul un nœud en standby peut être ainsi récupéré. On ne peut pas reconstruire un nœud primaire. Pour ce faire, il faudra stopper toutes les bases de données, ainsi que pgpool-II, puis restaurer le nœud primaire à partir d'une sauvegarde.
Voici les étapes.
Un appel à la fonction de la libpq lo_creat() utilisera cette fonctionalité. De même, la création de « large objects » via l'API Java (driver JDBC) devrait fonctionner, tout comme l'API PHP (pg_lo_create, ou API similaire dans la bibliothèque de PHP, comme PDO), et ce genre d'API similaires dans plusieurs langages de programmation qui sont réputées pour utiliser un protocole similaire.
Les opérations suivantes de création d'un « large object » ne fonctionneront pas :
Peu importe le schéma où est stockée la table lobj_lock_table,
celle-ci doit en revanche être accessible en écriture à tous les utilisateurs.
Voici un exemple de création d'une telle table :
CREATE TABLE public.my_lock_table (); GRANT ALL ON public.my_lock_table TO PUBLIC;
La table spécifiée par lobj_lock_table doit être créée à
l'avance. Vous pouvez par exemple la créer dans la base template1
afin que toute base de données créée par la suite en dispose.
Si lobj_lock_table contient une chaîne vide (''),
la fonctionalité est désactivée. Du coup, la réplication des « large objects »
ne fonctionnera pas.
La valeur par défaut de ce paramètre est justement la chaîne vide ('').
Pré-requis pour la répartition de charge
Pour qu'une requête soit répartie, les pré-requis suivants doivent être respectés :
ignore_leading_white_space = true permettra
d'ignorer tous les éventuels espaces présents avant la requête.
Notez que vous pouvez interdire de manière explicite la répartition d'une charge sur une requête SELECT en ajoutant un commentaire au début de la requête SELECT (quel que ce soit ce commentaire). Par exemple :
/*REPLICATION*/ SELECT ...
Merci de lire attentivement la page replicate_select au sujet de la réplication. De même, étudiez attentivement ce schéma qui explique comment pgpool-II détermine à quel serveur PostgreSQL envoyer telle ou telle requête.
Attention : le connecteur JDBC a une option autocommit. Si autocommit est à
false, le connecteur JDBC envoie un BEGIN et un COMMIT
lui-même. Ainsi, pgpool-II ne pourra faire aucune répartition de charge. Vous devez
alors appeler setAutoCommit(true) pour activer
l'autocommit.
Failover dans le mode Réplication
pgpool-II désactive un serveur « mort » et le service continue, à condition qu'il y ait au moins un serveur PostgreSQL en vie.
Ce mode est utilisé lorsque pgpool-II est couplé avec un autre outil
de réplication de type maître/esclave(s) (comme Slony-I ou le Streaming
Réplication intégré à PostgreSQL). Cet outil est alors responsable de la
réplication des données.
L'information sur les serveurs PostgreSQL doit être renseignée (les paramètres
backend_hostname, backend_port, backend_weight et backend_data_directory),
de la même façon que dans le mode réplication.
De plus, il faut paramétrer master_slave_mode et
load_balance_mode à true.
pgpool-II enverra alors les requêtes qui doivent être répliquées au serveur
PostgreSQL maître, et les autres requêtes seront réparties parmi les différents
serveurs lorsque c'est possible.
L'algorithme de pgpool-II prend bien sûr en compte les requêtes qui ne peuvent être
réparties ; elles sont alors systématiquement envoyées au serveur maître.
Dans le mode maître-esclave, les DDL et DML pour une table temporaire ne
peuvent être exécutées que sur le serveur maître.
Vous pouvez forcer un SELECT à ne s'exécuter que sur le maître en ajoutant un
commentaire /*NO LOAD BALANCE*/ devant le SELECT.
Dans le mode maître-esclave, vous devez positionner
replication_mode à false et
master_slave_mode à true.
Le mode maître-esclave a un sous-mode piloté par le paramètre
'master_slave_sub_mode'. Il vaut par défaut
slony et convient si vous utilisez Slony-I.
Vous pouvez aussi le paramétrer à stream si
vous utilisez le système de réplication intégré à PostgreSQL (le
Streaming Replication).
Le fichier de configuration d'exemple pour le sous-mode Slony-I
est pgpool.conf.sample-master-slave, et celui
concernant la Streaming Replication est
pgpool.conf.sample-stream.
Vous devez redémarrer pgpool-II si vous changez l'un des paramètres vu précédemment.
Vous devrez probablement aussi renseigner les paramètres
white_function_list et
black_function_list si vous voulez contrôler plus finement
la répartition de charge dans le mode maître-esclave.
Reportez-vous à white_function_list
pour plus de détails.
Comme nous l'avons vu précédemment, pgpool-II peut fonctionner de pair avec la Streaming Replication, qui est disponible depuis la version 9.0 de PostgreSQL. Pour l'utiliser, il faut activer le paramètre master_slave et positionner le paramètre master_slave_sub_mode1 à stream. pgpool-II suppose que le Streaming Replication fonctionne et que les serveurs PostgreSQL esclaves sont en Hot Standby, ce qui signifie que les bases de données sont ouvertes en lecture seule sur ces derniers. Les directives suivantes peuvent être utilisées dans ce mode :
Permet de spécifier le décalage maximum toléré entre le serveur maître et
un serveur esclave dans une réplication, exprimé en octets de journaux de
transactions.
Si le décalage dépasse delay_threshold, pgpool-II n'envoie
alors plus de SELECT au serveur(s) esclave(s). Tout est alors envoyé au serveur
maître, même si la répartition de charge est activée, jusqu'à ce que le(s) serveur(s)
esclave(s) soit(soient) en deçà du décalage maximum autorisé.
Si delay_threshold est à 0 ou si le test
de vie est désactivé, ce test de décalage n'est jamais fait. Ce dernier est
effectué tous les health_check_period. La valeur par défaut
pour delay_threshold est 0.
Vous devez recharger la configuration de pgpool-II si vous changez cette
directive.
Permet de spécifier comment le décalage de réplication est tracé dans le
journal applicatif de pgpool-II. Si none est spécifié ici,
rien n'est écrit. Si always est spécifié, alors le décalage
sera tracé à chaque fois que le test est effectué.
Si if_over_threshold est spécifié, alors le décalage est
tracé uniquement lorsqu'il dépasse le delay_threshold.
La valeur par défaut pour log_standby_delay est
none.
Vous devez recharger la configuration de pgool-II si vous changez ce
paramètre.
Vous pouvez aussi superviser le décalage éventuel de la réplication en utilisant la commande "show pool_status".
Dans le mode maître/esclave avec la Streaming Replication, si le nœud primaire ou le nœud en attente s'arrête, pgpool-II peut être configuré pour exécuter un Failover. Les nœuds peuvent alors être attachés automatiquement sans configuration ou opérations complémentaires. Alors qu'il est en pleine réplication [~], le nœud en attente vérifie régulièrement si un fichier de déclenchement existe. S'il le trouve, le nœud en attente sort de son mode réplication et s'ouvre en mode lecture/écriture. En utilisant ce mécanisme, on peut avoir une base de données en attente qui prends le relais quand le nœud primaire tombe.
Attention : si vous pensez utiliser plusieurs nœuds en mode standby, il est recommandé de définir le paramètre delay_threshold pour empêcher tout requête dirigée vers d'autres nœuds en standby de récupérer des données plus vieilles.
Si un second nœud en standby prends le relais quand le premier nœud en standby avait déjà pris le relais, vous pourriez avoir des données erronnées en provenance du second standby. Nous vous recommandons de ne pas utiliser ce genre de configuration.
Voici commment configurer un mécanisme de Failover.
$ cd /usr/loca/pgsql/bin $ cat failover_stream.sh #! /bin/sh # Commandes pour faire un Failover en mode Streaming Replication # Ce script suppose que le nœud Maitre est le 0 et 1 le standby # # Si le Standby s'arrête, ne rien faire. Si le Primaire s'arrête, créer # un fichier de déclenchement afin que le standby prenne le relais sur le # nœud Primaire. # # Arguments: # $1: identifiant du nœud qui ne répond plus # $2: nom d'hôte du nouveau maître # $3: chemin vers le fichier trigger failed_node=$1 new_master=$2 trigger_file=$3 # Ne rien faire si c'est le standby qui tombe if [ $failed_node = 1 ]; then exit 0; fi # Créer un fichier de déclenchement /usr/bin/ssh -T $new_master /bin/touch $trigger_file exit 0; chmod 755 failover_stream.sh
failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
standby_mode = 'on' primary_conninfo = 'host=nom_du_nœud_primaire user=postgres' trigger_file = '/tmp/trigger_file0'
wal_level = hot_standby max_wal_senders = 1
host replication postgres 192.168.0.10/32 trust
Démarrez PostgreSQL sur les nœuds primaire et secondaire pour initialiser la réplication. Si le nœud primaire venait à tomber, le nœud secondaire prendra automatiquement le relais, en tant que nouveau nœud primaire, et sera alors prêt à recevoir les requêtes en écriture.
Lorsqu'on utilise la Streaming Replication et le Hot Standby, il est important de déterminer les requêtes pouvant être envoyées sur le nœud principal ou sur le nœud en standby (secondaire), et les requêtes qui ne peuvent pas l'être. Le mode Streaming Replication de pgpool-II se charge complètement de cette problématique. Dans ce chapitre, nous expliquerons comment pgpool-II parvient à cela.
Nous distinguons les requêtes qui devraient être envoyées à tel ou tel nœud en les examinant.
Dans une transaction explicite :
Toute commande qui ne peut être exécutée sur un nœud en standby (secondaire) comme un INSERT sont envoyées uniquement au primaire. Après toute commande de ce type, absolument tous les ordres SQL sont envoyés au nœud primaire. En effet, les SELECT suivant pourraient vouloir voir les résultats d'un INSERT immédiatement. Ce comportement continue jusqu'à ce que la transaction se ferme ou soit interrompue.
Dans le protocole étendu, il est possible de déterminer si la requête peut être envoyée au nœud en standby ou pas dans le mode de répartition de charge au moment où on analyse la requête. Les rêgles sont les mêmes que dans le protocole non-étendu. Par exemple, les INSERT sont envoyés au primaire, ainsi que toute requête qui suivra.
Note : si l'analyse d'une requête en SELECT est envoyée sur le standby à cause de la répartition de charge et qu'une requête en modification de données, comme un INSERT est envoyé à pgpool-II, alors le SELECT analysé devra être exécuté sur le nœud primaire. Cependant, on analyse de nouveau le SELECT sur le nœud primaire.
Enfin, les requêtes qui semblent douteuses ou possiblement en erreur sont envoyées sur le nœud primaire.
Dans le mode maître/esclave avec la Streaming Replication, on peut procéder à une restauration à chaud (« Online recovery »). Cependant, seul un nœud en standby peut être ainsi récupéré. On ne peut pas reconstruire un nœud primaire. Pour ce faire, il faudra stopper toutes les bases de données, ainsi que pgpool-II, puis restaurer le nœud primaire à partir d'une sauvegarde.
Voici les étapes.
Un appel à la fonction de la libpq lo_creat() utilisera cette fonctionalité. De même, la création de « large objects » via l'API Java (driver JDBC) devrait fonctionner, tout comme l'API PHP (pg_lo_create, ou API similaire dans la bibliothèque de PHP, comme PDO), et ce genre d'API similaires dans plusieurs langages de programmation qui sont réputées pour utiliser un protocole similaire.
Les opérations suivantes de création d'un « large object » ne fonctionneront pas :
Peu importe le schéma où est stockée la table lobj_lock_table,
celle-ci doit en revanche être accessible en écriture à tous les utilisateurs.
Voici un exemple de création d'une telle table :
CREATE TABLE public.my_lock_table (); GRANT ALL ON public.my_lock_table TO PUBLIC;
La table spécifiée par lobj_lock_table doit être créée à
l'avance. Vous pouvez par exemple la créer dans la base template1
afin que toute base de données créée par la suite en dispose.
Si lobj_lock_table contient une chaîne vide (''),
la fonctionalité est désactivée. Du coup, la réplication des « large objects »
ne fonctionnera pas.
La valeur par défaut de ce paramètre est justement la chaîne vide ('').
Pré-requis pour la répartition de charge
Pour qu'une requête soit répartie, les pré-requis suivants doivent être respectés :
ignore_leading_white_space = true permettra
d'ignorer tous les éventuels espaces présents avant la requête.
Notez que vous pouvez interdire de manière explicite la répartition d'une charge sur une requête SELECT en ajoutant un commentaire au début de la requête SELECT (quel que ce soit ce commentaire). Par exemple :
/*REPLICATION*/ SELECT ...
Merci de lire attentivement la page replicate_select au sujet de la réplication. De même, étudiez attentivement ce schéma qui explique comment pgpool-II détermine à quel serveur PostgreSQL envoyer telle ou telle requête.
Attention : le connecteur JDBC a une option autocommit. Si autocommit est à
false, le connecteur JDBC envoie un BEGIN et un COMMIT
lui-même. Ainsi, pgpool-II ne pourra faire aucune répartition de charge. Vous devez
alors appeler setAutoCommit(true) pour activer
l'autocommit.
Failover dans le mode Réplication
pgpool-II désactive un serveur « mort » et le service continue, à condition qu'il y ait au moins un serveur PostgreSQL en vie.
Ce mode est utilisé lorsque pgpool-II est couplé avec un autre outil
de réplication de type maître/esclave(s) (comme Slony-I ou le Streaming
Réplication intégré à PostgreSQL). Cet outil est alors responsable de la
réplication des données.
L'information sur les serveurs PostgreSQL doit être renseignée (les paramètres
backend_hostname, backend_port, backend_weight et backend_data_directory),
de la même façon que dans le mode réplication.
De plus, il faut paramétrer master_slave_mode et
load_balance_mode à true.
pgpool-II enverra alors les requêtes qui doivent être répliquées au serveur
PostgreSQL maître, et les autres requêtes seront réparties parmi les différents
serveurs lorsque c'est possible.
L'algorithme de pgpool-II prend bien sûr en compte les requêtes qui ne peuvent être
réparties ; elles sont alors systématiquement envoyées au serveur maître.
Dans le mode maître-esclave, les DDL et DML pour une table temporaire ne
peuvent être exécutées que sur le serveur maître.
Vous pouvez forcer un SELECT à ne s'exécuter que sur le maître en ajoutant un
commentaire /*NO LOAD BALANCE*/ devant le SELECT.
Dans le mode maître-esclave, vous devez positionner
replication_mode à false et
master_slave_mode à true.
Le mode maître-esclave a un sous-mode piloté par le paramètre
'master_slave_sub_mode'. Il vaut par défaut
slony et convient si vous utilisez Slony-I.
Vous pouvez aussi le paramétrer à stream si
vous utilisez le système de réplication intégré à PostgreSQL (le
Streaming Replication).
Le fichier de configuration d'exemple pour le sous-mode Slony-I
est pgpool.conf.sample-master-slave, et celui
concernant la Streaming Replication est
pgpool.conf.sample-stream.
Vous devez redémarrer pgpool-II si vous changez l'un des paramètres vu précédemment.
Vous devrez probablement aussi renseigner les paramètres
white_function_list et
black_function_list si vous voulez contrôler plus finement
la répartition de charge dans le mode maître-esclave.
Reportez-vous à white_function_list
pour plus de détails.
Comme nous l'avons vu précédemment, pgpool-II peut fonctionner de pair avec la Streaming Replication, qui est disponible depuis la version 9.0 de PostgreSQL. Pour l'utiliser, il faut activer le paramètre master_slave et positionner le paramètre master_slave_sub_mode1 à stream. pgpool-II suppose que le Streaming Replication fonctionne et que les serveurs PostgreSQL esclaves sont en Hot Standby, ce qui signifie que les bases de données sont ouvertes en lecture seule sur ces derniers. Les directives suivantes peuvent être utilisées dans ce mode :
Permet de spécifier le décalage maximum toléré entre le serveur maître et
un serveur esclave dans une réplication, exprimé en octets de journaux de
transactions.
Si le décalage dépasse delay_threshold, pgpool-II n'envoie
alors plus de SELECT au serveur(s) esclave(s). Tout est alors envoyé au serveur
maître, même si la répartition de charge est activée, jusqu'à ce que le(s) serveur(s)
esclave(s) soit(soient) en deçà du décalage maximum autorisé.
Si delay_threshold est à 0 ou si le test
de vie est désactivé, ce test de décalage n'est jamais fait. Ce dernier est
effectué tous les health_check_period. La valeur par défaut
pour delay_threshold est 0.
Vous devez recharger la configuration de pgpool-II si vous changez cette
directive.
Permet de spécifier comment le décalage de réplication est tracé dans le
journal applicatif de pgpool-II. Si none est spécifié ici,
rien n'est écrit. Si always est spécifié, alors le décalage
sera tracé à chaque fois que le test est effectué.
Si if_over_threshold est spécifié, alors le décalage est
tracé uniquement lorsqu'il dépasse le delay_threshold.
La valeur par défaut pour log_standby_delay est
none.
Vous devez recharger la configuration de pgool-II si vous changez ce
paramètre.
Vous pouvez aussi superviser le décalage éventuel de la réplication en utilisant la commande "show pool_status".
Dans le mode maître/esclave avec la Streaming Replication, si le nœud primaire ou le nœud en attente s'arrête, pgpool-II peut être configuré pour exécuter un Failover. Les nœuds peuvent alors être attachés automatiquement sans configuration ou opérations complémentaires. Alors qu'il est en pleine réplication [~], le nœud en attente vérifie régulièrement si un fichier de déclenchement existe. S'il le trouve, le nœud en attente sort de son mode réplication et s'ouvre en mode lecture/écriture. En utilisant ce mécanisme, on peut avoir une base de données en attente qui prends le relais quand le nœud primaire tombe.
Attention : si vous pensez utiliser plusieurs nœuds en mode standby, il est recommandé de définir le paramètre delay_threshold pour empêcher tout requête dirigée vers d'autres nœuds en standby de récupérer des données plus vieilles.
Si un second nœud en standby prends le relais quand le premier nœud en standby avait déjà pris le relais, vous pourriez avoir des données erronnées en provenance du second standby. Nous vous recommandons de ne pas utiliser ce genre de configuration.
Voici commment configurer un mécanisme de Failover.
$ cd /usr/loca/pgsql/bin $ cat failover_stream.sh #! /bin/sh # Commandes pour faire un Failover en mode Streaming Replication # Ce script suppose que le nœud Maitre est le 0 et 1 le standby # # Si le Standby s'arrête, ne rien faire. Si le Primaire s'arrête, créer # un fichier de déclenchement afin que le standby prenne le relais sur le # nœud Primaire. # # Arguments: # $1: identifiant du nœud qui ne répond plus # $2: nom d'hôte du nouveau maître # $3: chemin vers le fichier trigger failed_node=$1 new_master=$2 trigger_file=$3 # Ne rien faire si c'est le standby qui tombe if [ $failed_node = 1 ]; then exit 0; fi # Créer un fichier de déclenchement /usr/bin/ssh -T $new_master /bin/touch $trigger_file exit 0; chmod 755 failover_stream.sh
failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
standby_mode = 'on' primary_conninfo = 'host=nom_du_nœud_primaire user=postgres' trigger_file = '/tmp/trigger_file0'
wal_level = hot_standby max_wal_senders = 1
host replication postgres 192.168.0.10/32 trust
Démarrez PostgreSQL sur les nœuds primaire et secondaire pour initialiser la réplication. Si le nœud primaire venait à tomber, le nœud secondaire prendra automatiquement le relais, en tant que nouveau nœud primaire, et sera alors prêt à recevoir les requêtes en écriture.
Lorsqu'on utilise la Streaming Replication et le Hot Standby, il est important de déterminer les requêtes pouvant être envoyées sur le nœud principal ou sur le nœud en standby (secondaire), et les requêtes qui ne peuvent pas l'être. Le mode Streaming Replication de pgpool-II se charge complètement de cette problématique. Dans ce chapitre, nous expliquerons comment pgpool-II parvient à cela.
Nous distinguons les requêtes qui devraient être envoyées à tel ou tel nœud en les examinant.
Dans une transaction explicite :
Toute commande qui ne peut être exécutée sur un nœud en standby (secondaire) comme un INSERT sont envoyées uniquement au primaire. Après toute commande de ce type, absolument tous les ordres SQL sont envoyés au nœud primaire. En effet, les SELECT suivant pourraient vouloir voir les résultats d'un INSERT immédiatement. Ce comportement continue jusqu'à ce que la transaction se ferme ou soit interrompue.
Dans le protocole étendu, il est possible de déterminer si la requête peut être envoyée au nœud en standby ou pas dans le mode de répartition de charge au moment où on analyse la requête. Les rêgles sont les mêmes que dans le protocole non-étendu. Par exemple, les INSERT sont envoyés au primaire, ainsi que toute requête qui suivra.
Note : si l'analyse d'une requête en SELECT est envoyée sur le standby à cause de la répartition de charge et qu'une requête en modification de données, comme un INSERT est envoyé à pgpool-II, alors le SELECT analysé devra être exécuté sur le nœud primaire. Cependant, on analyse de nouveau le SELECT sur le nœud primaire.
Enfin, les requêtes qui semblent douteuses ou possiblement en erreur sont envoyées sur le nœud primaire.
Dans le mode maître/esclave avec la Streaming Replication, on peut procéder à une restauration à chaud (« Online recovery »). Cependant, seul un nœud en standby peut être ainsi récupéré. On ne peut pas reconstruire un nœud primaire. Pour ce faire, il faudra stopper toutes les bases de données, ainsi que pgpool-II, puis restaurer le nœud primaire à partir d'une sauvegarde.
Voici les étapes.
Un appel à la fonction de la libpq lo_creat() utilisera cette fonctionalité. De même, la création de « large objects » via l'API Java (driver JDBC) devrait fonctionner, tout comme l'API PHP (pg_lo_create, ou API similaire dans la bibliothèque de PHP, comme PDO), et ce genre d'API similaires dans plusieurs langages de programmation qui sont réputées pour utiliser un protocole similaire.
Les opérations suivantes de création d'un « large object » ne fonctionneront pas :
Peu importe le schéma où est stockée la table lobj_lock_table,
celle-ci doit en revanche être accessible en écriture à tous les utilisateurs.
Voici un exemple de créatio