PostgreSQL et la streaming replication

PostgreSQL et la 

streaming replication 

Stefan Fercot 

19 mai 2016

Sommaire 

• PostgreSQL, c’est quoi ? 

• Installation 

• Fonctionnement interne 

• Méthodes de sauvegarde (dumps, point-in-time recovery, streaming replication) 

• Streaming replication : retour d’expérience d’utilisation dans un environnement de 

type « cluster » 

• Quelques chiffres des volumétries gérées

PostgreSQL, c’est quoi ?

PostgreSQL 

• Système de base de données libre 

• Au sein des différentes communautés libres, PostgreSQL est souvent utilisé comme 

exemple à différents niveaux 

• qualité du code 

• indépendance des développeurs et gouvernance du projet 

• réactivité de la communauté 

• stabilité et puissance du logiciel 

• Tous ces atouts font que PostgreSQL est désormais reconnu et adopté par des milliers de 

grandes sociétés de par le monde

Histoire 

• L'origine du nom PostgreSQL remonte à la base de données Ingres, développée à l'université de Berkeley 

par Michael Stonebraker. En 1985, il prend la décision de reprendre le développement à partir de zéro et 

nomme ce nouveau logiciel Postgres, comme raccourci de post-Ingres. 

• En 1995, avec l'ajout du support du langage SQL, postgres fut renommé Postgres95 puis PostgreSQL. 

• Aujourd'hui, le nom officiel est “PostgreSQL” (prononcez “post - gresse - Q - L”). Cependant, le nom 

“Postgres” est accepté comme alias. 

• http://www.postgresql.org/about/history

Communauté 

• ~ 2000 : Communauté japonaise (aujourd’hui plus de 3000 membres) 

