Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Depuis quelques semaines, j'ai des dysfonctionnements de mes bases de données.
D'après les logs ces problèmes viendraient vraisemblablement après un simple :
delete from fichier_clients where numero_client = 1309
ou : delete from entete_document where numero_document = 1950020
les plantages ne sont pas systématiques, apres un vaccum par exemple, la commande se passe bien,
puis se sera le tour d'une autre base de données de provoquer le plantage, avec toujours comme élément de cause un : DELETE FROM MATABLE
pour être complet, j'ai changé de serveur recemment avec une nouvelle reinstallation en postgresql 11 / PHP 7.03 sur une débian 9.
avant ça, pas de problème.
Merci pour votre aide.
ghouly,
extrait des logs :
2019-02-06 11:55:32.008 CET [1869] LOG: processus serveur (PID 13167) a été arrêté par le signal 11 : Segmentation fault
2019-02-06 11:55:32.008 CET [1869] DÉTAIL: Le processus qui a échoué exécutait : delete from fichier_clients where numero_client = 1309
2019-02-06 11:55:32.008 CET [1869] LOG: arrêt des autres processus serveur actifs
2019-02-06 11:55:32.008 CET [13334] webgestion@gmao28 ATTENTION: arrêt de la connexion à cause de l'arrêt brutal d'un autre processus serveur
2019-02-06 11:55:32.008 CET [13334] webgestion@gmao28 DÉTAIL: Le postmaster a commandé à ce processus serveur d'annuler la transaction
courante et de quitter car un autre processus serveur a quitté anormalement
et qu'il existe probablement de la mémoire partagée corrompue.
2019-02-06 11:55:32.008 CET [13334] webgestion@gmao28 ASTUCE : Dans un moment, vous devriez être capable de vous reconnecter à la base de
données et de relancer votre commande.
2019-02-06 11:55:32.008 CET [13318] webgestion@gmao50 ATTENTION: arrêt de la connexion à cause de l'arrêt brutal d'un autre processus serveur
2019-02-06 11:55:32.008 CET [13318] webgestion@gmao50 DÉTAIL: Le postmaster a commandé à ce processus serveur d'annuler la transaction
courante et de quitter car un autre processus serveur a quitté anormalement
et qu'il existe probablement de la mémoire partagée corrompue.
2019-02-06 11:55:32.008 CET [13318] webgestion@gmao50 ASTUCE : Dans un moment, vous devriez être capable de vous reconnecter à la base de
données et de relancer votre commande.
Hors ligne
Vous ne devriez pas avoir de SegFault lors de l'exécution de PostgreSQL. Il y a donc un problème quelque part.
Vous dîtes avoir changé de serveur. Comment s'est fait ce changement de serveur ? comment avez-vous la réinstallation en PostgreSQL 11 ?
Autre possibilité, avez-vous installé des extensions ? si oui, lesquelles ?
Guillaume.
Hors ligne
Bonjour,
le serveur est neuf, hebergé chez OVH,
j'ai moi meme reinstallé postgresql en ligne de commande
***********
Step 1 – Setup Apt Repository
wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O - | apt-key add -
Debian 9 (Stretch)
sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main" >> /etc/apt/sources.list.d/pgdg.list'
Step 2 – Install PostgreSQL Server
apt-get update
apt-get install postgresql postgresql-contrib
Step 3 – Connect to PostgreSQL
su - postgres
psql
Step 4 – Créer l'utilisateur et donnez les droits
create user myuser WITH ENCRYPTED PASSWORD 'xxxxxx';
ALTER USER myuser CREATEDB;
ALTER USER myuser CREATEROLE;
Step 5 - installation des paquets (ont été absents)
$ echo "deb http://ftp.de.debian.org/debian stretch main" >> /etc/apt/sources.list
$ apt-get update
************
SELECT * FROM pg_extension
"plpgsql" 10 11 false "1.0"
"hstore" 10 2200 true "1.5"
ps, j'avais oublié cette derniere extention , je ne sais plus si ce hstore ne serait pas impliqué dans ce qui m'arrive ?
par honneté, je ne sais meme pas à quoi il sert du coup , en tout cas je ne m'en sert pas.
Merci pour votre aide.
Dernière modification par gouly (06/02/2019 17:40:57)
Hors ligne
Côté logiciel vous n'utilisez à première vue que du très standard que tout le monde utilise, donc un défaut hardware est une piste possible. En particulier, une barrette mémoire défaillante peut produire ce genre de plantage récurrent.
Vous pouvez déjà vérifier si votre serveur a de la mémoire à correction d'erreur (ECC) avec la commande
dmidecode --type memory (chercher "Error Correction Type" dans le résultat)
et si oui regarder s'il y a des erreurs dans le syslog relatives à la mémoire
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
merci pour votre aide
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
Handle 0x001E, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 64 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Handle 0x001F, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x001E
Error Information Handle: Not Provided
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: Unknown
Set: None
Locator: DIMM_A1
Bank Locator: NODE 0 CHANNEL 0 DIMM 1
Type: Unknown
Type Detail: None
Speed: Unknown
Manufacturer: Empty/NO DIMM
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Rank: Unknown
Configured Clock Speed: Unknown
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: Unknown
Handle 0x0020, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x001E
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: DIMM_A2
Bank Locator: NODE 0 CHANNEL 0 DIMM 2
Type: DDR4
Type Detail: Synchronous
Speed: 2400 MHz
Manufacturer: Micron
Serial Number: 15AEE772
Asset Tag: DIMM_A2_AssetTag
Part Number: 9ASF1G72AZ-2G3B1
Rank: 1
Configured Clock Speed: 2400 MHz
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: 1.2 V
Handle 0x0021, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x001E
Error Information Handle: Not Provided
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: Unknown
Set: None
Locator: DIMM_B1
Bank Locator: NODE 0 CHANNEL 1 DIMM 1
Type: Unknown
Type Detail: None
Speed: Unknown
Manufacturer: Empty/NO DIMM
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Rank: Unknown
Configured Clock Speed: Unknown
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: Unknown
Handle 0x0022, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x001E
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: DIMM_B2
Bank Locator: NODE 0 CHANNEL 1 DIMM 2
Type: DDR4
Type Detail: Synchronous
Speed: 2400 MHz
Manufacturer: Micron
Serial Number: 15AEE6BC
Asset Tag: DIMM_B2_AssetTag
Part Number: 9ASF1G72AZ-2G3B1
Rank: 1
Configured Clock Speed: 2400 MHz
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: 1.2 V
Hors ligne
Et comment avez-vous réinstallé la base ?
Guillaume.
Hors ligne
chaque client a sa propre base,
dans un premier temps, création via pgadmin de la coquille vide (CREATE DATABASE nombase)
puis j'ai cree un script (sous windows)qui me restaure les données clients
@echo off
SET PGPASSWORD=xxxxxxxxxx
echo on
"F:\Postgresql\bin\pg_restore.exe" --host adresse_ip --port 5432 --username "webgestion" --clean --verbose --dbname "gmao01" "F:\BACKUP postgres clients\%1\gmao01.backup"
"F:\Postgresql\bin\pg_restore.exe" --host adresse_ip1 --port 5432 --username "webgestion" --clean --verbose --dbname "gmao02" "F:\BACKUP postgres clients\%1\gmao02.backup"
"F:\Postgresql\bin\pg_restore.exe" --host adresse_ip --port 5432 --username "webgestion" --clean --verbose --dbname "gmao05" "F:\BACKUP postgres clients\%1\gmao05.backup"
"F:\Postgresql\bin\pg_restore.exe" --host adresse_ip --port 5432 --username "webgestion" --clean --verbose --dbname "gmao06" "F:\BACKUP postgres clients\%1\gmao06.backup"
"F:\Postgresql\bin\pg_restore.exe" --host adresse_ip --port 5432 --username "webgestion" --clean --verbose --dbname "gmao07" "F:\BACKUP postgres clients\%1\gmao07.backup"
Hors ligne
OK, donc un pg_restore, ce qui ne devrait pas poser de problème. J'avoue qu'en dehors d'un problème matériel (RAM ou disque principalement), je ne vois pas ce qui pourrait causer ça.
Guillaume.
Hors ligne
Ah si, une autre possibilité serait que la table déclenche un trigger au moment de la suppression de la ligne. Ce trigger, si codé en C, pourrait occasionner un Seg Fault.
D'ailleurs, vous parlez d'une requête spécifique. À chaque exécution de cette requête, il y a un Seg Fault ? Si jamais on transforme ce "delete from fichier_clients where numero_client = 1309" en "select * from fichier_clients where numero_client = 1309", y a -t-il aussi un crash ?
Guillaume.
Hors ligne
Bonjour gleu,
je pense avoir trouvé et grâce à vous :-)
vous aviez evoqué les extensions au début cette discution.
et j'avais hstore qui était présent,
apres un : DROP EXTENSION hstore;
je touche du bois, mais depuis près de 36h maintenant, plus de plantage.
j'attend encore une journée et je cloture ce post en remerciant tous le monde,
Dernière modification par gouly (08/02/2019 12:59:57)
Hors ligne
Bonjour,
je reviens finalement apres quelques jours d'attente,
ayant supprimé l'extension hstore, mon systele est devenu beaucoup plus stable,
mais force de constater que je viens d'avoir la même erreur.
mais cette fois en supprimant une ligne non pas depuis mon application web, mais depuis...PgAdmin
voila les logs. d'origine de la panne
******************
2019-02-13 13:12:07.616 CET [1869] LOG: processus serveur (PID 26333) a été arrêté par le signal 11 : Segmentation fault
2019-02-13 13:12:07.616 CET [1869] DÉTAIL: Le processus qui a échoué exécutait : DELETE FROM public.entete_document
WHERE id IN
(12801);
2019-02-13 13:12:07.616 CET [1869] LOG: arrêt des autres processus serveur actifs
2019-02-13 13:12:07.616 CET [26329] webgestion@postgres ATTENTION: arrêt de la connexion à cause de l'arrêt brutal d'un autre processus serveur
2019-02-13 13:12:07.616 CET [26329] webgestion@postgres DÉTAIL: Le postmaster a commandé à ce processus serveur d'annuler la transaction
courante et de quitter car un autre processus serveur a quitté anormalement
et qu'il existe probablement de la mémoire partagée corrompue.
2019-02-13 13:12:07.616 CET [26329] webgestion@postgres ASTUCE : Dans un moment, vous devriez être capable de vous reconnecter à la base de
données et de relancer votre commande.
**************
voila la conséquence qui s'en suit quelques lignes plus bas
toutes les base de données ont plantées
**************
2019-02-13 13:12:09.462 CET [26413] webgestion@gmao50 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:09.527 CET [26414] webgestion@postgres FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:09.673 CET [26416] webgestion@postgres FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:10.132 CET [26415] webgestion@gmao51 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:10.187 CET [26417] webgestion@gmao51 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:10.804 CET [26418] webgestion@gmao52 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:10.860 CET [26419] webgestion@gmao52 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:11.459 CET [26420] webgestion@gmao53 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:11.516 CET [26421] webgestion@gmao53 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:12.022 CET [26423] webgestion@postgres FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:12.168 CET [26424] webgestion@postgres FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:12.189 CET [26422] webgestion@gmao54 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:12.253 CET [26425] webgestion@gmao54 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:12.966 CET [26426] webgestion@gmao55 FATAL: le système de bases de données est en cours de restauration
2019-02-13 13:12:13.023 CET [26427] webgestion@gmao55 FATAL: le système de bases de données est en cours de restauration
***************
pour le coups, cette fois je suis perdu !!
merci pour votre aide.
gouly,
Hors ligne
Pages : 1
