Réplication PostgreSQL : un guide complet

Comme tout propriétaire de site vous le dira, la perte de données et les temps d'arrêt, même à des doses minimes, peuvent être catastrophiques. Ils peuvent frapper les personnes non préparées à tout moment, ce qui entraîne une réduction de la productivité, de l'accessibilité et de la confiance dans le produit.

Pour protéger l'intégrité de votre site, il est essentiel de mettre en place des protections contre la possibilité de temps d'arrêt ou de perte de données.

C'est là qu'intervient la réplication des données.
Comme tout propriétaire de site vous le dira, la perte de données et les temps d'arrêt, même à des doses minimes, peuvent être catastrophiques. Entrez, réplication de données Cliquez pour tweeter
La réplication des données est un processus de sauvegarde automatisé dans lequel vos données sont copiées à plusieurs reprises de sa base de données principale vers un autre emplacement distant pour être conservées en lieu sûr. Il s'agit d'une technologie intégrale pour tout site ou application exécutant un serveur de base de données. Vous pouvez également tirer parti de la base de données répliquée pour traiter le SQL en lecture seule, ce qui permet d'exécuter davantage de processus dans le système.

La configuration de la réplication entre deux bases de données offre une tolérance aux pannes contre les incidents inattendus. Il est considéré comme la meilleure stratégie pour atteindre une haute disponibilité en cas de sinistre.

Dans cet article, nous allons plonger dans les différentes stratégies qui peuvent être mises en œuvre par les développeurs backend pour une réplication PostgreSQL transparente.

Qu'est-ce que la réplication PostgreSQL ?

La réplication PostgreSQL est définie comme le processus de copie de données d'un serveur de base de données PostgreSQL vers un autre serveur. Le serveur de base de données source est également appelé serveur « principal », tandis que le serveur de base de données recevant les données copiées est appelé serveur « réplique ».

La base de données PostgreSQL suit un modèle de réplication simple, où toutes les écritures sont dirigées vers un nœud principal. Le nœud principal peut alors appliquer ces changements et les diffuser aux nœuds secondaires.

Qu'est-ce que le basculement automatique ?

Une fois la réplication physique en continu configurée dans PostgreSQL, le basculement peut avoir lieu si le serveur principal de la base de données tombe en panne. Le basculement est utilisé pour définir le processus de récupération, qui peut prendre un certain temps, car il ne fournit pas d'outils intégrés pour délimiter les pannes de serveur.

Vous n'avez pas besoin de dépendre de PostgreSQL pour le basculement. Il existe des outils dédiés qui permettent le basculement automatique et le passage automatique en veille, réduisant ainsi les temps d'arrêt de la base de données.

En configurant la réplication de basculement, vous garantissez pratiquement une haute disponibilité en vous assurant que des serveurs de secours sont disponibles en cas de défaillance du serveur principal.

Avantages de l'utilisation de la réplication PostgreSQL

Voici quelques avantages clés de l'exploitation de la réplication PostgreSQL :

• Migration de données : vous pouvez tirer parti de la réplication PostgreSQL pour la migration de données via un changement de matériel de serveur de base de données ou via le déploiement du système.
• Tolérance aux pannes : si le serveur principal tombe en panne, le serveur de secours peut agir en tant que serveur car les données contenues pour les serveurs principal et de secours sont les mêmes.
• Performances du traitement transactionnel en ligne (OLTP) : vous pouvez améliorer le temps de traitement des transactions et le temps de requête d'un système OLTP en supprimant la charge des requêtes de création de rapports. Le temps de traitement d'une transaction est la durée nécessaire à l'exécution d'une requête donnée avant la fin d'une transaction.
• Test du système en parallèle : lors de la mise à niveau d'un nouveau système, vous devez vous assurer que le système fonctionne bien avec les données existantes, d'où la nécessité de tester avec une copie de la base de données de production avant le déploiement.

Fonctionnement de la réplication PostgreSQL

Généralement, les gens pensent que lorsque vous essayez d'utiliser une architecture primaire et secondaire, il n'y a qu'une seule façon de configurer les sauvegardes et la réplication, mais les déploiements PostgreSQL suivent l'une des trois approches suivantes :

