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

Pages : 1 2

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

albourg

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?

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

albourg

"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.

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

albourg

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?

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

albourg

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?????

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

albourg

là où les wal sont archivés sur le primaire:
/var/lib/pgsql/9.6/wal

#31 Réplication » requested WAL segment 0000000100000005000000BE has already been remove » 05/03/2018 12:34:03

albourg
Réponses : 15

Bonjour,
j'ai un postgres "primaire" qui s'est répliqué correctement sur un postgres "standby" correctement jusqu'en janvier.
Puis désastre sur le site backup.
Le site backup est de nouveau en place, j'ai restauré la config et db au moment du crash sur le site backup et je re-lance la réplication.
le log (backup) dit:
2018-03-05 10:21:27 UTCLOG:  entering standby mode
2018-03-05 10:21:27 UTCLOG:  started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:27 UTCFATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 0000000100000005000000BE has already been removed

2018-03-05 10:21:28 UTCLOG:  started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:28 UTCFATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 0000000100000005000000BE has already been removed

2018-03-05 10:21:33 UTCLOG:  started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:33 UTCFATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 0000000100000005000000BE has already been removed

2018-03-05 10:21:38 UTCLOG:  started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:38 UTCFATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 0000000100000005000000BE has already been removed

2018-03-05 10:21:43 UTCLOG:  started streaming WAL from primary at 5/BE000000 on timeline 1
2018-03-05 10:21:43 UTCFATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 0000000100000005000000BE has already been removed

=> Le log est bien celui qui manque. J'ai effacé le dossier pg_xlog du standby et relancé , sans succès
Et il est toujours sur le site primaire, bien qu'il dise le contraire!!!!!:

-bash-4.2$ ls -altr 0000000100000005000000BE
-rw-------. 1 postgres postgres 16777216 Jan 15 11:18 0000000100000005000000BE

Question: pourquoi le primaire ne l'envoie-t'il pas??? (Ca me fait peur: en cas de coupure il doit quand même pouvoir repartir)

#32 Re : Général » pg_basebackup: pg_stop_backup still waiting for all required WAL » 01/03/2018 16:32:01

albourg

oui, je dois le virer?

#33 Général » pg_basebackup: pg_stop_backup still waiting for all required WAL » 01/03/2018 15:23:35

albourg
Réponses : 3

Bonjour,

pg 9.6
nous avons eu un disque plein sur un serveur postgres (vm).
Nous avons augmenté l'espace disque. postgres a l'air de re-fonctionner mais lorsque l'on lance un pg_basebackup on a le message d'erreur:
---
WARNING:  pg_stop_backup still waiting for all required WAL segments to be archived (1920 seconds elapsed)
HINT:  Check that your archive_command is executing properly.  pg_stop_backup can be canceled safely, but the database backup will not be usable without all the WAL segments.
---

le log répète:
2018-03-01 13:28:55 UTCLOG:  archive command failed with exit code 1
2018-03-01 13:28:55 UTCDETAIL:  The failed archive command was: test ! -f /var/lib/pgsql/9.6/wal/00000001000000060000007F && cp pg_xlog/00000001000000060000007F /var/lib/pgsql/9.6/wal/00000001000000060000007F
2018-03-01 13:28:55 UTCWARNING:  archiving transaction log file "00000001000000060000007F" failed too many times, will try again later


Ce fichier ne se trouve plus dans pg_xlog et se trouve dans /var/lib/pgsql/9.6/wal. postgres essaie néanmois de l'archiver, alors que ça a été fait.
De plus, il a créé d'autres fichers dans pg_xlog (et dans le /var/lib/pgsql/9.6/wal):

