[RESOLU] Problème de réplication streaming : table non créée

ml · 16/11/2017 16:10:58

Bonjour,

Je suis une newbie sur PgSQL aussi je me tourne vers vous en dernier recours afin de comprendre pourquoi la réplication que je tente de mettre en place ne fonctionne pas.

Pour tester et me faire la main, j'ai installé 2 serveurs un maitre et un esclave en 10.1 sur RHEL 7.2 en local dans un but de faire de la HA sur 2 noeuds.

Pour la réplication j'ai configuré comme suit :

** Sur le maitre **
J'ai mis à jour le fichier postgresql.conf tel quel :
max_wal_senders = 10
wal_level = replica
archive_command = 'test ! -f /data/archives/%f && cp %p /data/archives/%f'
J'ai effectué la sauvegarde que j'ai ensuite importée coté esclave :
pg_basebackup -h localhost -D /data/pgsql/10/data/save -Ft -z -P

** Sur l'esclave **
wal_level = replica
hot_standby = on
J'ai créer un fichier recovery.conf tel quel :
standby_mode = 'on'
restore_command = 'cp /data/archives/%f %p'
primary_conninfo = 'host=localhost port=5432'
recovery_target_timeline = 'latest'

Le problème que j'ai actuellement est que la réplication n'aboutit pas. Lorsque je tente de créer un table par exemple, la requête ne me rend pas la main jusqu'à ce que je fasse un cancel. Elle est dès lors créée sur le Maitre mais pas sur l'esclave (logique)

Lorsque je finis par annuler la transaction j'ai le msg suivant :

ATTENTION: annulation de l'attente pour la réplication synchrone à la demande de l'utilisateur
DÉTAIL : La transaction a déjà enregistré les données localement, mais il se peut que
cela n'ait pas été répliqué sur le serveur en standby.
CREATE TABLE

J'ai laissé tourner jusqu'à 3 heure mais rien.

Ci-après les dernières lignes de la log de l'esclave :
2017-11-16 14:52:53.793 CET [4801] LOG: a reçu une demande d'arrêt rapide
2017-11-16 14:52:53.796 CET [4801] LOG: annulation des transactions actives
2017-11-16 14:52:53.799 CET [14792] FATAL: arrêt des connexions suite à la demande de l'administrateur
2017-11-16 14:52:53.801 CET [4809] FATAL: arrêt du processus walreceiver suite à la demande de l'administrateur
2017-11-16 14:52:53.802 CET [14791] FATAL: arrêt des connexions suite à la demande de l'administrateur
2017-11-16 14:52:53.806 CET [4806] LOG: arrêt en cours
2017-11-16 14:52:53.813 CET [4801] LOG: le système de base de données est arrêté
2017-11-16 14:52:53.938 CET [16112] LOG: le système de bases de données a été arrêté pendant la restauration à 2017-11-16 14:52:53 CET
cp: impossible d'évaluer « /data/archives/00000002.history »: Aucun fichier ou dossier de ce type
2017-11-16 14:52:53.941 CET [16112] LOG: entre en mode standby
cp: impossible d'évaluer « /data/archives/000000010000000000000015 »: Aucun fichier ou dossier de ce type
2017-11-16 14:52:53.949 CET [16112] LOG: la ré-exécution commence à 0/150522E0
2017-11-16 14:52:53.949 CET [16112] LOG: état de restauration cohérent atteint à 0/15052420
2017-11-16 14:52:53.949 CET [16112] LOG: longueur invalide de l'enregistrement à 0/15052420 : voulait 24, a eu 0
2017-11-16 14:52:53.950 CET [16110] LOG: le système de bases de données est prêt pour accepter les connexions en lecture seule
2017-11-16 14:52:53.958 CET [16118] LOG: Commence le flux des journaux depuis le principal à 0/15000000 sur la timeline 1
2017-11-16 15:00:22.393 CET [16152] LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
2017-11-16 15:00:22.393 CET [16153] LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant

Merci pour votre aide.

Ml

Dernière modification par ml (12/01/2018 18:18:53)

ruizsebastien · 16/11/2017 16:58:16

Bonjour,

Plusieurs pistes :
- avez-vous dans le postgresql.conf : listen_addresses = '*' des 2 serveurs
- avez-vous mis dans le .pgpass du slave et du master les lignes qui corespondent à la connexion à la pseudo base "replication"
- comment est configuré votre pg_hba.conf
?

et pour primary_conninfo = 'host=localhost port=5432' :
il faut mettre le hostname du master au lieu de localhost.

Dernière modification par ruizsebastien (16/11/2017 16:59:23)

ml · 16/11/2017 17:18:27

Bonjour

ruizsebastien a écrit :