• 2004 : Communauté francophone (http://www.postgresql.fr/) 

• 2006 : « Software in the Public Interest » 

• 2007 : Communauté italienne 

• 2008 : PostgreSQL Europe et US 

• 2009 : Boom des PGDay

Versions 

• 2010 : v9.0 → réplication intégrée 

• version 9.1.22, 9.2.17, 9.3.13, 9.4.8, 9.5.3 

• http://www.postgresql.org/support/versioning/

Références 

• Sponsors 

• http://www.postgresql.org/about/sponsors/ 

• Skype, VMware, Dalibo, Fujitsu, RedHat 

• Utilisateurs clé 

• http://www.postgresql.org/about/users/ 

• U.S. General Services Administration, Apple, Cisco,… 

• Yahoo, Instagram, Zalando, TripAdvisor 

• Le Bon Coin (http://www.postgresqlfr.org/temoignages:le_bon_coin)

Installation

Méthodes 

• Sources 

• Doc : http://docs.postgresql.fr/9.5/installation.html 

• Téléchargement : http://www.postgresql.org/download/ 

• Yum 

• Doc : https://wiki.postgresql.org/wiki/YUM_Installation

• Installation moteur 

• Création utilisateur 

• Création du répertoire de données 

• Démarrage 

Etapes

Yum

Fonctionnement interne

PGdata

Configuration 

• pg_hba.conf : règles d'authentification 

• pg_ident.conf : configuration mécanisme d'authentification extérieur 

• postgresql.conf : paramétrage

Mémoire 

• Données en cache : shared_buffers 

• Mémoire de travail des transactions : work_mem

WAL 

• Write Ahead Logs, (appelés parfois WAL ou XLOG) 

• Journaux de transactions 

• Garantie contre les pertes de données 

• Modification de données sur disque en 2 temps 

• Mécanisme d’archivage/recyclage 

• http://www.dalibo.org/glmf108_postgresql_et_ses_journaux_de_transactions

Checkpoint 

• Processus s’assurant que tous les fichiers de données, écrits sur le disque, 

ont été mis à jour pour refléter l'information des journaux de transaction 

• checkpoint_timeout = 15min 

• checkpoint_completion_target = 0.9

ACID 

• Atomicité (Atomic) 

• Une transaction est entière : « tout ou rien ». 

• Cohérence (Consistent) 

• Une transaction amène le système d'un état stable à un autre. 

• Isolation (Isolated) 

• Les transactions n'agissent pas les unes sur les autres. 

• Durabilité (Durable) 

• Une transaction validée provoque des changements permanents.

MultiVersion Concurrency Control (MVCC) 

• MVCC (Multi Version Concurrency Control) est le mécanisme interne de 

PostgreSQL utilisé pour garantir la cohérence des données lorsque plusieurs 

processus accèdent simultanément à la même table. 

• Chaque transaction travaille dans son image de la base, cohérent du début à la fin 

de ses opérations. 

• Une lecture ne bloque pas une écriture 

• Une écriture ne bloque pas une lecture 

• Une écriture ne bloque pas les autres écritures… 

• … sauf pour la mise à jour de la même ligne.

Méthodes de sauvegarde

Méthodes 

• Sauvegarde à froid des fichiers (ou physique) 

• Sauvegarde à chaud en SQL (ou logique) 

• Sauvegarde à chaud des fichiers (PITR)

pg_dump 

• Sauvegarde une base de données à chaud 

• Sauvegarde complète ou partielle 

• pg_dump est l'outil le plus utilisé pour sauvegarder une base de données 

PostgreSQL 

• pg_dump b1 > b1.dump 

• sauvegardera la base b1 de l'instance locale sur le port 5432 dans un fichier b1.dump

Point In Time Recovery 

• Sauvegarde traditionnelle 

• sauvegarde pg_dump à chaud 

• sauvegarde des fichiers à froid 

• Insuffisant pour les grosses bases 

• long à sauvegarder 

• encore plus long à restaurer 

• Perte de données potentiellement importante 

• car impossible de réaliser fréquemment une sauvegarde


• Les journaux de transactions contiennent toutes les modifications 

• Il faut les archiver 

• … et avoir une image des fichiers à un instant t 

• La restauration se fait en restaurant cette image 

• … et en rejouant les journaux 

• entièrement 

• partiellement (ie, jusqu'à un certain moment) 

• PITR = archivage continu et récupération d'un instantané


• archive_command = 'cp %p /mnt/backup/WAL/%f‘ 

• archive_timeout = 900 

• archive_mode = on 

• wal_level = archive

Streaming replication 

• Serveur standby (read-only) se connecte au primaire 

• Serveur primaire envoie au standby les enregistrements de WAL dès qu'ils 

sont générés, sans attendre qu'un fichier de WAL soit rempli 

• Archivage ou wal_keep_segments en cas de forte désynchronisation 

• Asynchrone par défaut

Streaming replication



• Etape 1 

• Créer dossier partagé entre les serveurs maître-esclave 

• Etape 2 

• Créer utilisateur PostgreSQL pour la réplication 

• sudo -u postgres createuser -SRD --replication -P replication 

• Autoriser l’accès dans pg_hba.conf 

• host replication replication IP_esclave/32 md5


• Etape 3 

• Modifier postgresql.conf sur le maître 

• listen_addresses = '*' 

• hot_standby = on 

• wal_level = hot_standby 

• archive_mode = on 

• archive_command = 'cp %p /DIR/%f‘ #Répertoire DIR partagé entre les serveurs maître-esclave 

• archive_timeout = 900 

• max_wal_senders=5 

• wal_keep_segments = 32 

• wal_sender_timeout = 60s


• Etape 4 

• Initier la réplication sur l’esclave 

• systemctl stop postgresql-9.5 

• rm -rf /PGdata/* 

• pg_basebackup -h IP_maître -U replication -D PGdata -X stream -P


• Créer recovery.conf sur l’esclave 

• standby_mode = 'on' 

• primary_conninfo = 'host=IP_maître port=5432 user=replication password=xxx application_name=NAME' 

• restore_command = 'cp /DIR/%f %p' 

• recovery_target_timeline = 'latest' 

• archive_cleanup_command = 'pg_archivecleanup /DIR %r' 

#Répertoire DIR partagé entre les serveurs maître-esclave

Retour d’expérience


• Utilisation dans un environnement de type « cluster » 

• Haute-disponibilité 

• Bascule automatique des ressources avec RHEL cluster 

• http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster


Quelques chiffres des volumétries gérées 

• Le Bon Coin : ~3To (160 cœurs, 1To RAM) 

• Max 250Go, moyenne 150Go, accroissement annuel 30Go 

• Exemples 

• 200Go : 24 cpu (6 cores physiques * 2 logique * 2 hyper-threading), 96G ram 

• 250Go : 8 vcpu, 40G ram. 200-500 iops

Demo

Sources 

• Formations http://www.dalibo.com/ 

• http://docs.postgresql.fr 

• http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster

Questions ?

PostgreSQL et la streaming replication

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?