Make backup copies of configuration files in config_dir #2371
Conversation
Before, the .backup files were always stored in the data directory. However, if there is a distinct configuration directory, it seems logical to put them there. If config_dir is not configured, it defaults back to the data directory, so this will not change things for setups where postgresql.conf is in the data directory. On the other hand, it will help with setups where postgresql.conf is outside the data directory and has local changes. In this case, those no longer get overwritten on boostrap/clone from the primary's backup configuration file that is streamed to the boostrapped node. Close zalando#2370
Pull Request Test Coverage Report for Build 2761120800
💛 - Coveralls |
|
The whole point of creating backups of configuration files is that configs are not actually backed up by some backup tools (for example wal-e). After restoring such a backup we copy these files back. If config files are stored in the external place things get complex (as usual). It is absolutely normal that the config directory is empty during the bootstrap or replica creation and we want to copy backup files over (current behavior). And your patch will break it. |
So what you actually want is to (optionally, or maybe by default, but configurable) copy over the primary's
Well fair enough, but then Patroni is currently breaking if there's already a local (and different) configuration file. Maybe it should not overwrite existing configuration files? Right now, if there is any change between primary and standby, those get overwritten, resulting in configuration loss. Would it be ok to make this configurable, i.e. let Patroni know whether we want the |
Before, the .backup files were always stored in the data directory. However, if
there is a distinct configuration directory, it seems logical to put them
there. If config_dir is not configured, it defaults back to the data directory,
so this will not change things for setups where postgresql.conf is in the data
directory.
On the other hand, it will help with setups where postgresql.conf is outside
the data directory and has local changes. In this case, those no longer get
overwritten on boostrap/clone from the primary's backup configuration file that
is streamed to the boostrapped node.
Close #2370