- avez-vous dans le postgresql.conf : listen_addresses = '*' des 2 serveurs

Oui

ruizsebastien a écrit :

- avez-vous mis dans le .pgpass du slave et du master les lignes qui corespondent à la connexion à la pseudo base "replication"

euh non car je pensais que ce n'était pas obligatoire... mais je crois les heures passées à lire la documentation, extrêmement bien faite soit dit en passant, m'ont fait sauté cette phrase
Et en relisant la doc je me rend compte en effet que ça l'est ..
cf " Un mot de passe devra aussi être fourni, si le primaire demande une
authentification par mot de passe. Il peut être fourni soit dans la chaîne primary_conninfo soit séparément dans un fichier ~/.pgpass sur le serveur de standby (utilisez replication comme nom de base de données). Ne spécifiez pas de
nom de base dans la chaîneprimary_conninfo " ..

ruizsebastien a écrit :

- comment est configuré votre pg_hba.conf ?

Comme suit, j'ai fais au plus imple :

# TYPE DATABASE USER ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 ident
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust

hostnossl all all 0.0.0.0/0 trust

ruizsebastien a écrit :

et pour primary_conninfo = 'host=localhost port=5432' :
il faut mettre le hostname du master au lieu de localhost.

Entendu

J'effectue les modifications et reviens vers vous.

Merci beaucoup !

Dernière modification par ml (16/11/2017 17:19:10)

ruizsebastien · 16/11/2017 17:44:07

Si vous rester en mode trust dans le pg_hba.conf, ce n'est pas la peine de modifier le fichier .pgpass.

toujours dans le pg_hba.conf :
host replication all 127.0.0.1/32 trust
et
host all all 127.0.0.1/32 ident

Il n'autorise les connections distantes que pour 127.0.0.1 soit localhost...

Il faudrait mettre plutôt quelque chose du genre :
host all all 0.0.0.0 0.0.0.0 trust
host replication all 0.0.0.0 0.0.0.0 trust

Dernière modification par ruizsebastien (16/11/2017 17:47:53)

ml · 16/11/2017 18:40:40

J'ai fais les modifications suivantes :

1. création du fichier .pgpass (hostname et password par les valeurs qui conviennent)
hostname:5432:*:postgres:password

2. modification du primary_conninfo = 'host=localhost port=5432' : j'ai mis le hostname du master au lieu de localhost.

3. reboot du master qui m'a généré une erreur de connexion dans le slave :

2017-11-16 17:26:59.619 CET [16964] FATAL: n'a pas pu transmettre le message de fin d'envoi de flux au primaire : aucun COPY en cours
cp: impossible d'évaluer « /data/archives/00000002.history »: Aucun fichier ou dossier de ce type
cp: impossible d'évaluer « /data/archives/000000010000000000000017 »: Aucun fichier ou dossier de ce type
2017-11-16 17:26:59.627 CET [16919] LOG: longueur invalide de l'enregistrement à 0/17000098 : voulait 24, a eu 0
2017-11-16 17:26:59.630 CET [16982] FATAL: n'a pas pu se connecter au serveur principal : n'a pas pu se connecter au serveur : Connexion refusée
Le serveur est-il actif sur l'hôte « localhost » (127.0.0.1)
et accepte-t-il les connexionsTCP/IP sur le port 5432 ?
cp: impossible d'évaluer « /data/archives/00000002.history »: Aucun fichier ou dossier de ce type
cp: impossible d'évaluer « /data/archives/000000010000000000000017 »: Aucun fichier ou dossier de ce type
2017-11-16 17:27:04.641 CET [16995] LOG: Commence le flux des journaux depuis le principal à 0/17000000 sur la timeline 1

Y aurait-il quelque chose d'incorrect dans le ph_hba.conf ?

Dernière modification par ml (17/11/2017 10:16:14)

ruizsebastien · 17/11/2017 11:12:43

vous n'avez pas fait ça il me semble :
Si vous rester en mode trust dans le pg_hba.conf, ce n'est pas la peine de modifier le fichier .pgpass.

toujours dans le pg_hba.conf :
host replication all 127.0.0.1/32 trust
et
host all all 127.0.0.1/32 ident

Il n'autorise les connections distantes que pour 127.0.0.1 soit localhost...

Il faudrait mettre plutôt quelque chose du genre :
host all all 0.0.0.0 0.0.0.0 trust
host replication all 0.0.0.0 0.0.0.0 trust

Faire un reload de l'instance master.
une fois que c'est fait, il faudra supprimer les données du slave et refaire le pg_basebackup.

ml · 17/11/2017 11:31:04

Bonjour Sébastien,

C'est entendu !

Je fais les modifications et reviens vers vous.

