Move some replication guides to Administration

* Monitoring a replica set
* Reseeding a replica
* Recovering from a degraded state
* Resolving replication conflicts

Author: patiencedaur

doc/book/admin/index.rst

@@ -34,6 +34,7 @@ This chapter includes the following sections:
    security
    access_control
    vshard_admin
+   replication/index
    server_introspection
    daemon_supervision
    disaster_recovery

doc/book/admin/replication/index.rst

@@ -0,0 +1,10 @@
+Replication
+===========
+
+..  toctree::
+    :maxdepth: 2
+
+    repl_monitoring
+    repl_recover
+    repl_reseed
+    repl_problem_solving

doc/concepts/replication/mr-degraded.svg renamed to doc/book/admin/replication/mr-degraded.svg

@@ -42,7 +42,7 @@ these instances, issue a :doc:`/reference/reference_lua/box_info/replication` re
 This report is for a master-master replica set of three instances, each having
 its own instance id, UUID and log sequence number.
 
-..  image:: mm-3m-mesh.svg
+..  image:: /concepts/replication/images/mm-3m-mesh.svg
     :align: center
 
 The request was issued at master #1, and the reply includes statistics for the
@@ -78,6 +78,5 @@ The primary indicators of replication health are:
 
 For better understanding, see the following diagram illustrating the ``upstream`` and ``downstream`` connections within the replica set of three instances:
 
-..  image:: replication.svg
+..  image:: /concepts/replication/images/replication.svg
     :align: left
-

doc/concepts/replication/repl_monitoring.rst renamed to doc/book/admin/replication/repl_monitoring.rst

@@ -82,11 +82,6 @@ Several Tarantool instances can be organized in a replica set.
 They communicate and transfer data via the :ref:`iproto <box_protocol-iproto_protocol>` binary protocol.
 Learn more about Tarantool's :ref:`replication architecture <replication-architecture>`.
 
-As there are usually more database reads than writes, a popular scenario is to have
-one writable "master" node in the database and several read-only "replicas".
-If the master goes down, one of the replicas becomes the new master.
-This is called a failover.
-
 By default, replication in Tarantool is asynchronous.
 A transaction committed locally on the master node
 may not get replicated onto other instances before the client receives a success response.

doc/concepts/replication/repl_problem_solving.rst renamed to doc/book/admin/replication/repl_problem_solving.rst

@@ -18,12 +18,5 @@ This chapter includes the following sections:
    :numbered: 0
 
    repl_architecture
-   repl_bootstrap
-   repl_add_instances
-   repl_remove_instances
-   repl_monitoring
-   repl_recover
-   repl_reseed
-   repl_problem_solving
    repl_sync
    repl_leader_elect

doc/concepts/replication/repl_recover.rst renamed to doc/book/admin/replication/repl_recover.rst

@@ -152,7 +152,7 @@ role is "read_only" (replica) for all but one instance in the replica set.
 In a master-replica configuration, every change that happens on the master will
 be visible on the replicas, but not vice versa.
 
-.. image:: mr-1m-2r-oneway.svg
+.. image:: images/mr-1m-2r-oneway.svg
     :align: center
 
 A simple two-instance replica set with the master on one machine and the replica
@@ -166,7 +166,7 @@ on a different machine provides two benefits:
 In a **master-master** configuration (also called "multi-master"), every change
 that happens on either instance will be visible on the other one.
 
-.. image:: mm-3m-mesh.svg
+.. image:: images/mm-3m-mesh.svg
     :align: center
 
 The failover benefit in this case is still present, and the load-balancing
@@ -211,7 +211,7 @@ makes potential failover easy.
 Some database products offer **cascading replication** topologies: creating a
 replica on a replica. Tarantool does not recommend such setup.
 
-.. image:: no-cascade.svg
+.. image:: images/no-cascade.svg
     :align: center
 
 The problem with a cascading replica set is that some instances have no
@@ -221,14 +221,14 @@ is an entry in ``box.space._cluster`` system space with the replica set UUID.
 Without knowing the replica set UUID, a master refuses to accept connections from
 such instances when replication topology changes. Here is how this can happen:
 
