architecture de haute disponibilité · cherslectrices&lecteurs,...

ModuleW1

Architecture de haute disponibilité

20.06

Dalibo SCOP

https://dalibo.com/formations


Module W1

TITRE : Architecture de haute disponibilitéSOUS-TITRE : Module W1

REVISION: 20.06DATE: 10 juin 2020COPYRIGHT: © 2005-2020 DALIBO SARL SCOPLICENCE: Creative Commons BY-NC-SA

Le logo éléphant de PostgreSQL (« Slonik ») est une création sous copyright et le nom« PostgreSQL » est une marque déposée par PostgreSQL Community Association ofCanada.

Remerciements : Ce manuel de formation est une aventure collective qui se transmet ausein de notre société depuis des années. Nous remercions chaleureusement ici toutesles personnes qui ont contribué directement ou indirectement à cet ouvrage, notam-ment : Jean-Paul Argudo, AlexandreAnriot, Carole Arnaud, Alexandre Baron, David Bidoc,Sharon Bonan, Franck Boudehen, Damien Clochard, Christophe Courtois, Marc Cousin,Gilles Darold, Jehan-Guillaume de Rorthais, Ronan Dunklau, Vik Fearing, Stefan Fercot,Pierre Giraud, Nicolas Gollet, Dimitri Fontaine, Florent Jardin, Virginie Jourdan, DenisLaxalde, Guillaume Lelarge, Benoit Lobréau, Jean-Louis Louër, Thibaut Madelaine, AdrienNayrat, Flavie Perette, Thomas Reiss, Maël Rimbault, Julien Rouhaud, Stéphane Schild-knecht, Julien Tachoires, Nicolas Thauvin, Christophe Truffier, Cédric Villemain, ThibaudWalkowiak, Frédéric Yhuel.

À propos de DALIBO :

DALIBO est le spécialiste français de PostgreSQL. Nous proposons du support, de la for-mation et du conseil depuis 2005.

Retrouvez toutes nos formations sur https://dalibo.com/formations

https://dalibo.com/formations

LICENCE CREATIVE COMMONS BY-NC-SA 2.0 FR

Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions

Vous êtes autorisé à :

• Partager, copier, distribuer et communiquer le matériel par tous moyens et soustous formats

• Adapter, remixer, transformer et créer à partir du matériel

Dalibo ne peut retirer les autorisations concédées par la licence tant que vous appliquezles termes de cette licence selon les conditions suivantes :

Attribution : Vous devez créditer l’œuvre, intégrer un lien vers la licence et indiquer si desmodifications ont été effectuées à l’œuvre. Vous devez indiquer ces informations par tousles moyens raisonnables, sans toutefois suggérer que Dalibo vous soutient ou soutient lafaçon dont vous avez utilisé ce document.

Pas d’Utilisation Commerciale: Vous n’êtes pas autorisé à faire un usage commercial de cedocument, tout ou partie du matériel le composant.

Partage dans les Mêmes Conditions : Dans le cas où vous effectuez un remix, que voustransformez, ou créez à partir du matériel composant le document original, vous devezdiffuser le document modifié dans les même conditions, c’est à dire avec la même licenceavec laquelle le document original a été diffusé.

Pas de restrictions complémentaires : Vous n’êtes pas autorisé à appliquer des conditionslégales ou des mesures techniques qui restreindraient légalement autrui à utiliser le doc-ument dans les conditions décrites par la licence.

Note : Ceci est un résumé de la licence. Le texte complet est disponible ici :

https://creativecommons.org/licenses/by-nc-sa/2.0/fr/legalcode

Pour toute demande au sujet des conditions d’utilisation de ce document, envoyez vosquestions à [email protected] !

https://creativecommons.org/licenses/by-nc-sa/2.0/fr/legalcode

[email protected]

Chers lectrices & lecteurs,

Nos formations PostgreSQL sont issues de plus de 12 ans d’études, d’expérience deterrain et de passion pour les logiciels libres. Pour Dalibo, l’utilisation de PostgreSQLn’est pas une marque d’opportunisme commercial, mais l’expression d’un engagementde longue date. Le choix de l’Open Source est aussi le choix de l’implication dans lacommunauté du logiciel.

Au-delà du contenu technique en lui-même, notre intention est de transmettre les valeursqui animent et unissent les développeurs de PostgreSQL depuis toujours : partage, ou-verture, transparence, créativité, dynamisme... Le but premier de nos formations est devous aider à mieux exploiter toute la puissance de PostgreSQL mais nous espérons égale-ment qu’elles vous inciteront à devenir un membre actif de la communauté en partageantà votre tour le savoir-faire que vous aurez acquis avec nous.

Nous mettons un point d’honneur à maintenir nos manuels à jour, avec des informationsprécises et des exemples détaillés. Toutefois malgré nos efforts et nos multiples relec-tures, il est probable que ce document contienne des oublis, des coquilles, des impréci-sions ou des erreurs. Si vous constatez un souci, n’hésitez pas à le signaler via l’[email protected] !

mailto:[email protected]

Table des Matières

Licence Creative Commons BY-NC-SA 2.0 FR 5

1 Architectures de Haute-Disponibilité 101.1 Préambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Rappels théoriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 Réplication interne physique . . . . . . . . . . . . . . . . . . . . . . . . 181.4 Réplication interne logique . . . . . . . . . . . . . . . . . . . . . . . . . 241.5 Réplication externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.6 Sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.7 Réplication bas niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

