Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nous sauvegardions la seule base de donnée Postgres que nous avions a chaud, en utilisant pg_start_backup, puis pg_stop_backup
Nos WALL etant sauvegardés et purgés toutes les 2h.
Entre le pg_start_backup et le pg_stop_backup nous utilisions Networker afin de mettre sur bande nos données (dont des tablespaces).
Nous avons une nouvelle application qui elle a été construite en mode cluster ou instance pour Postgres.
Ainsi pour une instance Postgres, nous avons 4 bases de données distinctes derrière.
La méthode de sauvegarde a chaud que nous utilisions précédemment, ne fonctionne plus. En effet des que l'on démarre un backup sur la première base et que nous lançons le second sur la seconde base, afin que les données des 4 bases soit synchronisées, Postgres nous signale qu'il a deja un pg_start_backup en court, et que donc il ne peut pas backupé la seconde en même temps.
Nous avons donc décidé d'utiliser pg_basebackup qui répond presque parfaitement a notre problématique, puisque c'est toujours une sauvegarde a chaud, avec PITR.
En revanche il faut spécifier un fichier de sortie. Et la est notre problème. Nous aimerions toujours utiliser Networker pour sauvegarder sur bande nos FS.
Seulement avant nous avions le contrôle entre le start et le stop backup, plus maintenant.
Y'a t'il une solution pour qu'en gros ce soit Networker qui gère la sauvegarde physique des données ? Ou sommes nous obligé de prendre le fichier résultat de pg_basebackup et le mettre lui sur bande ?
Et dans ce cas la, une sauvegarde physique de nos FS n'est plus utile du tout je suppose ?
Cdt,
Bonjour,
Je rebondis sur le sujet, car ca parle de disque SSD. J'ai suivi une formation Postgres il y a peu, et je me souviens que le formateur, nous avait indiqué les avantages et inconvénients de tels disques sur une base de données (que ce soit postgres ou pas d'ailleurs). Pour ce qui est des avantages, je n'ai pas trop de mal a retrouver, ca semble être la vitesse d'écriture et de lecture physique.
En revanche je suis certain que le formateur avait relevé, un problème lié aux BD en général avec ces disques. Peut etre quelqu'un saurait il me repondre sur les inconvenients de tels disques ?
Merci par avance.
Merci bien.
J'aurais une autre interrogation concernant cette fois ci la remise a zéro des statistiques.
A part l'utilisation de pg_stat_reset, y'a t'il d'autres événements qui peuvent remettre a jour les statistiques du nombre de fois qu'un index est utilisé par exemple ?
Un REINDEX puisqu'il drop et recréer les index si je ne m'abuse, remet-il a zéro également les statistiques ?
Bonjour,
Existerait il une table système sur laquelle s'appuyer afin de connaitre l'état de fragmentation des tables ?
En gros puis je obtenir une estimation de l'espace disque que je pourrais gagner en faisant un vacuum full sur ma base ?
Sachant que c'est une opération qui peut s'avérer parfois lourde, j'aimerais être sur du gain que je peux en retirer.
Merci par avance.
Et dans le cas d'une migration de la version 8.3.8 vers la 8.4, je suppose que c'est la même chose ? Je ne pourrais avoir qu'une version installée ou alors me sera t'il possible d'avoir mon serveur Postgrés en 8.3.8 et a coté mes RPM client Postgrés en 8.4, afin de faire ma sauvegarde avec le pg_dump de la version cible, en l'occurrence dans mon cas la 8.4 ?
Merci pour ces précisions.
Donc j'ai bien tout suivi, il me suffit d'installer les RPM suivants (étant en Red Hat 5), afin de disposer des fonctionnalités client de postgres, pour ainsi effectuer ma sauvegarde via pg_dump en 8.4 :
-> postgresql-libs
-> postgresql
Et ensuite dérouler le mode opératoire fournit par Postgres.
Et je peux déplacer le répertoire contenant le logiciel Postgres, comme bon me semble, post installation.
Cdt
PS: Merci pour votre disponibilité et réactivité en tout cas, c'est assez impressionnant.
Bonjour,
Comme vu de nombreuses fois sur votre forum, il est conseillé lors d'une migration d'utiliser pour la sauvegarde le pg_dump de la version cible.
J'aimerai avoir un petite précision sur ce sujet. Prenons par exemple une migration majeure de version 8.3.8 vers 8.4
Cela implique donc que l'installation du moteur 8.4 est la première des phases de la migration ? Donc dans un autre répertoire que celui contenant le moteur de la version 8.3.8.
Si la réponse a ma question est une affirmation, dans ce cas la, est il possible post migration, de déplacer le moteur 8.4 a la place de l'ancien 8.3.8 ? En gros ce que j'aimerais savoir c'est si un move d'un moteur postgres dans un autre répertoire, le rend inutilisable ?
Merci par avance
Pages : 1