1. Réplication au niveau du volume pour répliquer au niveau de la couche de stockage du nœud principal au nœud secondaire, suivie d'une sauvegarde vers le stockage blob/S3.
2. Réplication en continu PostgreSQL pour répliquer les données du nœud principal vers le nœud secondaire, puis les sauvegarder sur le stockage blob/S3.
3. Effectuer des sauvegardes incrémentielles du nœud principal vers S3 tout en reconstruisant un nouveau nœud secondaire à partir de S3. Lorsque le nœud secondaire se trouve à proximité du nœud principal, vous pouvez commencer à diffuser à partir du nœud principal.

Approche 1 : diffusion en continu

La réplication en continu PostgreSQL, également connue sous le nom de réplication WAL, peut être configurée de manière transparente après l'installation de PostgreSQL sur tous les serveurs. Cette approche de la réplication est basée sur le déplacement des fichiers WAL de la base de données primaire vers la base de données cible.

Vous pouvez implémenter la réplication en continu PostgreSQL en utilisant une configuration primaire-secondaire. Le serveur primaire est l'instance principale qui gère la base de données primaire et toutes ses opérations. Le serveur secondaire agit en tant qu'instance supplémentaire et exécute sur lui-même toutes les modifications apportées à la base de données primaire, générant une copie identique dans le processus. Le serveur principal est le serveur de lecture/écriture tandis que le serveur secondaire est simplement en lecture seule.

Pour cette approche, vous devez configurer à la fois le nœud principal et le nœud de secours. Les sections suivantes expliqueront les étapes nécessaires à leur configuration en toute simplicité.

Configuration du nœud principal

Vous pouvez configurer le nœud principal pour la réplication en continu en procédant comme suit :

Étape 1 : Initialiser la base de données

Pour initialiser la base de données, vous pouvez utiliser la commande de l' initidb utility . Ensuite, vous pouvez créer un nouvel utilisateur avec des privilèges de réplication en utilisant la commande suivante :

 CREATE USER REPLICATION LOGIN ENCRYPTED PASSWORD '';

L'utilisateur devra fournir un mot de passe et un nom d'utilisateur pour la requête donnée. Le mot clé de réplication est utilisé pour donner à l'utilisateur les privilèges requis. Un exemple de requête ressemblerait à ceci :

 CREATE USER rep_user REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_pass'

Étape 2 : Configurer les propriétés de diffusion en continu

Ensuite, vous pouvez configurer les propriétés de streaming avec le fichier de configuration PostgreSQL ( postgresql.conf ) qui peut être modifié comme suit :

 wal_level = logical wal_log_hints = on max_wal_senders = 8 max_wal_size = 1GB hot_standby = on

Voici un petit aperçu des paramètres utilisés dans l'extrait précédent :

• wal_log_hints : Ce paramètre est requis pour la capacité pg_rewind qui est pratique lorsque le serveur de secours n'est pas synchronisé avec le serveur principal.
• wal_level : vous pouvez utiliser ce paramètre pour activer la réplication en continu PostgreSQL, avec des valeurs possibles telles que minimal , replica ou logical .
• max_wal_size : Ceci peut être utilisé pour spécifier la taille des fichiers WAL qui peuvent être conservés dans les fichiers journaux.
• hot_standby : vous pouvez tirer parti de ce paramètre pour une connexion en lecture avec le secondaire lorsqu'il est défini sur ON.
• max_wal_senders : vous pouvez utiliser max_wal_senders pour spécifier le nombre maximum de connexions simultanées pouvant être établies avec les serveurs de secours.

Étape 3 : Créer une nouvelle entrée

Après avoir modifié les paramètres dans le fichier postgresql.conf, une nouvelle entrée de réplication dans le fichier pg_hba.conf peut permettre aux serveurs d'établir une connexion entre eux pour la réplication.

Vous pouvez généralement trouver ce fichier dans le répertoire de données de PostgreSQL. Vous pouvez utiliser l'extrait de code suivant pour la même chose :

 host replication rep_user IPaddress md5

Une fois l'extrait de code exécuté, le serveur principal permet à un utilisateur appelé rep_user de se connecter et d'agir en tant que serveur de secours en utilisant l'adresse IP spécifiée pour la réplication. Par exemple:

 host replication rep_user 192.168.0.22/32 md5

Configuration du nœud de secours

Pour configurer le nœud de secours pour la réplication en continu, procédez comme suit :

