marco/plugin-barman-cloud
1
0
Fork 0
mirror of https://github.com/cloudnative-pg/plugin-barman-cloud.git synced 2026-01-12 05:33:11 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs: improve

Browse Source 
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
This commit is contained in:
Francesco Canovai 2025-05-09 17:10:59 +02:00
parent ef7afbbc29
commit 74916768dd
1 changed files with 27 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
web/docs/usage.md
View File

@ -213,13 +213,25 @@ spec:
## Configuring the plugin instance sidecar ## Configuring the plugin instance sidecar
The Barman Cloud Plugin uses a sidecar container that runs alongside each The Barman Cloud Plugin runs as a sidecar container next to each PostgreSQL
PostgreSQL instance pod. instance pod. It manages backup, WAL archiving, and restore processes.
This sidecar handles backup, WAL archiving, and restore Configuration comes from multiple `ObjectStore` resources:
operations. You can control how the sidecar works by setting the
`.spec.instanceSidecarConfiguration` section in your `ObjectStore` resource. 1. The one referenced in the
These settings apply to all PostgreSQL instances that use this object store. `.spec.plugins` section of the `Cluster`. This is the
object store used for WAL archiving and base backups.
2. The one referenced in the external cluster
used in the `.spec.replica.source` section of the `Cluster`. This is
used by the log-shipping designated primary to get the WAL files.
3. The one referenced in the
`.spec.bootstrap.recovery.source` section of the `Cluster`. Used by
the initial recovery job to create the cluster from an existing backup.
You can fine-tune sidecar behavior in the `.spec.instanceSidecarConfiguration`
of your ObjectStore. These settings apply to all PostgreSQL instances that use
this object store. Any updates take effect at the next `Cluster` reconciliation,
and could generate a rollout of the `Cluster`.
```yaml ```yaml
apiVersion: barmancloud.cnpg.io/v1 apiVersion: barmancloud.cnpg.io/v1
@ -228,39 +240,19 @@ metadata:
name: minio-store name: minio-store
spec: spec:
configuration: configuration:
# [...] # [...]
instanceSidecarConfiguration: instanceSidecarConfiguration:
retentionPolicyIntervalSeconds: 1800 retentionPolicyIntervalSeconds: 1800
resources: resources:
requests: requests:
memory: "64Mi" memory: "XXX"
cpu: "250m" cpu: "YYY"
limits: limits:
memory: "512Mi" memory: "XXX"
cpu: "500m" cpu: "YYY"
``` ```
The plugin injects a sidecar in the recovery job and in the PostgreSQL :::note
instance Pods when needed. If more than one `ObjectStore` applies, the `instanceSidecarConfiguration` of
the one set in `.spec.plugins` has priority.
When this happens, the sidecar will manage multiple `ObjectStore` :::
resources:
1. the target object store, where WAL files and backups will
be written
2. the replica source object store, used by the log-shipping designated
primary to get the WAL files
3. the recovery object store, used when creating the cluster from an
existing backup (used only by the recovery job)
The resources defined by the recovery object store will be used when
injecting the sidecar in the recovery job.
If a sidecar is needed by PG instances pod, the resources defined in
the target object store will be used. Should this object store be not
defined, the replica object store will be used.
Changes to the sidecar configuration will be applied on the next
reconciliation of the `Cluster` resources it.