-.. image:: cascade-problem-1.svg
+.. image:: images/cascade-problem-1.svg
     :align: center
 
 We have a chain of three instances. Instance #1 contains entries for instances
 #1 and #2 in its ``_cluster`` space. Instances #2 and #3 contain entries for
 instances #1, #2 and #3 in their ``_cluster`` spaces.
 
-.. image:: cascade-problem-2.svg
+.. image:: images/cascade-problem-2.svg
     :align: center
 
 Now instance #2 is faulty. Instance #3 tries connecting to instance #1 as its
@@ -237,7 +237,7 @@ instance #3.
 
 **Ring replication** topology is, however, supported:
 
-.. image:: cascade-to-ring.svg
+.. image:: images/cascade-to-ring.svg
     :align: center
 
 So, if you need a cascading topology, you may first create a ring to ensure all
@@ -247,7 +247,7 @@ desire.
 A stock recommendation for a master-master replication topology, however, is a
 **full mesh**:
 
-.. image:: mm-3m-mesh.svg
+.. image:: images/mm-3m-mesh.svg
     :align: center
 
 You then can decide where to locate instances of the mesh -- within the same

doc/concepts/replication/repl_reseed.rst renamed to doc/book/admin/replication/repl_reseed.rst

@@ -22,5 +22,6 @@ If you are new to Tarantool, please see our
     db/index
     vshard_quick
     app/index
+    replication/index
     sql/index
     other/index

doc/concepts/index.rst

@@ -0,0 +1,11 @@
+..  _how-to-replication:
+
+Replication
+===========
+
+..  toctree::
+
+    repl_bootstrap
+    repl_add_instances
+    repl_remove_instances
+    

doc/concepts/replication/cascade-problem-1.svg renamed to doc/concepts/replication/images/cascade-problem-1.svg

@@ -7,7 +7,7 @@ Removing instances
 Let's assume that we have the following configured replica set with 3 instances
 (*instance1*, *instance2* and *intance3*) and we want to remove *instance2*.
 
-.. image:: replication.svg
+.. image:: /concepts/replication/images/replication.svg
       :align: left
 
 To remove it politely, follow these steps:

doc/concepts/replication/cascade-problem-2.svg renamed to doc/concepts/replication/images/cascade-problem-2.svg

