Styles

jeudi 28 mai 2015

Void linux, la distribution qui vous fera oublier Debian 8, systemd et Gnome 3

Ainsi Debian vient de sortir sa nouvelle version 8.0 "Jessie". La distribution Debian avait l'avantage de privilégier la simplicité, le respect des standards ouverts, la stabilité. Par une politique de version lente (tous les 5 ans) et des mises à jour au compte-goutte sauf au niveau sécurité, Debian était resté en version 7.0 "wheezy" sous Gnome 2 jusqu'à récemment. Nombreux sont ceux qui ont passés leurs vieux PC sous Debian à la suite notamment de la fin du support de Windows XP, car, chose étonnante, l'obsolescence programmée n'est pas aimée de tout le monde.

Or, la version 8.0 de Debian impose maintenant systemd par défaut, à la place de l'init SysV. Systemd a été conçu par les employés de Red Hat pour ne fonctionner qu'avec un noyau linux© avec beaucoup de pré-requis et ne cherche plus ni la simplicité ni la portabilité du code. En bref, systemd ne suit pas la philosophie d'Unix.

Mais pourquoi Debian a-t-il fait le choix de systemd ? Que des entreprises commerciales comme Red Hat souhaitent développer des systèmes monolithiques et fermés ne pose aucun problème : ce sont ses affaires. Red Hat appelle ça "la modernité":



Et j'imagine que les utilisateurs de Red Hat Entreprise Linux© en sont satisfait. Mais si Debian est aujourd'hui obligé d'utiliser systemd, c'est parce qu'elle souhaite offrir la nouvelle interface Gnome 3 par défaut. Or Gnome 3 est très lié à systemd, et séparer systemd de Gnome 3 n'est pas simple et introduit des instabilités (sans parler de la maintenance d'une telle séparation dans le temps).

Gnome 3, non content d'avoir alourdit l'interface, se lie fortement à une technologie qui n'est disponible que sous linux©

Gnome 3, non content d'avoir alourdit l'interface, se lie fortement à une technologie qui n'est disponible que sous linux©. Bien que Gnome 3 soit considéré comme portable, dans le détail, on s'aperçoit que de nombreuses fonctionnalités sont désactivées par défaut car dépendantes de systemd. Par exemple, les développeurs ayant essayé de porter Gnome 3 sous OpenBSD l'ont noté.

Gnome 3, sous l'influence d'Ubuntu et d'autres, a changé de paradigme en essayant de s'adapter aux nouveaux terminaux tactiles. En souhaitant être considéré comme "moderne", Gnome a fait le choix d'abandonner les PC plus anciens à leur sort, au détriment de ces utilisateurs.

Ainsi, j'ai voulu installer Debian 8.0 "jessie" sur mon vieux PC de 2004, maintenu sous Debian depuis 2009. Et maintenant sous Gnome 3, mon PC rame comme jamais il n'a ramé. Comme si l'OS libre était devenu un boufficiel. Mon sang n'a fait qu'un tour. Trop c'est trop : systemd, Gnome 3, mon PC qui rame, ... j'ai décidé de changer de crèmerie, et j'ai choisi d'installer la distribution Void Linux:
  • c'est une distribution linux (car seul linux a certains pilotes pour mon matériel, sinon j'aurais pris du BSD)
  • elle a fait le choix de ne pas mettre systemd par défaut,
  • elle permet d'installer par défaut MATE Desktop, qui est la continuation et la simplification de l'interface classique Gnome 2,
  • elle dispose d'un système de gestion d'initialisation et de gestion des services portable, performant et respectant la philosophie d'Unix : runit
  • elle met en oeuvre un système de gestion original de paquets transactionnel et toujours à jour grâce à une compilation automatisée d'après les dépôts git des projets : xbps
  • cette gestion de paquets toujours à jours permet une publication continue de void linux (pas de version de void linux, le système est toujours à jour)
  • elle a fait le choix d'utiliser libressl par défaut à la place de openssl suite aux découvertes des nombreuses vulnérabilités d'openssl,
  • runit et xbps sont sous licence BSD, ce qui est, à mon avis, beaucoup plus respectueux des utilisateurs de ces logiciels qu'une licence GPLv3 ou Apache v2.0 imposant des contraintes sur les ajouts que pourraient faire les utilisateurs.
  • l'outil de construction de paquet xbps-src permet une grande flexibilité et autorise l'emploi de différentes librairies C (notamment musl) : important dans le cas de ressources limitées.