ml · 17/11/2017 12:29:41

Après modification du fichier pg_hba.conf
Reload de la master
Suppression des données du slave et rechargement via pg_basebackup

J'ai l'erreur suivante :

-bash-4.2$ psql
psql: FATAL: aucune entrée dans pg_hba.conf pour l'hôte « [local] », utilisateur « postgres »,
base de données « postgres », SSL inactif

Ci_après mon fichier pg_hba.conf :

# TYPE DATABASE USER ADDRESS METHOD

# "local" is for Unix domain socket connections only
#local all all trust
# IPv4 local connections:
#host all all 127.0.0.1/32 ident
host all all 0.0.0.0 0.0.0.0 trust
# IPv6 local connections:
#host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication all trust
#host replication all 127.0.0.1/32 trust
#host replication all ::1/128 trust
#hostnossl all all 0.0.0.0/0 trust
host replication all 0.0.0.0 0.0.0.0 trust

ruizsebastien · 17/11/2017 12:33:31

il faut decommenter la ligne suivante :
#local all all trust
et celle là aussi :
#host all all ::1/128 trust
et refaire le reload.

ml · 17/11/2017 12:58:25

Ca fonctionne merci

Néanmoins coté slave dans le fichier de log j'ai tjrs les 2 erreurs que je ne comprends pas :

2017-11-17 11:37:06.818 CET [21928] LOG: le système de base de données est arrêté
2017-11-17 11:37:06.941 CET [22109] LOG: le système de bases de données a été arrêté pendant la restauration à 2017-11-17 11:37:06 CET
cp: impossible d'évaluer « /data/archives/00000002.history »: Aucun fichier ou dossier de ce type
2017-11-17 11:37:06.944 CET [22109] LOG: entre en mode standby
cp: impossible d'évaluer « /data/archives/00000001000000000000001D »: Aucun fichier ou dossier de ce type
2017-11-17 11:37:06.949 CET [22109] LOG: la ré-exécution commence à 0/1D000098
2017-11-17 11:37:06.949 CET [22109] LOG: état de restauration cohérent atteint à 0/1D0000D0
2017-11-17 11:37:06.949 CET [22109] LOG: enregistrement avec prev-link 10000/2240000 incorrect à 0/1D0000D0
2017-11-17 11:37:06.950 CET [22107] LOG: le système de bases de données est prêt pour accepter les connexions en lecture seule
2017-11-17 11:37:06.957 CET [22115] LOG: Commence le flux des journaux depuis le principal à 0/1D000000 sur la timeline 1

Et puis je viens de lancer la création d'une table qui mouline depuis plus de 5 min.. j'en reviens à mon problème de départ
Auriez-vous une idée ?

ml · 17/11/2017 13:34:06

Je viens d'annuler la transaction de création de table : avant j'avais une trace ds le fichier de log du slave indiquant :

LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant

mais là il n'y a rien, la dernière ligne du fichier de log slave étant :

LOG: Commence le flux des journaux depuis le principal à 0/1D000000 sur la timeline 1

ruizsebastien · 17/11/2017 15:05:05

