PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Réplication » Upgrade standby » 07/08/2020 17:52:54

"mettre à jour le secondaire avec rsync"
Potentiellement ca compare 3Tb via le wan, ca ne va jamais aller.
Y a-t'il moyen , à l'instar de oracle et sql server, de n'envoyer que des fichiers WAL? Ou de faire en sorte que l'upgrade enregistre toutes les modifs dans des WAL?

#2 Réplication » Upgrade standby » 07/08/2020 12:07:09

albourg
Réponses : 3

Bonjour,

j'ai une db primaire postgres 10 de 3Tb.
J'ai un standby connecté via un WAN (aussi en postgres 10).

Comment upgrader le primaire et le standby en pg 12 sans renvoyer les 3Tb via le WAN?

Merci.

#3 Re : Sécurité » standby ssl certificate » 08/07/2020 15:58:03

J'ai le root.crt sur le standby

Donc si le pg_hba du primaire, j'ai
hostssl replication     all             <standby ip>/32        trust

et sur le standby:
primary_conninfo = 'host=<primary ip> user=postgres sslrootcert=/var/lib/pgsql/.postgresql/root.crt sslmode=require'

La connection sera cryptée grace au root.crt?

#4 Re : Sécurité » standby ssl certificate » 06/07/2020 08:22:04

It doesn't really work!
On master:
From pgadmin, if I give the root.crt to client

hostssl dpa2            dpa2          192.168.20.140/32         md5 

=> client can connect if it has root.crt and password.

I would like standby to be able to connect using only root.crt
On primary I tried:

hostssl replication     all             10.12.51.122/32        cert

then

hostssl replication     all             10.12.51.122/32        md5

and in standby's postgreql.conf

primary_conninfo = 'host=192.168.50.122 user=postgres sslrootcert=/var/lib/pgsql/.postgresql/root.crt'

But I get:

2020-07-06 08:18:12.180 CEST [35311] FATAL:  could not connect to the primary server: FATAL:  client certificates can only be checked if a root certificate store is available
        FATAL:  no pg_hba.conf entry for replication connection from host "10.12.51.122", user "postgres", SSL off

certificates are right:

[postgres@pgdpa01 data]$ openssl verify -CAfile root.crt server.crt
server.crt: OK

I would just like ssl to be used between primary and standby, so that data are not in clear text on a wan. How how how?

#5 Sécurité » standby ssl certificate » 01/07/2020 13:57:51

albourg
Réponses : 6

Bonjour,

postgres 12.3 linux x86_64 centos 7.
J'ai un standby qui se connecte au primaire, j'ai mis "trust" dans pg_hba.conf.
J'aimerais que le standby utilise un certificat (j'ai déjà des certificats self-signed via la procédure https://www.postgresql.org/docs/12/ssl-tcp.html).
Comment est-il possible se spécifier les certificats dans le connect string du standby pour éviter le "trust"?

Merci.

#6 Re : Sécurité » SSL - besoin d'explications » 29/06/2020 13:31:26

Donc si je mets md5 il demande le mot de passe mais le certificat est quand même nécessaire à cause de hostssl. Merci.

Reste à flanquer ça dans le connect string du standby.

#7 Re : Sécurité » SSL - besoin d'explications » 29/06/2020 11:01:43

Merci pour ces réponses.
Comme le dit daniel, je cherche juste à ce que le client ne communique que s'il a un certificat... pour l'instant.
Par contre,
1. quelle est la différence entre cert et md5?
2. Si je veux qu'un standby se connecte à ce serveur, comment puis-je lui donner le root.crt dans le connect string?

Merci.

#8 Sécurité » SSL - besoin d'explications » 26/06/2020 13:37:39

albourg
Réponses : 5

Bonjour,
postgres 12.2, linux x64. J'ai généré un certificat self-signed moi-même via ce script:

DAYS=3650
DOMAIN=masociete.com
HOST=serveur
SSLCONF=/etc/pki/tls/openssl.cnf

echo generate csr + key pair root.csr root.key
openssl req -new -nodes -text -out root.csr -keyout root.key -subj "/CN=root.$DOMAIN"
chmod og-rwx root.key
echo sign using root.csr, root.key to generate root.crt
openssl x509 -req -in root.csr -text -days $DAYS -extfile $SSLCONF -extensions v3_ca -signkey root.key -out root.crt
echo Use same command to generate server csr+key pair server.csr server.key
openssl req -new -nodes -text -out server.csr -keyout server.key -subj "/CN=$HOST.$DOMAIN"
chmod og-rwx server.key
echo sign using CA root
openssl x509 -req -in server.csr -text -days $DAYS -CA root.crt -CAkey root.key -CAcreateserial -out server.crt
chmod og-rwx server.crt
openssl verify -CAfile root.crt server.crt