J'ai donc téléchargé une image ISO de void linux avec MATE Desktop et ai installé sans problème l'OS sur mon vieux PC en utilisant l'outil d'installation (un peu rugueux comme outil, mais il rend le service). Et là, le miracle s'est produit : je retrouve une interface connue (comme Gnome 2), beaucoup, beaucoup, mais alors, BEAUCOUP plus rapide que sous Debian. Le démarrage et l'arrêt du PC sont eux-même très accélérés grâce à runit qui marche à merveille. J'ai l'impression de retrouver un PC tout neuf, bien équilibré. J'arrive même à lire des vidéos HD dans Firefox en HTML5, sans accélération graphique, sans ralentissement de la vidéo. En force pure, mon vieux PC de 2004 est certainement dépassé, mais en utilisation quotidienne pour naviguer sur internet, même sur de gros sites bien lourds et avec des vidéos, ça marche nickel sans ralentissement. J'ai même installé ma tablette graphique Wacom et l'outil MyPaint et hop, voilà que je fais du dessin sans problème et à une vitesse vraiment surprenante vu la taille de ma mémoire (512Mo mémoire graphique incluse !)

Je ne pensais pas obtenir une telle accelération en changeant de distribution linux© mais je suis obligé de constater le contraire ! Je suis tombé amoureux de void linux, je ne pense pas en changer de si tôt.

mardi 14 avril 2015

Qui peut constuire une maison sans dessiner un plan ?

Article de Leslie Lamport à lire sur la nécessité de rédiger des spécifications avant de coder. Ce qui est assez désespérant c'est que ce genre d'article ait encore besoin d'être publié aujourd'hui: cette "bonne pratique" était déjà recommandée dans les années 60.

Une des phrases à retenir :
Si nous ne commençons pas par une spécification, chaque ligne de code que nous écrivons est un "patch".

lundi 6 avril 2015

Installation de PostgreSQL sous OpenBSD et utilisation de psql sous Windows pour y accéder

Cet article montre comment ne pas se fatiguer avec la gestion de l'encodage des caractères entre des serveurs et clients très différents.

Sous OpenBSD

- installer le package postgresql-server
- lire le fichier et exécuter les instructions pour créer le répertoire de données :
more /usr/local/share/doc/pkg-readmes/postgresql-server-9.3.4p0
se connecter en root :
su -
puis se connecter avec _postgresql pour créer le répertoire de données:
su - _postgresql
mkdir /var/postgresql/data
initdb -D /var/postgresql/data -U postgres -E LATIN9 -A md5 -W
exit
Ce qui est important dans ces commandes c'est LATIN9 qui sera à utiliser dans l'appel à psql sous Windows pour s'assurer que ça fonctionne bien entre les deux systèmes.

Editer /var/postgresql/data/postgresql.conf:
listen_addresses = '*'

Editer /var/postgresql/data/pg_hba.conf:
host    all             all             0.0.0.0/0               md5

Pour démarrer/redémarrer/arrêter la base de données à partir du compte root:
/etc/rc.d/postgresql start
/etc/rc.d/postgresql restart
/etc/rc.d/postgresql stop
Pour démarrer/arrêter automatiquement postgresql au démarrage et arrêt de la machine, ajouter postgresql à la variable pkg_scripts dans /etc/rc.conf.local :
pkg_scripts="postgresql"
Tous les services doivent être séparés par un espace dans cette variable, comme par exemple pkg_scripts="postgresql service2 service3" où chaque entrée doit être dans /etc/rc.d/