Étape 1 : Sauvegarder le nœud principal

Pour configurer le nœud de secours, utilisez l'utilitaire pg_basebackup pour générer une sauvegarde du nœud principal. Cela servira de point de départ pour le nœud de secours. Vous pouvez utiliser cet utilitaire avec la syntaxe suivante :

 pg_basebackp -D -h -X stream -c fast -U rep_user -W

Les paramètres utilisés dans la syntaxe mentionnée ci-dessus sont les suivants :

• -h : Vous pouvez l'utiliser pour mentionner l'hôte principal.
• -D : Ce paramètre indique le répertoire sur lequel vous travaillez actuellement.
• -C : Vous pouvez l'utiliser pour définir les points de contrôle.
• -X : Ce paramètre peut être utilisé pour inclure les fichiers journaux transactionnels nécessaires.
• -W : vous pouvez utiliser ce paramètre pour demander à l'utilisateur un mot de passe avant de se connecter à la base de données.

Étape 2 : Configurer le fichier de configuration de la réplication

Ensuite, vous devez vérifier si le fichier de configuration de réplication existe. Si ce n'est pas le cas, vous pouvez générer le fichier de configuration de réplication sous recovery.conf.

Vous devez créer ce fichier dans le répertoire de données de l'installation de PostgreSQL. Vous pouvez le générer automatiquement en utilisant l'option -R dans l'utilitaire pg_basebackup .

Le fichier recovery.conf doit contenir les commandes suivantes :

standby_mode = 'on'

primary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=”host_name”'

recovery_target_timeline = 'dernier'

Les paramètres utilisés dans les commandes susmentionnées sont les suivants :

• primary_conninfo : vous pouvez l'utiliser pour établir une connexion entre les serveurs principal et secondaire en utilisant une chaîne de connexion.
• standby_mode : ce paramètre peut faire démarrer le serveur principal en tant que serveur de secours lorsqu'il est activé.
• recovery_target_timeline : vous pouvez l'utiliser pour définir le temps de récupération.

Pour configurer une connexion, vous devez fournir le nom d'utilisateur, l'adresse IP et le mot de passe comme valeurs pour le paramètre primary_conninfo. Par exemple:

 primary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'

Étape 3 : Redémarrez le serveur secondaire

Enfin, vous pouvez redémarrer le serveur secondaire pour terminer le processus de configuration.

Cependant, la réplication en continu s'accompagne de plusieurs défis, tels que :

• Divers clients PostgreSQL (écrits dans différents langages de programmation) conversent avec un seul point de terminaison. Lorsque le nœud principal échoue, ces clients continuent de réessayer avec le même nom DNS ou IP. Cela rend le basculement visible pour l'application.
• La réplication PostgreSQL n'est pas fournie avec un basculement et une surveillance intégrés. Lorsque le nœud principal tombe en panne, vous devez promouvoir un nœud secondaire en tant que nouveau nœud principal. Cette promotion doit être exécutée de manière à ce que les clients écrivent sur un seul nœud principal et qu'ils n'observent pas les incohérences des données.
• PostgreSQL réplique l'intégralité de son état. Lorsque vous devez développer un nouveau nœud secondaire, le secondaire doit récapituler tout l'historique des changements d'état à partir du nœud principal, ce qui nécessite beaucoup de ressources et rend coûteux l'élimination des nœuds dans la tête et la création de nouveaux.

Approche 2 : périphérique de bloc répliqué

L'approche de périphérique de bloc répliqué dépend de la mise en miroir de disque (également appelée réplication de volume). Dans cette approche, les modifications sont écrites sur un volume persistant qui est mis en miroir de manière synchrone sur un autre volume.

L'avantage supplémentaire de cette approche est sa compatibilité et la durabilité des données dans les environnements cloud avec toutes les bases de données relationnelles, y compris PostgreSQL, MySQL et SQL Server, pour n'en nommer que quelques-unes.

Cependant, l'approche de mise en miroir de disque pour la réplication PostgreSQL nécessite que vous répliquiez à la fois les données du journal WAL et des tables. Étant donné que chaque écriture dans la base de données doit désormais passer par le réseau de manière synchrone, vous ne pouvez pas vous permettre de perdre un seul octet, car cela pourrait laisser votre base de données dans un état corrompu.