Au niveau pg_hba.conf

hostssl db            usr            192.168.0.1/16          md5

ensuite:

createuser --pwprompt usr

psql ->

create database db;
grant connect on database db to usr;
grant all privileges on database db to usr;

Si je copie root.crt sur mon poste, le spécifie à pgadmin (+ ssl require), je peux me connecter. Sans le certificat, ça ne fonctionne pas.
Or dans la doc , https://www.postgresql.org/docs/current … RTIFICATES, il est marqué

add the authentication option clientcert=verify-ca or clientcert=verify-full to the appropriate hostssl line(s) in pg_hba.conf

Quand je mets

hostssl db            usr            192.168.0.1/16         clientcert=verify-ca

dans le pg_hba.conf, le connection est refusée. Il indique même que le certificat est invalide.
Or,

openssl verify -CAfile root.crt server.crt

permet d'affirmer que le certificat est correct.

Quelqu'un peut m'expliquer pq le clientcert=verify-ca ne fonctionne pas, et éventuellement s'il est utile, comment le faire fonctionner?

Merci.

#9 Réplication » utilisation de scp plutôt que cp/fuselib/... » 13/12/2019 15:14:19

albourg
Réponses : 1

Bonjour,

je configure un postgres 12 en master standby.
Le ssh est configuré pour que les 2 noeuds puissent communiquer sans prompt du mot de passe par ssh.

Sur le standby, je configure la récup du backup comme suit:

restore_command = 'scp masterdb:/var/lib/pgsql/12/wal/%f %p'

Souci: pour le archive_cleanup_command, je ne peux utiliser que
archive_cleanup_command = 'pg_archivecleanup <dir>/%f %r'
mais je ne peux pas configurer de dossier présent sur le noeud masterdb. Je suis obligé d'utiliser soit:
* un mount nfs
* un mount avec fuselib

Question: y a-t-il un autre solution que pg_archivecleanup qui supporte scp? (warm_standby ou autre)??????


Merci.

#10 Général » postgres 12 - pg_basebackup - syntax changed » 05/12/2019 18:55:31

albourg
Réponses : 1

as postgres:
-bash-4.2$ pg_basebackup -P -R --pgdata=/var/lib/pgsql/12/data --checkpoint=fast --host=eidlot2-database-1.pass.lan --username=postgres
pg_basebackup: error: could not connect to server: could not translate host name "eidlot2-database-1.pass.lan --username=postgres" to address: Name or service not known

this worked fine in 11.
-bash-4.2$ pg_basebackup -P -R --pgdata=/var/lib/pgsql/12/data --checkpoint=fast --username=postgres --host=eidlot2-database-1.pass.lan
works!
and if there is a space after the last letter (...pass.lan<space>, it does NOT work).

#11 Installation » drop schema public » 30/10/2019 13:07:58

albourg
Réponses : 1

Bonjour,

Est-il permis de dropper et de recréer le schéma public en postgres 11?
Si oui, y a-l'il une procédure / des droits à accorder après avoir recréé le schéma public?

Merci.

#12 Re : Installation » explication sur les timezones » 16/10/2019 11:20:03

Nous avons une db où nous avons positionné (à la création) timezone Brussels car l'installation software a été faite à Bruxelles, mais ce serveur doit tourner en Afrique.
Ce serveur a donc été envoyé en Afrique de l'Ouest.
Jboss/jpa a créé des champs "timestamp without timezone".
Les applications communiquent l'heure en UTC.

La question est "quel est l'impact si on change le timezone du serveur de Brussels->UTC".
Je pensais que select ts afficherait une valeur différente, mais ce n'est pas le cas.

#13 Re : Installation » explication sur les timezones » 16/10/2019 09:00:54

rjuju a fait un select now(). Pas un select sur un champs "timestamp without timezone" d'une table existante.

#14 Re : Installation » explication sur les timezones » 15/10/2019 15:47:54

