Vous n'êtes pas identifié(e).
Bonjour,
Je rencontre un problème lors de la restauration d'une base sur un environnement en streaming_réplication. Lors de la restauration d'une des bases utilisant pg_restore, je me rend compte que mes FS $PG_XLOG et $ARCH sont plein à 100% quelques minutes après le lancement de pg_restaure et du coup la restauration échoue.
Questions:
Est ce que je devrai arrêter l'esclave et modifier les paramètres d'archives dans postgresql.conf et après je restaure l'esclave avec pg_basebackup?
Faut il piocher dans les paramètres postgresql.conf pour résoudre ce problème? Voir s'il faut voir autre choses? ou tout simplement augmenter la taille des FS $PG_XLOG et $ARCH? de combien?
Voici qq information:
*PostgreSQL 9.1.6 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), 64-bit
*l'archivage des wal s'effectue dans un FS du serveur esclave.
*archive_cleanup est en place.
* Je possède 12Go de ram sur le servaur maître et le shared_buffers=3GB.
* La base en question fait 22Go
* le FS pg_xlog fait 8Go ainsi que le FS des archives.
* La totalité des données Postgresql sur cette machine est de ~38Go.
Merci d'avance pour votre aide.
Hors ligne
Il vous faut augmenter fortement l'espace disponible pour les journaux de transactions. Pour baisser la consommation des journaux de transactions, la meilleure méthode est d'augmenter le checkpoint_segments et le checkpoint_timeout. Mais bon, 8 Go pour le pg_xlog et les archives, c'est vraiment trop peu.
Guillaume.
Hors ligne
Merci guillaume pour votre réponse,
Pour information, voilà ce que j'ai comme paramètres:
checkpoint_segments = 40
checkpoint_timeout = 5min ==> (valeur par défaut).
Une question: c'est quoi la proportion de la taille des FS $PG_XLOG et $ARCH par rapport à la taille de la base que j'ai? Y a-t- il une formule de calcul et une valeur (à la louche) à me communiquer SVP.
Bien à vous
Hors ligne
Vous pouvez être certain d'avoir 3*40+1 journaux, soit 2 Go, en fonctionnement normal. Ensuite, si vous avez des pics d'activité, ça peut augmenter. Si wal_keep_segments est supérieur à 0, ça va augmenter aussi. C'est pire si l'archivage ne fonctionne pas (auquel cas ça dépend de votre réactivité à corriger l'archivage, et avec 8Go, va falloir être rapide pour ne pas bloquer complètement votre instance).. De toute façon, c'est bien trop peu pour le répertoire d'archivage. Si jamais vous le remplissez, l'archivage ne fonctionne plus et du coup vous remplissez aussi le répertoire des journaux, ce qui finit par bloquer PostgreSQL.
Bref, plus, beaucoup plus, mais sans formule malheureusement 
Guillaume.
Hors ligne
J'aurai bien aimer avoir une valeur même à la louche hélas. Il me reste qu'a demander de doubler l'espace du FS.
Chose aussi que je ne comprends pas c'est que en appliquant la règle du nombre de fichiers "wal" (3 * checkpoint_segments + 1). Le résultat n'est pas bon chez moi car j'ai 82 fichiers wals seulement !? Dois je toucher à un autre paramètre ou c'est un fonctionnement normal?
Merci encore
Hors ligne
Doubler l'espace du FS est une valeur à la louche
3 x checkpoint_segments + 1 est un maximum standard. Pas une valeur obligatoire.
Guillaume.
Hors ligne
Merci Guillaume pour ta réponse et pour ta disponibilité.
Hors ligne