Cette approche est normalement exploitée à l'aide d'Azure PostgreSQL et d'Amazon RDS.

Approche 3 : WAL

WAL se compose de fichiers de segment (16 Mo par défaut). Chaque segment contient un ou plusieurs enregistrements. Un enregistrement de séquence de journal (LSN) est un pointeur vers un enregistrement dans WAL, vous permettant de connaître la position/l'emplacement où l'enregistrement a été enregistré dans le fichier journal.

Un serveur de secours exploite les segments WAL - également appelés XLOGS dans la terminologie PostgreSQL - pour répliquer en continu les modifications de son serveur principal. Vous pouvez utiliser la journalisation en écriture anticipée pour garantir la durabilité et l'atomicité dans un SGBD en sérialisant des blocs de données de tableau d'octets (chacun avec un LSN unique) dans un stockage stable avant qu'ils ne soient appliqués à une base de données.

L'application d'une mutation à une base de données peut entraîner diverses opérations sur le système de fichiers. Une question pertinente qui se pose est de savoir comment une base de données peut assurer l'atomicité en cas de panne de serveur due à une panne de courant alors qu'elle était au milieu d'une mise à jour du système de fichiers. Lorsqu'une base de données démarre, elle commence un processus de démarrage ou de relecture qui peut lire les segments WAL disponibles et les compare avec le LSN stocké sur chaque page de données (chaque page de données est marquée avec le LSN du dernier enregistrement WAL qui affecte la page).

Réplication basée sur l'envoi de journaux (niveau bloc)

La réplication en continu affine le processus d'envoi des journaux. Au lieu d'attendre le commutateur WAL, les enregistrements sont envoyés au fur et à mesure de leur création, ce qui réduit le délai de réplication.

La réplication en continu l'emporte également sur l'envoi de journaux, car le serveur de secours se connecte au serveur principal sur le réseau en exploitant un protocole de réplication. Le serveur primaire peut alors envoyer des enregistrements WAL directement via cette connexion sans avoir à dépendre des scripts fournis par l'utilisateur final.

Réplication basée sur l'envoi de journaux (niveau fichier)

L'envoi de journaux est défini comme la copie de fichiers journaux vers un autre serveur PostgreSQL pour générer un autre serveur de secours en relisant les fichiers WAL. Ce serveur est configuré pour fonctionner en mode de récupération, et son seul but est d'appliquer tous les nouveaux fichiers WAL au fur et à mesure qu'ils apparaissent.

Ce serveur secondaire devient alors une sauvegarde à chaud du serveur PostgreSQL principal. Il peut également être configuré pour être un réplica en lecture, où il peut proposer des requêtes en lecture seule, également appelées secours automatique.

Archivage WAL continu

La duplication des fichiers WAL lorsqu'ils sont créés dans n'importe quel emplacement autre que le sous-répertoire pg_wal pour les archiver est connue sous le nom d'archivage WAL. PostgreSQL appellera un script donné par l'utilisateur pour l'archivage, chaque fois qu'un fichier WAL est créé.

Le script peut tirer parti de la commande scp pour dupliquer le fichier vers un ou plusieurs emplacements tels qu'un montage NFS. Une fois archivés, les fichiers de segment WAL peuvent être exploités pour récupérer la base de données à tout moment.

Les autres configurations basées sur les journaux incluent :

• Réplication synchrone : avant que chaque transaction de réplication synchrone ne soit validée, le serveur principal attend que les serveurs de secours confirment qu'ils ont obtenu les données. L'avantage de cette configuration est qu'il n'y aura pas de conflits dus aux processus d'écriture parallèles.
• Réplication multi-maître synchrone : ici, chaque serveur peut accepter les demandes d'écriture et les données modifiées sont transmises du serveur d'origine à tous les autres serveurs avant que chaque transaction ne soit validée. Il exploite le protocole 2PC et adhère à la règle du tout ou rien.

Détails du protocole de diffusion WAL

Un processus connu sous le nom de récepteur WAL, exécuté sur le serveur de secours, exploite les détails de connexion fournis dans le paramètre primary_conninfo de recovery.conf et se connecte au serveur principal en exploitant une connexion TCP/IP.

Pour démarrer la réplication en continu, l'interface peut envoyer le paramètre de réplication dans le message de démarrage. Une valeur booléenne true, yes, 1 ou ON indique au backend qu'il doit passer en mode walsender de réplication physique.

