pgPool-II, la réplication par duplication des requêtes

1. Installation de pgPool-II

Comme vu dans l'article sur le mode de pooling de connexions de pgPool-II, l'installation de pgPool-II est très simple. Nous n'allons reprendre ici que les commandes de base :

2. Configuration

La configuration a toujours lieu dans le fichier pgpool.conf.

La première chose à faire est d'activer la réplication. Pour cela, il faut mettre à 'on' le paramètre replication_mode.

Ceci fait, pgPool-II enverra une copie de chaque requête qu'il reçoit à tous les nœuds de bases de données. Néanmoins, par défaut, les SELECT ne sont pas répliqués. Si vous souhaitez faire exécuter les SELECT sur les différents nœuds, c'est possible. Il faut pour cela activer le paramètre replicate_select. Nous n'allons pas le faire dans notre cas.

Ensuite, il faut configurer les différents nœuds. Nous avions déjà configuré le nœud 0 lors du précédent article sur pgPool-II, nous allons maintenant faire le nœud 1 :

pgPool-II va donc se connecter aux deux nœuds. Pour cela, il faut évidemment corriger la configuration des accès sur debian1 et debian2. La première chose à faire est d'autoriser les accès distants. Nous passons donc le paramètre listen_addresses à '*' dans le fichier /etc/postgresql/8.4/main/postgresql.conf. Ensuite, nous devons autoriser les adresses IP des deux serveurs. Cela se fait dans le fichier /etc/postgresql/8.4/main/pg_hba.conf. La configuration retenue est la suivante :

De cette façon, nous autorisons les connexions de n'importe quel utilisateur PostgreSQL sur n'importe quelle base de données, à condition qu'elle provienne des adresses IP 192.168.10.66 et 192.168.10.67 (adresses IP des serveurs debian1 et debian2). Remarquez la méthode trust. Seules les méthodes trust, password et pam sont acceptées. password est certainement un peu meilleur que trust, car il est quand même nécessaire d'avoir un mot de passe. Cependant, ce dernier circule en clair sur le réseau. pam est probablement le meilleur choix, à défaut de mieux. Néanmoins, cela vous contraint à créer autant d'utilisateurs Unix que de personnes capables de se connecter à l'instance PostgreSQL.

Maintenant que la configuration est faite, nous devons faire en sorte que PostgreSQL la prenne en compte. Si vous avez dû modifier le paramètre listen_addresses, vous devez redémarrer PostgreSQL. Dans le cas contraire, un simple rechargement de la configuration suffit.

Tout ce travail fait sur debian1 doit aussi être fait sur debian2.

Avant de lancer pgPool-II, il est de bon ton de s'assurer que les connexions se font bien. Essayez de vous connecter sur les bases de debian1 à partir de debian1 et de debian2. Puis, faites de même sur les bases de debian2.

3. Utilisation de la réplication

Commençons par lancer le démon pgpool :

Maintenant, nous allons créer une base sur debian1.

Remarquez que nous utilisons toujours l'option -p pour indiquer le numéro de port de pgpool et donc bien nous assurer de passer par pgPool-II. Pour éviter d'avoir à saisir cette option, vous pouvez initialiser la variable d'environnement PGPORT de cette façon :

Évidemment, un moyen encore plus simple est de faire en sorte que pgPool-II écoute sur le port 5432.

Revenons-en à notre base de données. Nous l'avons créée sur debian1. Voyons si elle existe bien :

Oui, c'est bien le cas. Maintenant, voyons si elle existe sur debian2 :

C'est bien le cas aussi. La requête de création de base générée par l'outil createdb a bien été envoyée aux deux serveurs par l'outil pgPool-II.

Maintenant, connectons-nous à la base b1 de debian1 et ajoutons une table :

Parfait. Voyons ce qui s'est passé sur debian2 :

La table est bien là. Elle contient bien les nouvelles lignes. Avouez que c'est difficile de faire plus simple.

Voyons maintenant une autre limite de la réplication par les instructions SQL. Créons une table avec un champ de type timestamp (horodatage, avec date, heure et fuseau horaire) et un champ de type float4 :

Vérifions maintenant ce que cela a donné sur le deuxième nœud :

Premier constat, la table est bien là. Deuxième constat, nous avons bien les deux lignes. Troisième constat, la colonne serial est bien gérée. Ce n'est pas très étonnant vu que nous n'avons pas des dizaines de clients en train de faire des insertions. De plus, par défaut, nous sommes en mode insert_lock. Ce paramètre du fichier pgpool.conf permet de verrouiller la table pendant l'insertion. PgPool-II fait cela en remplaçant l'instruction INSERT par la série d'instructions suivantes : BEGIN; LOCK TABLE...; INSERT...; COMMIT;. Cela peut rapidement poser des problèmes de performance. Ces problèmes sont cependant moins présents à partir de la version 2.2. En effet, cette version ne réalise réellement le verrouillage que si elle détecte une donnée de type serial dans la table. Sur les versions précédentes, c'était fait en permanence à partir du moment où ce paramètre était activé.

