Vous n'êtes pas identifié(e).
Bonjour,
De combien de temps d'arrêt disposez-vous (interruption de service) ?
Vous faites du streaming replication simple, sans HA type patroni ou autre ?
Quelle volumétrie avez-vous ?
Si vous pouvez vous permettre d'arrêter vos application plusieurs minutes, vous pouvez tester pg_upgrade.
Si ce n'est pas possible, pour minimiser le temps d'arrêt vous pouvez toujours utiliser la réplication logique qui permet d'avoir au sein d'un même cluster de serveur, plusieurs versions majeures de postgresql.
Pour TimescaleDB, je ne connais pas, désolé.
ou encore mieux pour toute la base avec pg_stat_statements :
https://docs.postgresql.fr/16/pgstatstatements.html
attention : dixit la doc : "Le module doit être chargé par l'ajout de pg_stat_statements à shared_preload_libraries dans le fichier de configuration postgresql.conf"
bonjour
vous pouvez avoir ça pour une requête en particulier avec un "EXPLAIN (ANALYZE, BUFFERS) ma_requête;"
https://docs.postgresql.fr/16/using-explain.html
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
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.
oui c'est ça.
Dans pgAdmin4 le délimiteur doit être par défaut à ",".
Il faut que vous le changiez pour ";"
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.
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 ?
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).
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.
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.
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.
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.
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 ?
malheureusement je ne vois pas d'autres alternatives.
pas de sauvegardes, pas de restaurations.
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)
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 ?
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 ?
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é.
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
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.
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.
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.
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.
Bonjour, peut être voulez vous parler de foreign key (FK) ?
si oui alors la doc est ici :
https://docs.postgresql.fr/16/ddl-const … TRAINTS-FK