L'expéditeur WAL est un autre processus qui s'exécute sur le serveur principal et est chargé d'envoyer les enregistrements WAL au serveur de secours au fur et à mesure qu'ils sont générés. Le récepteur WAL enregistre les enregistrements WAL dans WAL comme s'ils avaient été créés par l'activité client de clients connectés localement.

Une fois que les enregistrements WAL atteignent les fichiers de segment WAL, le serveur de secours continue constamment à rejouer le WAL afin que le primaire et le secours soient à jour.

Éléments de la réplication PostgreSQL

Dans cette section, vous allez acquérir une compréhension plus approfondie des modèles couramment utilisés (réplication à maître unique et multi-maître), des types (réplication physique et logique) et des modes (synchrone et asynchrone) de la réplication PostgreSQL.

Modèles de réplication de bases de données PostgreSQL

L'évolutivité signifie ajouter plus de ressources/matériel aux nœuds existants pour améliorer la capacité de la base de données à stocker et traiter plus de données, ce qui peut être réalisé horizontalement et verticalement. La réplication PostgreSQL est un exemple de scalabilité horizontale qui est beaucoup plus difficile à mettre en œuvre que la scalabilité verticale. Nous pouvons atteindre une évolutivité horizontale principalement par la réplication à maître unique (SMR) et la réplication à maître multiple (MMR).

La réplication à maître unique permet de modifier les données uniquement sur un seul nœud, et ces modifications sont répliquées sur un ou plusieurs nœuds. Les tables répliquées dans la base de données répliquée ne sont pas autorisées à accepter des modifications, à l'exception de celles du serveur principal. Même si c'est le cas, les modifications ne sont pas répliquées sur le serveur principal.

La plupart du temps, SMR est suffisant pour l'application car il est moins compliqué à configurer et à gérer, sans risque de conflit. La réplication à maître unique est également unidirectionnelle, puisque les données de réplication circulent principalement dans une direction, de la base de données principale vers la base de données répliquée.

Dans certains cas, le SMR seul peut ne pas suffire et vous devrez peut-être mettre en œuvre le MMR. MMR permet à plusieurs nœuds d'agir en tant que nœud principal. Les modifications apportées aux lignes de table dans plusieurs bases de données primaires désignées sont répliquées dans leurs tables homologues dans toutes les autres bases de données primaires. Dans ce modèle, des schémas de résolution de conflits sont souvent utilisés pour éviter des problèmes tels que des clés primaires en double.

Il y a quelques avantages à utiliser le MMR, à savoir :

• En cas de défaillance de l'hôte, d'autres hôtes peuvent toujours fournir des services de mise à jour et d'insertion.
• Les nœuds principaux sont répartis dans plusieurs emplacements différents, de sorte que le risque de défaillance de tous les nœuds principaux est très faible.
• Possibilité d'utiliser un réseau étendu (WAN) de bases de données principales qui peuvent être géographiquement proches de groupes de clients, tout en maintenant la cohérence des données sur l'ensemble du réseau.

Cependant, l'inconvénient de la mise en œuvre du ROR est la complexité et sa difficulté à résoudre les conflits.

Plusieurs branches et applications fournissent des solutions MMR car PostgreSQL ne le supporte pas nativement. Ces solutions peuvent être open source, gratuites ou payantes. L'une de ces extensions est la réplication bidirectionnelle (BDR) qui est asynchrone et basée sur la fonction de décodage logique PostgreSQL.

Étant donné que l'application BDR rejoue les transactions sur d'autres nœuds, l'opération de relecture peut échouer s'il existe un conflit entre la transaction appliquée et la transaction validée sur le nœud de réception.

Types de réplication PostgreSQL

Il existe deux types de réplication PostgreSQL : la réplication logique et la réplication physique.

Une simple opération logique "initdb" effectuerait l'opération physique de création d'un répertoire de base pour un cluster. De même, une simple opération logique « CREATE DATABASE » réaliserait l'opération physique de création d'un sous-répertoire dans le répertoire de base.

La réplication physique traite généralement des fichiers et des répertoires. Il ne sait pas ce que ces fichiers et répertoires représentent. Ces méthodes sont utilisées pour conserver une copie complète de toutes les données d'un seul cluster, généralement sur une autre machine, et sont effectuées au niveau du système de fichiers ou du disque et utilisent des adresses de bloc exactes.

