@@ -56,7 +56,7 @@ To use this plugin, ensure the following prerequisites are met:
5656
5757## Installation
5858
59- ** Important Notes :**
59+ ** IMPORTANT NOTES :**
6060
61611 . The plugin ** must** be installed in the same namespace where the operator is
6262 installed (typically ` cnpg-system ` ).
@@ -101,7 +101,7 @@ Both checks are necessary to proceed with the installation.
101101
102102### Step 2 - Install the barman-cloud Plugin
103103
104- > ** Note :** This section is temporary and will be updated once manifests are
104+ > ** NOTE :** This section is temporary and will be updated once manifests are
105105> included as part of the release process.
106106
107107Use the following command to download the plugin's codebase, including its
@@ -171,10 +171,11 @@ This confirms that the plugin is deployed and operational.
171171
172172## Usage
173173
174- ### The BarmanObjectStore object
174+ ### Defining the ` BarmanObjectStore `
175175
176- A BarmanObjectStore object should be created for each object stored used by the
177- PostgreSQL architecture. This is an example:
176+ A ` BarmanObjectStore ` object should be created for each object store used in
177+ your PostgreSQL architecture. Below is an example configuration for using
178+ MinIO:
178179
179180``` yaml
180181apiVersion : barmancloud.cnpg.io/v1
@@ -196,17 +197,16 @@ spec:
196197 compression : gzip
197198` ` `
198199
199- The ` objectstore.spec.configuration` API is the same api used by the [in-tree
200- barman-cloud
201- support](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)
202- and can be used like discussed in [the relative documentation
203- page](https://cloudnative-pg.io/documentation/preview/backup_barmanobjectstore/).
200+ The ` .spec.configuration` API follows the same schema as the
201+ [in-tree barman-cloud support](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration).
202+ Refer to [the CloudNativePG documentation](https://cloudnative-pg.io/documentation/preview/backup_barmanobjectstore/)
203+ for detailed usage.
204204
205- # ## WAL Archiving
205+ # ## Configuring WAL Archiving
206206
207- Once the `BarmanObjectStore` has been defined, a cluster using it to archive
208- WALs will reference it in the `.spec.plugins` section, like in the following
209- example :
207+ Once the `BarmanObjectStore` is defined, you can configure a PostgreSQL cluster
208+ to archive WALs by referencing the store in the `.spec.plugins` section, as
209+ shown below :
210210
211211` ` ` yaml
212212apiVersion: postgresql.cnpg.io/v1
@@ -220,21 +220,17 @@ spec:
220220 - name: barman-cloud.cloudnative-pg.io
221221 parameters:
222222 barmanObjectName: minio-store
223-
224223 storage:
225224 size: 1Gi
226225` ` `
227226
228- This will enable WAL archiving and data directory backups, as discussed in the
229- next section.
230-
231- # ## Backup
227+ This configuration enables both WAL archiving and data directory backups.
232228
233- Once the transaction log files are being archived, the cluster is ready to be
234- backed up.
229+ # ## Performing a Base Backup
235230
236- To request a backup, the `backup.spec.pluginConfiguration` stanza must be set
237- with the name of this plugin like in the following example :
231+ Once WAL archiving is enabled, the cluster is ready for backups. To create a
232+ backup, configure the `backup.spec.pluginConfiguration` section to specify this
233+ plugin :
238234
239235` ` ` yaml
240236apiVersion: postgresql.cnpg.io/v1
@@ -243,19 +239,16 @@ metadata:
243239 name: backup-example
244240spec:
245241 method: plugin
246-
247242 cluster:
248243 name: cluster-example
249-
250244 pluginConfiguration:
251245 name: barman-cloud.cloudnative-pg.io
252246` ` `
253247
254- # ## Restore
248+ # ## Restoring a Cluster
255249
256- To recover a cluster from an object store, the user should create a new
257- ` Cluster` resource referring to the object store containing the backup, like in
258- the following example :
250+ To restore a cluster from an object store, create a new `Cluster` resource that
251+ references the store containing the backup. Below is an example configuration :
259252
260253` ` ` yaml
261254apiVersion: postgresql.cnpg.io/v1
@@ -265,28 +258,25 @@ metadata:
265258spec:
266259 instances: 3
267260 imagePullPolicy: IfNotPresent
268-
269261 bootstrap:
270262 recovery:
271263 source: source
272-
273264 externalClusters:
274265 - name: source
275266 plugin:
276267 name: barman-cloud.cloudnative-pg.io
277268 parameters:
278269 barmanObjectName: minio-store
279270 serverName: cluster-example
280-
281271 storage:
282272 size: 1Gi
283273` ` `
284274
285- **IMPORTANT ** recovering a cluster like in the previous example do not enable
286- WAL archiving for the cluster being recovered .
275+ **NOTE: ** The above configuration does **not** enable WAL archiving for the
276+ restored cluster.
287277
288- The latter can be configured by combining the `.spec.plugins` section with the
289- `externalClusters.plugin` section, like in the following example :
278+ To enable WAL archiving for the restored cluster, include the `.spec.plugins`
279+ section alongside the `externalClusters.plugin` section, as shown below :
290280
291281` ` ` yaml
292282apiVersion: postgresql.cnpg.io/v1
@@ -296,35 +286,34 @@ metadata:
296286spec:
297287 instances: 3
298288 imagePullPolicy: IfNotPresent
299-
300289 bootstrap:
301290 recovery:
302291 source: source
303-
304292 plugins:
305293 - name: barman-cloud.cloudnative-pg.io
306294 parameters:
295+ # Backup Object Store (push, read-write)
307296 barmanObjectName: minio-store-bis
308-
309297 externalClusters:
310298 - name: source
311299 plugin:
312300 name: barman-cloud.cloudnative-pg.io
313301 parameters:
302+ # Recovery Object Store (pull, read-only)
314303 barmanObjectName: minio-store
315304 serverName: cluster-example
316-
317305 storage:
318306 size: 1Gi
319307` ` `
320308
321- The object store that is used to archive the transaction log may be the same
322- object store that is being used to restore a cluster or a different one .
309+ The same object store may be used for both transaction log archiving and
310+ restoring a cluster, or you can configure separate stores for these purposes .
323311
324- # ## Replica clusters
312+ # ## Configuring Replica Clusters
325313
326- The previous definition can be combined to setup a distributed topology using
327- the `.spec.replica` section like in the following example :
314+ You can set up a distributed topology by combining the previously defined
315+ configurations with the `.spec.replica` section. Below is an example of how to
316+ define a replica cluster :
328317
329318` ` ` yaml
330319apiVersion: postgresql.cnpg.io/v1
0 commit comments