psql sous windows pour accéder à un serveur postgresql sous unix

Installez PostgreSQL sous windows pour disposer de psql. Créer un fichier psqlopenbsd.bat :
@@echo off
set PGCLIENTENCODING=LATIN9
chcp 1252 > nul
set PSQLRC=d:\jrx\jrxemacs\.psqlrc
"c:\Program Files\PostgreSQL\9.3\bin\psql.exe" -h adresse_ip -U postgres postgres
en remplaçant adresse_ip par l'adresse ip du serveur, en s'assurant que PGCLIENTENCODING correspond à l'encoding des data du serveur (encoding utilisé lors de la création de la base de données avec initdb).

lundi 30 mars 2015

Outils de sécurité réseau avec OpenBSD et PF - Matthieu Herrb

Matthieu Herrb. Outils de sécurité réseau avec OpenBSD et PF. Journées Réseaux (JRES), Nov 2011, Toulouse, France.

Cet article présente la mise en place de solutions de sécurité réseau basées sur des logiciels libres au LAAS du CNRS. Dans le domaine de la sécurité réseau, deux composants clé utilisés dans le laboratoire sont le pare-feu principal et le portail captif destiné à accueillir les connexions de visiteurs. Les outils retenus se basent sur le filtre de paquets PF ainsi que sur des extensions du serveur DHCP du système OpenBSD.
Après avoir étudié plusieurs scénarios de déploiement, le pare-feu principal du laboratoire est constitué de deux serveurs redondants contrôlant le trafic à l'aide de PF en mode transparent.
Pour l'accueil de connexions réseaux de visiteurs, le laboratoire souhaite continuer à leur proposer un accès ouvert. Un portail captif « auto déclaratif » sur lequel chaque visiteur s'enregistre pour accéder à l'Internet a été réalisé à l'aide d'outils présents dans OpenBSD.

dimanche 15 mars 2015

Quand Facebook réinvente le minitel

Facebook vient de réinventer internet sur le modèle économique du minitel où le prix est fonction du site Web que vous visitez. Vous imaginez bien la menace que cela représente pour la neutralité d'internet. Heureusement, vous savez très bien que ce genre de modèle économique ne marchera pas, ne serait-ce que par l'ingéniosité des internautes ainsi muselés.

vendredi 13 mars 2015

Substitution de processus

Je viens de créer l'article Wikipedia Substitution de processus pour décrire ce magnifique mécanisme :


En informatique, la substitution de processus est une forme de communication inter-processus permettant à l'entrée ou à la sortie d'une commande d’apparaître sous la forme d'un fichier. L'interface système substitue la commande en ligne par un nom d'un fichier. Cela permet aux programmes qui n'acceptent normalement que des des fichiers de lire directement à partir ou vers un autre programme.




Exemple

Les exemples suivants utilisent la syntaxe Bash.

La commande diff de Unix accepte normalement les noms de deux fichiers à comparer, ou un nom de fichier et l'entrée standard. La substitution de processus vous permet de comparer directement la sortie de deux programmes :

$ diff <(sort fichier1) <(sort fichier2)

L'expression <(commande) dit à l'interpréteur d'exécuter commande et fait apparaitre sa sortie sous la forme d'un fichier. La commande peut être n'importe quelle commande complexe de l'interface système.

Sans la substitution, les alternatives sont:

1. Sauvegarder la sortie de la commande(s) vers un fichier temporaire, puis lire le(s) fichier(s) temporaire(s).

$ sort fichier2 > /tmp/fichier2.trie
$ sort fichier1 | diff - /tmp/fichier2.trie
$ rm /tmp/fichier2.trie

