Feedback: fixes and improvements (#3564)

* Add warning about sync and async transactions in the sync replication section
* Fix typo in the access control section
* Some minor translation fixes

Fixes #3533
Fixes #3560

Author: xuniq

doc/concepts/replication/repl_sync.rst

@@ -29,23 +29,37 @@ When there is more than one synchronous transaction, they all wait for being
 replicated. Moreover, if an asynchronous transaction appears, it will
 also be blocked by the existing synchronous transactions. This behavior is very
 similar to a regular queue of asynchronous transactions because all the transactions
-are committed in the same order as they make the ``box.commit()`` call.
+are committed in the same order as they make the :ref:`box.commit() <box-commit>` call.
 So, here comes **the commit rule**:
 transactions are committed in the same order as they make
-the ``box.commit()`` call—regardless of being synchronous or asynchronous.
+the ``box.commit()`` call -- regardless of being synchronous or asynchronous.
 
 If one of the waiting synchronous transactions times out and is rolled back, it
 will first roll back all the newer pending transactions. Again, just like how
 asynchronous transactions are rolled back when WAL write fails.
 So, here comes **the rollback rule:**
 transactions are always rolled back in the order reversed from the one they
-make the ``box.commit()`` call—regardless of being synchronous or asynchronous.
+make the ``box.commit()`` call -- regardless of being synchronous or asynchronous.
 
 One more important thing is that if an asynchronous transaction is blocked by
 a synchronous transaction, it does not become synchronous as well.
 This just means it will wait for the synchronous transaction to be committed.
 But once it is done, the asynchronous transaction will be committed
-immediately—it won't wait for being replicated itself.
+immediately -- it won't wait for being replicated itself.
+
+..  warning::
+
+    Be careful when using synchronous and asynchronous transactions together.
+    Asynchronous transactions are considered committed even if there is no connection to other nodes.
+    Therefore, an old leader node (:ref:`synchronous transaction queue owner <box_info_synchro>`) might have some
+    committed asynchronous transactions that no other replica set member has.
+
+    When the connection to such an old (previous) leader node is restored, it starts receiving data from the new leader.
+    At the same time, other replica set members receive the data from the previous leader that they don't have yet.
+    The data from the previous leader contains some committed asynchronous transactions.
+    At this time, the integrity protection will throw
+    the :ref:`ER_SPLIT_BRAIN <repl_leader_elect_splitbrain>` error, which will force the user to rebootstrap the previous leader.
+
 
 Limitations and known problems
 ------------------------------

locale/ru/LC_MESSAGES/book/admin/access_control.po

@@ -264,7 +264,7 @@ msgid ""
 msgstr ""
 "'usage' (использование), например, допустимо ли любое действие, несмотря на "
 "другие права (иногда удобно отменить право на использование, чтобы временно "
-"заблокировать пользователя, не удаляя ег"
+"заблокировать пользователя, не удаляя его"
 
 msgid "'session', e.g. whether the user can 'connect'."
 msgstr ""

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

@@ -27,6 +27,13 @@ msgstr ""
 "проходит коммит лишь после репликации на некотором количестве экземпляров, и"
 " только тогда клиенту приходит ответ о завершении транзакции."
 
+msgid ""
+"To learn how to enable and use synchronous replication, "
+"check the :ref:`guide <how-to-repl_sync>`."
+msgstr ""
+"Подробная информация о включении и настройке синхронной репликации "
+"приведена в :ref:`соответствующем руководстве <how-to-repl_sync>`."
+
 msgid "Synchronous and asynchronous transactions"
 msgstr "Синхронные и асинхронные транзакции"
 
@@ -46,14 +53,14 @@ msgid ""
 "be blocked by the existing synchronous transactions. This behavior is very "
 "similar to a regular queue of asynchronous transactions because all the "
 "transactions are committed in the same order as they make the "
-"``box.commit()`` call. So, here comes **the commit rule**: transactions are "
+":ref:`box.commit() <box-commit>` call. So, here comes **the commit rule**: transactions are "
 "committed in the same order as they make the ``box.commit()`` "
-"call—regardless of being synchronous or asynchronous."
+"call -- regardless of being synchronous or asynchronous."
 msgstr ""
 "Если наряду с несколькими синхронными транзакциями, ожидающими репликации, "
 "совершается асинхронная транзакция, она блокируется синхронными. Коммиты при"
 " этом выполняются в той последовательности, в которой для каждой из "
-"транзакций вызывается метод ``box.commit()``. Похожим образом работает "
+"транзакций вызывается метод :ref:`box.commit() <box-commit>`. Похожим образом работает "
 "обычная очередь асинхронных транзакций. Можно сформулировать **правило "
 "коммитов**: порядок коммитов соответствует порядку вызова ``box.commit()`` "
 "для каждой из транзакций, независимо от того, синхронные транзакции или "
@@ -65,7 +72,7 @@ msgid ""
 "like how asynchronous transactions are rolled back when WAL write fails. So,"
 " here comes **the rollback rule:** transactions are always rolled back in "
 "the order reversed from the one they make the ``box.commit()`` "
-"call—regardless of being synchronous or asynchronous."
+"call -- regardless of being synchronous or asynchronous."
 msgstr ""
 "Если для одной из синхронных транзакций истечет время ожидания, эта "
 "транзакция будет отменена, а вместе с ней и все последующие транзакции в "
@@ -79,13 +86,43 @@ msgid ""
 "by a synchronous transaction, it does not become synchronous as well. This "
 "just means it will wait for the synchronous transaction to be committed. But"
 " once it is done, the asynchronous transaction will be committed "
-"immediately—it won't wait for being replicated itself."
+"immediately -- it won't wait for being replicated itself."
 msgstr ""
 "Асинхронная транзакция, заблокированная синхронной, не становится сама "
 "синхронной, а просто ожидает коммита синхронной транзакции. Как только это "
 "произойдет, асинхронная транзакция сразу сможет пройти коммит, не ожидая "
 "репликации."
 
+msgid ""
+"Be careful when using synchronous and asynchronous transactions together. "
+"Asynchronous transactions are considered committed even if there is no "
+"connection to other nodes. Therefore, an old leader node "
+"(:ref:`synchronous transaction queue owner <box_info_synchro>`) might have "
+"some committed asynchronous transactions that no other replica set member has."
+msgstr ""
+"Будьте осторожны при одновременном использовании синхронных и асинхронных транзакций. "
+"Для асинхронных транзакций коммит засчитывается успешным даже в том случае, если нет "
+"соединения с другими узлами. Поэтому на старом ``leader``-узле "
+"(:ref:`владельце очереди синхронных транзакций <box_info_synchro>`) могут быть "
+"асинхронные транзакции, которые прошли коммит, но отсутствуют на других узлах набора реплик."
+
+msgid ""
+"When the connection to such an old (previous) leader node is restored, "
+"it starts receiving data from the new leader. At the same time, "
+"other replica set members receive the data from the previous leader that they don't have yet. "
+"The data from the previous leader contains some committed asynchronous transactions. "
+"At this time, the integrity protection "
+"will throw the :ref:`ER_SPLIT_BRAIN <repl_leader_elect_splitbrain>` error, "
+"which will force the user to rebootstrap the previous leader."
+msgstr ""
+"Когда предыдущий лидер снова становится доступен в наборе реплик, "
+"он начинает получать данные с нового лидера. В это же время "
+"остальные узлы в наборе реплик начинают получать данные со старого лидера, которых у них еще нет. "
+"Эти данные содержат и асинхронные транзакции, прошедшие коммит. "
+"В этот момент система выдаст ошибку "
+":ref:`ER_SPLIT_BRAIN <repl_leader_elect_splitbrain>`, заставляя "
+"пользователя провести повторную настройку (rebootstrap) предыдущего лидера."
+
 msgid "Limitations and known problems"
 msgstr "Ограничения и известные проблемы"