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 : Site PostgreSQL.fr » Utilisation /tmp sur une VM Linux à l'export d'un dump au format TAR » 20/03/2024 13:14:31

Bonjour,

cela n'a rien à voir avec le user postgres.
/tmp n'est pas vraiment un bon endroit pour faire un export de données.
Donc soit vous agrandissez /tmp suffisamment pour pouvoir accueillir le dump
soit vous générez le dump dans un autre file system (dans lequel postgres a le droit d'écrire)

Mais de toute façon évitez d'utiliser /tmp

#2 Re : Général » Solution pour versionner le code plpgsql » 14/03/2024 18:37:08

bonjour,

Je ne connais pas de meilleur solution que GIT pour versionner du code.
C'est incroyablement puissant et permet d'aller bien plus loin que ce que vous auriez pu imaginer au départ.
Un peu complexe au début, mais une fois que c'est ok, c'est parfait.

#3 Re : Migration » Difficile d'importer les données sur POstgreSQL » 27/02/2024 17:27:51

oui c'est ça.
Dans pgAdmin4 le délimiteur doit être par défaut à ",".
Il faut que vous le changiez pour ";"

#4 Re : Migration » Difficile d'importer les données sur POstgreSQL » 27/02/2024 16:37:28

Bonjour,

en première analyse vite fait : vous avez choisi le délimiteur "," alors que dans votre fichier csv c'est ";"
Et du coup ESCAPE n'est pas bon non plus.

#5 Re : Général » plus d'accès à la structure de mes tables ! » 16/02/2024 18:25:37

2ème série de question :
- votre "compte_initial" il sert à quoi ?
- qui est le propriétaire des tables que vous essaiez de voir mais que vous ne voyez pas ?
- qui est le propriétaire des tables que vous pouvez voir ?

#6 Re : Général » plus d'accès à la structure de mes tables ! » 16/02/2024 18:04:55

Bonjour
et si vous faites (avec une connexion postgres ou autre superuser) :

\dg+ votre_compte_initial

ça donne quoi ?
(remplacer "votre_compte_initial" par le vrai nom de votre user à problème).

#7 Re : Installation » upgrade postgres en docker » 06/02/2024 19:17:49

Bonjour,

Je ne suis pas un pro de docker mais comme dans tout système, normalement, vous pouvez avoir plusieurs versions de postgresql d'installé.
Il suffit ensuite de jouer avec les variables d'environnement.

#8 Re : Installation » postgres 10 sous red hat 9 » 31/01/2024 17:19:57

bonjour,

avez-vous essayer ceci :
https://yum.postgresql.org/repopackages … atoldrepos

Il s'agit de créer un repo chez vous via les repos archivés.
Enfin bref il suffit de suivre les exemples indiqués dans le lien.

#9 Re : Réplication » Switchover sans perte de données » 30/01/2024 17:12:40

Bonjour Guillaume,

Oui il s'agit bien de cette page.

Mais oui tu as absolument raison, les bascules volontaires/planifiées sont très différentes des bascules sur incident/urgentes.
Bien vu.
Je vais essayer de creuser encore un peu plus le sujet (qui est vraiment très intéressant et qui intéresse au plus haut point les décideurs dans les entreprises).
Sans trop d'espoir d'étudier le code car le python et moi... bof.

#10 Re : Réplication » Switchover sans perte de données » 29/01/2024 16:30:42

Merci Guillaume,

c'est intéressant.
Par contre en lisant cette partie du code et la doc patroni, j'ai l'impression que ça dépend en 1er lieu du type de replication (synchrone ou asynchrone).
En asynchrone la doc indique que la priorité est l'aspect "availability" au détriment des données. Donc dans ce mode patroni est autorisé à sacrifier des données.
Et tout ce joue dans ce cas avec le paramètre "maximum_lag_on_failover" : si ce maximum est atteint ou dépassé, le replica ne peut plus prétendre à être promu.
Mais avant ce maximum, c'est ok et donc ce lag de transaction est perdu.

#11 Re : Réplication » Switchover sans perte de données » 26/01/2024 17:17:47

Bonjour, alors ça c'est très intéressant. Est-ce que quelqu'un sait si Patroni fait ce genre de comparaison au moment d'une promotion/élection ?

#12 Re : Général » urgent : impossible de redémarrer une base postgres sans dump » 22/12/2023 12:22:08

malheureusement je ne vois pas d'autres alternatives.
pas de sauvegardes, pas de restaurations.

#13 Re : Général » urgent : impossible de redémarrer une base postgres sans dump » 22/12/2023 11:56:40

donc vous avez perdu un disque que vous avez remplacé.
Pourquoi ne pas appliquer le snapshot ovh "en entier" ce qui permettrait d'avoir tous les fichiers qui seraient remis aux bons endroits par l'application du snapshot ?
et ensuite relancer l'instance (restart pour être sûr)

#14 Re : Général » urgent : impossible de redémarrer une base postgres sans dump » 22/12/2023 11:15:07

et par défaut le PGDATA est situé à un seul endroit.
Si ce que vous semblez dire est exact, vous avez éclaté vos fichiers sur plusieurs disques distincts, donc vous devez avoir utilisé des tablespaces ?
exact ?

#15 Re : Général » urgent : impossible de redémarrer une base postgres sans dump » 22/12/2023 11:12:19

Bonjour,

oulala ! beaucoup d'information à droite et à gauche.
déjà on ne peut pas restaurer un PGDATA linux sur une machine windows.
comment avez vous sauvegarder votre instance linux avant d'avoir le problème de disque ?
Le principe de la sauvegarde physique c'est que vous ne pouvez pas restaurer qu'une partie seulement des fichiers car les autres fichiers seront en décallage.
En fait nos réponses dépendront de la manière dont vous avez sauvegarder votre instance avant le problème.
est-ce que vous êtes en mode archive_mode=on ?
avez vous au pire une sauvegarde logique (type pg_dump) ?
et surtout avez des traces du moteur postgres lorsque vous tenter de redémarrer l'instance ?

#16 Re : Général » Génération de WALs même avec wal_level=minimal » 30/11/2023 18:45:41

wal_level permet d'ajouter plus ou moins d'information dans les wal et cela permet (selon le niveau choisi) de faire de la replication physique, logique, etc...
Si vous mettez wal_level à minimal vous aurez moins d'informations dans les wal donc au final moins de wal au total pour une même période de temps qu'avec wal_level à logical.
archive_mode permet d'activer ou de désactiver l'archivage des wal à des fins de restauration PITR, c'est dire que selon la quantité de wal que vous archivé vous pourrez revenir jusqu'à un point dans le temps plus ou moins éloigné.

#17 Re : Général » Génération de WALs même avec wal_level=minimal » 30/11/2023 18:22:22

Bonjour,
vous ne pourrez jamais empêcher la génération des fichiers WAL car ce sont des éléments vitaux pour le fonctionnement de postgresql.
On ne va pas faire un cours ici mais pour faire vite : il ne faut jamais rien toucher du contenu du répertoire des wal sinon vous risquez de perdre définitivement votre instance et vos données.
https://docs.postgresql.fr/16/wal-intro.html

#18 Re : Général » Procédure de travail sur plusieurs serveurs répliqués » 24/11/2023 15:21:18

Bonjour,
Dans ce cas pourquoi ne pas utiliser la réplication physique plutôt que logique ?
avec la réplication physique, tout ce qui est fait sur le noeud leader est automatiquement envoyé sur le ou les noeuds replicas.
Ce n'est pas le cas avec la réplication logique qui n'envoie que les ordres DML de modification.

#19 Re : phpPgAdmin » Problème autovacuum ne marche pas » 07/11/2023 15:38:22

Bonjour,

L'autovacuum et le vacuum full sont 2 opérations différentes.
La vacuum full va réorganiser tous les blocs des tables, rendant l'espace disque, un peu comme si vous faisiez un export/import. Ce qui explique que la table passe de 3GB à 20MB.
L'autovacuum ne fait pas ça, à la place il va "flaguer" les lignes mortes pour qu'elles puissent être réutilisées par de nouvelles lignes. Donc dans ce cas la table ne devient pas plus petite, l'espace n'est pas rendu. Au mieux la table ne grossit pas ou moins vite que sans l'autovacuum.
Vous pouvez checker les actions autovacuum et autoanalyze dans cette vue : pg_stat_all_tables.

#20 Re : Réplication » [Résolu] réplication d'un cluster de prod vers un serveur test » 06/11/2023 12:15:57

Bonjour,
avec la réplication physique, toutes les opérations sur le leader sont effectuées automatiquement sur le ou les replicas.
Mais contrairement à la replication logique, les réplicas en réplication physique sont en read-only.

#21 Re : Général » modihier des clés external_id et reporter dans les tables liées » 11/10/2023 17:16:36

Bonjour,

et vos tables sont liés par quoi ?
dans le lien que j'avais donné, la doc explique la technique de la FK avec l'option "on update cascade" ce qui semble correspondre à votre besoin.
Mais je me trompe peut être.

#23 Re : Migration » [pg_upgrade] - Double migration vers v.12 » 25/09/2023 10:27:11

en relisant votre post, je comprend mieux.
Vous voulez fusionner les instances v10 et v11 dans une instance v12, c'est bien ça ?
Donc pour répondre à votre question : non ce n'est pas possible.
Pour la deuxième phase il faudra faire un pg_dump, pg_restore car l'instance v12 n'est plus vide à ce moment là (elle contient des données de la v10)

#24 Re : Migration » [pg_upgrade] - Double migration vers v.12 » 25/09/2023 10:24:35

Bonjour,

avant de lancer pg_upgrade, il faut faire un initdb pour créer une instance vide dans la version postgresql cible.
Donc cette instance doit être vide.
s'il y a des objets dans votre instance c'est que d'une manière ou d'une autre vous pointez vers l'instance à migrer, pas la nouvelle.

#25 Re : Réplication » chaine de connexion à un cluster Patroni / pgs14 » 07/09/2023 09:09:58

Bonjour,

Oui je confirme les propos de ioguix : si vous vous lancez dans le HA, quelque soit la solution choisie il faut avoir dans la maison quelqu'un qui connait bien le sujet car ça peut rapidement devenir complexe.

Au passage pour vos tests sur Patroni : vous pouvez toujours mettre le cluster en mode maintenance (patronictl pause) : cela va empêcher les bascules et donc l'élection d'un nouveau leader si vous arrêtez volontairement le leader actuel.

Pied de page des forums

Propulsé par FluxBB