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/cluster_manifest.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,6 +48,10 @@ Those parameters are grouped under the `metadata` top-level key.
48
48
Labels that are set here but not listed as `inherited_labels` in the operator
49
49
parameters are ignored.
50
50
51
+
***annotations**
52
+
A map of annotations to add to the `postgresql` resource. The operator reacts to certain annotations, for instance, to trigger specific actions.
53
+
*`postgres-operator.zalando.org/action: restore-in-place`: When this annotation is present with this value, the operator will trigger an automated in-place restore of the cluster. This process requires a valid `clone` section to be defined in the manifest with a target `timestamp`. See the [user guide](../user.md#automated-restore-in-place-point-in-time-recovery) for more details.
54
+
51
55
## Top-level parameters
52
56
53
57
These parameters are grouped directly under the `spec` key in the manifest.
manifest. The manifest is an instance of the custom resource definition (CRD)
30
32
called `OperatorConfiguration`. The operator registers this CRD during the
@@ -187,6 +189,9 @@ Those are top-level keys, containing both leaf keys and groups.
187
189
***repair_period**
188
190
period between consecutive repair requests. The default is `5m`.
189
191
192
+
***pitr_backup_retention**
193
+
retention time for PITR (Point-In-Time-Recovery) state ConfigMaps. The operator will clean up ConfigMaps older than the configured retention. The value is a [duration string](https://pkg.go.dev/time#ParseDuration), e.g. "168h" (which is 7 days), "24h". The default is `168h`.
194
+
190
195
***set_memory_request_to_limit**
191
196
Set `memory_request` to `memory_limit` for all Postgres clusters (the default
192
197
value is also increased but configured `max_memory_request` can not be
Copy file name to clipboardExpand all lines: docs/user.md
+40Lines changed: 40 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -891,6 +891,45 @@ original UID, making it possible retry restoring. However, it is probably
891
891
better to create a temporary clone for experimenting or finding out to which
892
892
point you should restore.
893
893
894
+
## Automated Restore in place (Point-in-Time Recovery)
895
+
896
+
The operator supports automated in-place restores, allowing you to restore a database to a specific point in time without changing connection strings on the application side. This feature orchestrates the deletion of the current cluster and the creation of a new one from a backup.
897
+
898
+
:warning: This is a destructive operation. The existing cluster's StatefulSet and pods will be deleted as part of the process. Ensure you have a reliable backup strategy and have tested the restore process in a non-production environment.
899
+
900
+
To trigger an in-place restore, you need to add a special annotation and a `clone` section to your `postgresql` manifest:
901
+
902
+
* **Annotate the manifest**: Add the `postgres-operator.zalando.org/action: restore-in-place` annotation to the `metadata` section.
903
+
* **Specify the recovery target**: Add a `clone` section to the `spec`, providing the `cluster` name and the `timestamp` for the point-in-time recovery. The `cluster` name **must** be the same as the `metadata.name` of the cluster you are restoring. The `timestamp` must be in RFC 3339 format and point to a time in the past for which you have WAL archives.
cluster: "acid-minimal-cluster" # Must match metadata.name
918
+
uid: "<original_UID>"
919
+
timestamp: "2022-04-01T10:11:12+00:00"
920
+
# ... other cluster parameters
921
+
```
922
+
923
+
When you apply this manifest, the operator will:
924
+
* See the `restore-in-place` annotation and begin the restore workflow.
925
+
* Store the restore request and the new cluster definition in a temporary `ConfigMap`.
926
+
* Delete the existing `postgresql` custom resource, which triggers the deletion of the associated StatefulSet and pods.
927
+
* Wait for the old cluster to be fully terminated.
928
+
* Create a new `postgresql` resource with a new UID but the same name.
929
+
* The new cluster will bootstrap from the latest base backup prior to the given `timestamp` and replay WAL files to recover to the specified point in time.
930
+
931
+
The process is asynchronous. You can monitor the operator logs and the state of the `postgresql` resource to follow the progress. Once the new cluster is up and running, your applications can reconnect.
932
+
894
933
## Setting up a standby cluster
895
934
896
935
Standby cluster is a [Patroni feature](https://github.com/zalando/patroni/blob/master/docs/replica_bootstrap.rst#standby-cluster)
@@ -1302,3 +1341,4 @@ As of now, the operator does not sync the pooler deployment automatically
1302
1341
which means that changes in the pod template are not caught. You need to
1303
1342
toggle `enableConnectionPooler` to set environment variables, volumes, secret
1304
1343
mounts and securityContext required for TLS support in the pooler pod.
0 commit comments