2. Créer un tube nommé (aussi connu sous le nom de FIFO), démarrez une commande écrivant vers le tube nommé en tâche de fond, puis exécutez l'autre commande avec le tube nommé en tant qu'entrée.

$ mkfifo /tmp/tri2.fifo
$ sort fichier2 > /tmp/tri2.fifo &
$ sort fichier1 | diff - /tmp/tri2.fifo
$ rm /tmp/tri2.fifo

Les deux alternatives sont plus lourdes.

La substitution de processus peut aussi être utilisée pour capturer la sortie qui est normalement destinée à aller vers un fichier, et la rediriger vers l'entrée d'un processus. La syntaxe Bash pour écrire vers un processus est >(commande). Voici un exemple utilisant les commandes tee, wc et gzip pour compter les lignes d'un fichier avec wc -l et les compresser avec gzip en une seule passe:

$ tee >(wc -l >&2) < grosfichier | gzip > grosfichier.gz


Avantages

Les avantages principaux de la substitution de processus sur ses alternatives sont :

  • sa simplicité : les commandes peuvent être saisies en ligne; il n'y a pas besoin avant cela de sauvegarder des fichiers temporaires ou créer des tubes nommés.
  • sa performance : lire directement d'un autre processus est souvent plus rapide que de devoir écrire dans un fichier temporaire sur disque, puis de le lire. Cela permet aussi d'économiser de l'espace disque.
  • son parallélisme: le processus substitué peut s'exécuter concurremment avec la commande lisant sa sortie ou écrivant sur son entrée, tirant avantage du traitement multiple pour réduire le temps total de traitement.


Mécanisme

Sous le capot, la substitution de processus fonctionne en créant un tube nommé, puis en substituant son nom sur la ligne de commande (la substitution de processus est ainsi parfois appelée "tube nommé anonyme"). Pour illustrer les étapes en jeu, considérez la substitution simple de commande suivante :

diff fichier1 <(sort fichier2)

Les étapes entreprises par l'interface système sont:

  1. Création d'un nouveau tube nommé. Ce fichier spécial est souvent nommé sur le modèle /dev/fd/63 sur les sytèmes de style Unix; vous pouvez le voir avec une commande comme echo <(true).
  2. Exécution de la commande substituée en arrière plan (sort fichier2 dans notre cas), tubant sa sortie sur le tube nommé.
  3. Exécution de la commande primaire, en remplaçant la commande substituée par le nom du tube nommé. Dans notre cas, la commande entière peut se développer en diff fichier1 /dev/fd/63.
  4. Quand l'exécution est terminée, suppression du tube nommé.


Limitations

La substitution de processus a quelques limitations: les "fichiers" créés ne peut pas être recherchés (fseek), ce qui veut dire que le processus lisant ou écrivant vers le fichier ne peut pas réaliser un accès direct; il doit seulement lire ou écrire du début à la fin. Les programmes qui vérifient explicitement le type de fichier avant de l'ouvrir pourrait refuser de fonctionner avec le substitution de processus, car le "fichier" résultant de la substitution de processus n'est pas un fichier normal. "Il n'est pas possible d'obtenir un code de sortie d'une commande de substitution de processus à partir de l’interface système ayant créé la substitution de processus.

Voir aussi

vendredi 6 mars 2015

Histoire de la réplication dans PostgreSQL

Cet article est une traduction par mes soins de l'article de Peter Eisentraut : The history of replication in PostgreSQL, publiée avec son autorisation.

2001: PostgreSQL 7.1: le journal à écriture anticipée

PostgreSQL 7.1 a lancé le Journal à Ecriture Anticipée (Write-ahead log : WAL). Avant cette version, tous les fichiers de données ouverts devaient être fsyncés sur chaque commit, ce qui était très lent. La lenteur du fsync est encore un problème aujourd'hui, mais maintenant nous sommes seulement préoccupés par le fsyncage du WAL et le fsyncage des fichiers de données au cours du processus de point de contrôle (checkpoint). À l'époque, nous avions à fsyncer tout, tout le temps.