Donc quand on fait un select ts il le renvoie toujours au format UTC peu importe le contenu du postgresql.conf.
Pour l'afficher à un ts particulier il faut dire "AT TIME ZONE 'UTC'" et à ce moment il affiche l'heure locale selon postgresql.conf, et l'offset par rapport à utc. Perso je ne trouve pas ça très logique, j'aurais fait l'inverse.

#15 Re : Installation » explication sur les timezones » 15/10/2019 15:20:29

Je ne suis pas sur de comprendre. A partir du serveur:
J'ai une db timezone europe / brussels, et un champs createdon timestamp without timezone

select requestuuid, createdon, createdon AT TIME ZONE 'UTC'
from xxx;
             requestuuid              |        createdon        |          timezone
--------------------------------------+-------------------------+----------------------------
 fa8f06d3-906a-4db9-ae4c-b7f342e4b3da | 2019-05-20 16:25:56.374 | 2019-05-20 18:25:56.374+02

Je change le timezone à UTC dans postgresql.conf et relance postgres

select requestuuid, createdon, createdon AT TIME ZONE 'UTC'
from xxx;
             requestuuid              |        createdon        |          timezone
--------------------------------------+-------------------------+----------------------------
 fa8f06d3-906a-4db9-ae4c-b7f342e4b3da | 2019-05-20 16:25:56.374 | 2019-05-20 16:25:56.374+00

Je m'attendais à ce que createdon soit modifié mais pas du tout., et "createdon at time utc" est lui modifié à l'affichage pour tenir compte du timezone de postgresql.conf.
Donc si je comprends bien, quand je fais un select createdon, il m'envoie la valeur de createdon UTC peu importe le contenu de postgresql.conf?

#16 Re : Installation » explication sur les timezones » 10/10/2019 09:11:41

Et donc je suppose qu'il n'est pas possible, si j'ai plusieurs databases, de spécifier un timezone par database?

#17 Installation » explication sur les timezones » 09/10/2019 14:34:26

albourg
Réponses : 11

Bonjour,

Dans postgresql.conf, il y a une ligne
    timezone = 'UTC'

