You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/reference/operator_parameters.md
+20
Original file line number
Diff line number
Diff line change
@@ -346,6 +346,26 @@ configuration they are grouped under the `kubernetes` key.
346
346
gone at this point.
347
347
The default is `false`.
348
348
349
+
***persistent_volume_claim_retention_policy**
350
+
The operator tries to protect volumes as much as possible. If somebody
351
+
accidentally deletes the statefulset or scales in the `numberOfInstances` the
352
+
Persistent Volume Claims and thus Persistent Volumes will be retained.
353
+
However, this can have some consequences when you scale out again at a much
354
+
later point, for example after the cluster's Postgres major version has been
355
+
upgraded, because the old volume runs the old Postgres version with stale data.
356
+
Even if the version has not changed the replication lag could be massive. In
357
+
this case a reinitialization of the re-added member would make sense. You can
358
+
also modify the [retention policy of PVCs](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-retention) in the operator configuration.
359
+
The behavior can be changed for two scenarios: `when_deleted` - default is
360
+
`"retain"` - or `when_scaled` - default is also `"retain"`. The other possible
361
+
option is `delete`.
362
+
363
+
***enable_persistent_volume_claim_deletion**
364
+
By default, the operator deletes PersistentVolumeClaims when removing the
365
+
Postgres cluster manifest, no matter if `persistent_volume_claim_retention_policy`
366
+
on the statefulset is set to `retain`. To keep PVCs set this option to `false`.
367
+
The default is `true`.
368
+
349
369
***enable_pod_disruption_budget**
350
370
PDB is enabled by default to protect the cluster from voluntarily disruptions
351
371
and hence unwanted DB downtime. However, on some cloud providers it could be
0 commit comments