Skip to content

Commit cee0785

Browse files
committed
Fix formatting of list in pgo failover command description
1 parent b9847a7 commit cee0785

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

docs/commands.asciidoc

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -154,7 +154,7 @@ a backup job to be created.
154154

155155
When you request a backup, *pgo* will prompt you if you want
156156
to proceed because this action will delete any existing backup job
157-
for this cluster that might exist. The backup files will still
157+
for this cluster that might exist. The backup files will still
158158
be left intact but the actual Kubernetes Job will be removed prior
159159
to creating a new Job with the same name.
160160

@@ -215,7 +215,7 @@ connect to the primary forming a streaming replication postgres cluster.
215215
The Postgres replicas are read-only, whereas the primary is read-write.
216216
To create a Postgres replica enter a command such as:
217217
....
218-
pgo scale mycluster
218+
pgo scale mycluster
219219
....
220220

221221
The *pgo scale* command is additive, in that each time you execute
@@ -251,7 +251,7 @@ upon.
251251
pgo scale mycluster --node-label=speed=fast
252252
....
253253

254-
If you don't specify a *--node-label* flag, a node affinity
254+
If you don't specify a *--node-label* flag, a node affinity
255255
rule of *NotIn* will be specified to *prefer* that the replica
256256
be schedule on a node that the primary is not running on.
257257

@@ -565,6 +565,7 @@ can be used to promote a replica to a primary role in a PostgreSQL
565565
cluster.
566566

567567
This process includes the following actions:
568+
568569
* pick a target replica to become the new primary
569570
* delete the current primary deployment to avoid user requests from
570571
going to multiple primary databases (split brain)
@@ -593,9 +594,8 @@ by viewing it:
593594
kubectl get pgtasks mycluster-failover -o yaml
594595
....
595596

596-
Once completed, you will see a new replica has been started to replace
597+
Once completed, you will see a new replica has been started to replace
597598
the promoted replica, this happens automatically due to the re-lable, the
598599
Deployment will recreate its pod because of this. The failover typically
599600
takes only a few seconds, however, the creation of the replacement
600601
replica can take longer depending on how much data is being replicated.
601-

0 commit comments

Comments
 (0)