feedback: add fixes (#3613)

* Fixes #3552 - fix broken link
* Fix translation and wording

Author: xuniq

doc/concepts/replication/repl_leader_elect.rst

@@ -39,6 +39,16 @@ in the cluster but don't use synchronous spaces at all.
 Synchronous replication has a separate :ref:`documentation section <repl_sync>`.
 Leader election is described below.
 
+..  note::
+
+    The system behavior can be specified exactly according to the Raft algorithm. To do this:
+
+    *   Ensure that the user has only synchronous spaces.
+    *   Set the :ref:`replication_synchro_quorum <repl_leader_elect_config>` option to ``N / 2 + 1``.
+    *   Set the :ref:`replication_synchro_timeout <cfg_replication-replication_synchro_timeout>` option to infinity.
+    *   In the :ref:`election_fencing_mode <repl_leader_elect_config>` option, select either the ``soft`` mode (the default)
+        or the ``strict`` mode, which is more restrictive.
+
 .. _repl_leader_elect_process:
 
 Leader election process
@@ -56,7 +66,7 @@ After the first boot, each node has its term equal to 1. When a node sees that
 it is not a leader and there is no leader available for some time in the replica
 set, it increases the term and starts a new leader election round.
 
-Leader election happens via votes. The node, which started the election, votes
+Leader election happens via votes. The node that started the election votes
 for itself and sends vote requests to other nodes.
 Upon receiving vote requests, a node votes for the first of them, and then cannot
 do anything in the same term but wait for a leader to be elected.
@@ -67,7 +77,7 @@ and notifies other nodes about that. Also, a split vote can happen
 when no nodes received a quorum of votes. In this case,
 after a :ref:`random timeout <repl_leader_elect_config>`,
 each node increases its term and starts a new election round if no new vote
-request with a greater term arrives during this time period.
+request with a greater term arrives during this time.
 Eventually, a leader is elected.
 
 If any unfinalized synchronous transactions are left from the previous leader,
@@ -85,7 +95,8 @@ a non-leader node starts a new election if the following conditions are met:
 
 ..  note::
 
-    A cluster member considers the leader node to be alive if the member received heartbeats from the leader at least once during the period of ``replication_timeout * 4``,
+    A cluster member considers the leader node to be alive if the member received heartbeats from the leader at least
+    once during the ``replication_timeout * 4``,
     and there are no replication errors (the connection is not broken due to timeout or due to an error).
 
 Terms and votes are persisted by each instance to preserve certain Raft guarantees.
@@ -136,12 +147,11 @@ Once noticing the error, a user can choose any representative from each of the s
 To correlate the data, the user should remove it from the nodes of one set,
 and reconnect them to the nodes from the other set that have the correct data.
 
-Also, if election is enabled on the node, it won't replicate from any nodes except
+Also, if election is enabled on the node, it doesn't replicate from any nodes except
 the newest leader. This is done to avoid the issue when a new leader is elected,
 but the old leader has somehow survived and tries to send more changes
 to the other nodes.
 
 Term numbers also work as a kind of filter.
-For example, you can be sure that if election
-is enabled on two nodes and ``node1`` has the term number less than ``node2``,
-then ``node2`` won't accept any transactions from ``node1``.
+For example, if election is enabled on two nodes and ``node1`` has the term number less than ``node2``,
+then ``node2`` doesn't accept any transactions from ``node1``.

doc/how-to/replication/repl_leader_elect.rst

@@ -80,35 +80,35 @@ refer to the :doc:`function description </reference/reference_lua/box_info/elect
 
 The Raft-based election implementation logs all its actions
 with the ``RAFT:`` prefix. The actions are new Raft message handling,
-node state changing, voting, term bumping, and so on.
+node state changing, voting, and term bumping.
 
 ..  _repl_leader_elect_important:
 
 Important notes
 ---------------
 
-Leader election won't work correctly if the election quorum is set to less or equal
+Leader election doesn't work correctly if the election quorum is set to less or equal
 than ``<cluster size> / 2`` because in that case, a split vote can lead to
 a state when two leaders are elected at once.
 
-For example, let's assume there are five nodes. When the quorum is set to ``2``, ``node1``
+For example, suppose there are five nodes. When the quorum is set to ``2``, ``node1``
 and ``node2`` can both vote for ``node1``. ``node3`` and ``node4`` can both vote
 for ``node5``. In this case, ``node1`` and ``node5`` both win the election.
 When the quorum is set to the cluster majority, that is
-``(<cluster size> / 2) + 1`` or bigger, the split vote is not possible.
+``(<cluster size> / 2) + 1`` or greater, the split vote is impossible.
 
 That should be considered when adding new nodes.
 If the majority value is changing, it's better to update the quorum on all the existing nodes
 before adding a new one.
 
-Also, the automated leader election won't bring many benefits in terms of data
+Also, the automated leader election doesn't bring many benefits in terms of data
 safety when used *without* :ref:`synchronous replication <repl_sync>`.
 If the replication is asynchronous and a new leader gets elected,
 the old leader is still active and considers itself the leader.
 In such case, nothing stops
 it from accepting requests from clients and making transactions.
-Non-synchronous transactions will be successfully committed because
-they won't be checked against the quorum of replicas.
-Synchronous transactions will fail because they won't be able
-to collect the quorum -- most of the replicas will reject
+Non-synchronous transactions are successfully committed because
+they are not checked against the quorum of replicas.
+Synchronous transactions fail because they are not able
+to collect the quorum -- most of the replicas reject
 these old leader's transactions since it is not a leader anymore.

doc/reference/reference_lua/errcodes.rst

@@ -4,12 +4,12 @@
 Database error codes
 -------------------------------------------------------------------------------
 
-In the current version of the binary protocol, error messages, which are normally
+In the current version of the binary protocol, error messages, which are usually
 more descriptive than error codes, are not present in server responses. The actual
-message may contain a file name, a detailed reason or operating system error code.
+message may contain a filename, a detailed reason or operating system error code.
 All such messages, however, are logged in the error log. Below are general
 descriptions of some popular codes. A complete list of errors can be found in file
-`errcode.h <https://github.com/tarantool/tarantool/blob/2.1/src/box/errcode.h>`_ in the source tree.
+`errcode.h <https://github.com/tarantool/tarantool/blob/master/src/box/error.h>`_ in the source tree.
 
 .. container:: table
 
@@ -122,15 +122,15 @@ For example consider the :ref:`fio_read.lua <cookbook-fio_read>` program in our
     f:close()
     print(data)
 
-After a function call that might fail, like fio.open() above,
+After a function call that might fail, like ``fio.open()`` above,
 it is common to see syntax like ``if not f then ...``
 or ``if f == nil then ...``, which check
 for common failures. But if there had been a syntax
 error, for example fio.opex instead of fio.open, then
 there would have been a Lua error and f would not have
 been changed. If checking for such an obvious error
 had been a concern, the programmer would probably have
-used pcall().
+used ``pcall()``.
 
 All functions in Tarantool modules should work this way,
 unless the manual explicitly says otherwise.

locale/ru/LC_MESSAGES/concepts/replication/repl_leader_elect.po

@@ -6,7 +6,7 @@ msgid ""
 "Starting from version :doc:`2.6.1 </release/2.6.1>`, Tarantool has the "
 "built-in functionality managing automated *leader election* in a replica "
 "set. This functionality increases the fault tolerance of the systems built "
-"on the base of Tarantool and decreases dependency on the external tools for "
+"on the base of Tarantool and decreases dependency on external tools for "
 "replica set management."
 msgstr ""
 "В Tarantool, начиная с версии :doc:`2.6.1 </release/2.6.1>`, есть встроенная"
@@ -16,8 +16,8 @@ msgstr ""
 "снижает зависимость от внешних инструментов для управления набором реплик."
 
 msgid ""
-"To learn how to configure and monitor automated leader elections,
-check the :ref:`how-to guide <how-to-repl_leader_elect>`."
+"To learn how to configure and monitor automated leader elections, "
+"check the :ref:`how-to guide <how-to-repl_leader_elect>`."
 msgstr ""
 "Чтобы узнать, как настраивать и отслеживать автоматические выборы лидера, "
 "прочитайте :ref:`практическое руководство <how-to-repl_leader_elect>`."
@@ -88,25 +88,27 @@ msgstr ""
 "своего терма и начинает новый тур выборов."
 
 msgid ""
-"Leader election happens via votes. The node which started the election votes"
+"Leader election happens via votes. The node that started the election votes"
 " for itself and sends vote requests to other nodes. Upon receiving vote "
 "requests, a node votes for the first of them, and then cannot do anything in"
-" the same term but wait for a leader being elected."
+" the same term but wait for a leader to be elected."
 msgstr ""
 "Выборы лидера происходят посредством голосования. Узел, начинающий выборы, "
 "голосует сам за себя и отправляет другим запросы на голос. Каждый экземпляр "
 "голосует за первый узел, от которого пришел такой запрос, и далее в течение "
 "всего терма ожидает избрания лидера, не выполняя никаких действий."
 
 msgid ""
-"The node that collected a :ref:`quorum of votes <repl_leader_elect_config>` "
+"The node that collected a quorum of votes defined by the "
+":ref:`replication_synchro_quorum <repl_leader_elect_config>` parameter "
 "becomes the leader and notifies other nodes about that. Also, a split vote "
 "can happen when no nodes received a quorum of votes. In this case, after a "
 ":ref:`random timeout <repl_leader_elect_config>`, each node increases its "
 "term and starts a new election round if no new vote request with a greater "
-"term arrives during this time period. Eventually, a leader is elected."
+"term arrives during this time. Eventually, a leader is elected."
 msgstr ""
-"Узел, собравший :ref:`кворум голосов <repl_leader_elect_config>`, становится"
+"Узел, собравший кворум голосов "
+":ref:`replication_synchro_quorum <repl_leader_elect_config>`, становится"
 " лидером и оповещает об этом другие узлы. Голоса могут разделиться, если ни "
 "один узел не получит кворума. В этом случае спустя :ref:`случайное время "
 "<repl_leader_elect_config>` происходят перевыборы: каждый узел увеличивает "
@@ -116,21 +118,22 @@ msgstr ""
 
 msgid ""
 "All the non-leader nodes are called *followers*. The nodes that start a new "
-"election round are called *candidates*. The elected leader sends heartbeats "
-"to the non-leader nodes to let them know it is alive. So if there are no "
-"heartbeats for a period set by the :ref:`replication_timeout "
-"<cfg_replication-replication_timeout>` option, a new election starts. Terms "
-"and votes are persisted by each instance in order to preserve certain Raft "
-"guarantees."
+"election round are alled *candidates*. The elected leader sends heartbeats "
+"to the non-leader nodes to let them know it is alive."
 msgstr ""
 "Узлы, не являющиеся лидерами, называются *последователями* (followers). "
 "Узлы, которые начинают новый тур выборов, называются *кандидатами* "
 "(candidates). Избранный лидер отправляет остальным узлам контрольные сигналы"
-" (heartbeats), оповещая о том, что он работает (alive). Если контрольные "
-"сигналы не приходят в течение времени, заданного параметром "
-":ref:`replication_timeout <cfg_replication-replication_timeout>`, начинаются"
-" новые выборы. Чтобы алгоритм Raft гарантированно выполнялся, термы и голоса"
-" сохраняются на каждом экземпляре."
+" (heartbeats), оповещая о том, что он работает (alive)."
+
+msgid ""
+"In case there are no heartbeats for the period of "
+":ref:`replication_timeout <cfg_replication-replication_timeout>` * 4, "
+"a non-leader node starts a new election if the following conditions are met: "
+msgstr ""
+"Если контрольные сигналы не приходят в течение периода времени "
+":ref:`replication_timeout <cfg_replication-replication_timeout>` * 4, узел, "
+"не являющийся лидером, начинает новые выборы при соблюдении следующих условий: "
 
 msgid ""
 "During the election, the nodes prefer to vote for those ones that have the "
@@ -145,7 +148,7 @@ msgid ""
 "When :ref:`election is enabled <repl_leader_elect_config>`, there must be "
 "connections between each node pair so as it would be the full mesh topology."
 " This is needed because election messages for voting and other internal "
-"things need direct connection between the nodes."
+"things need a direct connection between the nodes."
 msgstr ""
 "Необходимо, чтобы все узлы, :ref:`включенные в процесс выборов "
 "<repl_leader_elect_config>`, были соединены попарно и образовывали полную "
@@ -154,7 +157,7 @@ msgstr ""
 "узлами."
 
 msgid ""
-"Also, if election is enabled on the node, it won't replicate from any nodes "
+"Also, if election is enabled on the node, it doesn't replicate from any nodes "
 "except the newest leader. This is done to avoid the issue when a new leader "
 "is elected, but the old leader has somehow survived and tries to send more "
 "changes to the other nodes."
@@ -165,9 +168,9 @@ msgstr ""
 "реплики."
 
 msgid ""
-"Term numbers also work as a kind of a filter. For example, you can be sure "
-"that if election is enabled on two nodes and ``node1`` has the term number "
-"less than ``node2``, then ``node2`` won't accept any transactions from "
+"Term numbers also work as a kind of filter. For example, "
+"if election is enabled on two nodes and ``node1`` has the term number "
+"less than ``node2``, then ``node2`` doesn't accept any transactions from "
 "``node1``."
 msgstr ""
 "Числовые значения термов также выполняют функцию своеобразного фильтра. "

locale/ru/LC_MESSAGES/reference/reference_lua/errcodes.po

@@ -9,7 +9,7 @@ msgid ""
 "operating system error code. All such messages, however, are logged in the "
 "error log. Below are general descriptions of some popular codes. A complete "
 "list of errors can be found in file `errcode.h "
-"<https://github.com/tarantool/tarantool/blob/2.1/src/box/errcode.h>`_ in the"
+"<https://github.com/tarantool/tarantool/blob/master/src/box/errcode.h>`_ in the"
 " source tree."
 msgstr ""