9


1 ARCHITECTURES DE HAUTE-DISPONIBILITÉ

1.1 PRÉAMBULE

• Attention au vocabulaire !• Identifier le besoin• Keep It Simple...

La réplication est le processus de partage d’informations permettant de garantir la sécuritéet la disponibilité des données entre plusieurs serveurs et plusieurs applications. ChaqueSGBD dispose de différentes solutions pour cela et introduit sa propre terminologie. Lesexpressions telles que « cluster », « actif/passif » ou « primaire/secondaire » peuvent avoirun sens différent selon le SGBD choisi. Dès lors, il devient difficile de comparer et desavoir ce que désignent réellement ces termes. C’est pourquoi nous débuterons ce mod-ule par un rappel théorique et conceptuel. Nous nous attacherons ensuite à citer les outilsde réplication, internes et externes.

10

1. ARCHITECTURES DE HAUTE-DISPONIBILITÉ

1.1.1 AUMENU

• Rappels théoriques• Réplication interne

– réplication physique– réplication logique (v10)

• Quelques logiciels externes de réplication• Alternatives

Dans cette présentation, nous reviendrons rapidement sur la classification des solutionsde réplication, qui sont souvent utilisés dans un but de haute disponibilité, mais pasuniquement.

PostgreSQL dispose d’une réplication physique basée sur le rejeu des journaux de trans-actions par un serveur dit « en standby ». Nous présenterons ainsi les techniques dites deWarm Standby et de Hot Standby.

Il dispose aussi depuis la version 10 d’une réplication logique. Elle sera aussi présentée.

Nous détaillerons ensuite les projets de réplication autour de PostgreSQL les plus en vueactuellement.

1.1.2 OBJECTIFS

• Identifier les différences entre les solutions de réplication proposées• Choisir le système le mieux adapté à votre besoin

La communauté PostgreSQL propose plusieurs réponses aux problématiques de réplica-tion. Le but de cette présentation est de vous apporter les connaissances nécessairespour comparer chaque solution et comprendre les différences fondamentales qui les sé-parent.

À l’issue de cette présentation, vous serez capable de choisir le système de réplicationqui correspond le mieux à vos besoins et aux contraintes de votre environnement deproduction.

https://dalibo.com/formations11


1.2 RAPPELS THÉORIQUES

• Termes• Réplication

– synchrone / asynchrone– symétrique / asymétrique– diffusion des modifications

Le domaine de la haute-disponibilité est couvert par un bon nombre de termes qu’il estpréférable de définir avant de continuer.

1.2.1 CLUSTER, PRIMAIRE, SECONDAIRE, STANDBY...

• Cluster :– groupe de bases de données = 1 instance (PostgreSQL)– groupe de serveurs (haute-disponibilité et/ou réplication)

• Pour désigner les membres :– Primaire/maître– Secondaire/standby/esclave

Toute la documentation (anglophone) de PostgreSQL parle de cluster dans le contexte d’unserveur PostgreSQL seul. Dans ce contexte, le cluster est un groupe de bases de données,groupe étant la traduction directe de cluster. En français, on évitera tout ambiguïté enparlant d’« instance ».

Dans le domaine de la haute-disponibilité et de la réplication, un cluster désigne un groupede serveurs. Par exemple, un groupe d’un serveur primaire et de ses deux serveurs sec-ondaires compose un cluster de réplication.

Le serveur, généralement unique, ouvert en écriture est désigné comme « primaire » (pri-mary) ou « maître » (master). Les serveurs connectés dessus sont « secondaires » (sec-ondary) ou « standby » (prêts à prendre le relai). Les termes « maître/esclave » sont à évitermais encore très courants. On trouvera dans le présent cours aussi bien « primaire/sec-ondaire » que « principal/standby ».

12


1.2.2 RÉPLICATION ASYNCHRONE ASYMÉTRIQUE

• Asymétrique– écritures sur un serveur primaire unique– lectures sur le primaire et/ou les secondaires

• Asynchrone– les écritures sur les serveurs secondaires sont différées– perte de données possible en cas de crash du primaire

• Quelques exemples– streaming replication, Slony, Bucardo

Dans la réplication asymétrique, seul le serveur primaire accepte des écritures, et lesserveurs secondaires ne sont accessibles qu’en lecture.

Dans la réplication asynchrone, les écritures sont faites sur le primaire et, avant qu’ellesne soient poussées vers le secondaire, le client a un retour lui indiquant que l’écritures’est bien passée. La mise à jour des tables répliquées est différée (asynchrone). Elle estréalisée par un programmateur de tâches, possédant une horloge. Des points de synchro-nisation sont utilisés pour propager les changements.

L’inconvénient de ce système est que, si un crash intervient sur le primaire après quele client ait eu la réponse du succès de l’écriture mais avant que les données ne soientpoussées sur le secondaire, certaines données validées sur le primaire ne seront pasdisponibles sur le secondaire. Autrement dit, il existe une fenêtre, plus ou moins impor-tante, de perte de données.

1.2.3 RÉPLICATION ASYNCHRONE SYMÉTRIQUE



• Symétrique– « multi-maîtres »– écritures sur les différents primaires– besoin d’un gestionnaire de conflits– lectures sur les différents primaires

• Asynchrone– les écritures sur les secondaires sont différées– perte de données possible en cas de crash du serveur primaire– Risque d’incohérences !

• Exemples :– BDR (2nd Quadrant) : réplication logique– Bucardo : réplication par triggers

Dans la réplication symétrique, tous les serveurs sont accessibles aux utilisateurs, aussibien en lecture qu’en écriture. On parle souvent alors de « multi-maîtres ».

La réplication asynchrone, comme indiquée précédemment, met en attente l’envoi desmodifications sur les secondaires, donc il y a toujours un risque de perte de donnéespourtant validées si le serveur primaire tombe sans avoir eu le temps d’envoyer les don-nées à au moins un serveur secondaire

Ce mode de réplication ne respecte généralement pas les propriétés ACID (atomicité, co-hérence, isolation, durabilité) car si une copie échoue sur l’autre primaire alors que latransaction a déjà été validée, on peut alors arriver dans une situation où les donnéessont incohérentes entre les serveurs.

Généralement, ce type de système doit proposer un gestionnaire de conflits, depréférence personnalisable.

Pour tenter d’y parvenir, BDR1 , de 2ndQuadrant, se base sur la réplication logique et uneextension propre au-dessus de PostgreSQL. BDR assure une réplication symétrique detoutes les données concernées entre de nombreuses instances, et s’adresse notammentau cas de bases dont on a besoin dans des lieux géographiquement très éloignés. Lagestion des conflits est automatique, mais les verrous ne sont pas propagés par un choixdélibéré (It is a deliberate design choice by Postgres-BDR to not propagate lock informationsince it would cause an unacceptable performance loss across long distance network links.), cequi peut donc poser des problèmes d’intégrité et l’application doit en tenir compte. Ladocumentation recommande par exemple de privilégier les UUID pour éviter les conflits.BDR offre le choix entre slow/consistent (lent et cohérent) et fast/eventually consistent(rapide et peut-être cohérent). Les premières versions de BDR étaient sous licence libre,mais ne sont plus supportées, et la version actuelle (BDR v3) n’est pas libre.

1https://www.2ndquadrant.com/en/resources/postgres-bdr-2ndquadrant/

14

https://www.2ndquadrant.com/en/resources/postgres-bdr-2ndquadrant/

https://www.2ndquadrant.com/en/resources/postgres-bdr-2ndquadrant/


Bucardo2 se base, lui, sur de la réplication par triggers. Il sera évoqué plus loin.

1.2.4 RÉPLICATION SYNCHRONE ASYMÉTRIQUE

• Asymétrique– écritures sur un serveur primaire unique– lectures sur le serveur primaire et/ou les secondaires

• Synchrone– les écritures sur les secondaires sont immédiates– le client sait si sa commande a réussi sur le serveur secondaire

Dans la réplication asymétrique, seul le serveur primaire accepte des écritures, et les sec-ondaires ne sont accessibles qu’en lecture.

Dans la réplication synchrone, le client envoie sa requête en écriture sur le serveur pri-maire, le serveur primaire l’écrit sur son disque, il envoie les données au serveur sec-ondaire attend que ce dernier l’écrive sur son disque. Si tout ce processus s’est bien passé,le client est averti que l’écriture a été réalisée avec succès. On utilise généralement unmécanisme dit de Two Phase Commit ou « Validation en deux phases », qui assure qu’unetransaction est validée sur tous les nœuds dans la même transaction. Les propriétés ACIDsont dans ce cas respectées.

Le gros avantage de ce système est qu’il n’y a pas de risque de perte de données quandle serveur primaire s’arrête brutalement et qu’on doive repartir sur le serveur secondaire.L’inconvénient majeur est que cela ralentit fortement les écritures.

Ce type de réplication garantit que le serveur secondaire a bien écrit la transaction dansses journaux et qu’elle a été synchronisée sur disque (fsync). En revanche elle ne garantitpas que le secondaire a bien rejoué la transaction. Il peut se passer un laps de temps trèscourt où une lecture sur le secondaire serait différente du serveur primaire (le temps quele secondaire rejoue la transaction).

2https://www.bucardo.org/Bucardo/


https://www.bucardo.org/Bucardo/

https://www.bucardo.org/Bucardo/


1.2.5 RÉPLICATION SYNCHRONE SYMÉTRIQUE

• Symétrique– écritures sur les différents serveurs primaires– besoin d’un gestionnaire de conflits– lectures sur les différents primaires

• Synchrone– les écritures sur les serveurs secondaires sont immédiates– le client sait si sa commande a réussi sur le secondaire– risque important de lenteur

Ce système est le plus intéressant... en théorie. L’utilisateur peut se connecter à n’importequel serveur pour des lectures et des écritures. Il n’y a pas de risques de perte de don-nées vu que la commande ne réussit que si les données sont bien enregistrées sur tousles serveurs. Autrement dit, c’est le meilleur système de réplication et de répartition decharge.

Dans les inconvénients, il faut gérer les éventuels conflits qui peuvent survenir quanddeux transactions concurrentes opèrent sur le même ensemble de lignes. On résout cescas particuliers avec des algorithmes plus ou moins complexes. Il faut aussi accepter laperte de performance en écriture induite par le côté synchrone du système.

PostgreSQL ne supporte pas la réplication symétrique, mais certains projets essaientd’apporter cette fonctionnalité. Citons deux exemples :

Un fork de PostgreSQL existe, nommé Postgres-X23 (anciennement « Postgres-XC »). Cen’est pas un choix pérenne : il est basé sur PostgreSQL 9.3, ce qui signifie que sa base decode est périmée depuis 2018. Par ailleurs, c’est un projet qui nécessite un investissementtrès important en terme de matériel et maintenance opérationnelle. Vous ne bénéficiezpas des nouveautés depuis la 9.3. Enfin, et c’est le plus grave, il n’a plus l’air maintenu.