La réplication logique est un moyen de reproduire des entités de données et leurs modifications, en fonction de leur identité de réplication (généralement une clé primaire). Contrairement à la réplication physique, elle traite des bases de données, des tables et des opérations DML et s'effectue au niveau du cluster de bases de données. Il utilise un modèle de publication et d' abonnement dans lequel un ou plusieurs abonnés sont abonnés à une ou plusieurs publications sur un nœud d' éditeur .

Le processus de réplication commence par prendre un instantané des données sur la base de données de l'éditeur, puis en le copiant sur l'abonné. Les abonnés extraient les données des publications auxquelles ils sont abonnés et peuvent republier les données ultérieurement pour permettre une réplication en cascade ou des configurations plus complexes. L'abonné applique les données dans le même ordre que l'éditeur afin que la cohérence transactionnelle soit garantie pour les publications au sein d'un même abonnement également appelé réplication transactionnelle.

Les cas d'utilisation typiques de la réplication logique sont :

• Envoi de modifications incrémentielles dans une seule base de données (ou un sous-ensemble d'une base de données) aux abonnés au fur et à mesure qu'elles se produisent.
• Partage d'un sous-ensemble de la base de données entre plusieurs bases de données.
• Déclencher le déclenchement des modifications individuelles à mesure qu'elles arrivent sur l'abonné.
• Consolidation de plusieurs bases de données en une seule.
• Fournir l'accès aux données répliquées à différents groupes d'utilisateurs.

La base de données abonnée se comporte de la même manière que toute autre instance PostgreSQL et peut être utilisée comme éditeur pour d'autres bases de données en définissant ses publications.

Lorsque l'abonné est traité en lecture seule par l'application, il n'y aura aucun conflit à partir d'un seul abonnement. D'autre part, s'il existe d'autres écritures effectuées soit par une application, soit par d'autres abonnés au même ensemble de tables, des conflits peuvent survenir.

PostgreSQL prend en charge les deux mécanismes simultanément. La réplication logique permet un contrôle précis de la réplication et de la sécurité des données.

Modes de réplication

Il existe principalement deux modes de réplication PostgreSQL : synchrone et asynchrone. La réplication synchrone permet d'écrire simultanément les données sur les serveurs principal et secondaire, tandis que la réplication asynchrone garantit que les données sont d'abord écrites sur l'hôte, puis copiées sur le serveur secondaire.

Dans la réplication en mode synchrone, les transactions sur la base de données principale sont considérées comme terminées uniquement lorsque ces modifications ont été répliquées sur toutes les répliques. Les serveurs répliques doivent tous être disponibles en permanence pour que les transactions soient effectuées sur le serveur principal. Le mode de réplication synchrone est utilisé dans les environnements transactionnels haut de gamme avec des exigences de basculement immédiat.

En mode asynchrone, les transactions sur le serveur principal peuvent être déclarées terminées lorsque les modifications ont été effectuées uniquement sur le serveur principal. Ces modifications sont ensuite répliquées ultérieurement dans les répliques. Les serveurs répliques peuvent rester désynchronisés pendant une certaine durée, appelée délai de réplication. Dans le cas d'un crash, une perte de données peut se produire, mais la surcharge fournie par la réplication asynchrone est faible, elle est donc acceptable dans la plupart des cas (elle ne surcharge pas l'hôte). Le basculement de la base de données principale vers la base de données secondaire prend plus de temps que la réplication synchrone.

Comment configurer la réplication PostgreSQL

Pour cette section, nous montrerons comment configurer le processus de réplication PostgreSQL sur un système d'exploitation Linux. Pour cette instance, nous utiliserons Ubuntu 18.04 LTS et PostgreSQL 10.

Allons creuser !

Installation

Vous commencerez par installer PostgreSQL sur Linux en procédant comme suit :

1. Tout d'abord, vous devez importer la clé de signature PostgreSQL en tapant la commande ci-dessous dans le terminal :

    wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O- | sudo apt-key add -

2. Ensuite, ajoutez le dépôt PostgreSQL en tapant la commande ci-dessous dans le terminal :

    echo "deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main" | sudo tee /etc/apt/sources.list.d/postgresql.list

