pg_start_backupführt einen Checkpoint durch, wie dezso feststellt. Dies hat zwar Auswirkungen, aber Ihre Datenbank führt Checkpoints ohnehin regelmäßig durch und muss dies auch tun, um zu funktionieren. Sie sind also eindeutig kein Problem für Sie. Ein früher Checkpoint bedeutet, dass weniger Daten gesammelt wurden, was bedeutet, dass ein Checkpoint von pg_start_backupgeringerer Auswirkung als normal ist.
Wenn Sie sich Sorgen machen müssen, ist der rsync oder ein gleichwertiger pg_basebackupSchritt. Die Lese-E / A-Vorgänge hiervon werden nicht allzu schlecht sein, da sie sequentiell ablaufen. Wahrscheinlich beeinträchtigt sie jedoch die E / A-Leistung Ihrer Datenbank erheblich. Außerdem werden heiße Daten aus dem RAM-Cache eher zugunsten von weniger gedrängt -verwendete Daten, wodurch der Cache überlastet wird, wenn die benötigten Daten wieder eingelesen werden.
Sie können niceund verwenden ionice, um die Auswirkungen der E / A zu begrenzen (jedoch nicht die Auswirkungen auf den Cache). Dies ist jedoch mit Kosten verbunden. Die Sicherung dauert länger, und bis Sie die Sicherung abgeschlossen und pg_stop_backupIhr System ausgeführt haben, sammelt sich - so wie ich es verstehe - die WAL an, die nicht gelöscht werden kann, und es sammelt sich die Prüfpunktverschuldung für einen BIG-Prüfpunkt am Ende des Sicherungslaufs an. Außerdem werden Tabelle und Index angesammelt Aufblähen, weil es tote Reihen nicht aufräumen kann. Sie können es sich also wirklich nicht leisten, das Backup für immer dauern zu lassen, besonders wenn Sie sehr hohe Churn-Tabellen haben.
Letztendlich ist es schwer zu sagen, ob Sie in Ihrer Umgebung gefahrlos pg_start_backupund pg_stop_backupfür Hot-Backups verwenden können. Die meisten Leute können, aber wenn Sie sich dem nähern, was Ihre Hardware leisten kann, enge Timing-Anforderungen haben, sich das Risiko eines Stalls nicht leisten können und sowohl sehr hohe Churn-Tische als auch sehr große Tische haben, kann dies problematisch sein .
Leider müssen Sie es so ziemlich testen und sehen.
Wenn möglich, ist es möglicherweise sinnvoll CHECKPOINT, einen atomaren Snapshot des Volumes zu erstellen, auf dem sich Ihre Datenbank befindet. Verwenden Sie stattdessen LVM, die Tools Ihres SAN, EBS oder was auch immer Sie gerade verwenden. In diesem Fall können Sie den Schnappschuss nach Belieben kopieren. Dieser Ansatz eignet sich nicht für eine Basissicherung für PITR / Warm-Standby / Hot-Standby, eignet sich jedoch perfekt für eine statische Sicherungskopie und hat eine wesentlich geringere Auswirkung auf das System. Sie können dies jedoch nur tun, wenn Ihre Snapshots atomar sind und sich Ihre gesamte Datenbank einschließlich WAL auf einem einzigen Volume befindet.
Eine Möglichkeit, die ich noch nicht untersucht habe, ist die Kombination der beiden Ansätze. Mir fällt ein, dass man möglicherweise ( ungetestet und möglicherweise falsch und unsicher , ich weiß es noch nicht):
pg_start_backup- Löst Snapshots aller Tablespaces, des Hauptdatenverzeichnisses und des xlog-Volumes aus
pg_stop_backup- Kopieren Sie WAL bis zum endgültigen Archiv von
pg_stop_backup
- Kopieren Sie die Daten von den Snapshot-Volumes
Im Wesentlichen besteht die Idee darin, die Verzögerungszeit der DB für die Checkpoints zu verringern, indem Sie einen Zeitpunkt für jedes Volume festlegen, das Sie nach Belieben kopieren können.