Comment configurer la réplication de streaming postgresql 12 dans Centos 8

Comment configurer la réplication de streaming postgresql 12 dans Centos 8

Postgresql La base de données prend en charge plusieurs solutions de réplication pour créer des applications à haute disponibilité, évolutives et tolérantes, dont l'une est Journal d'écriture (Wal) Expédition. Cette solution permet à un serveur de secours d'être implémenté à l'aide d'une réplication de livraison de journaux basée sur des fichiers ou de réplication de streaming, ou si possible, une combinaison des deux approches.

Avec la réplication du streaming, un serveur de base de données de secours (esclave de réplication) est configuré pour se connecter au serveur maître / primaire, qui diffuse Wal enregistre à la veille au fur et à mesure qu'ils sont générés, sans attendre le Wal dossier à remplir.

Par défaut, la réplication du streaming est asynchrone où les données sont écrites au (s) serveur (s) de secours après une transaction sur le serveur principal. Cela signifie qu'il existe un petit retard entre engager une transaction dans le serveur maître et les modifications devenant visibles dans le serveur de secours. L'un des inconvénients de cette approche est que dans le cas où le serveur maître se bloque, toutes les transactions non engagées peuvent ne pas être reproduites et cela peut entraîner une perte de données.

Ce guide montre comment configurer un Postgresql 12 Master-Standby Streaming Replication on Centos 8. Nous utiliserons "machines à sous de réplication«Pour la veille comme solution pour éviter que le serveur maître ne recycle ancienne Wal segments avant le standby les ont reçus.

Notez que par rapport à d'autres méthodes, les créneaux de réplication ne conservent que le nombre de segments connus pour être nécessaires.

Environnement de test:

