Support standby replication from GS (GCS) (#1446)

* Add support for manual gs_wal_path in standby
* Remove separate standby version configuration
* Remove setting standby path via cluster/uid/version
Picking up the version doesn't work reliably without making changes to
Spilo. It's clearer to just specify the full S3/GS bucket path.

Co-authored-by: Felix Kunde <felix-kunde@gmx.de>
This commit is contained in:
James McDonald
2021-12-03 11:24:29 +01:00
committed by GitHub
co-authored by Felix Kunde
parent 1ed16fadca
commit def9e1d688
6 changed files with 52 additions and 19 deletions
+8 -2
View File
@@ -798,8 +798,8 @@ different location than its source database. Unlike cloning, the PostgreSQL
version between source and target cluster has to be the same.
To start a cluster as standby, add the following `standby` section in the YAML
file and specify the S3 bucket path. An empty path will result in an error and
no statefulset will be created.
file. Specify the S3/GS bucket path. Omitting both settings will result in an error
and no statefulset will be created.
```yaml
spec:
@@ -807,6 +807,12 @@ spec:
s3_wal_path: "s3://<bucketname>/spilo/<source_db_cluster>/<UID>/wal/<PGVERSION>"
```
```yaml
spec:
standby:
gs_wal_path: "gs://<bucketname>/spilo/<source_db_cluster>/<UID>/wal/<PGVERSION>"
```
At the moment, the operator only allows to stream from the WAL archive of the
master. Thus, it is recommended to deploy standby clusters with only [one pod](https://github.com/zalando/postgres-operator/blob/master/manifests/standby-manifest.yaml#L10).
You can raise the instance count when detaching. Note, that the same pod role