à partir du moment où vous avez ce message : le système de bases de données est prêt pour accepter les connexions en lecture seule
C'est que c'est bon.
Le message précédent (cp: impossible d'évaluer « /data/archives/00000001000000000000001D »: Aucun fichier ou dossier de ce type) n'est qu'un warning à ignorer.

ml · 17/11/2017 15:27:27

C'est entendu mais alors pourquoi la table que je tente de créer n’aboutit pas s'il vous plait ?

Dernière modification par ml (17/11/2017 15:27:45)

rjuju · 17/11/2017 15:42:41

Qu'avez-vous configuré sur le serveur principal pour le paramètre synchronous_standby_names, et que renvoie "select * from pg_stat_replication" quand la création de table est en attente ?

ml · 17/11/2017 16:24:14

J'ai indiqué la valeur suivante :

synchronous_standby_names = 'sub_test' # standby servers that provide sync rep
synchronous_commit = on

Coté slave faut-il que j'indique cette valeur quelque part ?

Concernant la requête voici le résultat éxécuté pendant la création de la base

postgres=# select * from pg_stat_replication ;

rjuju · 17/11/2017 17:11:08

Vous demandez à attendre explicitement qu'un serveur secondaire nommé sub_test acquitte chaque commit, donc oui vous devez le spécifier au niveau du application_name dans la chaîne de connexion du serveur secondaire. Ou revoir votre configuration si vous ne voulez pas de réplication synchrone ou que n'importe quel serveur secondaire puisse être synchrone.

ml · 17/11/2017 17:20:55

Oui c'est exactement ce que je souhaite faire.

Dans quel fichier dois-je spécifier ce paramètre s'il vous plaît ? le Recovery.conf ?
Car je ne l'ai pas trouvé dans le postgresql.conf..

ml · 17/11/2017 17:54:59

Cela fonctionne !

Merci infiniment pour votre aide !!!!

J'ai modifié le recovery.conf comme suit :

primary_conninfo ='application_name=sub_test host=xatdlts4d01 port=5432'

Merciiiiiiiiiiiiiiiiii

ml · 24/11/2017 11:02:45

Bonjour !

J'aurais une question s'il vous plaît :

- le paramètre " synchronous_commit = on " indique que la base est en mode synchrone ?
- pour être en mode asynchrone il suffit de positionner le paramètre à OFF seulement ou alors y a t-il d'autres valeurs à paramètrer ?

D'après la documentation il me semble que c'est oui mais j'aimerais votre confirmation.

Merci

Dernière modification par ml (24/11/2017 11:03:14)

ruizsebastien · 24/11/2017 11:17:54

bonjour,

synchronous_commit est à OFF par défaut, donc soit vous l'enlevez du postgresql.conf soit vous le mettez explicitement à OFF.
Pas d'autres valeurs à ce paramètre.

ml · 24/11/2017 11:25:39

C'est entendu, je pose la question car en faisant des tests, en mode asynchrone, de création de tables par exemple la réplication est quasi instantanée.
Voilà pourquoi je me demandais si je n'avais pas omis d'autres paramètres.
Merci pour votre retour

rjuju · 24/11/2017 13:35:09

La valeur par défaut de synchronous_commit est bien on. Si vous le passez à off vous pouvez perdre des données en cas d'arrêt brutal (mais pas corrompre l'instance).

Pour désactiver la réplication synchrone, il faut laisser vide le paramètre synchronous_standby_names.

gleu · 24/11/2017 14:34:28

+1 pour rjuju

ml · 24/11/2017 17:57:50

Ok merci à tous
J'ai retirer " synchronous_standby_names "
La réplication est tiujours quasi instantanée mais c'est probablement parce que je n'ai rien dessus ..
Merci encore !

#1 16/11/2017 16:10:58

[RESOLU] Problème de réplication streaming : table non créée

#2 16/11/2017 16:58:16

Re : [RESOLU] Problème de réplication streaming : table non créée

#3 16/11/2017 17:18:27

Re : [RESOLU] Problème de réplication streaming : table non créée

#4 16/11/2017 17:44:07

Re : [RESOLU] Problème de réplication streaming : table non créée

#5 16/11/2017 18:40:40

Re : [RESOLU] Problème de réplication streaming : table non créée

#6 17/11/2017 11:12:43

Re : [RESOLU] Problème de réplication streaming : table non créée

#7 17/11/2017 11:31:04

Re : [RESOLU] Problème de réplication streaming : table non créée

#8 17/11/2017 12:29:41

Re : [RESOLU] Problème de réplication streaming : table non créée

#9 17/11/2017 12:33:31

Re : [RESOLU] Problème de réplication streaming : table non créée

#10 17/11/2017 12:58:25

Re : [RESOLU] Problème de réplication streaming : table non créée

#11 17/11/2017 13:34:06

Re : [RESOLU] Problème de réplication streaming : table non créée

#12 17/11/2017 15:05:05

Re : [RESOLU] Problème de réplication streaming : table non créée

#13 17/11/2017 15:27:27

Re : [RESOLU] Problème de réplication streaming : table non créée

#14 17/11/2017 15:42:41

Re : [RESOLU] Problème de réplication streaming : table non créée

#15 17/11/2017 16:24:14

Re : [RESOLU] Problème de réplication streaming : table non créée

#16 17/11/2017 17:11:08

Re : [RESOLU] Problème de réplication streaming : table non créée

#17 17/11/2017 17:20:55

Re : [RESOLU] Problème de réplication streaming : table non créée

#18 17/11/2017 17:54:59

Re : [RESOLU] Problème de réplication streaming : table non créée

#19 24/11/2017 11:02:45

Re : [RESOLU] Problème de réplication streaming : table non créée

#20 24/11/2017 11:17:54

Re : [RESOLU] Problème de réplication streaming : table non créée

#21 24/11/2017 11:25:39

Re : [RESOLU] Problème de réplication streaming : table non créée

#22 24/11/2017 13:35:09

Re : [RESOLU] Problème de réplication streaming : table non créée

#23 24/11/2017 14:34:28

Re : [RESOLU] Problème de réplication streaming : table non créée

#24 24/11/2017 17:57:50

Re : [RESOLU] Problème de réplication streaming : table non créée

Pied de page des forums

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux