La mise en place d’une r\u00e9plication entre deux bases de donn\u00e9es offre une tol\u00e9rance aux pannes contre les impr\u00e9vus. Elle est consid\u00e9r\u00e9e comme la meilleure strat\u00e9gie pour obtenir une haute disponibilit\u00e9 en cas de sinistre.<\/p>\n
Dans cet article, nous allons nous plonger dans les diff\u00e9rentes strat\u00e9gies qui peuvent \u00eatre mises en \u0153uvre par les d\u00e9veloppeurs backend<\/a> pour une r\u00e9plication PostgreSQL transparente. La r\u00e9plication PostgreSQL est d\u00e9finie comme le processus de copie des donn\u00e9es d’un serveur de base de donn\u00e9es PostgreSQL<\/a> vers un autre serveur. Le serveur de base de donn\u00e9es source est \u00e9galement connu sous le nom de serveur \u00ab primaire \u00bb, tandis que le serveur de base de donn\u00e9es recevant les donn\u00e9es copi\u00e9es est connu sous le nom de serveur \u00ab r\u00e9plique \u00bb.<\/p>\n La base de donn\u00e9es PostgreSQL suit un mod\u00e8le de r\u00e9plication simple, o\u00f9 toutes les \u00e9critures vont vers un n\u0153ud primaire. Le n\u0153ud primaire peut ensuite appliquer ces modifications et les diffuser aux n\u0153uds secondaires.<\/p>\n Le basculement est une m\u00e9thode permettant de r\u00e9cup\u00e9rer les donn\u00e9es si le serveur primaire s’arr\u00eate<\/a> pour une raison quelconque. Tant que vous avez configur\u00e9 PostreSQL pour g\u00e9rer la r\u00e9plication de votre flux physique, vous – et vos utilisateurs – serez prot\u00e9g\u00e9s des temps d’arr\u00eat dus \u00e0 une d\u00e9faillance du serveur primaire.<\/p>\n Notez que le processus de basculement peut prendre un certain temps \u00e0 configurer et \u00e0 lancer. Il n’existe pas d’outils int\u00e9gr\u00e9s pour la surveillance et la port\u00e9e des pannes de serveur dans PostgreSQL, vous devrez donc faire preuve de cr\u00e9ativit\u00e9.<\/p>\n Heureusement, vous ne devez pas \u00eatre d\u00e9pendant de PostgreSQL pour le basculement. Il existe des outils d\u00e9di\u00e9s qui permettent le basculement automatique et la commutation automatique sur le serveur de secours, r\u00e9duisant ainsi les temps d’arr\u00eat de la base de donn\u00e9es<\/a>.<\/p>\n En mettant en place la r\u00e9plication par basculement, vous garantissez pratiquement la haute disponibilit\u00e9 en vous assurant que les serveurs de secours sont disponibles si le serveur primaire s’effondre un jour.<\/p>\n Voici quelques avantages cl\u00e9s de l’utilisation de la r\u00e9plication PostgreSQL :<\/p>\n En g\u00e9n\u00e9ral, les gens pensent que quand on s’amuse avec une architecture primaire et secondaire, il n’y a qu’une seule fa\u00e7on de configurer les sauvegardes<\/a> et la r\u00e9plication. Les d\u00e9ploiements PostgreSQL, cependant, peuvent suivre n’importe laquelle de ces trois m\u00e9thodes<\/a> :<\/p>\n La r\u00e9plication en continu PostgreSQL, \u00e9galement connue sous le nom de r\u00e9plication WAL, peut \u00eatre configur\u00e9e de mani\u00e8re transparente apr\u00e8s l’installation de PostgreSQL sur tous les serveurs. Cette approche de la r\u00e9plication est bas\u00e9e sur le d\u00e9placement des fichiers WAL de la base de donn\u00e9es primaire vers la base de donn\u00e9es cible.<\/p>\n Vous pouvez impl\u00e9menter la r\u00e9plication en continu PostgreSQL en utilisant une configuration primaire-secondaire. Le serveur primaire est l’instance principale qui g\u00e8re la base de donn\u00e9es primaire et toutes ses op\u00e9rations. Le serveur secondaire agit en tant qu’instance suppl\u00e9mentaire et ex\u00e9cute toutes les modifications apport\u00e9es \u00e0 la base de donn\u00e9es primaire sur lui-m\u00eame, g\u00e9n\u00e9rant une copie identique dans le processus. Le serveur primaire est le serveur de lecture\/\u00e9criture tandis que le serveur secondaire est simplement en lecture seule.<\/p>\n Pour cette m\u00e9thode, vous devez configurer \u00e0 la fois le n\u0153ud primaire et le n\u0153ud de secours. Les sections suivantes expliquent les \u00e9tapes \u00e0 suivre pour les configurer facilement.<\/p>\n Vous pouvez configurer le n\u0153ud primaire pour la r\u00e9plication en continu en effectuant les \u00e9tapes suivantes :<\/p>\n Pour initialiser la base de donn\u00e9es<\/a>, vous pouvez utiliser la commande utilitaire L’utilisateur devra fournir un mot de passe et un nom d’utilisateur pour la requ\u00eate donn\u00e9e. Le mot-cl\u00e9 de r\u00e9plication est utilis\u00e9 pour donner \u00e0 l’utilisateur les privil\u00e8ges requis. Un exemple de requ\u00eate ressemblerait \u00e0 ceci :<\/p>\n Ensuite, vous pouvez configurer les propri\u00e9t\u00e9s de streaming avec le fichier de configuration de PostgreSQL (postgresql.conf<\/strong>) qui peut \u00eatre modifi\u00e9 comme suit :<\/p>\n Voici un peu de contexte autour des param\u00e8tres utilis\u00e9s dans le snippet pr\u00e9c\u00e9dent :<\/p>\n Apr\u00e8s avoir modifi\u00e9 les param\u00e8tres dans le fichier postgresql.conf<\/strong>, une nouvelle entr\u00e9e de r\u00e9plication dans le fichier pg_hba.conf<\/strong> peut permettre aux serveurs d’\u00e9tablir une connexion entre eux pour la r\u00e9plication.<\/p>\n Vous pouvez g\u00e9n\u00e9ralement trouver ce fichier dans le r\u00e9pertoire de donn\u00e9es de PostgreSQL. Vous pouvez utiliser l’extrait de code suivant pour ce faire :<\/p>\n Une fois que le bout de code est ex\u00e9cut\u00e9, le serveur primaire permet \u00e0 un utilisateur appel\u00e9 Pour configurer le n\u0153ud de standby pour la r\u00e9plication en continu, suivez ces \u00e9tapes :<\/p>\n Pour configurer le n\u0153ud de secours, exploitez l’utilitaire Les param\u00e8tres utilis\u00e9s dans la syntaxe mentionn\u00e9e ci-dessus sont les suivants :<\/p>\n Ensuite, vous devez v\u00e9rifier si le fichier de configuration de r\u00e9plication existe. S’il n’existe pas, vous pouvez g\u00e9n\u00e9rer le fichier de configuration de r\u00e9plication en tant que recovery.conf<\/strong>.<\/p>\n Vous devez cr\u00e9er ce fichier dans le r\u00e9pertoire de donn\u00e9es de l’installation PostgreSQL. Vous pouvez le g\u00e9n\u00e9rer automatiquement en utilisant l’option Le fichier recovery.conf<\/strong> doit contenir les commandes suivantes :<\/p>\n Les param\u00e8tres utilis\u00e9s dans les commandes susmentionn\u00e9es sont les suivants :<\/p>\n Pour \u00e9tablir une connexion, vous devez fournir le nom d’utilisateur, l’adresse IP et le mot de passe comme valeurs pour le param\u00e8tre primary_conninfo. Par exemple :<\/p>\n Enfin, vous pouvez red\u00e9marrer le serveur secondaire pour terminer le processus de configuration.<\/p>\n Cependant, la r\u00e9plication en continu s’accompagne de plusieurs d\u00e9fis, tels que :<\/p>\n La m\u00e9thode du dispositif de blocs r\u00e9pliqu\u00e9s d\u00e9pend de la mise en miroir des disques (\u00e9galement connue sous le nom de r\u00e9plication de volume). Dans cette approche, les modifications sont \u00e9crites sur un volume persistant qui est mis en miroir de mani\u00e8re synchrone sur un autre volume.<\/p>\n L’avantage suppl\u00e9mentaire de cette m\u00e9thode\u00a0est sa compatibilit\u00e9 et la durabilit\u00e9 des donn\u00e9es dans les environnements de cloud avec toutes les bases de donn\u00e9es relationnelles, y compris PostgreSQL, MySQL et SQL Server<\/a>, pour n’en citer que quelques-unes.<\/p>\n Cependant, m\u00e9thode\u00a0de la r\u00e9plication PostgreSQL par miroir de disque n\u00e9cessite que vous r\u00e9pliquiez \u00e0 la fois le journal WAL et les donn\u00e9es de table. Comme chaque \u00e9criture dans la base de donn\u00e9es doit maintenant passer par le r\u00e9seau de mani\u00e8re synchrone, vous ne pouvez pas vous permettre de perdre un seul octet, car cela pourrait laisser votre base de donn\u00e9es dans un \u00e9tat corrompu.<\/p>\n Cette m\u00e9thode\u00a0est normalement exploit\u00e9e en utilisant Azure PostgreSQL et Amazon RDS.<\/p>\n WAL se compose de fichiers de segments (16 Mo par d\u00e9faut). Chaque segment comporte un ou plusieurs enregistrements. Un enregistrement de s\u00e9quence de journal (LSN) est un pointeur vers un enregistrement dans WAL, vous permettant de conna\u00eetre la position\/l’emplacement o\u00f9 l’enregistrement a \u00e9t\u00e9 sauvegard\u00e9 dans le fichier journal.<\/p>\n Un serveur de secours exploite les segments WAL – \u00e9galement connus sous le nom de XLOGS dans la terminologie PostgreSQL – pour r\u00e9pliquer en continu les modifications de son serveur primaire. Vous pouvez utiliser la journalisation write-ahead pour garantir la durabilit\u00e9 et l’atomicit\u00e9 d’un SGBD en s\u00e9rialisant des morceaux de donn\u00e9es de type byte-array (chacun avec un LSN unique) dans un stockage stable avant qu’ils ne soient appliqu\u00e9s \u00e0 une base de donn\u00e9es.<\/p>\n L’application d’une mutation \u00e0 une base de donn\u00e9es peut entra\u00eener diverses op\u00e9rations sur le syst\u00e8me de fichiers. Une question pertinente qui se pose est de savoir comment une base de donn\u00e9es peut assurer l’atomicit\u00e9 en cas de d\u00e9faillance du serveur due \u00e0 une panne de courant alors qu’elle est en pleine mise \u00e0 jour du syst\u00e8me de fichiers. Lorsqu’une base de donn\u00e9es d\u00e9marre, elle lance un processus de d\u00e9marrage ou de relecture qui peut lire les segments WAL disponibles et les compare avec le LSN stock\u00e9 sur chaque page de donn\u00e9es (chaque page de donn\u00e9es est marqu\u00e9e avec le LSN du dernier enregistrement WAL qui affecte la page).<\/p>\n La r\u00e9plication en continu affine le processus d’exp\u00e9dition des journaux. Au lieu d’attendre le changement de WAL, les enregistrements sont envoy\u00e9s au fur et \u00e0 mesure de leur cr\u00e9ation, ce qui r\u00e9duit le d\u00e9lai de r\u00e9plication.<\/p>\n La r\u00e9plication en continu l’emporte \u00e9galement sur l’exp\u00e9dition de journaux, car le serveur en attente se lie au serveur primaire sur le r\u00e9seau en tirant parti d’un protocole de r\u00e9plication. Le serveur primaire peut alors envoyer des enregistrements WAL directement sur cette connexion sans avoir \u00e0 d\u00e9pendre de scripts fournis par l’utilisateur final.<\/p>\n L’exp\u00e9dition de journaux est d\u00e9finie comme la copie des fichiers journaux vers un autre serveur PostgreSQL pour g\u00e9n\u00e9rer un autre serveur de secours en rejouant les fichiers WAL. Ce serveur est configur\u00e9 pour fonctionner en mode de r\u00e9cup\u00e9ration, et son seul but est d’appliquer tous les nouveaux fichiers WAL au fur et \u00e0 mesure qu’ils apparaissent.<\/p>\n Ce serveur secondaire devient alors une sauvegarde \u00e0 chaud du serveur PostgreSQL primaire. Il peut \u00e9galement \u00eatre configur\u00e9 pour \u00eatre une r\u00e9plique en lecture, o\u00f9 il peut offrir des requ\u00eates en lecture seule, \u00e9galement appel\u00e9 hot standby.<\/p>\n Dupliquer les fichiers WAL \u00e0 mesure qu’ils sont cr\u00e9\u00e9s dans un emplacement autre que le sous-r\u00e9pertoire Le script peut s’appuyer sur la commande D’autres configurations bas\u00e9es sur les journaux incluent :<\/p>\n Un processus connu sous le nom de r\u00e9cepteur WAL, ex\u00e9cut\u00e9 sur le serveur de secours, exploite les d\u00e9tails de connexion fournis dans le param\u00e8tre Pour lancer la r\u00e9plication en continu, le frontend peut envoyer le param\u00e8tre de r\u00e9plication dans le message de d\u00e9marrage. Une valeur bool\u00e9enne de true, yes, 1, ou ON permet au backend<\/a> de savoir qu’il doit passer en mode walsender de r\u00e9plication physique.<\/p>\n L’exp\u00e9diteur WAL est un autre processus qui s’ex\u00e9cute sur le serveur primaire et qui est charg\u00e9 d’envoyer les enregistrements WAL au serveur de secours au fur et \u00e0 mesure qu’ils sont g\u00e9n\u00e9r\u00e9s. Le r\u00e9cepteur WAL enregistre les enregistrements WAL dans le WAL comme s’ils \u00e9taient cr\u00e9\u00e9s par l’activit\u00e9 des clients connect\u00e9s localement.<\/p>\n Une fois que les enregistrements WAL atteignent les fichiers de segment WAL, le serveur de standby continue de rejouer constamment le WAL afin que le primaire et le standby soient \u00e0 jour.<\/p>\n Dans cette section, vous allez acqu\u00e9rir une compr\u00e9hension plus approfondie des mod\u00e8les (r\u00e9plication mono-ma\u00eetre et multi-ma\u00eetre), des types (r\u00e9plication physique et logique) et des modes (synchrone et asynchrone) couramment utilis\u00e9s pour la r\u00e9plication PostgreSQL.<\/p>\n L’\u00e9volutivit\u00e9 consiste \u00e0 ajouter plus de ressources\/mat\u00e9riel aux n\u0153uds existants afin d’am\u00e9liorer la capacit\u00e9 de la base de donn\u00e9es \u00e0 stocker et \u00e0 traiter plus de donn\u00e9es, ce qui peut \u00eatre r\u00e9alis\u00e9 horizontalement et verticalement. La r\u00e9plication PostgreSQL est un exemple d’\u00e9volutivit\u00e9 horizontale qui est beaucoup plus difficile \u00e0 mettre en \u0153uvre que l’\u00e9volutivit\u00e9 verticale. Nous pouvons r\u00e9aliser l’extensibilit\u00e9 horizontale principalement par la r\u00e9plication \u00e0 ma\u00eetre unique (SMR) et la r\u00e9plication \u00e0 ma\u00eetre multiple (MMR).<\/p>\n La r\u00e9plication \u00e0 ma\u00eetre unique permet aux donn\u00e9es d’\u00eatre modifi\u00e9es uniquement sur un seul n\u0153ud, et ces modifications sont r\u00e9pliqu\u00e9es sur un ou plusieurs n\u0153uds. Les tables r\u00e9pliqu\u00e9es dans la base de donn\u00e9es r\u00e9pliqu\u00e9e ne sont pas autoris\u00e9es \u00e0 accepter des modifications, sauf celles provenant du serveur primaire. M\u00eame si elles le font, les modifications ne sont pas r\u00e9pliqu\u00e9es vers le serveur primaire.<\/p>\n La plupart du temps, SMR est suffisant pour l’application car il est moins compliqu\u00e9 \u00e0 configurer et \u00e0 g\u00e9rer, sans risque de conflits. La r\u00e9plication \u00e0 ma\u00eetre unique est \u00e9galement unidirectionnelle, puisque les donn\u00e9es de r\u00e9plication circulent dans une seule direction principalement, de la base de donn\u00e9es primaire \u00e0 la base de donn\u00e9es r\u00e9plique.<\/p>\n Dans certains cas, SMR seul peut ne pas \u00eatre suffisant, et vous pouvez avoir besoin de mettre en \u0153uvre MMR. MMR permet \u00e0 plus d’un n\u0153ud d’agir en tant que n\u0153ud primaire. Les modifications apport\u00e9es aux lignes des tables dans plus d’une base de donn\u00e9es primaire d\u00e9sign\u00e9e sont r\u00e9pliqu\u00e9es vers leurs tables homologues dans toutes les autres bases de donn\u00e9es primaires. Dans ce mod\u00e8le, des sch\u00e9mas de r\u00e9solution de conflits sont souvent employ\u00e9s pour \u00e9viter les probl\u00e8mes tels que les cl\u00e9s primaires dupliqu\u00e9es.<\/p>\n L’utilisation du mod\u00e8le MMR pr\u00e9sente quelques avantages, \u00e0 savoir :<\/p>\n Cependant, l’inconv\u00e9nient de la mise en \u0153uvre de MMR est sa complexit\u00e9 et sa difficult\u00e9 \u00e0 r\u00e9soudre les conflits.<\/p>\n Plusieurs branches et applications fournissent des solutions MMR car PostgreSQL ne le supporte pas nativement. Ces solutions peuvent \u00eatre open source<\/a>, gratuites ou payantes. Une de ces extensions<\/a> est la r\u00e9plication bidirectionnelle (BDR) qui est asynchrone et qui est bas\u00e9e sur la fonction de d\u00e9codage logique de PostgreSQL.<\/p>\n Puisque l’application BDR r\u00e9plique les transactions sur d’autres n\u0153uds, l’op\u00e9ration de r\u00e9plication peut \u00e9chouer s’il y a un conflit entre la transaction appliqu\u00e9e et la transaction commise sur le n\u0153ud r\u00e9cepteur.<\/p>\n Il existe deux types de r\u00e9plication PostgreSQL : la r\u00e9plication logique et la r\u00e9plication physique.<\/p>\n Une simple op\u00e9ration logique<\/em> La r\u00e9plication physique traite g\u00e9n\u00e9ralement des fichiers et des r\u00e9pertoires. Elle ne sait pas ce que ces fichiers et r\u00e9pertoires repr\u00e9sentent. Ces m\u00e9thodes sont utilis\u00e9es pour maintenir une copie compl\u00e8te de l’ensemble des donn\u00e9es d’un seul cluster, g\u00e9n\u00e9ralement sur une autre machine. Elles sont effectu\u00e9es au niveau du syst\u00e8me de fichiers ou du disque et utilisent des adresses de bloc exactes.<\/p>\n La r\u00e9plication logique est un moyen de reproduire des entit\u00e9s de donn\u00e9es et leurs modifications, sur la base de leur identit\u00e9 de r\u00e9plication (g\u00e9n\u00e9ralement une cl\u00e9 primaire). Contrairement \u00e0 la r\u00e9plication physique, elle traite des bases de donn\u00e9es, des tables et des op\u00e9rations DML et se fait au niveau du cluster de base de donn\u00e9es. Elle utilise un mod\u00e8le de publication<\/em> et d’abonnement<\/em> o\u00f9 un ou plusieurs abonn\u00e9s<\/em> sont abonn\u00e9s \u00e0 une ou plusieurs publications<\/em> sur un n\u0153ud \u00e9diteur<\/em>.<\/p>\n Le processus de r\u00e9plication commence par prendre un instantan\u00e9 des donn\u00e9es sur la base de donn\u00e9es de l’\u00e9diteur, puis le copie sur l’abonn\u00e9. Les abonn\u00e9s tirent les donn\u00e9es des publications auxquelles ils sont abonn\u00e9s et peuvent republier les donn\u00e9es ult\u00e9rieurement pour permettre une r\u00e9plication en cascade ou des configurations plus complexes. L’abonn\u00e9 applique les donn\u00e9es dans le m\u00eame ordre que l’\u00e9diteur, de sorte que la coh\u00e9rence transactionnelle est garantie pour les publications au sein d’un m\u00eame abonnement ; c’est ce qu’on appelle la r\u00e9plication transactionnelle.<\/p>\n Les cas d’utilisation typiques de la r\u00e9plication logique sont les suivants :<\/p>\n La base de donn\u00e9es de l’abonn\u00e9 se comporte de la m\u00eame mani\u00e8re que toute autre instance PostgreSQL et peut \u00eatre utilis\u00e9e comme \u00e9diteur pour d’autres bases de donn\u00e9es en d\u00e9finissant ses publications.<\/p>\n Lorsque l’abonn\u00e9 est trait\u00e9 en lecture seule par l’application, il n’y aura pas de conflits \u00e0 partir d’un seul abonnement. Par contre, s’il y a d’autres \u00e9critures effectu\u00e9es soit par une application, soit par d’autres abonn\u00e9s sur le m\u00eame ensemble de tables, des conflits peuvent survenir.<\/p>\n PostgreSQL supporte les deux m\u00e9canismes simultan\u00e9ment. La r\u00e9plication logique permet un contr\u00f4le fin \u00e0 la fois de la r\u00e9plication des donn\u00e9es et de la s\u00e9curit\u00e9.<\/p>\n Il existe principalement deux modes de r\u00e9plication PostgreSQL : synchrone et asynchrone. La r\u00e9plication synchrone permet d’\u00e9crire des donn\u00e9es sur le serveur primaire et secondaire en m\u00eame temps, tandis que la r\u00e9plication asynchrone garantit que les donn\u00e9es sont d’abord \u00e9crites sur l’h\u00f4te, puis copi\u00e9es sur le serveur secondaire.<\/p>\n Dans la r\u00e9plication en mode synchrone, les transactions sur la base de donn\u00e9es primaire sont consid\u00e9r\u00e9es comme termin\u00e9es uniquement lorsque ces modifications ont \u00e9t\u00e9 r\u00e9pliqu\u00e9es sur toutes les r\u00e9pliques. Les serveurs r\u00e9pliques doivent tous \u00eatre disponibles en permanence pour que les transactions soient termin\u00e9es sur le primaire. Le mode synchrone de r\u00e9plication est utilis\u00e9 dans les environnements transactionnels haut de gamme avec des exigences de basculement imm\u00e9diat.<\/p>\n En mode asynchrone, les transactions sur le serveur primaire peuvent \u00eatre d\u00e9clar\u00e9es compl\u00e8tes lorsque les changements ont \u00e9t\u00e9 effectu\u00e9s sur le seul serveur primaire. Ces changements sont ensuite r\u00e9pliqu\u00e9s dans les r\u00e9pliques plus tard dans le temps. Les serveurs r\u00e9pliques peuvent rester d\u00e9synchronis\u00e9s pendant une certaine dur\u00e9e, appel\u00e9e d\u00e9calage de r\u00e9plication. En cas de panne, une perte de donn\u00e9es peut se produire, mais la surcharge fournie par la r\u00e9plication asynchrone est faible, elle est donc acceptable dans la plupart des cas (elle ne surcharge pas l’h\u00f4te). Le basculement de la base de donn\u00e9es primaire vers la base de donn\u00e9es secondaire prend plus de temps que la r\u00e9plication synchrone.<\/p>\n Dans cette section, nous allons montrer comment configurer le processus de r\u00e9plication PostgreSQL sur un syst\u00e8me d’exploitation Linux. Pour cette instance, nous utiliserons Ubuntu 18.04 LTS et PostgreSQL 10.<\/p>\n
\nQu’est-ce que la r\u00e9plication PostgreSQL ?<\/h2>\n
![\"Illustration](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/PostgreSQL-Replication-Illustration.png\")
Qu’est-ce que le basculement automatique ?<\/h3>\n
Avantages de l’utilisation de la r\u00e9plication PostgreSQL<\/h2>\n
\n
Comment fonctionne la r\u00e9plication PostgreSQL<\/h2>\n
\n
M\u00e9thode 1 : Streaming<\/h3>\n
Configuration du n\u0153ud primaire<\/h4>\n
\u00c9tape 1 : initialiser la base de donn\u00e9es<\/h5>\n
initdb<\/code>. Ensuite, vous pouvez cr\u00e9er un nouvel utilisateur avec des privil\u00e8ges de r\u00e9plication en utilisant la commande suivante :<\/p>\nCREATE USER 'example_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'example_password';<\/code><\/pre>\nCREATE USER 'rep_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_password';<\/code><\/pre>\n\u00c9tape 2 : Configuration des propri\u00e9t\u00e9s de streaming<\/h5>\n
wal_level = logical\nwal_log_hints = on\nmax_wal_senders = 8\nmax_wal_size = 1GB\nhot_standby = on<\/code><\/pre>\n\n
wal_log_hints<\/code><\/strong>: Ce param\u00e8tre est n\u00e9cessaire pour la fonction pg_rewind<\/code> qui s’av\u00e8re utile lorsque le serveur en attente n’est pas synchronis\u00e9 avec le serveur principal.<\/li>\nwal_level<\/code><\/strong>: Vous pouvez utiliser ce param\u00e8tre pour activer la r\u00e9plication PostgreSQL en continu, avec des valeurs possibles telles que minimal<\/code>, replica<\/code>, ou logical<\/code>.<\/li>\nmax_wal_size<\/code><\/strong>: Vous pouvez utiliser ce param\u00e8tre pour sp\u00e9cifier la taille des fichiers WAL qui peuvent \u00eatre conserv\u00e9s dans les fichiers journaux.<\/li>\nhot_standby<\/code><\/strong>: Vous pouvez utiliser ce param\u00e8tre pour une connexion en lecture seule avec le secondaire lorsqu’il est d\u00e9fini sur ON.<\/li>\nmax_wal_senders<\/code><\/strong>: Vous pouvez utiliser max_wal_senders<\/code> pour sp\u00e9cifier le nombre maximum de connexions simultan\u00e9es qui peuvent \u00eatre \u00e9tablies avec les serveurs en attente.<\/li>\n<\/ul>\n\u00c9tape 3 : Cr\u00e9er une nouvelle entr\u00e9e<\/h5>\n
host replication rep_user IPaddress md5<\/code><\/pre>\nrep_user<\/code> de se connecter et d’agir en tant que serveur de secours en utilisant l’IP sp\u00e9cifi\u00e9e pour la r\u00e9plication. Par exemple :<\/p>\nhost replication rep_user 192.168.0.22\/32 md5<\/code><\/pre>\nConfiguration du n\u0153ud de standby<\/h4>\n
\u00c9tape 1 : sauvegarder le n\u0153ud primaire<\/h5>\n
pg_basebackup<\/code> pour g\u00e9n\u00e9rer une sauvegarde du n\u0153ud primaire. Celle-ci servira de point de d\u00e9part pour le n\u0153ud de secours. Vous pouvez utiliser cet utilitaire avec la syntaxe suivante :<\/p>\n pg_basebackp -D -h -X stream -c fast -U rep_user -W<\/code><\/pre>\n\n
-h<\/code><\/strong>: Vous pouvez utiliser ce param\u00e8tre pour mentionner l’h\u00f4te primaire.<\/li>\n-D<\/code><\/strong>: Ce param\u00e8tre indique le r\u00e9pertoire sur lequel vous travaillez actuellement.<\/li>\n-C<\/code><\/strong>: Vous pouvez l’utiliser pour d\u00e9finir les points de contr\u00f4le.<\/li>\n-X<\/code><\/strong>: Ce param\u00e8tre peut \u00eatre utilis\u00e9 pour inclure les fichiers journaux transactionnels n\u00e9cessaires.<\/li>\n-W<\/code><\/strong>: Vous pouvez utiliser ce param\u00e8tre pour demander \u00e0 l’utilisateur un mot de passe avant de se connecter \u00e0 la base de donn\u00e9es.<\/li>\n<\/ul>\n\u00c9tape 2 : Configurer le fichier de configuration de r\u00e9plication<\/h5>\n
-R<\/code> dans l’utilitaire pg_basebackup<\/code>.<\/p>\nstandby_mode = 'on'\n\nprimary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name= \"host_name\"''\n\nrecovery_target_timeline = 'latest' (dernier)<\/code><\/pre>\n\n
primary_conninfo<\/code><\/strong>: Vous pouvez utiliser ce param\u00e8tre pour \u00e9tablir une connexion entre les serveurs primaire et secondaire en exploitant une cha\u00eene de connexion.<\/li>\nstandby_mode<\/code><\/strong>: Ce param\u00e8tre peut faire en sorte que le serveur primaire d\u00e9marre en tant que serveur de secours lorsqu’il est allum\u00e9.<\/li>\nrecovery_target_timeline<\/code><\/strong>: Vous pouvez utiliser ce param\u00e8tre pour d\u00e9finir le temps de r\u00e9cup\u00e9ration.<\/li>\n<\/ul>\nprimary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'<\/code><\/pre>\n\u00c9tape 3 : Red\u00e9marrer le serveur secondaire<\/h5>\n
\n
M\u00e9thode 2 : Dispositif de bloc r\u00e9pliqu\u00e9<\/h3>\n
M\u00e9thode 3 : WAL<\/h3>\n
R\u00e9plication en continu des journaux (niveau bloc)<\/h4>\n
R\u00e9plication bas\u00e9e sur l’exp\u00e9dition de journaux (niveau fichier)<\/h4>\n
Archivage WAL continu<\/h4>\n
pg_wal<\/code> pour les archiver est connu sous le nom d’archivage WAL. PostgreSQL appellera un script donn\u00e9 par l’utilisateur pour l’archivage, chaque fois qu’un fichier WAL sera cr\u00e9\u00e9.<\/p>\nscp<\/code> pour dupliquer le fichier vers un ou plusieurs emplacements tels qu’un montage NFS. Une fois archiv\u00e9s, les fichiers de segments WAL peuvent \u00eatre exploit\u00e9s pour r\u00e9cup\u00e9rer la base de donn\u00e9es \u00e0 un moment donn\u00e9.<\/p>\n\n
D\u00e9tails du protocole de diffusion WAL<\/h4>\n
primary_conninfo<\/code> de recovery.conf<\/strong> et se connecte au serveur primaire en exploitant une connexion TCP\/IP.<\/p>\n![\"Diagramme](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/WAL-Streaming-Protocol-Details.png\")
\u00c9l\u00e9ments de r\u00e9plication PostgreSQL<\/h2>\n
Mod\u00e8les de r\u00e9plication des bases de donn\u00e9es PostgreSQL<\/h3>\n
\n
Types de r\u00e9plication PostgreSQL<\/h3>\n
initdb<\/code>\u00a0effectuerait l’op\u00e9ration physique de cr\u00e9ation d’un r\u00e9pertoire de base pour un cluster. De m\u00eame, une simple op\u00e9ration logique<\/em> CREATE DATABASE<\/code>\u00a0effectuerait l’op\u00e9ration physique<\/em> de cr\u00e9ation d’un sous-r\u00e9pertoire dans le r\u00e9pertoire de base.<\/p>\n\n
Modes de r\u00e9plication<\/h3>\n
Comment configurer la r\u00e9plication PostgreSQL<\/h2>\n