You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/ROOT/pages/database-administration/standard-databases/errors.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -198,7 +198,7 @@ If there are two allocations in `quarantined` mode (meaning that the database is
198
198
In this case, it is recommended to recreate the database with quarantined allocations from a backup.
199
199
See xref:database-administration/standard-databases/recreate-database.adoc#uri-seed[Recreate a database -> Use a backup as a seed].
200
200
201
-
To monitor if a clustered database is write-available, it is recommended to run the xref:procedures.adoc#procedure_dbms_cluster_statusCheck[`dbms.cluster.statusCheck()`] procedure on each server hosting the database in primary mode.
201
+
To monitor if a clustered database is write-available, it is recommended to run the xref:procedures/built-in-procedures.adoc#procedure_dbms_cluster_statusCheck[`dbms.cluster.statusCheck()`] procedure on each server hosting the database in primary mode.
202
202
If any response returns xref:clustering/monitoring/status-check.adoc#_possible_values_of_replicationsuccessful[`replicationSuccessful = true`], you can use `replaceStateKeepStore` or `replaceStateReplaceStore` on one of the quarantined allocations of the database.
203
203
This works because a successful replication indicates that a majority of cluster members are available, allowing the new server to rejoin safely. +
204
204
See xref:clustering/monitoring/status-check.adoc[] for more information on the `dbms.cluster.statusCheck()` procedure.
0 commit comments