3. Mettez à jour l'index du référentiel en saisissant la commande suivante dans le terminal :

    sudo apt-get update

4. Installez le package PostgreSQL à l'aide de la commande apt :

    sudo apt-get install -y postgresql-10

5. Enfin, définissez le mot de passe de l'utilisateur PostgreSQL à l'aide de la commande suivante :

    sudo passwd postgres

L'installation de PostgreSQL est obligatoire pour le serveur principal et le serveur secondaire avant de démarrer le processus de réplication PostgreSQL.

Une fois que vous avez configuré PostgreSQL pour les deux serveurs, vous pouvez passer à la configuration de la réplication du serveur principal et du serveur secondaire.

Configuration de la réplication dans le serveur primaire

Effectuez ces étapes une fois que vous avez installé PostgreSQL sur les serveurs principal et secondaire.

1. Tout d'abord, connectez-vous à la base de données PostgreSQL avec la commande suivante :

    su - postgres

2. Créez un utilisateur de réplication avec la commande suivante :

    psql -c "CREATEUSER replication REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD'YOUR_PASSWORD';"

3. Modifiez pg_hba.cnf avec n'importe quelle application nano dans Ubuntu et ajoutez la configuration suivante : commande d'édition de fichier

    nano /etc/postgresql/10/main/pg_hba.conf

   Pour configurer le fichier, utilisez la commande suivante :

    host replication replication MasterIP/24 md5

4. Ouvrez et modifiez postgresql.conf et placez la configuration suivante dans le serveur principal :

    nano /etc/postgresql/10/main/postgresql.conf

   Utilisez les paramètres de configuration suivants :
   

    listen_addresses = 'localhost,MasterIP'

    wal_level = replica

    wal_keep_segments = 64

    max_wal_senders = 10

5. Enfin, redémarrez PostgreSQL sur le serveur principal principal :

 systemctl restart postgresql

Vous avez maintenant terminé la configuration sur le serveur principal.

Configuration de la réplication sur le serveur secondaire

Suivez ces étapes pour configurer la réplication sur le serveur secondaire :

1. Connectez-vous à PostgreSQL RDMS avec la commande ci-dessous :

    su - postgres

2. Arrêtez le fonctionnement du service PostgreSQL pour nous permettre de travailler dessus avec la commande ci-dessous :

    systemctl stop postgresql

3. Modifiez le fichier pg_hba.conf avec cette commande et ajoutez la configuration suivante :
   Modifier la commande
   

    nano /etc/postgresql/10/main/pg_hba.conf

   Configuration
   

    host replication replication MasterIP/24 md5

4. Ouvrez et modifiez postgresql.conf sur le serveur secondaire et mettez la configuration suivante ou décommentez si elle est commentée : Modifier la commande
   
   Configuration
   

    nano /etc/postgresql/10/main/postgresql.conf

    listen_addresses = 'localhost,SecondaryIP'

    wal_keep_segments = 64

    wal_level = replica

    hot_standby = on

    max_wal_senders = 10

   SecondaryIP est l'adresse du serveur secondaire

5. Accédez au répertoire de données PostgreSQL sur le serveur secondaire et supprimez tout :

    cd /var/lib/postgresql/10/main

    rm -rfv *

6. Copiez les fichiers du répertoire de données du serveur principal PostgreSQL dans le répertoire de données du serveur secondaire PostgreSQL et écrivez cette commande sur le serveur secondaire :

    pg_basebackup -h MasterIP -D /var/lib/postgresql/11/main/ -P -U

    replication --wal-method=fetch

7. Entrez le mot de passe PostgreSQL du serveur principal et appuyez sur Entrée. Ensuite, ajoutez la commande suivante pour la configuration de récupération : Modifier la commande
   

    nano /var/lib/postgresql/10/main/recovery.conf

   Configuration
   

    standby_mode = 'on' primary_conninfo = 'host=MasterIP port=5432 user=replication password=YOUR_PASSWORD' trigger_file = '/tmp/MasterNow'

   Ici, YOUR_PASSWORD est le mot de passe de l'utilisateur de réplication dans le serveur primaire PostgreSQL créé

8. Une fois le mot de passe défini, vous devrez redémarrer la base de données PostgreSQL secondaire puisqu'elle a été arrêtée :

 systemctl start postgresql

Test de votre configuration

