pg_start_backupeffectuera un point de contrôle, comme le note dezso. Cela a un impact, mais votre base de données effectue des points de contrôle assez régulièrement de toute façon, et doit le faire pour fonctionner, donc ce n'est clairement pas un problème pour vous. Un point de contrôle précoce signifie que moins de données ont été accumulées, ce qui signifie que, si quelque chose, un point de contrôle pg_start_backupaura un impact moindre que la normale.
Où vous devez vous inquiéter est la rsync ou l' pg_basebackupétape équivalente . Les E / S de lecture à partir de cela ne seront pas trop mauvaises car elles sont séquentielles, mais cela affectera probablement encore considérablement les performances d'E / S de votre base de données, et cela aura également tendance à pousser les données chaudes hors du cache RAM au profit de moins -utilisé les données, provoquant la destruction du cache car les données les plus nécessaires sont ensuite relues.
Vous pouvez utiliser niceet ionicepour aider à limiter l'impact des E / S (mais pas l'impact du cache); cependant, cela a un coût. La sauvegarde prendra plus de temps, et jusqu'à ce que vous terminiez la sauvegarde et exécutiez pg_stop_backupvotre système est - si je comprends bien - accumulant des WAL qu'il ne peut pas supprimer, accumulant la dette du point de contrôle pour un GRAND point de contrôle à la fin de la sauvegarde, et accumulant la table et l'index ballonnement car il ne peut pas nettoyer les lignes mortes. Vous ne pouvez donc vraiment pas vous permettre que la sauvegarde prenne une éternité, surtout si vous avez des tables de désabonnement très élevées.
En fin de compte, il est difficile de dire si vous pouvez utiliser en toute sécurité pg_start_backupet pg_stop_backuppour des sauvegardes à chaud dans votre environnement. La plupart des gens le peuvent, mais si vous êtes proche de ce que votre matériel peut faire, que vous avez des contraintes de temps serrées, que vous ne pouvez pas courir le risque d'un décrochage et que vous avez des tables de désabonnement très élevées ainsi que de très grandes tables, cela peut être gênant. .
Malheureusement, vous devez à peu près le tester et voir.
Si vous le pouvez, il peut être utile d'émettre un CHECKPOINTpuis de prendre un instantané atomique du volume sur lequel se trouve votre base de données à l'aide de LVM, des outils de votre SAN, d'EBS ou de tout ce que vous utilisez. Si vous pouvez le faire, vous pouvez ensuite copier l'instantané à votre guise. Cette approche ne convient pas pour effectuer une sauvegarde de base pour PITR / redondance d'UC / redondance d'UC, mais elle est parfaitement adaptée à une copie de sauvegarde statique et a un impact beaucoup plus faible sur le système. Cependant, vous ne pouvez le faire que si vos instantanés sont atomiques et que votre base de données entière, y compris WAL, est sur un seul volume.
Une possibilité que je n'ai pas encore étudiée consiste à combiner les deux approches. Il me semble que l'on pourrait éventuellement ( non testé et peut-être faux et dangereux , je ne sais pas encore):
pg_start_backup- Déclenchez des instantanés de tous les espaces disque logiques, du datadir principal et du volume xlog
pg_stop_backup- Copiez WAL dans l'archive finale de
pg_stop_backup
- Copiez les données des volumes instantanés
Essentiellement, l'idée est de réduire la durée pendant laquelle la base de données doit retarder ses points de contrôle en prenant un point dans le temps de chaque volume que vous pouvez copier à votre guise.