Pgpool semblait prometteur, mais certaines fonctions (notamment le load-balancing et laréplication) se révèlent souvent complexes à mettre en œuvre, difficile à stabiliser et lim-itées à des cas d’utilisation très spécifiques. Malgré son ancienneté il y a encore beaucoupde corrections de bugs à chaque mise à jour.

Le besoin d’une architecture « multi-maîtres » revient régulièrement, mais il faut s’assurerqu’il est réel. Avant d’envisager une architecture complexe, et donc source d’erreurs, op-timisez une installation asymétrique simple et classique, testez ses performances : Post-greSQL pourrait bien vous surprendre.

3https://github.com/postgres-x2/postgres-x2

16

https://github.com/postgres-x2/postgres-x2

https://github.com/postgres-x2/postgres-x2


1.2.6 DIFFUSION DESMODIFICATIONS

• Par requêtes– diffusion de la requête

• Par triggers– diffusion des données résultant de l’opération

• Par journaux, physique– diffusion des blocs disques modifiés

• Par journaux, logique– extraction et diffusion des données résultant de l’opération depuis les jour-

naux

La récupération des données de réplication se fait de différentes façons suivant l’outilutilisé.

La diffusion de l’opération de mise à jour (donc le SQL lui-même) est très flexible et com-patible avec toutes les versions. Cependant, cela pose la problématique des opérationsdites non déterministes. L’insertion de la valeur now() exécutée sur différents serveursfera que les données seront différentes, généralement très légèrement différentes, maisdifférentes malgré tout. L’outil pgpool, qui implémente cette méthode de réplication, estcapable de récupérer l’appel à la fonction now() pour la remplacer par la date et l’heure. Ilest capable de le faire car il connaît les différentes fonctions de date et heure proposéesen standard par PostgreSQL. Cependant, il ne connaît pas les fonctions utilisateurs quipourraient faire de même. Il est donc préférable de renvoyer les données, plutôt que lesrequêtes.

Le renvoi du résultat peut se faire de deux façons : soit en récupérant les nouvelles don-nées avec un trigger, soit en récupérant les nouvelles données dans les journaux de trans-actions.

Cette première solution est utilisée par un certain nombre d’outils externes de réplica-tion, comme Slony ou Bucardo. Les fonctions triggers étant écrites en C, cela assure debonnes performances. Cependant, seules les modifications des données sont attrapablesavec des triggers. Les modifications de la structure de la base ne le sont pas (l’ajout destriggers sur événement en 9.3 est une avancée intéressante pour permettre ce genre defonctionnalités dans le futur). Autrement dit, l’ajout d’une table, l’ajout d’une colonnedemande une administration plus poussée, non automatisable.

La deuxième solution (par journaux de transactions) est bien plus intéressante car lesjournaux contiennent toutes les modifications, données comme structures. De ce fait,une fois mise en place, elle ne demande pas une grosse administration.

Depuis PostgreSQL 9.4, un nouveau niveau logical a été ajouté dans le paramétrage



des journaux de transactions (paramètre wal_level). Couplé à l’utilisation des slots deréplication (nouveau paramètre max_replication_slots), il permet le décodage logiquedes modifications de données correspondant aux blocs modifiés dans les journaux detransactions. L’objectif était de permettre la reconstitution d’un ordre SQL permettantd’obtenir le même résultat, ce qui permettrait la mise en place d’une réplication logiquedes résultats entièrement intégrée, donc sans triggers. En pratique, ceci est disponibledepuis la version 10 de PostgreSQL.

1.3 RÉPLICATION INTERNE PHYSIQUE

• Réplication– asymétrique– asynchrone ou synchrone

• Secondaires– non disponibles (Warm Standby)– disponibles en lecture seule (Hot Standby)– cascade– retard programmé

La réplication interne est par défaut asynchrone et asymétrique. Le mode synchroneest disponible à partir de la version 9.1. Il est même possible de sélectionner le modesynchrone/asynchrone pour chaque serveur secondaire individuellement, et séparémentpour chaque transaction.

Il fonctionne par l’envoi des enregistrements des journaux de transactions, soit parenvoi de fichiers complets (on parle de Log Shipping), soit par envoi de groupesd’enregistrements en flux (on parle là de Streaming Replication), puisqu’il s’agit d’uneréplication par diffusion de journaux.

La différence entre Warm Standby et Hot Standby est très simple :

• un serveur secondaire enWarm Standby est un serveur de secours sur lequel il n’estpas possible de se connecter ;

• un serveur secondaire en Hot Standby accepte les connexions et permet l’exécutionde requêtes en lecture seule.

Un secondaire peut récupérer les informations de réplication depuis un autre serveursecondaire (fonctionnement en cascade, à partir de la 9.2).

Le serveur secondaire peut appliquer les informations de réplication après un délai con-figurable (depuis la 9.4).

18


1.3.1 LOG SHIPPING

• But– envoyer les journaux de transactions à un secondaire

• Première solution disponible (dès 2006)• Gros inconvénients

– il est possible de perdre un journal de transactions entier– latence à la réplication– penser à archive_timeout ou pg_receivewal