Dans la conception originale de POSTGRES universitaire, l'absence d'un journal était intentionnel, et se démarquait des architectures largement basées sur la journalisation comme Oracle. Dans Oracle, vous avez besoin de faire un retour arrière sur les modifications dans le journal. Dans PostgreSQL, le système de stockage sans écrasement prend soin de cela. Mais, probablement, personne n'a pensé aux implications de fsync à l'époque.

Notez que le WAL était vraiment juste un détail d'implémentation à ce stade. Vous ne pouviez pas le lire ou l'archiver.

2004: Slony

Juste pour le contexte: Slony-I 1.0 est sorti en Juillet 2004.

2005: PostgreSQL 8.0: récupération à un point donné

PostgreSQL 8.0 a ajouté la possibilité de copier le WAL ailleurs, et plus tard le lire à nouveau, soit en entier soit jusqu'à un point donné dans le temps, d'où le nom de récupération à un point donné (Point-In-Time Recovery : PITR) pour cette fonctionnalité. Cette fonctionnalité était principalement destinée à laisser tomber pg_dump comme méthode de sauvegarde. Jusque-là, la seule méthode de sauvegarde existante était un vidage complet (dump), qui devenait malaisé plus les bases de données augmentaient. D'où cette méthode consistant à prendre occasionnellement une sauvegarde de base, qui est la partie coûteuse, puis à ajouter les parties du WAL, ce qui est moins coûteux.

Les mécanismes de configuration de base que nous utilisons encore aujourd'hui, par exemple, le fichier recovery.conf, ont été introduits dans le cadre de cette fonctionnalité.

Mais toujours pas de réplication ici.

2008: PostgreSQL 8.3: pg_standby

Des malins ont fini par comprendre que si vous archiviez le WAL sur un serveur et en même temps vous le récupériez (recover) à l'infini sur un autre, vous aviez une configuration de réplication. Vous pouviez probablement le faire avec vos propres scripts dès là 8.0, mais PostgreSQL 8.3 a ajouté le programme pg_standby dans contrib, ce qui donna à chacun un outil standard. Ainsi, on peut dire sans doute que la 8.3 fut la première version qui contint un semblant de solution de réplication intégré.

Le serveur de secours effectuait une récupération permanente jusqu'à sa promotion, de sorte qu'il ne pouvait être lu pendant qu'il répliquait. C'est ce que maintenant nous appelons un secours semi-automatique (warm standby).

Je pense que beaucoup d'installations PostgreSQL 8.3 refusent de mourir parce que c'est la première version où vous pouviez facilement avoir un serveur de réserve assez à jour, sans avoir recours à des outils complexes et parfois problématiques comme Slony ou DRBD.

2010: PostgreSQL 9.0: secours automatique, réplication par flux

Dans PostgreSQL 9.0, deux fonctions de réplication importantes sont arrivés indépendamment l'une de l'autre. Tout d'abord, la possibilité de se connecter à un serveur de secours en mode lecture seule, ce qui s'appelle un secours automatique (hot standby). Alors qu'auparavant, un serveur de secours était principalement utile uniquement comme réserve au cas où le serveur primaire tombait, avec le secours automatique, vous pouvez utiliser les serveurs secondaires pour y répartir la charge de lecture seule.

Deuxièmement, au lieu de s'en remettre uniquement aux archives WAL et aux fonctionnalités de récupération pour transporter les données du WAL, un serveur de secours peut se connecter directement au serveur principal via le protocole libpq existant et obtenir les données du WAL de cette manière, ce qu'on appelle la réplication par flux (streaming replication). Son utilisation principale dans cette version permettait au secours d'être plus à jour, peut-être de l'ordre de quelques secondes, plutôt que de quelques minutes avec l'approche basée sur l'archivage. Pour une configuration robuste, vous aviez encore besoin de mettre en place un archivage. Mais la réplication par flux était également une fonctionnalité tournée vers l'avenir qui finirais par faciliter la mise en place de véritables configurations de réplication, en réduisant la dépendance envers l'ancien mécanisme d'archivage.

