Further improvements

Author: NataliaIvakina

modules/ROOT/pages/clustering/multi-region-deployment/disaster-recovery.adoc

@@ -20,7 +20,7 @@ You have to create a new cluster and restore the databases, see xref:clustering/
 
 Databases in clusters may be allocated differently within the cluster and may also have different numbers of primaries and secondaries.
 
-image::healthy-cluster.svg[width="400", title="Healthy cluster", role=popup]
+image::healthy-cluster.svg[width="400", title="A healthy cluster", role=popup]
 
 The consequence of this is that all servers may be different in which databases they are hosting.
 Losing a server in a cluster may cause some databases to lose a member while others are unaffected.
@@ -39,23 +39,28 @@ image::disaster.svg[width="400", title="Example of a cluster disaster", role=pop
 
 |Database A
 |All allocations are lost.
-|The database needs to be recreated from a backup.
+|The database needs to be recreated from a backup since there are no available allocations left in the cluster.
 
 |Database B
 |The primary allocation is lost, and the secondary allocation is available.
-|The database needs to be recreated, but can be based on available allocations in the cluster.
+|The database needs to be recreated since it has lost a majority of primary allocations and is therefore write-unvailable.
+However, the recreation can be based on the secondary allocation still present on a healthy server, so a backup is not required.
+The recreated database will be as up-to-date as the secondary allocation was at the time of the disaster.
 
 |Database C
 |Two primary allocations and a secondary one are lost.
-|The database needs to be recreated, but can be based on available allocations in the cluster.
+|The database needs to be recreated since it has lost a majority of primary allocations and is therefore write-unavailable.
+However, the recreation can be based on the primary and secondary allocations still present on healthy servers, so a backup is not required.
+The recreated database will reflect the state of the most up-to-date surviving primary or secondary allocation.
 
 |Database D
 |One primary allocation and two secondary allocations are lost.
-|The database will move when a server is deallocated.
+|The database remains write-available, allowing it to automatically move allocations from lost servers to available ones when the lost servers are deallocated.
+Therefore, the database does not need to be recreated even though some allocations have been lost.
 
 |Database E
 |Stays unaffected.
-|No action is required.
+|None of the database's allocations were affected by the disaster, so no action is required.
 |===
 
 Although databases C and D share the same topology, their primaries and secondaries are allocated differently, requiring distinct recovery strategies in this disaster example.
@@ -227,7 +232,7 @@ image::servers-cordoned.svg[width="400", title="Cordon unavailable servers", rol
 . For each `Cordoned` server, make sure a new *unconstrained* server has been added to the cluster to take its place.
 See xref:clustering/servers.adoc#cluster-add-server[Add a server to the cluster] for more information.
 +
-If servers were added in the <<make-the-system-database-write-available, Make the `system` database write-available>> step of this guide (like it is done in the current disaster recovery example), additional servers might not be needed here.
+If servers were added in the <<make-the-system-database-write-available, Make the `system` database write-available>> step of this guide (like it has been done in the current disaster recovery example), additional servers might not be needed here.
 It is important that the new servers are unconstrained, or deallocating servers might be blocked even though enough servers were added. 
 +
 [NOTE]
@@ -269,13 +274,15 @@ If any database has `currentStatus` = `quarantined` on an available server, recr
 If you recreate databases using xref:database-administration/standard-databases/recreate-database.adoc#undefined-servers[undefined servers] or xref:database-administration/standard-databases/recreate-database.adoc#undefined-servers-backup[undefined servers with fallback backup], the store might not be recreated as up-to-date as possible in certain edge cases where the `system` database has been restored.
 =====
 +
-image::servers-cordoned-databases-moved.svg[width="400", title="Recreate databases", role=popup]
+image::servers-cordoned-databases-moved.svg[width="400", title="All write-unavailable databases were recreated", role=popup]
 
 . For each `Cordoned` server, run `DEALLOCATE DATABASES FROM SERVER cordoned-server-id` on one of the available servers.
 This will move all database allocations from this server to an available server in the cluster.
 +
 image::servers-deallocated.svg[width="400", title="Deallocate databases from unavailable servers", role=popup]
 +
+Note that the database D was still write-available, which means the allocations can be moved from lost servers to available ones when the lost servers are deallocated.
++
 [NOTE]
 =====
 This operation might fail if enough unconstrained servers were not added to the cluster to replace lost servers.
@@ -284,8 +291,11 @@ Another reason is that some available servers are also `Cordoned`.
 
 . For each deallocating or deallocated server, run `DROP SERVER deallocated-server-id`.
 This removes the server from the cluster's view.
-
-
++
+image::fully-recovered-cluster.svg[width="400", title="The fully recovered cluster", role="popup"]
++
+After dropping the deallocated servers, you still have to ensure that all moved and recreated databases are write-available.
+For this purpose, follow the steps <<write-available-databases-steps, below>>.
 
 [[make-databases-write-available]]
 === Make databases write-available
@@ -323,6 +333,7 @@ Instead, check that the primary is allocated on an available server and that it
 A stricter verification can be done to verify that all databases are in their desired states on all servers.
 For the stricter check, run `SHOW DATABASES` and verify that `requestedStatus` = `currentStatus` for all database allocations on all servers.
 
+[[write-available-databases-steps]]
 ==== Path to correct state
 
 Use the following steps to make all databases in the cluster write-available again.
@@ -350,7 +361,7 @@ Recreating a database will not complete if one of the following messages is disp
 ** `No store found on any of the seeders ServerId1, ServerId2...`
 . For each database which will not complete recreation, recreate them from backup using xref:database-administration/standard-databases/recreate-database.adoc#uri-seed[Backup as seed].
 
-image::fully-recovered-cluster.svg[width="400", title="Fully recovered cluster", role="popup"]
+