Maintenant que nous avons effectué les étapes, testons le processus de réplication et observons la base de données du serveur secondaire. Pour cela, nous créons une table sur le serveur principal et observons si la même chose se reflète sur le serveur secondaire.

Allons-y.

1. Étant donné que nous créons la table sur le serveur principal, vous devez vous connecter au serveur principal :

    su - postgres psql

2. Maintenant, nous créons une table simple nommée 'testtable' et insérons des données dans la table en exécutant les requêtes PostgreSQL suivantes dans le terminal :

    CREATE TABLE testtable (websites varchar(100)); INSERT INTO testtable VALUES ('section.com'); INSERT INTO testtable VALUES ('google.com'); INSERT INTO testtable VALUES ('github.com');

3. Observez la base de données PostgreSQL du serveur secondaire en vous connectant au serveur secondaire :

    su - postgres psql

4. Maintenant, nous vérifions si la table 'testtable' existe et pouvons renvoyer les données en exécutant les requêtes PostgreSQL suivantes dans le terminal. Cette commande affiche essentiellement le tableau entier.

    select * from testtable;

Voici la sortie de la table de test :

 | websites | ------------------- | section.com | | google.com | | github.com | --------------------

Vous devriez pouvoir observer les mêmes données que celles du serveur principal.

Si vous voyez ce qui précède, alors vous avez réussi le processus de réplication !

Quelles sont les étapes de basculement manuel de PostgreSQL ?

Passons en revue les étapes d'un basculement manuel PostgreSQL :

1. Faites planter le serveur principal.
2. Faites la promotion du serveur de secours en exécutant la commande suivante sur le serveur de secours :

    ./pg_ctl promote -D ../sb_data/ server promoting

3. Connectez-vous au serveur de secours promu et insérez une ligne :

    -bash-4.2$ ./edb-psql -p 5432 edb Password: psql.bin (10.7) Type "help" for help. edb=# insert into abc values (4,'Four');

Si l'insertion fonctionne correctement, le serveur de secours, auparavant un serveur en lecture seule, a été promu en tant que nouveau serveur principal.

Comment automatiser le basculement dans PostgreSQL

La configuration du basculement automatique est simple.

Vous aurez besoin du gestionnaire de basculement EDB PostgreSQL (EFM). Après avoir téléchargé et installé EFM sur chaque nœud principal et de secours, vous pouvez créer un cluster EFM, qui se compose d'un nœud principal, d'un ou plusieurs nœuds de secours et d'un nœud témoin facultatif qui confirme les assertions en cas d'échec.

EFM surveille en permanence la santé du système et envoie des alertes par e-mail en fonction des événements système. Lorsqu'une panne se produit, il bascule automatiquement vers le serveur de secours le plus récent et reconfigure tous les autres serveurs de secours pour qu'ils reconnaissent le nouveau nœud principal.

Il reconfigure également les équilibreurs de charge (tels que pgPool) et empêche le "split-brain" (lorsque deux nœuds pensent chacun qu'ils sont principaux) de se produire.

Sommaire

En raison des grandes quantités de données, l'évolutivité et la sécurité sont devenues deux des critères les plus importants dans la gestion des bases de données, en particulier dans un environnement transactionnel. Bien que nous puissions améliorer l'évolutivité verticalement en ajoutant plus de ressources/matériel aux nœuds existants, cela n'est pas toujours possible, souvent en raison du coût ou des limites de l'ajout de nouveau matériel.

Par conséquent, une évolutivité horizontale est requise, ce qui signifie ajouter plus de nœuds aux nœuds de réseau existants plutôt que d'améliorer la fonctionnalité des nœuds existants. C'est là que la réplication PostgreSQL entre en jeu.
Pour protéger l'intégrité de votre site, il est essentiel de mettre en place des protections contre la possibilité de temps d'arrêt ou de perte de données. En savoir plus dans ce guide Cliquez pour tweeter
Dans cet article, nous avons discuté des types de réplications PostgreSQL, des avantages, des modes de réplication, de l'installation et du basculement PostgreSQL entre SMR et MMR. Maintenant écoutons de vous.

Lequel implémentez-vous habituellement ? Quelle fonctionnalité de base de données est la plus importante pour vous et pourquoi ? Nous serions ravis de lire vos pensées! Partagez-les dans la section des commentaires ci-dessous.