Skip to content

Commit fa84406

Browse files
fcanovaimnencia
authored andcommitted
docs: describe instanceSidecarConfiguration
Document how the instance sidecar is configured and what happens when resources definitions conflict between objectstores. Signed-off-by: Francesco Canovai <[email protected]>
1 parent ce18ea8 commit fa84406

File tree

1 file changed

+34
-0
lines changed

1 file changed

+34
-0
lines changed

web/docs/usage.md

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -210,3 +210,37 @@ spec:
210210
parameters:
211211
barmanObjectName: minio-store-b
212212
```
213+
214+
## Configuring the plugin instance sidecar
215+
216+
The Barman Cloud Plugin uses a sidecar container that runs alongside each
217+
PostgreSQL instance pod. This sidecar handles backup, WAL archiving, and restore
218+
operations. You can control how the sidecar works by setting the
219+
`.spec.instanceSidecarConfiguration` section in your `ObjectStore` resource.
220+
These settings apply to all PostgreSQL instances that use this object store.
221+
222+
```yaml
223+
apiVersion: barmancloud.cnpg.io/v1
224+
kind: ObjectStore
225+
metadata:
226+
name: minio-store
227+
spec:
228+
configuration:
229+
# [...]
230+
instanceSidecarConfiguration:
231+
retentionPolicyIntervalSeconds: 30
232+
resources:
233+
requests:
234+
memory: "64Mi"
235+
cpu: "250m"
236+
limits:
237+
memory: "512Mi"
238+
cpu: "500m"
239+
```
240+
241+
When the plugin is enabled, the sidecar is automatically injected into each
242+
PostgreSQL instance pod. Even if you define multiple `ObjectStore` resources,
243+
only one sidecar will run per instance. If a replica cluster also archives WALs
244+
to a different `ObjectStore`, the sidecar will use the resource settings from the
245+
`ObjectStore` referenced by the archiving plugin, not the one in the
246+
`.spec.externalClusters` section.

0 commit comments

Comments
 (0)