De nombreux articles traitent de la promotion d’un serveur de secours PostgreSQL en serveur principal avec la commande pg_ctl promote. Beaucoup d’entre eux concluent que le serveur de secours doit être reconstruit lorsque le serveur principal est de retour. Qu’en est-il d’une maintenance programmée, maintenance incluant des arrêts, sur le serveur primaire ? Doit-on reconstruire le système primaire/standby ? Évidemment la réponse est : NON. En supposant qu’il y a suffisamment d’espace disque pour conserver les fichiers WAL pendant la tâche de maintenance, en gérant prudemment le point de réplication (replication slot) et l’option de récupération recovery_timeline_target durant les procédures failover/failback, il n’y a pas besoin de reconstruire le système standby impliquant des sauvegardes/restaurations de bases de données et/ou d’utiliser pg_rewind.

La mise en route de la réplication en continu (streaming replication) avec PostgreSQL 9.6 sur des serveurs Linux Ubuntu 18.04 est très simple. Dans la réplication en continu, le serveur de standby se connecte au serveur primaire, lequel diffuse les enregistrements WAL (Write Ahead Log) au serveur de standby au fur et à mesure qu’ils sont générés, sans attendre que le fichier WAL soit rempli. La réplication en continu permet à un serveur de standby de rester plus à jour que ce qui est possible avec le transfert des journaux. Le serveur de standby peut être en lecture seule (read only) pour le reporting par exemple. Un point de replication (replication slot) garantit que les fichiers WAL nécessaires au serveur de standby ne sont pas supprimés dans le serveur primaire avant leur traitement par le serveur de standby. Plusieurs points de réplication peuvent être définis en fonction du nombre de serveurs standby.

Un guide rapide pour construire une base de données PostgreSQL 9.6 sur Ubuntu 18.04, guide incluant normalisation et personnalisation (port, répertoires des fichiers de configuration et de bases de données…). L’utilitaire historique pg_ctl demeure en charge de la gestion d’une base PostgreSQL (démarrage, arrêt, redémarrage…).