Le Log Shipping permet d’envoyer les journaux de transactions terminés sur un autreserveur. Ce dernier peut être un serveur secondaire, enWarm Standby ou en Hot Standby,prêt à les rejouer.

Cependant, son gros inconvénient vient du fait qu’il faut attendre qu’un journal soit com-plètement écrit pour qu’il soit propagé vers le secondaire. Autrement dit, il est possiblede perdre les transactions contenues dans le journal de transactions en cours en cas defailover.

Sans même ce problème, cela veut aussi dire que le retard du serveur secondaire sur leserveur primaire peut être assez important, ce qui est gênant dans le cas d’un standbyqu’on peut utiliser en lecture seule, par exemple dans le cadre d’une répartition de lacharge de lecture.

On peut cependant moduler le risque de trois façons:

• sauf avarie très grave sur le serveur primaire, le journal de transactions courant peutêtre récupéré et appliqué sur le serveur secondaire ;

• on peut réduire la fenêtre temporelle de la réplication en modifiant la valeur dela clé de configuration archive_timeout... au delà du délai exprimé avec cettevariable de configuration, le serveur change de journal de transactions, provoquantl’archivage du précédent. On peut par exemple envisager un archive_timeout à30 secondes, et ainsi obtenir une réplication à 30 secondes près ;

• on peut utiliser l’outil pg_receivewal (nommé pg_receivexlog jusqu’en 9.6) quicrée à distance les journaux de transactions à partir d’un flux de réplication.



1.3.2 STREAMING REPLICATION

• But– avoir un retard moins important sur le serveur primaire

• Rejouer les enregistrements de transactions du serveur primaire par paquets– paquets plus petits qu’un journal de transactions

• Solution idéalement couplée au Hot Standby

L’objectif du mécanisme de Streaming Replication est d’avoir un secondaire qui accusemoins de retard. En effet, dans le cas du Log Shipping, il faut attendre qu’un journal soitcomplètement rempli avant qu’il ne soit envoyé au serveur secondaire. Un journal peutcontenir plusieurs centaines de transactions, ce qui veut dire qu’en cas de crash du serveurprimaire, si ce dernier n’a pas eu le temps de transférer le dernier journal, on peut avoirperdu plusieurs centaines de transactions. Le Streaming Replication diminue ce retard enenvoyant les enregistrements des journaux de transactions par groupe bien inférieur àun journal complet. Il introduit aussi deux processus gérant le transfert entre le serveurprimaire et le serveur secondaire. Ainsi, en cas de perte du serveur primaire, la perte dedonnées est très faible.

Les délais de réplication entre le serveur primaire et le serveur secondaire sont très courts.Couplée au Hot Standby, cette technologie a rendu obsolète certains systèmes de répli-cation, utilisés bien souvent avec deux nœuds (un serveur primaire et un serveur sec-ondaire) : unemodification sur le serveur primaire sera en effet très rapidement visible surun secondaire, en lecture seule. Néanmoins, cette solution a ses propres inconvénients :réplication de l’instance complète, architecture forcément identique entre les serveurs ducluster, etc.

1.3.3 WARM STANDBY

• Intégré à PostgreSQL depuis la 8.2• Serveur de secours en cas de panne• Le secondaire est identique au serveur primaire

– à quelques transactions près• En pratique, préférer le Hot Standby

Le Warm Standby existe depuis la version 8.2. La robustesse de ce mécanisme simple estprouvée depuis longtemps.

Les journaux de transactions (généralement appelés WAL, pour Write Ahead Log) sont im-médiatement envoyés au serveur secondaire après leur écriture. Le serveur secondaire

20


est dans unmode spécial d’attente (le mode de restauration), et lorsqu’un journal de trans-actions est reçu, il est automatiquement appliqué au serveur secondaire

Cependant, les installations récentes préfèrent paramétrer directement les secondairesen Hot Standby.

1.3.4 HOT STANDBY

• Évolution du Warm Standby• Basé sur le même mécanisme• Le serveur secondaire est ouvert aux connexions

– et aux requêtes en lecture seule• Différentes configurations

– asynchrone ou synchrone– application immédiate ou retardée

LeHot Standby (apparu en 9.0) est une évolution duWarm Standby en ce sens qu’il comblele gros défaut du Warm Standby. Un serveur secondaire en Hot Standby accepte les con-nexions des utilisateurs et permet d’exécuter des requêtes en lecture seule.



1.3.5 EXEMPLE

Cet exemple montre un serveur primaire en streaming replication vers un serveur sec-ondaire. Ce dernier est en plus en Hot Standby. De ce fait, les utilisateurs peuvent seconnecter sur le serveur secondaire pour les requêtes en lecture et sur le primaire pourdes lectures comme des écritures. Cela permet une forme de répartition de charge sur leslectures, la répartition étant gérée par le serveur d’applications ou par un outil spécialisé.

22


1.3.6 RÉPLICATION INTERNE



1.3.7 RÉPLICATION EN CASCADE

1.4 RÉPLICATION INTERNE LOGIQUE

• Réplique les changements– sur une seule base de données– d’un ensemble de tables défini

• Principe Éditeur/Abonnés

Contrairement à la réplication physique, la réplication logique ne réplique pas les blocs dedonnées. Elle décode le résultat des requêtes qui sont transmis au secondaire. Celui-ciapplique les modifications SQL issues du flux de réplication logique.

La réplication logique utilise un système de publication/abonnement avec un ou plusieursabonnés qui s’abonnent à une ou plusieurs publications d’un nœud particulier.