bash-4.2$ ls -altr pg_xlog
total 81980
-rw-------.  1 postgres postgres 16777216 Mar  1 11:27 000000010000000600000092
-rw-------.  1 postgres postgres      305 Mar  1 11:30 00000001000000060000008E.00000028.backup
-rw-------.  1 postgres postgres 16777216 Mar  1 11:30 00000001000000060000008E
drwx------. 22 postgres postgres     4096 Mar  1 12:41 ..
-rw-------.  1 postgres postgres 16777216 Mar  1 12:42 00000001000000060000008F
drwx------.  2 postgres postgres     4096 Mar  1 12:46 archive_status
-rw-------.  1 postgres postgres      305 Mar  1 12:46 000000010000000600000090.00000028.backup
-rw-------.  1 postgres postgres 16777216 Mar  1 12:46 000000010000000600000090
drwx------.  3 postgres postgres     4096 Mar  1 12:46 .
-rw-------.  1 postgres postgres 16777216 Mar  1 13:32 000000010000000600000091

ls -altr /var/lib/pgsql/9.6/wal
...
-rw-------. 1 postgres postgres 16777216 Feb 26 19:54 00000001000000060000007E
-rw-------. 1 postgres postgres 16777216 Mar  1 11:15 00000001000000060000007F
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000087
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000086
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000085
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000084
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000083
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000082
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000081
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000080
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 00000001000000060000008C
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 00000001000000060000008B
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 00000001000000060000008A
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000089
-rw-------. 1 postgres postgres 16777216 Mar  1 11:26 000000010000000600000088
-rw-------. 1 postgres postgres 16777216 Mar  1 11:27 00000001000000060000008D

Il a l'air coincé quelque part sur le 00000001000000060000007F .
Un conseil?

#34 Réplication » la réplication ne démarre pas. » 26/04/2017 18:56:25

albourg
Réponses : 1

Primaire:
---
listen_addresses = '*'
ssl = on                             
wal_level = hot_standby   
archive_mode = on
archive_command = 'test ! -f /var/lib/pgsql/9.6/wal/%f && cp %p /var/lib/pgsql/9.6/wal/%f'
max_wal_senders = 3

pg_hba.conf:
host    replication     all               10.12.51.175/32          trust
---

Standby:
recovery.conf:
---
standby_mode = 'on'
primary_conninfo = 'host=192.168.50.175'
--

Dans le log du standby:
2017-04-26 16:23:58 UTCLOG:  database system was shut down in recovery at 2017-04-26 16:23:55 UTC
2017-04-26 16:23:58 UTCLOG:  entering standby mode
2017-04-26 16:23:58 UTCLOG:  redo starts at 0/BDFD4980
2017-04-26 16:23:59 UTCLOG:  consistent recovery state reached at 0/BE00AFD8
2017-04-26 16:23:59 UTCLOG:  invalid record length at 0/BE00AFD8: wanted 24, got 0
2017-04-26 16:23:59 UTCLOG:  database system is ready to accept read only connections
2017-04-26 16:23:59 UTCLOG:  started streaming WAL from primary at 0/BE000000 on timeline 1

Puis plus rien, pourquoi? Je pense qu'il ne sait pas se connecter au primaire. Dois-je créer un user en postgres et un certificat pour la réplication aussi? (j'aimerais m'en passer pour la réplication).

Merci.

#35 Réplication » hot standby et ssl » 10/03/2017 16:32:24

albourg
Réponses : 1

Bonjour,