Revenons-en à notre table t2 et à ses données. Si nous regardons un peu plus précisément les données, nous nous rendons compte de différences :

- L'heure est différente sur la première ligne.

- Le nombre est différent sur la seconde.

En effet, pgPool-II envoie les requêtes sur les deux serveurs. Du coup, si cette requête contient un appel à une fonction dont le résultat n'est pas reproductible dans les mêmes conditions, il est possible de voir des différences. Les fonctions now() et random() sont des cas typiques pouvant révéler ce problème. Le moment où now() est exécuté sur le serveur 1 a de très fortes chances d'être différent du moment où cette même fonction est exécutée sur le serveur 2. Quant à random(), son but est d'être justement différent à chaque exécution.

Au passage, on remarquera que les heures sur nos deux serveurs sont vraiment très différentes. Il aurait été bon de mettre en place une synchronisation de l'heure avec le protocole NTP. Cependant, ça ne change rien au problème actuel.

Tout ça pour dire qu'une des limitations de pgPool-II est d'avoir à éviter ce genre de cas. Une solution possible est de récupérer la valeur de now() ou de random() avec un premier appel à un SELECT, puis de construire le INSERT à partir de la valeur renvoyée. En voici un exemple :

Autre inconvénient majeur de cette forme de réplication, c'est que vous devez absolument passer par le pooler pour que la réplication se fasse. Dans notre exemple, si nous n'indiquons pas le port 9999, nous nous connectons directement à PostgreSQL et nous pouvons faire toutes les modifications voulues sans qu'elles soient répliquées. Ceci est vrai aussi sur l'esclave. Il n'est pas bloqué en lecture seule. Donc, il faut faire particulièrement attention à la façon dont le système est configuré pour ne pas avoir une réplication qui laisse à désirer. Le meilleur moyen de se protéger est d'interdire tous les accès ne provenant pas du serveur pgPool-II. Le fichier pg_hba.conf devra donc n'accepter que l'adresse IP du serveur exécutant le démon pgpool.

4. Configuration de la répartition de charge

La réplication est un système intéressant, surtout dans le cas d'outils permettant d'accéder aux esclaves en lecture seule. Ça permet par exemple de déporter les sauvegardes sur l'esclave. Ça permet aussi de mettre en place la génération de rapports (activité généralement lourde pour l'activité CPU et l'utilisation de la mémoire et des disques) sur l'esclave.

Autre intérêt des esclaves accessibles en lecture seule, la possibilité de gérer une répartition de la charge entre le maître et le (ou les) esclave(s). pgPool-II peut s'en charger.

Pour activer ce mode, il faut passer à 'on' le paramètre load_balance_mode :

Ce mode activé, les requêtes SELECT seront distribuées parmi les différents nœuds de la base de données. Nous avons déjà expliqué comment définir un nœud. La seule différence est la possibilité de configurer un poids pour chacun des nœuds. Ce poids permet de connaître le pourcentage des requêtes qui seront envoyées sur un nœud par rapport aux autres nœuds. Disons que nous avons trois nœuds, le premier avec un poids de 0,2, le deuxième avec un poids de 0,3 et le dernier avec un poids de 0,5. Le premier recevra 20% des requêtes de lecture, le second 30% de ces mêmes requêtes et le troisième 50% des requêtes en lecture. L'intérêt est surtout de différencier le taux des requêtes en lecture sur le maître par rapport à celui des esclaves.

Il faut aussi savoir que toutes les requêtes SELECT ne sont pas bonnes à répartir. Il existe quelques exceptions que voici :