Une publication peut être définie sur n’importe quel serveur primaire de réplicationphysique. Le nœud sur laquelle la publication est définie est nommé éditeur. Le nœudoù un abonnement a été défini est nommé abonné.

24


Une publication est un ensemble de modifications générées par une table ou un groupede table. Chaque publication existe au sein d’une seule base de données.

Un abonnement définit la connexion à une autre base de données et un ensemble depublications (une ou plus) auxquelles l’abonné veut souscrire.

1.4.1 RÉPLICATION LOGIQUE - FONCTIONNEMENT

• Création d’une publication sur un serveur• Souscription d’un autre serveur à cette publication

Une publication est créée sur le serveur éditeur.

L’abonné souscrit à cette publication, c’est un « souscripteur ».

Un processus spécial est lancé : le bgworker logical replication. Il va se connecterà un slot de réplication sur le serveur éditeur.

Le serveur éditeur va procéder à un décodage logique des journaux de transaction pourextraire les résultats des ordres SQL.

Le flux logique est transmis à l’abonné qui les applique sur les tables.

1.4.2 RÉPLICATION LOGIQUE - LIMITATIONS

• Non répliqués :– Schémas

* uniquement INSERT / UPDATE / DELETE

* ni TRUNCATE en v10– Séquences– Large objects

• Pas de publication des tables parentes du partitionnement• Ne convient pas comme failover

La réplication logique est disponible depuis PostgreSQL 10.

Seules les données sont répliquées, c’est-à-dire le contenu des ordres INSERT, DELETE etUPDATE.

Le schéma de la base de données ainsi que les commandes DDL ne sont pas répliquées(ni même TRUNCATE avec PostgreSQL 10).



Le schéma initial peut être créé en utilisant par exemple pg_dump --schema-only. Ilfaudra dès lors répliquer manuellement les changements de structure.

Il n’est pas obligatoire de conserver strictement la même structure des deux côtés. Afinde conserver sa cohérence, la réplication s’arrêtera en cas de conflit.

Il est d’ailleurs nécessaire d’avoir des contraintes de type PRIMARY KEY ou UNIQUE et NOTNULL pour permettre la propagation des ordres UPDATE et DELETE.

Les triggers des tables abonnées ne seront pas déclenchés par les modifications reçuesvia la réplication.

En cas d’utilisation du partitionnement, il n’est pas possible d’ajouter des tables parentesdans la publication.

Les large objects ne sont pas répliqués. Les séquences non plus, y compris celles utiliséesdes colonnes de type serial.

De manière générale, il serait possible d’utiliser la réplication logique en vue d’un failoververs un serveur de secours en propageant manuellement les mises à jour de séquenceset de schéma. La réplication physique est cependant plus appropriée pour cela.

La réplication logique vise d’autres objectifs, tels la génération de rapports sur une in-stance séparée ou la mise à jour de version majeure de PostgreSQL avec une indisponibil-ité minimale.

1.5 RÉPLICATION EXTERNE

• Un très large choix d’outils !• Les plus connus :

– pgpool– Slony / Bucardo– pgLogical

On dénombre plus de 15 projets de réplication externe pour PostgreSQL. Jusqu’en 2010,PostgreSQL ne disposait pas d’un système de réplication évolué, ce qui explique en partieune telle profusion de solutions. Bien sûr, l’arrivée de la réplication interne physique (avecles technologies Hot Standby et streaming replication) change la donne mais ne remet pasen cause l’existence de tous ces projets. Par contre, l’arrivée de la réplication logique enversion 10 risque de les mettre à mal.

La liste exhaustive est trop longue pour que l’on puisse évoquer en détail chacune dessolutions, surtout que certaines sont considérées maintenant comme obsolètes ou ne

26


semblent plus maintenues. Voici les plus connues :

• Slony• Bucardo• pgpool• Londiste• PGCluster• Mammoth Replicator• Daffodil Replicator• RubyRep• pg_comparator• Postgres-X2 (ex-Postgres-XC)

L’essentiel est donc de trouver le logiciel adapté à votre besoin... et d’être conscient deses limites !Plus de détails à cette adressea .

1.6 SHARDING

• Répartition des données sur plusieurs instances• Évolution horizontale en ajoutant des serveurs• Parallélisation• Clé de répartition cruciale• Administration complexifiée• Sous PostgreSQL :

– Foreign Data Wrapper– PL/Proxy– Citus (extension), et nombreux forks

Le sharding n’est pas de la réplication, ce serait même l’inverse. Le principe consiste àrépartir les données sur plusieurs instances différentes, chacune étant responsable d’unepartie des données, et ouverte en écriture.

La volumétrie peut augmenter, il suffit de rajouter des serveurs. Plusieurs serveurs peu-vent travailler en parallèle sur la même requête. On contourne ainsi le principal gouletd’étranglement des performances : les entrées-sorties.

Le problème fondamental est la clé de répartitions des données sur les différents serveurs.Un cas simple est la répartition des données de nombreux clients dans plusieurs instances,

ahttps://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling


https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling


chaque client n’étant présent que dans une seule instance. On peut aussi opérer une sortede hash de la clé pour répartir équitablement les données sur les serveurs. Il faut aviseren fonction de la charge prévue, de la nécessité d’éviter les conflits lors des mises à jour,du besoin de croiser les données en masse, des purges à faire de temps à autre, et de lamanière de répartir harmonieusement les écritures et lectures entre ces instances. C’estau client ou à une couche d’abstraction de savoir quel(s) serveur(s) interroger.

