3.0 config: replication administration - update per review 2

Author: andreyaksenov

doc/book/admin/disaster_recovery.rst

@@ -37,7 +37,7 @@ Master crash: manual failover
 
 5.  On a new master, :ref:`remove a crashed instance from the '_cluster' space <replication-remove_instances-remove_cluster>`.
 
-6.  Start the instance again on a spare host.
+6.  Set up a replacement for the crashed master on a spare host.
 
 See also: :ref:`Performing manual failover <replication-controlled_failover>`.
 
@@ -55,10 +55,9 @@ Master crash: automated failover
 
 1.  Use ``box.info.election`` to make sure a new master is elected automatically.
 
-2.  Remove a crashed master from a replica set.
+2.  On a new master, :ref:`remove a crashed instance from the '_cluster' space <replication-remove_instances-remove_cluster>`.
 
 3.  Set up a replacement for the crashed master on a spare host.
-    Learn more from :ref:`Adding and removing instances <replication-automated-failover-add-remove-instances>`.
 
 See also: :ref:`Testing automated failover <replication-automated-failover-testing>`.
 

doc/book/admin/replication/repl_monitoring.rst

@@ -52,5 +52,3 @@ The primary indicators of replication health are:
     Since the ``lag`` calculation uses the operating system clocks from two different
     machines, do not be surprised if it’s negative: a time drift may lead to the
     remote master clock being consistently behind the local instance's clock.
-
-    For a :ref:`master-master <replication-bootstrap-master-master>` configuration, ``lag`` is the maximal lag.

doc/book/admin/replication/repl_problem_solving.rst

@@ -14,7 +14,7 @@ This topic describes how to solve problems in :ref:`master-master <replication-b
 Replacing the same primary key
 ------------------------------
 
-You have two instances of Tarantool. For example, you try to make a
+**Case 1:** You have two instances of Tarantool. For example, you try to make a
 ``replace`` operation with the same primary key on both instances at the same time.
 This causes a conflict over which tuple to save and which one to discard.
 
@@ -68,8 +68,7 @@ Preventing duplicate insert
 
 .. _replication-replication_stops:
 
-In a replica set of two masters, suppose master #1 tries to
-``insert`` a tuple with the same unique key:
+**Case 2:** In a replica set of two masters, both of them try to insert data by the same unique key:
 
 .. code-block:: tarantoolsession
 
@@ -154,8 +153,8 @@ To learn how to resolve a replication conflict by reseeding a replica, see :ref:
 
 .. _replication-runs_out_of_sync:
 
-Solution 1: replication runs out of sync
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Replication runs out of sync
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In a master-master cluster of two instances, suppose we make the following
 operation:
@@ -181,8 +180,8 @@ When this operation is applied on both instances in the replica set:
 
 .. _replication-commutative_changes:
 
-Solution 2: commutative changes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Commutative changes
+~~~~~~~~~~~~~~~~~~~
 
 The cases described in the previous paragraphs represent examples of
 **non-commutative** operations, that is operations whose result depends on the
@@ -200,11 +199,12 @@ the update is applied on the other masters.
 
 .. _replication_trigger_usage:
 
-Solution 3: trigger usage
-~~~~~~~~~~~~~~~~~~~~~~~~~
+Trigger usage
+~~~~~~~~~~~~~
 
-The logic and the snippet setting a trigger will be the same here as in case 1.
-But the trigger function will differ:
+The logic and the snippet setting a trigger will be the same here as in :ref:`case 1 <replication-problem_solving_replacing_primary_key>`.
+But the trigger function will differ.
+Note that the trigger below assumes that tuple has a timestamp in the second field.
 
 .. code-block:: lua
 

doc/book/admin/replication/repl_recover.rst

@@ -41,7 +41,7 @@ hardware or network failure, or due to a programming bug.
 
 
 
-The master's status is reported as ``disconnected`` when executing :ref:`box.info.replication <replication-monitoring>` on a replica:
+The master's upstream status is reported as ``disconnected`` when executing :ref:`box.info.replication <replication-monitoring>` on a replica:
 
 ..  include:: /how-to/replication/repl_bootstrap_auto.rst
     :start-after: box_info_replication_auto_leader_disconnected_start

doc/book/admin/troubleshoot.rst

@@ -249,12 +249,10 @@ error message like
 
 **Solution**
 
-Restart replication at each master instance.
-Connect to each master instance using the :ref:`tt connect <tt-connect>` command:
+This issue can be fixed in two ways:
 
-.. code-block:: console
-
-    $ tt connect <instance_name|URI>
+-   Manually: :ref:`reseed <replication-master-master-reseed-replica>` one master from another by removing write-ahead logs and snapshots.
+-   Programmatically: set up a :ref:`conflict resolution trigger <replication-problem_solving>`.
 
 Then, restart replication as described in :ref:`Restarting replication <replication-master-master-resolve-conflict>`.