Add support for WAL archive with versions and persistant storage #63
Conversation
|
@sstubbs Some of these commits are just chaning /entry -> /scripts since it better describes that. But otherwise this adds functionality for safe storage, on the kubernetes side, where it would be a partial solution until we get everything else through. Feel free to comment on any unusable structure. |
There was a problem hiding this comment.
OK great. I'm sure you know this but just to double check taking backup via cp or rsync should have the server stopped.
https://www.postgresql.org/docs/10/backup-file.html The functionality I'm working on is using native postgres replication but this is only a slave copy for ha/distater recovery. Once what I'm busy with is working and we both happy with it, we could use this functionality you have added here to do backups at certain points rather than pg_dump.
|
Actually, I am not aware of that. Why would cp or rsync stop the server? As I understand, and in the settings posted the cp should happen on a partial file for Wal. If that is not the case then maybe this method should be avoided. Can you give an example? |
|
Sorry I misread the commit. I thought you were copying the whole cluster as that was the only way in my mind to backup the gtm as I didn't realise it supported archive_command. Let me test this and see if it works. If the gtm supports archive_command then this is a brilliant solution and solves the backup issue. |
LamaAni
dismissed
sstubbs’s stale review
Needs re-review see comment about purpose
|
Needs re-review. |
|
@sstubbs Any update on this? |
What:
Add support for WAL archiving of data-nodes.
Why
To allow datanodes to be stored to remote data, local data, or other storage, an automatic script for storing the WAL was added. Versions are supported to allow data to be versioned.
Missing: Auto-versioning of data on startup.