PostgreSQL n’implémente pas directement le sharding. Plusieurs techniques et outils per-mettent de le mettre en place.

• Les Foreign Data Wrappers (et l’extension postgres_fdw en particulier) vouspermettent d’accéder à des données présentes sur d’autres serveurs. La ca-pacité de postgres_fdw à « pousser » filtres et jointures vers les serveursdistants s’améliore de version en version. Des tables distantes peuvent êtremontées en tant que partitions d’une table mère. En version 11, les insertionsdans une table partitionnée peuvent même redirigées vers une partition dis-tante de manière transparente. Vous trouverez un exemple dans cet article :https://pgdash.io/blog/postgres-11-sharding.html. La réplication logique peutservir à synchroniser des tables non distribuées sur les instances. Le partition-nement des tables au sein d’une instance est une option. Il reste cependant deslimites : la parallélisation des requêtes transverses n’est pas réelle ; on ne peutposer d’index global sur une table partitionnée possédant des partitions distantes ;le DDL reste manuel.

• PL/Proxy est une extension qui permet d’appeler plusieurs hôtes distants à la foisavec un seul appel de fonctions. Elle existe depuis des années. Son inconvénientmajeur est la nécessité de réécrire tous les appels à distribuer par des fonctions, onne peut se reposer sur le SQL de manière transparente.

• Citus4 est une extension, dont la version de base est libre, mais dont toutes lespossibilités ne sont disponibles que dans la version payante. Le but est de rendrele sharding transparent, permettant de garder la compatibilité avec le SQL habituel.Des nœuds sont déclarés auprès du serveur principal (où les clients se connectent),et quelques fonctions permettent de déclarer les tables comme distribuées selonune clé (et découpées entre les serveurs) ou tables de références (dupliquéespartout pour faciliter les jointures). Les requêtes sont redirigées vers le bon serveurselon la clé, ou réellement parallélisées sur les différents serveurs concernés. Leprojet est vivant, bien documenté, et a bonne réputation. Microsoft a acheté Citusen janvier 2019, ce qui pose question sur la pérennité de l’équipe et du produit.

Le sharding permet d’obtenir des performances impressionnantes, mais il a ses incon-

4https://www.citusdata.com/product

28

https://pgdash.io/blog/postgres-11-sharding.html

https://www.citusdata.com/product

https://www.citusdata.com/product


vénients :

• Plus de serveurs implique plus de sources de problèmes, de supervision, detâches d’administration (chaque serveur a potentiellement son secondaire, saréplication...) ;

• Le modèle de données doit être adapté au problème, limitant les interactions d’unnœud avec les autres ; le choix de la clé est crucial ;

• Les propriétés ACID et la cohérence sont plus difficilement respectées dans cesenvironnements.

Historiquement, plusieurs forks de PostgreSQL ont été développés en partie pour fairedu sharding, principalement en environnement OLAP/décisionnel, comme PostgreSQL-XC/XL5 ou Greenplum6 . Ces forks ont plus ou moins de difficultés à suivre la rapiditéd’évolution de la version communautaire : les choisir implique de se passer de certainesnouveautés. D’où le choix de Citus de la forme d’une extension.

Ce domaine est l’un de ceux où PostgreSQL devrait beaucoup évoluer dans les années àvenir, comme le décrivait Bruce Momjian en septembre 20187 .

1.7 RÉPLICATION BAS NIVEAU

• RAID• DRBD• SAN Mirroring• À prendre évidemment en compte...

Cette présentation est destinée à détailler les solutions logicielles de réplication pour Post-greSQL, uniquement. On peut tout de même évoquer les solutions de réplication de « basniveau », voire matérielles.

De nombreuses techniques matérielles viennent en complément essentiel des technolo-gies de réplication utilisées dans la haute disponibilité. Leur utilisation est généralementobligatoire, du RAID en passant par les SAN et autres techniques pour redonderl’alimentation, la mémoire, les processeurs, etc.

5https://www.postgres-xl.org/6https://greenplum.org/7https://momjian.us/main/writings/pgsql/sharding.pdf


https://www.postgres-xl.org/


https://greenplum.org/

https://momjian.us/main/writings/pgsql/sharding.pdf


https://greenplum.org/

https://momjian.us/main/writings/pgsql/sharding.pdf


1.7.1 RAID

• Obligatoire• Fiabilité d’un serveur• RAID 1 ou RAID 10• RAID 5 déconseillé (performances)• Lectures plus rapides

– dépend du nombre de disques impliqués

Un système RAID 1 ou RAID 10 permet d’écrire les mêmes données sur plusieurs disquesen même temps. Si un disque meurt, il est possible d’utiliser l’autre disque pour contin-uer. C’est de la réplication bas niveau. Le disque défectueux peut être remplacé sansinterruption de service. Ce n’est pas une réplication entre serveurs mais cela contribue àla haute-disponibilité du système.

Le RAID 5 offre les mêmes avantages en gaspillant moins d’espace qu’un RAID 1, mais ilest déconseillé pour les bases de données (PostgreSQL comme ses concurrents) à causedes performances en écriture, au quotidien comme lors de la reconstruction d’une grappeaprès remplacement d’un disque.

Le système RAID 10 est plus intéressant pour les fichiers de données alors qu’un systèmeRAID 1 est suffisant pour les journaux de transactions.