J'aimerais avoir des explications:
* est-ce que ca veut dire que le serveur travaille en utc et qu'il faut dire à l'OS dans quel timezone il se trouve?
* est-ce qu'il y a un autre endroit où définir l'heure à afficher (tenant compte du timezone) à afficher lorsqu'on fait un "select now()"
* est-il possible de laisser cette ligne, et de définir dans chaque database du cluster, un timezone par défaut (qui pourrait être différent par database)? Nous avons un environnement de test et certaines bases de données seront expédiées à plusieurs endroits dans le monde, donc on doit pouvoir le gérer.
* est-ce que c'est au client de définir son timezone lorsqu'il se connecte (quand on fait un select now() on a l'heure du serveur, quel que soit le timezone du client)?


Y a-t'il un document quelque part qui explique les possibilités, j'ai cherché un peu mais n'ai rien trouvé de vraiment très clair?

Merci de votre aide.

#18 Réplication » invalid resource manager ID 114 at 16C/59A6E268 - dois-je m'inquiéter? » 20/06/2019 08:05:39

albourg
Réponses : 1

Bonjour,

j'ai un postgres 10.6 sous linux, un "master" (port 5432) et un "slave" (port 5444, même machine) en mode "hot standby" (streaming replication).
le recovery.conf:

standby_mode = 'on'
primary_conninfo = 'user=postgres passfile=''/var/lib/pgsql/.pgpass'' host=127.0.0.1 port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres target_session_attrs=any'
trigger_file = '/mnt/pgdata/standbydir/remove_ext_to_switchover'
restore_command = 'cp /mnt/pgdata/wal/%f %p'

J'ai créé le fichier /mnt/pgdata/standbydir/remove_ext_to_switchover
=> log:

2019-06-20 06:44:52.748 CEST [32383] LOG:  trigger file found: /mnt/pgdata/standbydir/remove_ext_to_switchover
2019-06-20 06:44:52.749 CEST [32402] FATAL:  terminating walreceiver process due to administrator command
cp: cannot stat ‘/mnt/pgdata/wal/000000010000016C00000059’: No such file or directory
2019-06-20 06:44:52.770 CEST [32383] LOG:  invalid resource manager ID 114 at 16C/59A6E268
2019-06-20 06:44:52.771 CEST [32383] LOG:  redo done at 16C/59A6E230
2019-06-20 06:44:52.771 CEST [32383] LOG:  last completed transaction was at log time 2019-06-20 06:43:56.733303+02
cp: cannot stat ‘/mnt/pgdata/wal/000000010000016C00000059’: No such file or directory
cp: cannot stat ‘/mnt/pgdata/wal/00000002.history’: No such file or directory
2019-06-20 06:44:52.802 CEST [32383] LOG:  selected new timeline ID: 2
2019-06-20 06:44:52.886 CEST [32383] LOG:  archive recovery complete
cp: cannot stat ‘/mnt/pgdata/wal/00000001.history’: No such file or directory
2019-06-20 06:44:53.006 CEST [32381] LOG:  database system is ready to accept connections

Ca a l'air de fonctionner correctement, mais il y a quand même un message:
2019-06-20 06:44:52.770 CEST [32383] LOG:  invalid resource manager ID 114 at 16C/59A6E268

Dois-je m'en inquiéter?

Merci!

#19 Re : Réplication » requested WAL segment 0000000100000005000000BE has already been remove » 05/03/2018 16:19:45

restore_command cherche les fichiers sur le standby, pas sur le primaire!!!!!! cfr message plus haut!!!!

#20 Re : Réplication » requested WAL segment 0000000100000005000000BE has already been remove » 05/03/2018 16:17:00

En fait l'erreur est sur le primaire!
Le log du primaire montre:
2018-03-05 10:14:32 UTCERROR:  requested WAL segment 0000000100000005000000BE has already been removed => le primaire a bien reçu la requête.
MAIS une fois que le log n'est plus dans pg_xlog, postgres ne sait plus le renvoyer, vu qu'archive_command n'est pas analysé. A moins qu'il y ait un paramètre "archive_directory" quelque part????

#21 Re : Réplication » requested WAL segment 0000000100000005000000BE has already been remove » 05/03/2018 16:07:25

archive_command archive les fichiers sur le PRIMAIRE, et est configuré. Cette commane ne fait rien sur un noeud en rôle standby.
Cette commande est bien configurée et les WAL sont bien là sur le primaire.
Le standby a été coupé donc n'a pas reçu les WAL.
Je repose la question: que dois-je dire au standby ou au primaire pour qu'il expédie les wal du primaire au standby?

#22 Re : Réplication » requested WAL segment 0000000100000005000000BE has already been remove » 05/03/2018 15:51:36

"Non, cela signifie qu'il faut dire au serveur secondaire comment les récupérer."

C'est bien là le souci: Comment?
Je veux que mon serveur secondaire demande les WAL au primaire (et ils y sont toujours), sans devoir les rapatrier manuellement.

#23 Re : Réplication » requested WAL segment 0000000100000005000000BE has already been remove » 05/03/2018 15:38:01

Ca veut dire qu'il faut copier les fichiers du primaire sur le standby manuellement.
Cela veut dire que dans un système primaire/stanbdy, si on coupe le standby (redémarrage, maintenance, ...), il faut le remettre à jour MANUELLEMENT en rapatriant les WAL. C'est une inepsie.

Pourquoi le standby ne sait-il pas récupérer ce qui lui manque en les demandant au primaire puisqu'ils sont sur le primaire?

#24 Re : Réplication » requested WAL segment 0000000100000005000000BE has already been remove » 05/03/2018 15:13:03

Non. C'est un postgres 9.6, je n'ai pas vu de restore_command dans le squelette du postgresql.conf. Il s'est répliqué jusqu'en janvier sans en avoir besoin.
Je viens d'adapter mon recovery.conf sur le standby, j'ai ajouté:
restore_command = 'cp /var/lib/pgsql/9.6/wal/%f %p'
archive_cleanup_command = 'pg_archivecleanup /var/lib/pgsql/9.6/wal %r'

Le message est un peu différent:
cp: cannot stat ‘/var/lib/pgsql/9.6/wal/0000000100000005000000BE’: No such file or directory
2018-03-05 13:10:35 UTCLOG:  started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 13:10:35 UTCFATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 0000000100000005000000BE has already been removed


cp: cannot stat ‘/var/lib/pgsql/9.6/wal/0000000100000005000000BE’: No such file or directory=> Le fichier est bien à cet endroit sur le primaire. S'il doit être sur le standby ca veut dire que postgres ne peut récupérer les wal du primaire?????

Pied de page des forums

Propulsé par FluxBB