1. j'ai configuré un poste master, et le second en hot standby=> Ca fonctionne.
2. j'ai configuré le premier poste pour n'utiliser que SSL, avec un certificat sur le poste client=>
Ca marche:
* le client peut se connecter avec le certificat.
* le standby peut se connecter avec le certificat ssl (du standby: psql -h <ip primary> -U <user> -d <db>
=>password for user <user>: ******
...
SSL connection (cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256)
...
MAIS le log du standby affiche:

FATAL:  could not connect to the primary server: fe_sendauth: no password supplied

et le log du primaire

LOG:  could not receive data from client: Connection reset by peer

pg_hba standby:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     peer
host    all             all             127.0.0.1/32            ident
hostssl all     all     <ip primary>  md5 clientcert=1

pg_hba primary:

local   all             all                                     peer
host    all             all             127.0.0.1/32            md5
hostssl all         <user>    0.0.0.0/0             md5 clientcert=1
hostssl replication     all    <ip standby>/32             md5 clientcert=1
hostssl all     all    <ip standby>/32             md5 clientcert=1

Qu'est-ce qui ne va pas?
Merci.

#36 Sécurité » ssl et fichiers postgresql.* sur le client » 02/03/2017 14:24:12

albourg
Réponses : 1

Bonjour,

j'ai configuré postgres pour n'accepter que des connections ssl.
Pour cela j'ai dû copier sur le client dans %APPDATA%\postgresql les fichiers root.crt et postgresql.* générés sur le serveur.
Ca marche.

MAIS de mon pc (client), je dois pouvoir me connecter sur plusieurs serveurs, chacun ayant ses propres certificats.

Apparemment le client regarde les noms de fichiers root et postgresql.
Y a-t'il moyen de spécifier sur chaque serveur quel est le nom du fichier à utiliser sur le client, de manière à avoir sur mon poste les certificats de plusieurs serveurs?

Merci.

#37 PL/pgSQL » changer le owner de tables, séquences, ... » 01/12/2016 18:07:50

albourg
Réponses : 1

Bonjour,

via ora2pg, j'ai converti un schéma oracle.
J'ai bien le schéma cec... mais le owner  est abo (qui a créé la db). J'ai aussi un user postgres cec.
=> j'essaie avec une table, connecté comme abo (owner actuel):
ALTER TABLE cec.aaa OWNER TO cec;
=> PGADMIN plante après 2 minutes, psql aussi.

Qu'est-ce qui pose souci?

#38 PL/pgSQL » fonction convertie de oracle donne un résultat différent » 28/11/2016 12:37:27

albourg
Réponses : 1
CREATE OR REPLACE FUNCTION cec.qccontrolsaskedcount()
    RETURNS bigint
    LANGUAGE 'plpgsql'
    VOLATILE SECURITY DEFINER
    COST 100.0
AS $function$DECLARE

iRet bigint;

QCControlsAskedCountNoStage CURSOR FOR
SELECT CHECKASKCOUNT
FROM QUALITYCHECKSASKED QCA,  stagecharacteristics sc, batchState bs
WHERE qca.stage=sc.stageid and sc.characteristic like 'CFL%' and
bs.batchID=QCA.IDPELIDET AND bs.IDGROUP=iGroup LIMIT 1 OFFSET 0;

BEGIN
   iRet:=-1;

   open QCControlsAskedCountNoStage;
   FETCH QCControlsAskedCountNoStage into iRet;
   close QCControlsAskedCountNoStage;

   return iRet;
EXCEPTION
WHEN NO_DATA_FOUND THEN
   return -1;
END;
$function$;

arguments: igroup bigint.

Le curseur ne renvoie aucune ligne pour iGroup 1709311 (et c'est normal). CHECKASKCOUNT est défini comme un entier non null.
Je m'attends donc à ce que
select cec.qccontrolsaskedcount(1709311) renvoie -1. Mais ça envoie NULL. En oracle ca renvoie bien -1, et la valeur à renvoyer est de plus un entier non null. Cette fonction est sensée renvoyer un entier non null.

Il semble que le when no_data_found ne fonctionne pas en postgres de la même manière qu'en oracle. Quelqu'un peut m'expliquer ce qui coince?

#39 Re : PL/pgSQL » ERROR: UNION types text and integer cannot be matched » 16/11/2016 14:40:12

albourg

The declared type of the i-th column of TR is determined by applying Subclause 9.3, "Result of data type combinations", to the declared types of the i-th column of T1 and the i-th column of T2.
1. Null union null=null
2. Null union int=int.
Je ne vois aucune raison d'assigner un type texte quand il n'y en a pas.

#40 Re : PL/pgSQL » ERROR: UNION types text and integer cannot be matched » 16/11/2016 13:17:54

albourg

La norme SQL impose? En oracle ca marche en tout cas. 

SQL> select null from dual union select null from dual union select 1 from dual;

      NULL
----------
         1

En access aussi.

#41 Re : PL/pgSQL » ERROR: UNION types text and integer cannot be matched » 16/11/2016 11:48:07

albourg

J'ai du mal avec cette explication:

abotest=# select null union select null union select 1;
ERROR:  UNION types text and integer cannot be matched
LINE 1: select null union select null union select 1;
                                                   ^
abotest=# rollback;
ROLLBACK
abotest=#  select null union select 1;
 ?column?
----------
        1

(2 rows)

Si ce que vous dites est vrai, alors select null union select 1 devrait planter aussi, or ce n'est pas le cas. En fait le souci se pose quand il y a deux null et un n°.

#42 PL/pgSQL » ERROR: UNION types text and integer cannot be matched » 15/11/2016 18:04:15

albourg
Réponses : 7

cec.machines(id) is an integer not null >=0
cec.machines(machineid)  is null when cec.machines(id) =0
cec.groupitems(iditem) is an integer not null (and is primary key of cec.groupitems).



running 

select -2, null
union select 0, IDITEM from cec.GroupItems ;

works.
running 

select id, null as gr
FROM cec.MACHINES 
WHERE MACHINEID IS NOT NULL 
union select -2, null;

also works.

But running

select id, null as gr
FROM cec.MACHINES 
WHERE MACHINEID IS NOT NULL 
union select -2, null
union select 0, IDITEM from cec.GroupItems ;

gives

ERROR:  UNION types text and integer cannot be matched
LINE 5: union select 0, IDITEM from cec.GroupItems
                        ^
********** Error **********

ERROR: UNION types text and integer cannot be matched
SQL state: 42804
Character: 110

Why why why why?

#43 PSQL » create index refusé » 15/11/2016 10:13:04

albourg
Réponses : 1

Bonjour,

l'index est refusé

abotest=# CREATE INDEX idx_pr_hid_ref ON products ((hidden,rtrim(reference)||' V'||version,owner,id));
ERROR:  syntax error at or near ","
LINE 1: CREATE INDEX idx_pr_hid_ref ON products ((hidden,rtrim(refer...
                                                        ^

Quelqu'un peut me dire pourquoi?


Merci.

#44 PL/pgSQL » trigger et notify » 10/11/2016 15:00:35

albourg
Réponses : 2

Bonjour,

je suis nouveau à psql.
Je veux créer un trigger qui envoie une notification après un insert ou un update.
Créer le trigger, pas de souci, il me crée une fonction.

Lorsque je veux coder en plpgsql:

DECLARE 
CURSCHEMA VARCHAR (10);
BEGIN
   SELECT current_schema() into CURSCHEMA;
   NOTIFY CURSCHEMA||'_GIService', '-';
   RETURN NEW;
END

Il me donne une erreur au ||. Quel est le souci?
Merci.

#45 Migration » migration ora2pg import_all.sh » 08/11/2016 16:16:21

albourg
Réponses : 2

Bonjour,

je suis en train d'essayer de migrer une petite db oracle, un seul schéma SCH.

L'export est bien passé (export_schema.sh sans erreur).
En postgres, j'ai une db nommée abotest, un user abo et un password. Je ne sais pas ce que je dois mettre comme owner.
./import_all.sh -U abo -h 127.0.0.1 -d abotest -o SCH
Password for user abo:
psql: FATAL:  database "abo" does not exist
Would you like to create the owner of the database SCH? [y/N/q]

Je ne comprends pas le message "database "abo" does not exist". -U abo spécifie l'utilisateur, la db est spécifiée par -d et doit être "abotest".
Que veut-il dire par "le propriétaire de la database SCH"?  Le schéma SCH?
si je lui dis "oui", il le crée: createuser -h 127.0.0.1 -U abo --no-superuser --no-createrole --no-createdb SCH
MAIS ensuite il me demande "Would you like to create the database abotest". Pq ? Elle existe, je dois d'ailleurs chaque fois taper le mot de passe pour m'y connecter.

De plus, si je lance avec -Y pour ne pas confirmer chaque message, il se plaint qu'il ne peut créer la db (qui existe déjà) et s'arrête.
Pourriez-vous m'expliquer?

Merci.

Pages : 1 2

Pied de page des forums

Propulsé par FluxBB