Vous n'êtes pas identifié(e).
Quoi ? En êtes vous sur ? Et pourquoi il y avait pas eu cette erreur avant ?
J'ai une autre question, comment fait on pour installer un contrib dans une instance postgresql en particulier ? Disons que j'ai 3 instances de postgresql donc 3 pgdata également, j'aimerai dans celui correspondant à pddata1 installer les contrib postgresql
Bonjour,
Nous travaillons sur postgresql 9.4 dans un environnement linux debian. Le problème ne survient que maintenant, en fait des requêtes habituelles tournées sur base sans aucun problème, quand soudainement au début d'après midi aujourd'hui la même requête retourne un message d'erreur avec :
"could not find function "gin_trgm_triconsistent" in file "/usr/lib/postgresql/9.4/lib/pg_trgm.so" Where: SQL statement "UPDATE numenvault.Object_Folder SET name = p_name, description = p_description, properties = p_properties, allowed_child_object_type_ids = p_allowed_child_object_type_ids, last_modified_by = p_user, last_modification_date = v_change_timestamp, change_token = v_change_token WHERE id = p_id_folder" PL/pgSQL function numenvault.update_folder(bigint,numenvault.path_segment,text,hstore,character varying[],character varying,hstore) line 56 at SQL statement".
Auparavant, il n'y avait pas eu cette erreur.
De quoi s'agit il exactement, pouvez vous aider svp ? On a déjà essayé de faire un sudo apt-get install postgresql-contrib-9.4 mais toujours l'erreur. Et même un:
CREATE FUNCTION gin_trgm_triconsistent(internal, int2, text, int4, internal, internal, internal)
RETURNS "char"
AS 'MODULE_PATHNAME'
LANGUAGE C IMMUTABLE STRICT PARALLEL SAFE;
ALTER OPERATOR FAMILY gin_trgm_ops USING gin ADD
OPERATOR 7 %> (text, text),
FUNCTION 6 (text,text) gin_trgm_triconsistent (internal, int2, text, int4, internal, internal, internal);
n'a pas résolu ce problème.
Please help us !!! Merci d'avance
Merci pour ces précisions.
Je me trompe peut être mais le document ne décrit toujours pas la méthode de récuperation à un instant "t". Il décrit avec restore_command la restauration à partir des fichiers wal. Mais là il va tout restaurer. Ce que je veux c'est de revenir à un état antérieur. Donc pas tout restaurer mais restauré jusqu'à un point X.
Merci, j'ai déjà lu cette documentation, mais elle n'est pas trop explicite concernant la restauration à un instant t, à mon avis.
Parmis les 3 solutions que vous proposez quelle est la meilleure? Quelle est la différence entre les 3 ?
Bonjour,
Nous disposons d'une base de données PostgreSQL installée dans un environnement linux. Cette base est répliquée et utilise l'archivage des wal avec archive_command.
Maintenant, j'aimerai savoir s'il serait possible de faire une restauration de la base à un moment X. C'est à dire, revenir à un état antérieur, et cela en exploitant les wal archivés.
Si oui, comment le fait on exactement, pouvez vous m'indiquez le fonctionnement et le mode de restauration ? J'aimerai faire des tests. Merci à vous.
Bonjour,
L'idéal est de créer un nouveau topic sur ce sujet. Les gens pourraient mieux vous répondre.
Pour ma part désolé mais j'ai pas encore rencontré le problème. En googlant, il parle de modifier un paramètre dans le registre mais je ne sais pas si çà règlera ou pas le problème. Mais déjà essayez quand même d'executer l'installation en mode administrateur.
Merci pour ta réponse.
Le problème fut résolu.
Premièrement, il fallait bien paramétrer le fichier postgresql.conf. Pour notre part, j'ai utilisé les même classpath avec celui de l'install,donc:
pljava.classpath='/usr/pgsql-9.4/share/pljava/pljava-1.6.0-SNAPSHOT.jar'
Puis sur la même console, lancer tout simplement les commandes:
SET pljava.libjvm_location='/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64/jre/lib/amd64/server/libjvm.so';
create extension pljava;
Et c'est bon.
Remarque, on a pas eu besoin de lancer la commande> \i /opt/pljava/lib_pdf_tools_pg94/pljava_install.sql
Juste "create extension pljava;" et cela a créé automatiquement l'extension pljava avec le schéma sqlj.
Esperons que cela peux aussi aider les autres qui rencontrent le même problème.
Merci pour cette réponse, j'ai modifié LD_LIBRARY_PATH tel que :
bash-4.2$ export LD_LIBRARY_PATH=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64/jre/lib/amd64/server/:$LD_LIBRARY_PATH
Et avec ldd pljava.so, à mon avi çà renvoie bien le résultat attendu:
bash-4.2$ ldd pljava.so
linux-vdso.so.1 => (0x00007ffe5a3eb000)
libjvm.so => /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64/jre/lib/amd64/server/libjvm.so (0x00007f012faae000)
libecpg.so.6 => /usr/pgsql-9.4/lib/libecpg.so.6 (0x00007f012f78c000)
libpgtypes.so.3 => /usr/pgsql-9.4/lib/libpgtypes.so.3 (0x00007f012f57b000)
libpq.so.5 => /usr/pgsql-9.4/lib/libpq.so.5 (0x00007f012f34c000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f012f042000)
libm.so.6 => /lib64/libm.so.6 (0x00007f012ed40000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f012eb2a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f012e768000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f012e564000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f012e348000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f012e0d9000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f012dcef000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f012daa1000)
libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007f012d844000)
/lib64/ld-linux-x86-64.so.2 (0x000056316b320000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f012d55d000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f012d358000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f012d126000)
libz.so.1 => /lib64/libz.so.1 (0x00007f012cf10000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f012cd00000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f012cafc000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f012c8e2000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f012c6d2000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f012c4b5000)
libssl3.so => /lib64/libssl3.so (0x00007f012c269000)
libsmime3.so => /lib64/libsmime3.so (0x00007f012c041000)
libnss3.so => /lib64/libnss3.so (0x00007f012bd17000)
libnssutil3.so => /lib64/libnssutil3.so (0x00007f012baea000)
libplds4.so => /lib64/libplds4.so (0x00007f012b8e5000)
libplc4.so => /lib64/libplc4.so (0x00007f012b6e0000)
libnspr4.so => /lib64/libnspr4.so (0x00007f012b4a2000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f012b27a000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f012b043000)
librt.so.1 => /lib64/librt.so.1 (0x00007f012ae3a000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f012abd9000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f012a9d6000)
En outre, j'ai rajouté des config dans postgresql.conf tel que :
dynamic_library_path = '$libdir:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64-debug/jre/lib/amd64/server/'
pljava.classpath='/opt/pljava/lib_pdf_tools_pg94/pljava.jar'
pljava.vmoptions = '-Xmx1500M'
Mais même avec tout ce la je rencontre encore un message d'erreur lors du lancement de l'installation:
\i /opt/pljava/lib_pdf_tools_pg94/pljava_install.sql
BEGIN
CREATE SCHEMA
GRANT
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:4: ERROR: could not access file "pljava": No such file or directory
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:6: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:8: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:10: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:13: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:13: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:15: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:15: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:17: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:19: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:20: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:22: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:22: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:24: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:26: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:28: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:30: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:31: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:33: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:35: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:37: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:/opt/pljava/lib_pdf_tools_pg94/pljava_install.sql:39: ERROR: current transaction is aborted, commands ignored until end of transaction block
ROLLBACK
Sauriez vous d'où pourrait provenir l'erreur suivant: ERROR: could not access file "pljava": No such file or directory
Bonjour,
Nous essayons d'installer l'extension pljava sur une base dans Postgresql 9.4 sur linux. Mais nous restons bloquer avec ERROR: could not load library "/opt/pljava/lib_pdf_tools_pg94/pljava.so": libjvm.so: cannot open shared object file: No such file or directory.
Plus précisement, si je fais: ldd pljava.so
Cela renvoie:
ldd: warning: you do not have execution permission for `./pljava.so'
linux-vdso.so.1 => (0x00007fff6d9af000)
libjvm.so => not found
libecpg.so.6 => /usr/pgsql-9.4/lib/libecpg.so.6 (0x00007f333f07e000)
libpgtypes.so.3 => /usr/pgsql-9.4/lib/libpgtypes.so.3 (0x00007f333ee6d000)
libpq.so.5 => /usr/pgsql-9.4/lib/libpq.so.5 (0x00007f333ec3e000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f333e934000)
libm.so.6 => /lib64/libm.so.6 (0x00007f333e632000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f333e41c000)
libc.so.6 => /lib64/libc.so.6 (0x00007f333e05a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f333de3e000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f333dbd0000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f333d7e5000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f333d597000)
libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007f333d33b000)
/lib64/ld-linux-x86-64.so.2 (0x000055f95eaf0000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f333d053000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f333ce4f000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f333cc1d000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f333ca18000)
libz.so.1 => /lib64/libz.so.1 (0x00007f333c802000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f333c5f3000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f333c3ee000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f333c1d4000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f333bfc5000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f333bda7000)
libssl3.so => /lib64/libssl3.so (0x00007f333bb5b000)
libsmime3.so => /lib64/libsmime3.so (0x00007f333b934000)
libnss3.so => /lib64/libnss3.so (0x00007f333b609000)
libnssutil3.so => /lib64/libnssutil3.so (0x00007f333b3dc000)
libplds4.so => /lib64/libplds4.so (0x00007f333b1d8000)
libplc4.so => /lib64/libplc4.so (0x00007f333afd2000)
libnspr4.so => /lib64/libnspr4.so (0x00007f333ad94000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f333ab6c000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f333a935000)
librt.so.1 => /lib64/librt.so.1 (0x00007f333a72c000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f333a4cb000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f333a2c8000)
ce qui est interessant ici : libjvm.so => not found
J'ai déjà essayé avec de pointer avec LD_LIBRARY_PATH en faisant:
LD_LIBRARY_PATH=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64/jre/lib/amd64/server/libjvm.so
export LD_LIBRARY_PATH
Mais le fait est que cela renvoie toujours le même erreur avec ldd pljava.so
Demande de l'aide please ?
Je tiens à remarquer que lors de l'installation de pljava (linux), la base postgres possède bien l'extension de pljava avec le schema sqlj , mais quand on veut installer l'extension dans une autre base , c'est là que le problème se montre.
Quelqu'un peut aider svp ?
Merci de votre réponse sur ce sujet.
Effectivement, j'ai une requête qui lancait au master renvoie bien les résultats attendu. Mais quand on le lance au slave, une erreur "unexpected chunk number 0 (expected 1) for toast value 130066199 in pg_toast_2801358" arrête l’exécution de la requête. Il y avait un arrêt brusque de la base hier suite à une panne électrique, je suppose ce qui a engendré la corruption de la base slave.
Par curiosité, je ne comprends pas trop ce que vous voulez dire par corruption silencieuse, par quel moyen une requête pourrait il renvoyer des données fausses.
Comment savoir si une corruption provienne d'un problème de disque ou autres choses ?
Dans l'attente je vais dumper la base maitre et relancer les procédures de creation de slave.
Bonjour,
Si on a une base de réplique corrompue, alors que la réplique ne peut accepter que des SELECT. Comment fait on pour la reindexation, ou on le lance dans le master et il serait automatiquement appliqué au slave ?
Je ne comprend pas, pourquoi il metterai beaucoup de temps pour jouer les journaux alors qu'on l'a arrêté proprement avant la coupure ?
Bonjour,
En utilisant, postgresql 9.6 dans un environnement linux.
Suite d'une coupure d'electricité, postgresql ne veut plus se démarrer actuellement, le log suivant subsiste:
FATAL: the database system is shutting down
2017-09-09 23:02:04 EAT [P:4690][S:59b448bc.1252][T:0][A:[unknown]] ([unknown]@192.168.180.15(56690)): [1-1] LOG: connection received: host=192.168.180.15 port=56690
2017-09-09 23:02:04 EAT [P:4690][S:59b448bc.1252][T:0][A:[unknown]] (rep@192.168.180.15(56690)): [2-1] FATAL: the database system is shutting down
2017-09-09 23:02:09 EAT [P:4691][S:59b448c1.1253][T:0][A:[unknown]] ([unknown]@192.168.180.15(56692)): [1-1] LOG: connection received: host=192.168.180.15 port=56692
2017-09-09 23:02:09 EAT [P:4691][S:59b448c1.1253][T:0][A:[unknown]] (rep@192.168.180.15(56692)): [2-1] FATAL: the database system is shutting down
2017-09-09 23:02:14 EAT [P:4692][S:59b448c6.1254][T:0][A:[unknown]] ([unknown]@192.168.180.15(56694)): [1-1] LOG: connection received: host=192.168.180.15 port=56694
2017-09-09 23:02:14 EAT [P:4692][S:59b448c6.1254][T:0][A:[unknown]] (rep@192.168.180.15(56694)): [2-1] FATAL: the database system is shutting down
2017-09-09 23:10:06 EAT [P:4741][S:59b44a9e.1285][T:0][A:] (@): [1-1] LOG: database system was interrupted; last known up at 2017-09-09 16:56:31 EAT
2017-09-09 23:10:10 EAT [P:4742][S:59b44aa2.1286][T:0][A:[unknown]] ([unknown]@192.168.180.15(56884)): [1-1] LOG: connection received: host=192.168.180.15 port=56884
2017-09-09 23:10:10 EAT [P:4742][S:59b44aa2.1286][T:0][A:[unknown]] (rep@192.168.180.15(56884)): [2-1] FATAL: the database system is starting up
2017-09-09 23:10:15 EAT [P:4744][S:59b44aa7.1288][T:0][A:[unknown]] ([unknown]@192.168.180.15(56886)): [1-1] LOG: connection received: host=192.168.180.15 port=56886
2017-09-09 23:10:15 EAT [P:4744][S:59b44aa7.1288][T:0][A:[unknown]] (rep@192.168.180.15(56886)): [2-1] FATAL: the database system is starting up
2017-09-09 23:10:20 EAT [P:4745][S:59b44aac.1289][T:0][A:[unknown]] ([unknown]@192.168.180.15(56888)): [1-1] LOG: connection received: host=192.168.180.15 port=56888
2017-09-09 23:10:20 EAT [P:4745][S:59b44aac.1289][T:0][A:[unknown]] (rep@192.168.180.15(56888)): [2-1] FATAL: the database system is starting up
2017-09-09 23:10:25 EAT [P:4746][S:59b44ab1.128a][T:0][A:[unknown]] ([unknown]@192.168.180.15(56890)): [1-1] LOG: connection received: host=192.168.180.15 port=56890
2017-09-09 23:10:25 EAT [P:4746][S:59b44ab1.128a][T:0][A:[unknown]] (rep@192.168.180.15(56890)): [2-1] FATAL: the database system is starting up
2017-09-09 23:10:30 EAT [P:4747][S:59b44ab6.128b][T:0][A:[unknown]] ([unknown]@192.168.180.15(56892)): [1-1] LOG: connection received: host=192.168.180.15 port=56892
2017-09-09 23:10:30 EAT [P:4747][S:59b44ab6.128b][T:0][A:[unknown]] (rep@192.168.180.15(56892)): [2-1] FATAL: the database system is starting up
2017-09-09 23:10:35 EAT [P:4748][S:59b44abb.128c][T:0][A:[unknown]] ([unknown]@192.168.180.15(56894)): [1-1] LOG: connection received: host=192.168.180.15 port=56894
2017-09-09 23:10:35 EAT [P:4748][S:59b44abb.128c][T:0][A:[unknown]] (rep@192.168.180.15(56894)): [2-1] FATAL: the database system is starting up
2017-09-09 23:10:40 EAT [P:4749][S:59b44ac0.128d][T:0][A:[unknown]] ([unknown]@192.168.180.15(56896)): [1-1] LOG: connection received: host=192.168.180.15 port=56896
2017-09-09 23:10:40 EAT [P:4749][S:59b44ac0.128d][T:0][A:[unknown]] (rep@192.168.180.15(56896)): [2-1] FATAL: the database system is starting up
Par ailleurs, en faisant :systemctl status postgresql-9.6.service, on obtient:
postgresql-9.6.service - PostgreSQL 9.6 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-9.6.service; enabled; vendor preset: disabled)
Active: failed (Result: signal) since Sat 2017-09-09 22:50:14 EAT; 1min 3s ago
Process: 4210 ExecStart=/usr/pgsql-9.6/bin/postmaster -D ${PGDATA} (code=killed, signal=KILL)
Process: 4204 ExecStartPre=/usr/pgsql-9.6/bin/postgresql96-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 4210 (code=killed, signal=KILL)
Sep 09 22:40:13 SRVINPI.numen.mg systemd[1]: Starting PostgreSQL 9.6 database server...
Sep 09 22:40:14 SRVINPI.numen.mg postmaster[4210]: 2017-09-09 22:40:14 EAT [P:4210][S:59b4439d.1072][T:0][A:] (@): [1-1] LOG: redirecting log output to log...r process
Sep 09 22:40:14 SRVINPI.numen.mg postmaster[4210]: 2017-09-09 22:40:14 EAT [P:4210][S:59b4439d.1072][T:0][A:] (@): [2-1] HINT: Future log output will appea...rncs_hb".
Sep 09 22:45:13 SRVINPI.numen.mg systemd[1]: postgresql-9.6.service start operation timed out. Terminating.
Sep 09 22:50:14 SRVINPI.numen.mg systemd[1]: postgresql-9.6.service stop-final-sigterm timed out. Killing.
Sep 09 22:50:14 SRVINPI.numen.mg systemd[1]: postgresql-9.6.service: main process exited, code=killed, status=9/KILL
Sep 09 22:50:14 SRVINPI.numen.mg systemd[1]: Failed to start PostgreSQL 9.6 database server.
Sep 09 22:50:14 SRVINPI.numen.mg systemd[1]: Unit postgresql-9.6.service entered failed state.
Sep 09 22:50:14 SRVINPI.numen.mg systemd[1]: postgresql-9.6.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
Auriez vous une solution pour démarrer à nouveau postgresql svp ?
Merci pour cette réponse, je vais voir çà.
Bonjour,
En utilisant postgresql sur linux, connaissez vous un moyen de monitoriser la durée d'execution des requêtes effectuée sur ligne de commande psql ?
Pour être clair, j'aimerai conserver dans un fichiers les durées d’exécutions de plusieurs commandes psql.
Il y aurait pas t il d'autres options possible ?
J'ai bien arrêté le service postgres de la réplique la veille dans la soirée, sans changer de configuration sauf le paramètre archive_command du master. Le lendemain matin je regarde les logs (heure midi) et je constate ces erreurs.
Bonjour,
Merci de votre réponse.
Oui, il existe bien un serveur secondaire, mais ce qui est bizarre c'est que je l'avait arrêté durant ce temps en raison d'un manque d'espace disque. Donc je ne vois pas comment le serveur secondaire tenterait encore de s'y connecter au primaire.
Bonjour,
Je dispose d'un serveur postgresql sous linux.
En regardant les logs d'aujourd'hui, je trouve des messages tels que:
> FATAL: remaining connection slots are reserved for non-replication superuser connections
> ERROR: requested WAL segment 00000001000005240000009B has already been removed
Pouvez vous svp m'expliquer davantage sur les raisons d'apparitions de ces erreurs ?
Salut,
Si t'as la version 9.4 et supérieur je crois, tu peux utiliser l'option jobs "-j" du commande pg_dump pour augmenter la vitesse de ton dump avec un format de sortie repertoire.
Jobs:
Exécute une sauvegarde parallélisée en sauvegardant njobs tables simultanément. Cette option réduit la durée de la sauvegarde mais elle augmente aussi la charge sur le serveur de base de données. Vous ne pouvez utiliser cette option qu'avec le format de sortie répertoire car c'est le seul format où plusieurs processus peuvent écrire leur données en même temps.
Pour plus d'info: https://docs.postgresql.fr/9.6/app-pgdump.html
Ok, le problème est règlé avec :
ADD CONSTRAINT ckc_type_error_inject_type_err CHECK (type_error_inject_wr IS NULL OR length(type_error_inject_wr) <= 150);
Bonjour,
J'ai créé une table telle que:
CREATE TABLE suivi_inject_tl.type_error_inject_wr
(
id_type_error_inject_wr integer NOT NULL DEFAULT nextval('suivi_inject_tl.type_error_inject_wr_id_type_error_inject_wr_seq'::regclass),
type_error_inject_wr character varying(150),
CONSTRAINT pk_type_error_inject_wr PRIMARY KEY (id_type_error_inject_wr),
CONSTRAINT ckc_type_error_inject_type_err CHECK (type_error_inject_wr IS NULL OR type_error_inject_wr::text <= '150'::text)
)
Le souci est que quand je fais un INSERT INTO suivi_inject_tl.type_error_inject_wr(type_error_inject_wr) values ('Truc que je veux insérer');
>>> Cela me renvoie à l'erreur : ERROR: new row for relation "type_error_inject_wr" violates check constraint "ckc_type_error_inject_type_err"
Je ne comprends pas pourquoi cette erreur apparait avec CONSTRAINT ckc_type_error_inject_type_err CHECK (type_error_inject_wr IS NULL OR type_error_inject_wr::text <= '150'::text);
Avez vous idée du pourquoi et pouvez vous expliquer ?
Merci
Je met un bilan de résultat pour ceux qui sont intéressés:
gleu> normalement si je comprends bien, si archive_mode=on et la commande archive_command est renseignée avec une copie , les wal seront transmis vers l'emplacement définis dans archive_command. Par conséquent, si l'on ne met rien dans archive_command les wal ainsi seront entassés dans pg_xlog et seront toujours en attente de copie (wal.ready). Avec un test, j'ai utilisé archivecleanup commande depuis la réplique vu que la réplique connait quel est le wal déjà joué donc déjà mise en .done qu'on peut supprimer. Je rappelle que l'objectif ici est de seulement supprimer les wal déjà joués pour réduire et éviter le gonflement d'espace occupé par les wal en attentes de copie. Une fois les wal déjà joué supprimés, on désactive archive_mode. Et ainsi postgresql reprend son jeu normal sans mode d'archivage. Cette opération à été testé sur une base de test avec un résultat positif
Peut être avez vous des objections à ceux ci ?
rjuju> Mettre archive_command à false, je viens de tester, çà ne résolu pas le problème, d'ailleurs je ne comprends pas pourquoi.
Par contre, je pense que l'idée est assez la même ou presque, une autre astuce (plus bas) vérifiée et mise en application résolu bien le problème.
Puisque dans le cas où l'on ne dispose pas de serveur de réplique et/ou que l'on aime pas trop utiliser la commande archivecleanup, pour supprimer les wal supprimables on peut utiliser la méthode suivante. Tout simplement, on ne désactive pas archive_mode mais cependant on met archive_command = '/bin/true'. Cela conduira en quelque sorte à une illusion de copie, qui va entrainer ainsi de mettre les wal.ready en wal.done sur le master qui effacera les wal pouvant être supprimé. Postgresql gardera ensuite dans pg_xlog les wal nécessaires à son mode de vie normal selon vos paramétrages.
En tout cas, merci beaucoup aux aides et conseils que vous avez apporter pour ce sujet.
Je ne comprends pas, comment çà manuel?
L'option %r de pg_acrchivecleanup est manuel vous dites ?
Bonjour à tous, je soulève le sujet car dans mon pgAdmin j'ai pas Nombre maximum de caractères par colonne, dans Fichier > Préférences > Editeur de requêtes
Bonjour,
J'ai l'impression que vous essayez de vous en sortir sans faire d'archivage. C'est une très mauvaise idée et ça va vous péter à la figure. Configurez l'archivage, et ça ira beaucoup mieux
>>> Vous voulez sans doute parler si la réplication s'arrête durant un certain laps de temps et qu'il faudra la reconstruire pour la redémarrer n'ayant plus les jeux de wal nécessaires pour rattraper le master non ? Ou quels autres inconvénients signalez vous ?
Il ne faut surtout pas utiliser pg_archivecleanup sur le répertoire pg_xlog du serveur primaire
Pourquoi ? On a fait un jeu de test sur pg_archivecleanup hier soir et çà à marcher pourtant !!! Mais j'aimerai quand même savoir la raison pour que vous déconseillez cette méthode.
Auparavant, on avait déjà désactive archive_mode durant un certain laps de temps mais les wal dans pg_xlog ne diminuaient pas, et engager toujours l'espace disque. Puis on a monté le répertoire dans la réplique, qu'on a ensuite purgé les pgxlog avec pg_arhivecleanup command, et çà marchait.