@@ -0,0 +1,150 @@
+
+msgid "Monitoring a replica set"
+msgstr "Мониторинг набора реплик"
+
+msgid ""
+"To learn what instances belong in the replica set, and obtain statistics for"
+" all these instances, issue a "
+":doc:`/reference/reference_lua/box_info/replication` request:"
+msgstr ""
+"Чтобы узнать, какие экземпляры входят в набор реплик и получить статистику "
+"по всем этим экземплярам, передайте запрос "
+":doc:`/reference/reference_lua/box_info/replication`:"
+
+msgid ""
+"tarantool> box.info.replication\n"
+"---\n"
+"  replication:\n"
+"    1:\n"
+"      id: 1\n"
+"      uuid: b8a7db60-745f-41b3-bf68-5fcce7a1e019\n"
+"      lsn: 88\n"
+"    2:\n"
+"      id: 2\n"
+"      uuid: cd3c7da2-a638-4c5d-ae63-e7767c3a6896\n"
+"      lsn: 31\n"
+"      upstream:\n"
+"        status: follow\n"
+"        idle: 43.187747001648\n"
+"        peer: [email protected]:3301\n"
+"        lag: 0\n"
+"      downstream:\n"
+"        vclock: {1: 31}\n"
+"    3:\n"
+"      id: 3\n"
+"      uuid: e38ef895-5804-43b9-81ac-9f2cd872b9c4\n"
+"      lsn: 54\n"
+"      upstream:\n"
+"        status: follow\n"
+"        idle: 43.187621831894\n"
+"        peer: [email protected]:3301\n"
+"        lag: 2\n"
+"      downstream:\n"
+"        vclock: {1: 54}\n"
+"..."
+msgstr ""
+"tarantool> box.info.replication\n"
+"---\n"
+"  replication:\n"
+"    1:\n"
+"      id: 1\n"
+"      uuid: b8a7db60-745f-41b3-bf68-5fcce7a1e019\n"
+"      lsn: 88\n"
+"    2:\n"
+"      id: 2\n"
+"      uuid: cd3c7da2-a638-4c5d-ae63-e7767c3a6896\n"
+"      lsn: 31\n"
+"      upstream:\n"
+"        status: follow\n"
+"        idle: 43.187747001648\n"
+"        peer: [email protected]:3301\n"
+"        lag: 0\n"
+"      downstream:\n"
+"        vclock: {1: 31}\n"
+"    3:\n"
+"      id: 3\n"
+"      uuid: e38ef895-5804-43b9-81ac-9f2cd872b9c4\n"
+"      lsn: 54\n"
+"      upstream:\n"
+"        status: follow\n"
+"        idle: 43.187621831894\n"
+"        peer: [email protected]:3301\n"
+"        lag: 2\n"
+"      downstream:\n"
+"        vclock: {1: 54}\n"
+"..."
+
+msgid ""
+"This report is for a master-master replica set of three instances, each "
+"having its own instance id, UUID and log sequence number."
+msgstr ""
+"Данный отчет сгенерирован для набора реплик из трех экземпляров с "
+"конфигурацией мастер-мастер, у каждого из которых есть свой собственный ID "
+"экземпляра, UUID и номер записи в журнале."
+
+msgid ""
+"The request was issued at master #1, and the reply includes statistics for "
+"the other two masters, given in regard to master #1."
+msgstr ""
+"Запрос был выполнен с мастера №1, и ответ включает в себя статистику по двум"
+" другим мастерам относительно мастера №1."
+
+msgid "The primary indicators of replication health are:"
+msgstr "Основные индикаторы работоспособности репликации:"
+
+msgid ""
+":ref:`idle <box_info_replication_upstream_idle>`, the time (in seconds) "
+"since the instance received the last event from a master."
+msgstr ""
+":ref:`бездействие <box_info_replication_upstream_idle>`, время (в секундах) "
+"с момента получения последнего события от мастера."
+
+#, fuzzy
+msgid ""
+"If the master has no updates to send to the replicas, it sends heartbeat "
+"messages every :ref:`replication_timeout <cfg_replication-"
+"replication_timeout>` seconds. The master is programmed to disconnect if it "
+"does not see acknowledgments of the heartbeat messages within "
+"``replication_timeout`` * 4 seconds."
+msgstr ""
+"Если на мастере нет новых данных, требующих репликации, он отправляет на "
+"реплики сообщения контрольного сигнала каждые :ref:`replication_timeout "
+"<cfg_replication-replication_timeout>` секунд. Мастер запрограммирован на "
+"отключение, если он не получает сообщения контрольного сигнала дольше "
+"``replication_timeout`` * 4 секунд."
+
+msgid ""
+"Therefore, in a healthy replication setup, ``idle`` should never exceed "
+"``replication_timeout``: if it does, either the replication is lagging "
+"seriously behind, because the master is running ahead of the replica, or the"
+" network link between the instances is down."
+msgstr ""
+"Таким образом, в работоспособном состоянии значение ``idle`` никогда не "
+"должно превышать значение ``replication_timeout``: в противном случае, либо "
+"репликация сильно отстает, поскольку мастер опережает реплику, либо "
+"отсутствует сетевое подключение между экземплярами."
+
+msgid ""
+":ref:`lag <box_info_replication_upstream_lag>`, the time difference between "
+"the local time at the instance, recorded when the event was received, and "
+"the local time at another master recorded when the event was written to the "
+":ref:`write ahead log <internals-wal>` on that master."
+msgstr ""
+":ref:`отставание <box_info_replication_upstream_lag>`, разница во времени "
+"между локальным временем на экземпляре, зарегистрированным при получении "
+"события, и локальное время на другом мастере, зарегистрированное при записи "
+"события в :ref:`журнал упреждающей записи <internals-wal>` на этом мастере."
+
+msgid ""
+"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."
+msgstr ""
+"Поскольку при расчете ``отставания`` используются часы операционной системы "
+"с двух разных машин, не удивляйтесь, получив отрицательное число: смещение "
+"во времени может привести к постоянному запаздыванию времени на удаленном "
+"мастере относительно часов на локальном экземпляре."
+
+msgid "For multi-master configurations, ``lag`` is the maximal lag."
+msgstr "Для многомастерной конфигурации это максимально возможное отставание."