- les SELECT compris dans une transaction explicite (car, au moment de l'ouverture de la transaction, il est impossible de savoir si la transaction sera en lecture seule ou non) ;

- SELECT nextval et SELECT setval ;

- SELECT INTO ;

- SELECT FOR UPDATE et SELECT FOR SHARE.

Les requêtes qui sont considérées bonnes pour la répartition sont les requêtes qui commencent par SELECT à l'exception des quatre variantes ci-dessus :

- les requêtes COPY TO STDOUT ;

- les requêtes DECLARE … SELECT ;

- les requêtes FETCH ;

- les requêtes CLOSE.

Attention, n'importe quelle caractère avant le mot SELECT fera que l'instruction ne sera pas envoyée sur un autre nœud que le maître. Quelque fois, le mot SELECT est précédé d'un commentaire ou d'un ou plusieurs espaces. Pour se protéger contre la non-répartition des requêtes SELECT commençant par des espaces, il existe un paramètre. En activant ignore_leading_white_space, vous évitez ce comportement.

Il existe un excellent graphique montrant le processus de décision de la répartition de charge à partir du contenu d'une requête. Il est disponible sur http://pgpool.projects.postgresql.org/pgpool-II/doc/load_balance.png.

Il est à noter que si vous préférez utiliser un outil de réplication autre que pgPool-II, vous pouvez malgré tout bénéficier de la répartition de charge. L'autre outil de réplication peut être Slony, Londiste, bref tous ceux qui permettent un accès à l'esclave en lecture seule. Vous devez désactiver load_balance_mode (qui n'est pas activable si replication_mode est désactivé), et activer le paramètre master_slave_mode.

Après avoir relancé pgPool-II, vous pourrez voir vos requêtes de lecture réparties entre les différents nœuds définis.

5. Utilisation de la répartition de charge

Considérons deux serveurs, debian1 et debian2. Nous allons les mettre en réplication via pgPool-II et en répartition de charge pour les requêtes en lecture.

Voici la partie la plus intéressante de la configuration de pgPool-II :

La configuration des accès aux serveurs PostgreSQL est identique à celle qui a été faite au début de cet article. Pour ce qui est de la configuration générale de PostgreSQL, nous allons configurer un paramètre supplémentaire. Nous allons passer log_statement à 'all' pour tracer toutes les requêtes SQL sur les deux serveurs.

Nous allons maintenant créer une nouvelle base, y ajouter une table et insérer quelques données dans cette table :

La requête de création de la base est bien arrivée aux deux serveurs PostgreSQL. L'ordre de création de la table a été modifié pour être intégré dans une transaction explicite. L'ordre d'insertion a subi le même sort. Néanmoins, une autre instruction SQL s'est glissée dans la transaction pour vérifier qu'il n'y avait pas de colonnes avec une valeur par défaut utilisant la fonction nextval (typique pour les colonnes auto-incrémentées). Il faut aussi remarquer que cette recherche ne se fait que sur le maître. Le nœud 2 n'a que l'ordre INSERT dans sa transaction explicite.

Maintenant, exécutons plusieurs SELECT :

Laissons cette session tranquille et ouvrons-en une autre :

Et, cette fois, les traces nous disent que c'est debian2 qui s'en est occupé :

Pour avoir une idée plus complète d'une répartition de charge pour un grand nombre de requêtes, installons pgbench :

Créons une base bench, et initialisons-la grâce au mode -i de pgbench :

Parfait. Avant de lancer les tests de pgbench, nous allons vider les journaux applicatifs de PostgreSQL :

Il faut faire de même sur debian2.

Nous allons maintenant utiliser pgbench en lui demandant de ne faire que des SELECT (mode -S). pgbench va simuler huit clients. Il faut donc s'assurer que le paramètre num_init_children de la configuration de pgPool-II vaut au minimum 8. Pour être sûr de ne pas avoir de concurrence entre les différents clients, nous avons doublé cette valeur. Relancez le démon pgpool si vous avez dû modifier la configuration.

Maintenant, nous pouvons lancer pgbench :

Regardons le nombre de SELECT dans les journaux de debian1 :

Et dans ceux de debian2 :

Nous avons bien du 50/50. Maintenant, changeons le poids. Disons 0,3 pour debian1 et 0,7 pour debian2, vidons les journaux applicatifs sur les deux serveurs, puis relançons le test :

On obtient, cette fois, 2000 transactions par debian1 et 6000 par debian2. Ce n'est pas exactement du 30/70, mais plusieurs facteurs ont pu jouer pour que cela ne corresponde pas exactement.

6. Petit récapitulatif

Avantages majeurs :

- extrêmement simple à mettre en place ;

- très facile à comprendre ;

- réplication des changements de schéma ;

- les esclaves en lecture seule.

Inconvénients majeurs :

- aucune garantie que les données soient identiques entre les nœuds si l'applicatif utilise des fonctions comme now(), random() ou des types comme les OID, TID ;

- les tables temporaires ne sont pas supprimées automatiquement à la fin d'une session ;

- les clients doivent obligatoirement passer par le pooler.

Conclusion

pgPool-II n'est pas le seul outil proposant ce type de réplication. On pourra notamment citer sequoia/tungsten et ha-jdbc (http://ha-jdbc.sourceforge.net/). Lequel utiliser dépend de votre contexte. Le bon point de pgPool-II est qu'il est capable de faire d'autres choses, comme du pooling de connexions ou de la répartition de charge.

Il est aussi à noter que nous n'avons pas tout vu de pgPool-II. Notamment, il resterait à voir les outils PCP et la base de données système.