Exécuter pg_dump sur un serveur de secours automatique?

Avertissement: je n'ai certes pas encore essayé, mais je ne suis pas sûr de savoir si cela ne fonctionnait pas correctement, alors je voulais demander.

Je voudrais exécuter un travail de sauvegarde nocturne (via pg_dumpall) à partir d'un serveur de secours à chaud exécutant la réplication en streaming, pour éviter de mettre cette charge sur le serveur principal. Je n'ai vu que mention de quelques pièges que les gens ont rencontrés, par exemple ici et ici , mais très peu de conseils. Ce n'est pas grave si la sauvegarde est légèrement en retard sur le primaire, tant qu'elle est cohérente (ce qu'elle devrait être).

Mes questions sont:

1. Est-ce que je veux vraiment faire cela, ou la sauvegarde doit-elle être effectuée sur le serveur principal? Pourquoi?

2. Lors d'un vidage en mode veille, de quels paramètres ai-je besoin et quelle procédure dois-je utiliser pour le faire correctement? par exemple, dois-je arrêter la réplication pendant la durée de la sauvegarde?

AFAIK, en cours d'exécution pg_dump sur une est l'une des principales fonctions des standby. Il est parfaitement sûr, bien qu'il ne soit pas parfaitement fiable - les vidages peuvent échouer si le serveur de secours interrompt la transaction lorsqu'elle est trop loin derrière le maître.

La seule chose que vous devez vraiment surveiller est de vous assurer que le mode veille est à jour et se maintient. Si la veille a perdu sa connexion avec le maître et a pris trop de retard, vous ne voulez pas sauvegarder joyeusement une veille obsolète de trois semaines.

Vous devrez permettre au standby de se placer assez loin derrière le maître pendant la sauvegarde, car il devra sinon annuler votre pg_dumptransaction afin de continuer à rejouer WAL. Consultez la documentation sur la redondance d'UC , en particulier la section «Gestion des conflits de requêtes», ainsi que les paramètres max_standby_archive_delayet max_standby_streaming_delay.

Notez que le maître doit être disposé à conserver suffisamment d'archives WAL pour permettre à l'esclave de rattraper son retard.

1. Nous faisons de la sauvegarde en veille, c'est très bien.
2. Pour éviter un conflit d'instructions annulé pendant la sauvegarde sur le système de secours, vous devez suspendre la réplication en mode veille SELECT pg_xlog_replay_pause();, puis exécuter votre sauvegarde, une fois qu'elle est terminée, exécutez SELECT pg_xlog_replay_resume();pour reprendre la réplication. Gardez à l'esprit que l'exécution des commandes ci-dessus entraînera un retard de récupération sur l'esclave, qui peut être assez important, selon la taille de votre base de données. Tenez également compte de l'espace que prendront les segments WAL, car ils ne seront pas rejoués sur l'esclave pendant la pause.

Vous pouvez trouver d'autres fonctions d'administration utiles dans la documentation . Par exemple, vérifiez si le serveur est en fait dans la récupération, avant la pause , il: SELECT pg_is_in_recovery().

Si vous suspendez la réplication pendant la sauvegarde, (c'est une bonne idée pour préserver l'intégrité et la cohérence), vous pouvez modifier certaines lignes dans votre postgresql principal:

Combien de temps retarde habituellement votre sauvegarde. Assurez-vous que le nœud maître conserve tous les fichiers x_log nécessaires pour reprendre la réplication. Vous pouvez le faire dans l'édition postgresql.conf

wal_keep_segments = 32      # in logfile segments, 16MB each; 0 disables

Si vous ne modifiez pas cela et que votre processus de sauvegarde est trop long, c'est probablement que le nœud maître efface les fichiers xlog avant de les envoyer à l'esclave.