PostgreSQL 9.0 fut la première version où l'on put prétendre que PostgreSQL "supporte la réplication" sans avoir à évoquer de restrictions ou s'excuser. Même s'il est prévu qu'elle atteigne sa fin de vie (End of Life : EOF) cette année, je me attends à ce que cette version continue à vivre pendant un bon moment.

2011: PostgreSQL 9.1: pg_basebackup, la réplication synchrone

pg_basebackup a été l'une des fonctionnalités permise par la réplication par flux qui rendit les choses plus facile. Au lieu d'avoir à utiliser des outils externes comme rsync pour les sauvegardes de base, pg_basebackup utilise une connexion libpq normale pour sortir une sauvegarde de base, évitant ainsi des configurations compliquées de connexion et d'authentification pour les outils externes. (Certaines personnes continuent de préférer rsync car il est plus rapide pour eux.)

PostgreSQL 9.1 a également ajouté la réplication synchrone, qui s'assure que les données sont répliquées sur le serveur de secours désigné avant que le COMMIT indique un succès. Cette fonctionnalité est souvent mal comprise par les utilisateurs. Bien qu'elle vous assure que vos données soient sur au moins deux serveurs à tout moment, elle pourrait en fait réduire la disponibilité de votre système, parce que si le serveur de secours tombe, le serveur primaire tombera aussi, sauf si vous avez un troisième serveur disponible pour prendre en charge la tâche synchrone de secours.

C'est peut-être moins largement connu mais PostgreSQL 9.1 a également ajouté la fonction pg_last_xact_replay_timestamp pour surveiller facilement le décalage du secours.

D'après mon expérience, la mise à disposition de pg_basebackup et pg_last_xact_replay_timestamp a fait de PostgreSQL 9.1 la première version où gérer la réplication était relativement facile. Remonter plus loin, et vous pourriez vous sentir contraint par les outils disponibles. Mais en 9.1, ce ne est pas très différent de ce qui est disponible dans les versions les plus récentes.

Cette photo est © Malcolm Cerfonteyn - CC BY 2.0

2012: PostgreSQL 9.2: réplication en cascade

Pas aussi largement acclamé, plus pour les amateurs de Slony peut-être, PostgreSQL 9.2 permis aux serveurs de secours d'aller chercher leurs données de réplication par flux à partir d'autres serveurs de secours. Une conséquence notamment de cela est que pg_basebackup pouvait récupérer les données à partir d'un serveur de secours, laissant ainsi la charge hors du serveur principal, pour la mise en place d'un nouveau serveur de secours ou une copie autonome.

2013: PostgreSQL 9.3: le serveur de secours peut suivre le changement de chronologie

Cela n'a même pas été relevé dans les faits marquants de la version. Dans PostgreSQL 9.3, lorsqu'un primaire a deux secours, et l'un des secours est promu, l'autre secours peut continuer à suivre le nouveau primaire. Dans les versions précédentes, le deuxième secours devait être reconstruit. Cette amélioration rend les changements dynamiques d'infrastructure beaucoup plus simples. Non seulement elle élimine le temps, les soucis, et l'impact sur les performances de la mise en place d'un nouveau secours, plus important encore, elle évite la situation, après une promotion, de n'avoir aucun serveur de secours à jour pendant un certain temps.

2014: PostgreSQL 9.4: emplacements de réplication, décodage logique