Le RAID 0 (simple addition de disques sans redondance) est évidemment à proscrire.

1.7.2 DRBD

• Simple / synchrone / Bien documenté• Lent / Secondaire inaccessible / Linux uniquement

DRBD est un outil capable de répliquer le contenu d’un périphérique blocs. En ce sens,ce n’est pas un outil spécialisé pour PostgreSQL contrairement aux autres outils vus dansce module. Il peut très bien servir à répliquer des serveurs de fichiers ou de mails. Ilréplique les données en temps réel et de façon transparente, pendant que les applicationsmodifient leur fichiers sur un périphérique. Il peut fonctionner de façon synchrone ouasynchrone. Tout ça en fait donc un outil intéressant pour répliquer le répertoire desdonnées de PostgreSQL.

Pour plus de détails, consulter cet articlea .

ahttps://www.dalibo.org/hs45_drbd_la_replication_des_blocs_disques

30

https://www.dalibo.org/hs45_drbd_la_replication_des_blocs_disques

https://www.dalibo.org/hs45_drbd_la_replication_des_blocs_disques


DRBD est un système simple àmettre en place. Son gros avantage est la possibilité d’avoirune réplication synchrone, son inconvénient direct est sa lenteur et la non-disponibilitédes secondaires.

1.7.3 SANMIRRORING

• Comparable à DRBD• Solution intégrée• Manque de transparence

La plupart des constructeurs de baie de stockage propose des systèmes de réplicationautomatisé avec des mécanismes de failover/failback parfois sophistiqués. Ces solutionsprésentent généralement les mêmes caractéristiques que DRBD. Ces technologies ont enrevanche le défaut d’être opaques et de nécessiter unemain d’œuvre hautement qualifiée.

1.8 CONCLUSION

Points essentiels :• bien définir son besoin• identifier tous les SPOF• superviser son cluster• tester régulièrement les procédures de Failover ( Loi de Murphy...)

1.8.1 BIBLIOGRAPHIE

• Doc officielle : Chapitre 25• Hors série « Haute-disponibilité avec PostgreSQL » dans GNU/Linux France Mag-

azine

• « 25. Haute disponibilité, répartition de charge et réplication8 ». PGDG, 2010• « Haute-disponibilité avec PostgreSQL9 ». Guillaume Lelarge, 2009

Iconographie :

8https://docs.postgresql.fr/10/high-availability.html9https://www.dalibo.org/haute_disponibilite_avec_postgresql


https://docs.postgresql.fr/10/high-availability.html

https://www.dalibo.org/haute_disponibilite_avec_postgresql

https://docs.postgresql.fr/10/high-availability.html

https://www.dalibo.org/haute_disponibilite_avec_postgresql


• La photo initiale10 est sous licence CC-BY.

1.8.2 QUESTIONS

N’hésitez pas, c’est le moment !

10http://www.flickr.com/photos/epsos/3574411866/

32

http://www.flickr.com/photos/epsos/3574411866/

http://www.flickr.com/photos/epsos/3574411866/

NOS AUTRES PUBLICATIONS

FORMATIONS

• DBA1 : Administra on PostgreSQLhttps://dali.bo/dba1

• DBA2 : Administra on PostgreSQL avancéhttps://dali.bo/dba2

• DBA3 : Sauvegardes et réplica on avec PostgreSQLhttps://dali.bo/dba3

• DEVPG : Développer avec PostgreSQLhttps://dali.bo/devpg

• DEVSQLPG : SQL pour PostgreSQLhttps://dali.bo/devsqlpg

• PERF1 : PostgreSQL Performanceshttps://dali.bo/perf1

• PERF2 : Indexa on et SQL avancéhttps://dali.bo/perf2

• MIGORPG : Migrer d’Oracle vers PostgreSQLhttps://dali.bo/migorpg

LIVRES BLANCS

• Migrer d’Oracle à PostgreSQL

• Industrialiser PostgreSQL

• Bonnes pra ques de modélisa on avec PostgreSQL

• Bonnes pra ques de développement avec PostgreSQL

TÉLÉCHARGEMENT GRATUIT

Les versions électroniques de nos publica ons sont disponibles gratuitement sous licenceopen-source ou sous licence Crea ve Commons. Contactez-nous à l’adresse [email protected] pour plus d’informa on.

https://dali.bo/dba1



https://dali.bo/devpg

https://dali.bo/devsqlpg

https://dali.bo/perf1

https://dali.bo/perf2

https://dali.bo/migorpg



DALIBO, L’EXPERTISE POSTGRESQL

Depuis 2005, DALIBOmet à la disposi on de ses clients son savoir-faire dans le domainedes bases de données et propose des services de conseil, de forma on et de support auxentreprises et aux ins tu onnels.

En parallèle de son ac vité commerciale, DALIBO contribue aux développements de lacommunauté PostgreSQL et par cipe ac vement à l’anima on de la communauté fran-cophone de PostgreSQL. La société est également à l’origine de nombreux ou ls libres desupervision, de migra on, de sauvegarde et d’op misa on.

Le succès de PostgreSQL démontre que la transparence, l’ouverture et l’auto-ges on sontà la fois une source d’innova on et un gage de pérennité. DALIBO a intégré ces principesdans son ADN en optant pour le statut de SCOP : la société est contrôlée à 100 % parses salariés, les décisions sont prises collec vement et les bénéfices sont partagés à partségales.

architecture de haute disponibilité · cherslectrices&lecteurs,...

Documents