Vous n'êtes pas identifié(e).
Bonjour Pifor,
détrompez-vous, pgbackrest est en capacité de ne restaurer que certaines bases d'une instance :
Exclude Database Option (--db-exclude)
Restore excluding the specified databases.
Databases excluded will be restored as sparse, zeroed files to save space but still allow PostgreSQL to perform recovery. After recovery, those databases will not be accessible but can be removed with the drop database command. The --db-exclude option can be passed multiple times to specify more than one database to exclude.
https://pgbackrest.org/configuration.ht … db-exclude
bonne journée à vous
Bonjour,
Je n'ai aucun intérêt à dire ça, mais les formations Dalibo sont les meilleurs.
Les prix sont dans la moyenne du marché.
Les docs de formation sont disponibles gratuitement (possibilité donc d'étudier avant même la formation ce qui augmente pour vous la qualité de la formation).
De plus les formateurs sont des professionnels aguerris
Bonjour,
Si vous avez un peu de temps à perdre, je vous invite à étudier Patroni qui est bien plus simple et robuste à utiliser que les autres solutions
(qui sont certes très performantes mais beaucoup compliquées à maitriser).
Patroni est peut être votre solution y compris pour la partie SSL parfaitement gérée.
Oh ! et pour les considérations de maintenances, c'est pour cette raison principale que nous sommes venus à considérer Patroni :
la bascule entre les nœuds est simplicime.
par exemple dans patroni, le HA proxy peut interroger l'api patroni avec un curl et le retour sera différent si c'est un leader ou un replica.
Bonjour,
ce genre de fonctionnalités passent par des outils type F5 ou HA proxy.
Il y a des exemples et des tutos un peu partout
ouaip... dans tous les pg_upgrade que j'ai fait jusque là, les instances source et cible étaient arrêtées.
Y compris au moment du check.
Je ne l'ai jamais tenté avec l'instance à upgrader démarrée.
Du coup je ne savais pas que le check était sensible à ça.
peut être un problème d'environnement ?
si vous faites :
wich initdb
ça doit vous renvoyer la version 15 de initdb
vous pouvez essayer en commençant la commande par :
/usr/pgsql-15/bin/pg_upgrade --check ....etc....
et en enlevant le -c d'origine
Bonjour,
essayez en enlevant "--link"
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)