Ce guide suppose que vous êtes connecté à vos serveurs de base de données maître et de secours comme racine via Ssh (utiliser Sudo Commande si nécessaire si vous êtes connecté en tant qu'utilisateur normal avec les droits administratifs):

PostgreSQL Master Database Server: 10.20.20.9 Postgresql Sembalby Database Server: 10.20.20.8 

Les deux serveurs de base de données doivent avoir Postgresql 12 Installé, autrement, voir: comment installer PostgreSQL et Pgadmin dans Centos 8.

Note: Postgresql 12 Livré avec des modifications majeures à l'implémentation et à la configuration de la réplication, comme le remplacement de récupération.confli et la conversion de récupération.confli Paramètres aux paramètres de configuration postgresql normaux, ce qui facilite la configuration de la réplication des cluster.

Étape 1: Configuration du serveur de base de données PostgreSQL Master / Primary

1. Sur le serveur maître, passez au compte système Postgres et configurez les adresses IP sur lesquelles le serveur maître écoutera pour les connexions des clients.

Dans ce cas, nous utiliserons * signifiant tout.

# Su - Postgres $ psql -c "Alter System set écouter_address sur '*';" 

Le Modifier le système de système La commande SQL est une fonctionnalité puissante pour modifier les paramètres de configuration d'un serveur, directement avec une requête SQL. Les configurations sont enregistrées dans le postgresql.confli.auto Fichier situé à la racine du dossier de données (e.g / var / lib / pgsql / 12 / data /) et lire l'ajout à ceux stockés dans postgresql.confli. Mais les configurations dans le premier ont la priorité sur celles des fichiers plus récents et autres.

Configurer les adresses IP sur PostgreSQL Master

2. Créez ensuite un rôle de réplication qui sera utilisé pour les connexions du serveur de secours vers le serveur maître, en utilisant le Créer un utilisateur programme. Dans la commande suivante, le -P Indicateur invite à un mot de passe pour le nouveau rôle et -e fait écho aux commandes que CreateUser génère et envoie au serveur de base de données.

# su - Postgres $ CreateUser --réplication -p -e réplicateur $ exit 
Créer un utilisateur de réplication sur pgmaster

3. Entrez ensuite l'entrée suivante à la fin du / var / lib / pgsql / 12 / data / pg_hba.confli Fichier de configuration d'authentification client avec le champ de base de données défini sur la réplication comme indiqué dans la capture d'écran.

Réplicateur de réplication de l'hôte 10.20.20.8/24 MD5 
Configurer l'authentification de la réplication

4. Redémarrez maintenant le Postgres12 Service utilisant la commande SystemCTL suivante pour appliquer les modifications.

# systemctl redémarrer postgresql-12.service 

5. Ensuite, si vous avez le pare-feu Service en cours d'exécution, vous devez ajouter le service PostgreSQL dans la configuration Firewalld pour autoriser les demandes du serveur de secours au maître.

# Firewall-CMD --Add-Service = PostgreSQL - Permanent # Firewall-CMD - Reload 

Étape 2: Faire une sauvegarde de base pour bootstrap le serveur de secours

6. Ensuite, vous devez faire une sauvegarde de base du serveur maître à partir du serveur de secours; Cela aide à amorcer le serveur de secours. Vous devez arrêter le service PostgreSQL 12 sur le serveur de secours, passer au compte utilisateur Postgres, sauvegarder le répertoire de données (/ var / lib / pgsql / 12 / data /), puis supprimer tout en dessous comme indiqué, avant de prendre la sauvegarde de la base.

# systemctl stop postgresql-12.Service # Su - Postgres $ cp -r / var / lib / pgsql / 12 / data / var / lib / pgsql / 12 / data_orig $ rm -rf / var / lib / pgsql / 12 / data / * 

7. Puis utilisez le pg_basebackup Outil pour prendre la sauvegarde de base avec la bonne propriété (l'utilisateur du système de base de données I.e Postgres, dans Postgres compte d'utilisateur) et avec les bonnes autorisations.

Dans la commande suivante, l'option:

  • -H - Spécifie l'hôte qui est le serveur maître.
  • -D - Spécifie le répertoire de données.
  • -U - Spécifie l'utilisateur de connexion.
  • -P - Permet les rapports progressistes.
  • -V - Permet le mode verbeux.
  • -R - Permet la création de la configuration de récupération: crée un Etre prêt.signal Paramètres de connexion à fichier et à ajouter postgresql.auto.confli dans le cadre du répertoire de données.
  • -X - Utilisé pour inclure les fichiers journaux d'écriture requis (fichiers WAL) dans la sauvegarde. Une valeur du flux signifie diffuser le WAL pendant que la sauvegarde est créée.
  • -C - Permet la création d'un emplacement de réplication nommé par l'option -s avant de démarrer la sauvegarde.
  • -S - Spécifie le nom de l'emplacement de réplication.
$ pg_basebackup -h 10.20.20.9 -d / var / lib / pgsql / 12 / data -u réplicator -p -v -r -x stream -c -s pgstandby1 $ exit 
Sauvegarde de base du serveur maître

8. Lorsque le processus de sauvegarde est terminé, le nouveau répertoire de données sur le serveur de secours devrait ressembler à celle de la capture d'écran. UN Etre prêt.signal est créé et les paramètres de connexion sont ajoutés à postgresql.auto.confli. Vous pouvez lister son contenu en utilisant la commande LS.

# ls -l / var / lib / pgsql / 12 / data / 
Vérifiez le répertoire des données de sauvegarde

Un esclave de réplication fonctionnera dans «Pose chaude«Mode si le pose chaude Le paramètre est défini sur (la valeur par défaut) dans postgresql.confli Et il y a un Etre prêt.signal Fichier présent dans le répertoire de données.

9. Maintenant, de retour sur le serveur maître, vous devriez être en mesure de voir la fente de réplication appelée pgstandby1 Lorsque vous ouvrez le pg_replication_slots Voir comme suit.

# su - Postgres $ psql -c "select * from pg_replication_slots;" $ exit 
Créer des emplacements de réplication

dix. Pour afficher les paramètres de connexion annexés dans le postgresql.auto.confli fichier, utilisez la commande CAT.

# Cat / var / lib / pgsql / 12 / data / postgresql.auto.confli 
Affichage des paramètres de connexion

11. Commencez maintenant des opérations de base de données normales sur le serveur de secours en démarrant le service PostgreSQL comme suit.

# systemctl start postgresql-12 

Étape 3: Test de la réplication de streaming postgresql

12. Une fois qu'une connexion est établie avec succès entre le maître et la veille, vous verrez un Wal Processus du récepteur dans le serveur de secours avec un statut de streaming, vous pouvez vérifier cela en utilisant le pg_stat_wal_receiver voir.

$ psql -c "\ x" -c "select * from pg_stat_wal_receiver;" 
Vérifiez le processus du récepteur WAL

et un correspondant Wal Processus de l'expéditeur dans le serveur maître / principal avec un état de streaming et un sync_state D'Async, vous pouvez vérifier cette vue PG_STAT_REPLICING PG_STAT_REPLIcation.

$ psql -c "\ x" -c "select * from pg_stat_replication;" 
Vérifiez le processus Wal Sender dans Master

De la capture d'écran ci-dessus, la réplication de streaming est asynchrone. Dans la section suivante, nous montrerons comment activer éventuellement la réplication synchrone.

13. Maintenant, testez si la réplication fonctionne bien en créant une base de données de test dans le serveur maître et vérifiez si elle existe dans le serveur de secours.
[Master] Postgres = # Create Database Tecmint;
[veille] Postgres = # \ l

Test de réplication de streaming

Facultatif: activer la réplication synchrone

14. La réplication synchrone offre la possibilité de commettre une transaction (ou d'écrire des données) à la base de données principale et à la veille / réplique simultanément. Il confirme seulement qu'une transaction est réussie lorsque toutes les modifications apportées par la transaction ont été transférées dans un ou plusieurs serveurs de secours synchrones.

Pour permettre une réplication synchrone, le synchronous_commit doit également être défini sur ON (qui est la valeur par défaut, donc pas besoin de modification) et vous devez également définir le synchronous_standby_name paramètre à une valeur non vide. Pour ce guide, nous le définirons sur tous.

$ psql -c "Alter System set synchronous_standby_name à '*';" 
Définir les noms de secours de synchronisation dans Master

15. Puis recharger le service PostgreSQL 12 pour appliquer les nouvelles modifications.

# SystemCTL Reload PostgreSQL-12.service 

16. Maintenant, quand vous interrogez le Wal Processus de l'expéditeur sur le serveur principal une fois de plus, il devrait afficher un état de streaming et un sync_state de synchronisation.

$ psql -c "\ x" -c "select * from pg_stat_replication;" 
Vérifiez le processus Wal Sender dans Master

Nous sommes arrivés à la fin de ce guide. Nous avons montré comment configurer Postgresql 12 Master-Standby Database Streaming Replication in Centos 8. Nous avons également couvert comment activer la réplication synchrone dans un cluster de base de données PostgreSQL.

Il existe de nombreuses utilisations de la réplication et vous pouvez toujours choisir une solution qui répond à votre environnement informatique et / ou aux exigences spécifiques à l'application. Pour plus de détails, accédez aux serveurs de secours en slipt dans la documentation PostgreSQL 12.