Le décodage logique est ce qui a retenu le plus l'attention pour la nouvelle version PostgreSQL 9.4, mais je pense que les emplacements de réplication (replication slots) représentent la fonctionnalité majeure, peut-être la plus grande fonctionnalité de réplication depuis PostgreSQL 9.0. Notez que pendant que la réplication par flux est devenu de plus en plus sophistiquée au fil des ans, vous avez toujours besoin d'archiver le WAL pour la robustesse complète. C'est parce que le serveur primaire ne garde pas de liste de ses serveurs de secours supposés, il ne fait que transférer le flux WAL à qui que ce soit le demande, s'il se trouve l'avoir à disposition. Si le serveur de secours était suffisamment en retard, la réplication par flux échouait, et la récupération par le recours à l'archive devenait nécessaire. Si vous n'aviez pas d'archive, le serveur de secours n'était alors plus en mesure de rattraper son retard et devait être reconstruit. Et ce mécanisme d'archivage n'a essentiellement jamais changé depuis la version 8.0, quand il avait été conçu pour un but totalement différent. Ainsi, une configuration de réplication est en fait assez compliqué: Vous devez configurer un chemin d'accès du primaire au secours (pour l'archivage) et un chemin d'accès du secours au primaire (pour le flux). Et si vous vouliez mettre plusieurs secours, en cascade, le maintien de l'archive pouvais devenir vraiment compliqué. En outre, je pense que beaucoup de configurations d'archivage ont un paramétrage problématique de archive_command. Par exemple, est-ce que votre archive_command réalise un fsync du fichier du côté le recevant ? Probablement pas.

Plus maintenant : Dans PostgreSQL 9.4, vous pouvez configurer ces fameux emplacements de réplication, ce qui signifie concrètement que vous enregistrez sur le primaire la présence d'un secours, et le primaire garde le WAL pour chaque secours jusqu'à ce qu'ils l'aient tous récupéré. Avec cela, vous pouvez vous débarrasser complètement de l'archivage, à moins que vous en ayez besoin pour faire une véritable sauvegarde.

2015? PostgreSQL 9.5? pg_rewind?

Un des problèmes restants est que la promotion d'un secours rend l'ancien primaire incapable de changer de cap et de suivre le nouveau primaire. Si vous basculez parce que l'ancien primaire est mort, alors ce n'est pas un problème. Mais si vous voulez juste échanger le primaire et le secours, peut-être parce que le secours dispose d'un matériel plus puissant, l'ancien primaire, désormais un secours, doit être reconstruit entièrement à partir de zéro. Transformer un ancien primaire en un nouveau secours sans une nouvelle sauvegarde complète de base est un problème assez complexe, mais un outil qui peut le faire (actuellement nommé pg_rewind ) est proposé pour inclusion dans la prochaine version de PostgreSQL.

Au-delà

Un des problèmes que cette évolution de la réplication a créés est que la configuration est plutôt idiosyncratique, assez compliquée à mettre en place correctement, et presque impossible à généraliser suffisamment pour la documentation, les tutoriels,... Supprimer l'archivage avec 9.4 pourrait résoudre certains de ces points, mais configurer rien que la réplication par flux est toujours étrange, et encore plus étrange si vous ne savez pas comment tout cela est arrivé jusqu'ici. Vous devez modifier plusieurs paramètres obscurs de configuration, certains sur le primaire, certains sur le secours, dont certains nécessitent un redémarrage complet du serveur primaire. Et ensuite vous avez besoin de créer un nouveau fichier de configuration recovery.conf, même si vous ne voulez pas de récupérer quoi que ce soit. Apporter des changements dans ce domaine est essentiellement un processus politique complexe, parce que le système actuel a bien servi les gens pendant de nombreuses années, et arriver avec un nouveau système qui est objectivement meilleur et adresse tous les cas d'utilisation existants est lourd.

Un autre problème est que toutes ces fonctionnalités se basent fortement sur le mécanisme de WAL, et cela contraint tous les usages du WAL de diverses manières. Par exemple, il y a des optimisations qui ne passent pas par la journalisation WAL dans certaines circonstances, mais si vous voulez de la réplication, vous ne pouvez pas les utiliser. Qui ne veut pas faire de la réplication ? En plus, le WAL couvre un système de base de données complet et marche en tout ou rien. Vous ne pouvez pas répliquer seulement certaines tables, par exemple, ou consolider les journaux provenant de deux sources différentes.

Que diriez-vous de ne pas tout baser sur le WAL? Avoir deux journaux différents pour deux objectifs différents. Cela a été discuté, en particulier au moment où la réplication par flux a été construite. Mais alors vous avez besoin de deux journaux qui sont quasiment identiques. Et le WAL est par conception un goulot d'étranglement, alors créer un autre journal créerait probablement des problèmes de performance.

Le décodage logique brise nombre de ces restrictions et sera probablement la fondation pour le prochain tour des fonctionnalités majeures de réplication. Par exemple, la réplication partielle et la réplication multi-maître, certaines étant déjà en cours d'élaboration.

Que pouvons-nous attendre de la journalisation WAL pure et simple en attendant ? Une configuration plus facile est demandée fréquemment. Mais peut-on s'attendre à des sauts importants en terme de fonctionnalité? Qui sait. Il fut un temps, quelque chose comme la secours automatique était vu comme presque impossible. Donc il pourrait encore y avoir des surprises.

vendredi 7 mars 2014

PostgreSQL : configuration de l'environnement psql

Quand il s'agit de configurer et manipuler une base de données, rien de mieux que d'utiliser le client sql en mode texte qui permet de manipuler directement les objets de la base dans tous les sens. Concernant PostgreSQL, le client psql est aussi complet qu'un client SQL*Plus pour Oracle Database par exemple.

Il s'agit de configurer correctement psql pour être plus productif. Pour cela, on stockera dans ~/.psqlrc la configuration de base qui sera chargée à chaque lancement de psql.

Voici mon fichier de configuration ~/.psqlrc que j'utilise tous les jours:

\set QUIET ON

\set PROMPT1 '%n@%M %~%R%# '
\set PAGER OFF
\set HISTFILE ~/.psql_history- :HOST - :DBNAME
\set HISTSIZE 2000
\set ECHO_HIDDEN ON
\set COMP_KEYWORD_CASE upper
\timing on
\encoding unicode
\pset null 'NULL'
\pset border 1

\set QUIET OFF

\echo 'Predefined queries:\n'
\echo '\t\t\t:settings\t-- Server Settings'
\echo '\t\t\t:dbsize\t\t-- Database Size'
\echo '\t\t\t:tablesize\t-- Tables Size'
\echo '\t\t\t:uptime\t\t-- Server uptime'

\set settings 'select name, setting,unit,context from pg_settings;'

\set dbsize 'SELECT datname, pg_size_pretty(pg_database_size(datname)) db_size FROM pg_database ORDER BY db_size;'

\set tablesize 'SELECT nspname || \'.\' || relname AS \"relation\", pg_size_pretty(pg_relation_size(C.oid)) AS "size" FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN (\'pg_catalog\', \'information_schema\') ORDER BY pg_relation_size(C.oid) DESC LIMIT 40;'

\set uptime 'select now() - pg_postmaster_start_time() AS uptime;'


Faites \? sous psql pour voir quel est le sens de chaque instruction. A noter le moyen bien pratique pour enregistrer des requêtes prédéfinies dans des variables.

Sous windows, ce fichier n'est pas dans %HOME%\.psqlrc mais à %APPDATA%\postgresql\psqlrc.conf On peut aussi indiquer explicitement où se trouve le fichier .psqlrc en mettant son chemin complet dans la variable d'environnement PSQLRC.

Une autre configuration intéressante est l'instruction \x qui permet d'indiquer vouloir afficher les lignes de données en colonne plutôt qu'en ligne : pratique quand on est en présence de lignes assez longues.