Need add more patroni params, otherwise, large-scale database cloning cannot be performed

[cdmikechen]

Please, answer some short questions which should help us to understand your problem / question better?

• Which image of the operator are you using?
  registry.opensource.zalan.do/acid/postgres-operator:v1.8.2
• **Where do you run it - cloud or metal? Kubernetes or OpenShift?
  OpenShift
• **Are you running Postgres Operator in production?
  yes
• Type of issue?
  Bug report

Hi, team!

We have a timescaledb database running on our production database with postgres-operator, which currently has 100G of data storage.
we found that a clone operation trying to pull backup data from Minio did not successfully start the database. After doing a log review and a patroni configuration check, we found that it appeared that the master_start_timeout (in patroni 2.1.4) parameter of patroni was causing the problem (this value defaults to 300s and our database was doing a lot of writes on a daily basis, resulting in a relatively large wal files. And after restored the database, the database would start from Minio to continue pulling WAL on startup causing it to take a very long time to catch up to the original database).

We have tried to add master_start_timeout and found that the operator currently seems to support only a small number of patroni parameters.

Is there any way we can configure the master_start_timeout parameter without modifying the codes, or is it possible for the community to add a variable that would allow users to adjust the parameter according to the official patroni configuration?

[FxKu]

You can create a PR so that master_start_timeout becomes configurable from the Postgres manifest / or even global config. I think the failsafe_mode PR is a good example what needs to be changed in the code. You have to touch quite a few files but the changes would be pretty minimal.

[Jan-M]

Interesting, we are not observing this problem for large clonse ourselves.