From 2004c3755d2d4cacdc27797dec42e3a9ced9487f Mon Sep 17 00:00:00 2001
From: BayoNet <bayonet@virtUbuntu16.04>
Date: Thu, 27 Apr 2017 12:47:31 +0300
Subject: [PATCH 1/6] Information on <allow_databases> was added.

---
 docs/ru/access_rights.rst | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/docs/ru/access_rights.rst b/docs/ru/access_rights.rst
index 66fb1811729..0987d4d8465 100644
--- a/docs/ru/access_rights.rst
+++ b/docs/ru/access_rights.rst
@@ -27,7 +27,7 @@
   
           <!-- Список сетей, из которых разрешён доступ.
               Каждый элемент списка имеет одну из следующих форм:
-              <ip> IP-адрес или маска подсети. Например, 222.111.222.3 или 10.0.0.1/8 или 2a02:6b8::3 или 2a02:6b8::3/64.
+              <ip> IP-адрес или маска подсети. Например, 198.51.100.0/24 или 2001:DB8::/32.
               <host> Имя хоста. Например: example01. Для проверки делается DNS-запрос, и все полученные адреса сравниваются с адресом клиента.
               <host_regexp> Регулярное выражение для имён хостов. Например, ^example\d\d-\d\d-\d\.yandex\.ru$
                   Для проверки, для адреса клиента делается DNS PTR-запрос и к результату применяется регулярное выражение.
@@ -54,10 +54,13 @@
           <networks incl="networks" />
           <profile>web</profile>
           <quota>default</quota>
+          <allow_databases>
+             <database>test</database>
+          </allow_databases>
       </web>
 
-Здесь видно объявление двух пользователей - ``default`` и ``web``. Пользователя web мы добавили самостоятельно.
-Пользователь default выбирается в случаях, когда имя пользователя не передаётся, поэтому такой пользователь должен присутствовать в конфигурационном файле обязательно. Также пользователь default используется при распределённой обработки запроса - система ходит на удалённые серверы под ним. Поэтому, у пользователя default должен быть пустой пароль и не должно быть выставлено существенных ограничений или квот - иначе распределённые запросы сломаются.
+Здесь видно объявление двух пользователей - ``default`` и ``web``. Пользователя ``web`` мы добавили самостоятельно.
+Пользователь ``default`` выбирается в случаях, когда имя пользователя не передаётся, поэтому такой пользователь должен присутствовать в конфигурационном файле обязательно. Также пользователь ``default`` используется при распределённой обработки запроса - система ходит на удалённые серверы под ним. Поэтому, у пользователя ``default`` должен быть пустой пароль и не должно быть выставлено существенных ограничений или квот - иначе распределённые запросы сломаются.
 
 Пароль указывается либо в открытом виде (не рекомендуется), либо в виде SHA-256. Хэш не содержит соль. В связи с этим, не следует рассматривать такие пароли, как защиту от потенциального злоумышленника. Скорее, они нужны для защиты от сотрудников.
 
@@ -69,8 +72,8 @@
       ...
       <networks>
           <ip>::/64</ip>
-          <ip>93.111.222.128/26</ip>
-          <ip>2a02:6b8:0:111::/64</ip>
+          <ip>203.0.113.0/24</ip>
+          <ip>2001:DB8::/32</ip>
           ...
       </networks>
   </yandex>
@@ -83,4 +86,6 @@
 
 Далее указывается используемый профиль настроек пользователя (смотрите раздел "Профили настроек"). Вы можете указать профиль по умолчанию - default. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек - настройку readonly, равную 1, что обеспечивает доступ только на чтение.
 
-Затем указывается используемая квота (смотрите раздел "Квоты"). Вы можете указать квоту по умолчанию - default. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно; одна и та же квота может быть указана для разных пользователей - в этом случае, подсчёт использования ресурсов делается для каждого пользователя по отдельности.
+Затем указывается используемая квота (смотрите раздел "Квоты"). Вы можете указать квоту по умолчанию - ``default``. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно; одна и та же квота может быть указана для разных пользователей - в этом случае, подсчёт использования ресурсов делается для каждого пользователя по отдельности.
+
+Также в необязательном разделе ``<allow_databases>`` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию.

From b503f672a0a19c9f1602ff15c4d4630a2529fe3b Mon Sep 17 00:00:00 2001
From: BayoNet <bayonet@virtUbuntu16.04>
Date: Fri, 28 Apr 2017 19:05:46 +0300
Subject: [PATCH 2/6] Description of distributed_product_mode was added. Many
 syntax errors was fixed which led to the warnings and errors of sphinx-build.

---
 docs/ru/access_rights.rst          |  2 +-
 docs/ru/query_language/queries.rst | 74 ++++++++++++++++++++--------
 docs/ru/settings/settings.rst      | 78 +++++++++++++++++++-----------
 3 files changed, 105 insertions(+), 49 deletions(-)

diff --git a/docs/ru/access_rights.rst b/docs/ru/access_rights.rst
index 0987d4d8465..7ee17b486ae 100644
--- a/docs/ru/access_rights.rst
+++ b/docs/ru/access_rights.rst
@@ -84,7 +84,7 @@
 
 Для продакшен использования, указывайте только элементы вида ip (IP-адреса и их маски), так как использование host и host_regexp может вызывать лишние задержки.
 
-Далее указывается используемый профиль настроек пользователя (смотрите раздел "Профили настроек"). Вы можете указать профиль по умолчанию - default. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек - настройку readonly, равную 1, что обеспечивает доступ только на чтение.
+Далее указывается используемый профиль настроек пользователя (смотрите раздел "Профили настроек"). Вы можете указать профиль по умолчанию - ``default``. Профиль может называться как угодно; один и тот же профиль может быть указан для разных пользователей. Наиболее важная вещь, которую вы можете прописать в профиле настроек - настройку readonly, равную 1, что обеспечивает доступ только на чтение.
 
 Затем указывается используемая квота (смотрите раздел "Квоты"). Вы можете указать квоту по умолчанию - ``default``. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно; одна и та же квота может быть указана для разных пользователей - в этом случае, подсчёт использования ресурсов делается для каждого пользователя по отдельности.
 
diff --git a/docs/ru/query_language/queries.rst b/docs/ru/query_language/queries.rst
index a7e801bcfc8..b4ac2e78d48 100644
--- a/docs/ru/query_language/queries.rst
+++ b/docs/ru/query_language/queries.rst
@@ -5,6 +5,7 @@ CREATE DATABASE
 ~~~~~~~~~~~~~~~
 Создание базы данных db_name
 ::
+    
     CREATE DATABASE [IF NOT EXISTS] db_name
 
 ``База данных`` - это просто директория для таблиц.
@@ -14,6 +15,7 @@ CREATE TABLE
 ~~~~~~~~~~~~
 Запрос ``CREATE TABLE`` может иметь несколько форм.
 ::
+
     CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name
     (
         name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
@@ -27,10 +29,12 @@ CREATE TABLE
 Описание столбца, это ``name type``, в простейшем случае. Пример: ``RegionID UInt32``.
 Также могут быть указаны выражения для значений по умолчанию - смотрите ниже.
 ::
+
     CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name AS [db2.]name2 [ENGINE = engine]
 
 Создаёт таблицу с такой же структурой, как другая таблица. Можно указать другой движок для таблицы. Если движок не указан, то будет выбран такой же движок, как у таблицы ``db2.name2``.
 ::
+
     CREATE [TEMPORARY] TABLE [IF NOT EXISTS] [db.]name ENGINE = engine AS SELECT ...
 
 Создаёт таблицу со структурой, как результат запроса ``SELECT``, с движком engine, и заполняет её данными из SELECT-а.
@@ -57,9 +61,9 @@ CREATE TABLE
 
 ``MATERIALIZED expr``
 
-Материализованное выражение. Такой столбец не может быть указан при INSERT-е, то есть, он всегда вычисляется.
-При INSERT-е без указания списка столбцов, такие столбцы не рассматриваются.
-Также этот столбец не подставляется при использовании звёздочки в запросе SELECT - чтобы сохранить инвариант, что дамп, полученный путём SELECT *, можно вставить обратно в таблицу INSERT-ом без указания списка столбцов.
+Материализованное выражение. Такой столбец не может быть указан при INSERT, то есть, он всегда вычисляется.
+При INSERT без указания списка столбцов, такие столбцы не рассматриваются.
+Также этот столбец не подставляется при использовании звёздочки в запросе SELECT - чтобы сохранить инвариант, что дамп, полученный путём ``SELECT *``, можно вставить обратно в таблицу INSERT-ом без указания списка столбцов.
 
 ``ALIAS expr``
 
@@ -94,12 +98,17 @@ CREATE VIEW
 
 Для примера, пусть вы создали представление:
 ::
+
     CREATE VIEW view AS SELECT ...
+
 и написали запрос:
 ::
+
     SELECT a, b, c FROM view
+
 Этот запрос полностью эквивалентен использованию подзапроса:
 ::
+
     SELECT a, b, c FROM (SELECT ...)
 
 Материализованные (MATERIALIZED) представления хранят данные, преобразованные соответствующим запросом SELECT.
@@ -131,11 +140,13 @@ DROP
 ~~~~
 Запрос имеет два вида: ``DROP DATABASE`` и ``DROP TABLE``.
 ::
+
     DROP DATABASE [IF EXISTS] db
 
 Удаляет все таблицы внутри базы данных db, а затем саму базу данных db.
 Если указано ``IF EXISTS`` - не выдавать ошибку, если база данных не существует.
 ::
+
     DROP TABLE [IF EXISTS] [db.]name
 
 Удаляет таблицу.
@@ -145,6 +156,7 @@ DETACH
 ~~~~~~
 Удаляет из сервера информацию о таблице `name`. Сервер перестаёт знать о существовании таблицы.
 ::
+
     DETACH TABLE [IF EXISTS] [db.]name
 
 Но ни данные, ни метаданные таблицы не удаляются. При следующем запуске сервера, сервер прочитает метаданные и снова узнает о таблице.
@@ -156,6 +168,7 @@ RENAME
 ~~~~~~
 Переименовывает одну или несколько таблиц.
 ::
+
     RENAME TABLE [db11.]name11 TO [db12.]name12, [db21.]name21 TO [db22.]name22, ...
 
 Все таблицы переименовываются под глобальной блокировкой. Переименовывание таблицы является лёгкой операцией. Если вы указали после TO другую базу данных, то таблица будет перенесена в эту базу данных. При этом, директории с базами данных должны быть расположены в одной файловой системе (иначе возвращается ошибка).
@@ -168,6 +181,7 @@ ALTER
 """"""""""""""""""""""""
 Изменение структуры таблицы.
 ::
+
     ALTER TABLE [db].name ADD|DROP|MODIFY COLUMN ...
 
 В запросе указывается список из одного или более действий через запятую.
@@ -175,6 +189,7 @@ ALTER
 
 Существуют следующие действия:
 ::
+
     ADD COLUMN name [type] [default_expr] [AFTER name_after]
 
 Добавляет в таблицу новый столбец с именем name, типом type и выражением для умолчания ``default_expr`` (смотрите раздел "Значения по умолчанию"). Если указано ``AFTER name_after`` (имя другого столбца), то столбец добавляется (в список столбцов таблицы) после указанного. Иначе, столбец добавляется в конец таблицы. Внимательный читатель может заметить, что отсутствует возможность добавить столбец в начало таблицы. Для цепочки действий, name_after может быть именем столбца, который добавляется в одном из предыдущих действий.
@@ -241,6 +256,7 @@ ALTER
 
 Чтобы посмотреть набор кусков и партиций таблицы, можно воспользоваться системной таблицей ``system.parts``:
 ::
+
     SELECT * FROM system.parts WHERE active
 
 ``active`` - учитывать только активные куски. Неактивными являются, например, исходные куски оставшиеся после слияния в более крупный кусок - такие куски удаляются приблизительно через 10 минут после слияния.
@@ -249,6 +265,7 @@ ALTER
 Директория с данными - ``/var/lib/clickhouse/data/database/table/``,
 где ``/var/lib/clickhouse/`` - путь к данным ClickHouse, database - имя базы данных, table - имя таблицы. Пример:
 ::
+
     $ ls -l /var/lib/clickhouse/data/test/visits/
     total 48
     drwxrwxrwx 2 clickhouse clickhouse 20480 мая   13 02:58 20140317_20140323_2_2_0
@@ -260,9 +277,9 @@ ALTER
 
 Рассмотрим по порядку имя первого куска: ``20140317_20140323_2_2_0``.
  * ``20140317`` - минимальная дата данных куска
- * ``20140323`` - максимальная дата данных куска .. |br| raw:: html
- * ``2`` - минимальный номер блока данных .. |br| raw:: html
- * ``2`` - максимальный номер блока данных .. |br| raw:: html
+ * ``20140323`` - максимальная дата данных куска
+ * ``2`` - минимальный номер блока данных
+ * ``2`` - максимальный номер блока данных
  * ``0`` - уровень куска - глубина дерева слияний, которыми он образован
 
 Каждый кусок относится к одной партиции и содержит данные только за один месяц.
@@ -274,7 +291,8 @@ ALTER
 
 Директория ``detached`` содержит куски, не используемые сервером - отцепленные от таблицы с помощью запроса ``ALTER ... DETACH``. Также в эту директорию переносятся куски, признанные повреждёнными, вместо их удаления. Вы можете в любое время добавлять, удалять, модифицировать данные в директории detached - сервер не будет об этом знать, пока вы не сделаете запрос ``ALTER TABLE ... ATTACH``.
 ::
-ALTER TABLE [db.]table DETACH PARTITION 'name'
+
+    ALTER TABLE [db.]table DETACH PARTITION 'name'
 
 Перенести все данные для партиции с именем name в директорию detached и забыть про них.
 Имя партиции указывается в формате YYYYMM. Оно может быть указано в одинарных кавычках или без них.
@@ -283,10 +301,12 @@ ALTER TABLE [db.]table DETACH PARTITION 'name'
 
 Запрос реплицируется - данные будут перенесены в директорию detached и забыты на всех репликах. Запрос может быть отправлен только на реплику-лидер. Вы можете узнать, является ли реплика лидером, сделав SELECT в системную таблицу system.replicas. Или, проще, вы можете выполнить запрос на всех репликах, и на всех кроме одной, он кинет исключение.
 ::
+
     ALTER TABLE [db.]table DROP PARTITION 'name'
 
 Аналогично операции ``DETACH``. Удалить данные из таблицы. Куски с данными будут помечены как неактивные и будут полностью удалены примерно через 10 минут. Запрос реплицируется - данные будут удалены на всех репликах.
 ::
+
     ALTER TABLE [db.]table ATTACH PARTITION|PART 'name'
 
 Добавить данные в таблицу из директории detached.
@@ -297,6 +317,7 @@ ALTER TABLE [db.]table DETACH PARTITION 'name'
 
 То есть, вы можете разместить данные в директории detached на одной реплике и, с помощью запроса ALTER ... ATTACH добавить их в таблицу на всех репликах.
 ::
+
     ALTER TABLE [db.]table FREEZE PARTITION 'name'
 
 Создаёт локальный бэкап одной или нескольких партиций. В качестве имени может быть указано полное имя партиции (например, 201403) или его префикс (например, 2014) - тогда бэкап будет создан для всех соответствующих партиций.
@@ -338,6 +359,7 @@ ALTER TABLE [db.]table DETACH PARTITION 'name'
 Бэкапы защищают от человеческих ошибок (случайно удалили данные, удалили не те данные или не на том кластере, испортили данные).
 Для баз данных большого объёма, бывает затруднительно копировать бэкапы на удалённые серверы. В этих случаях, для защиты от человеческой ошибки, можно держать бэкап на том же сервере (он будет лежать в ``/var/lib/clickhouse/shadow/``).
 ::
+
   ALTER TABLE [db.]table FETCH PARTITION 'name' FROM 'path-in-zookeeper'
 
 Запрос работает только для реплицируемых таблиц.
@@ -627,7 +649,7 @@ SELECT
 
 ``ARRAY JOIN`` - это, по сути, ``INNER JOIN`` с массивом. Пример:
 
-.. code-block:: sql
+::
 
     :) CREATE TABLE arrays_test (s String, arr Array(UInt8)) ENGINE = Memory
 
@@ -680,7 +702,7 @@ SELECT
 
 Для массива в секции ARRAY JOIN может быть указан алиас. В этом случае, элемент массива будет доступен под этим алиасом, а сам массив - под исходным именем. Пример:
 
-.. code-block:: sql
+::
 
     :) SELECT s, arr, a FROM arrays_test ARRAY JOIN arr AS a
 
@@ -700,7 +722,7 @@ SELECT
 
 В секции ARRAY JOIN может быть указано несколько массивов одинаковых размеров через запятую. В этом случае, JOIN делается с ними одновременно (прямая сумма, а не прямое произведение). Пример:
 
-.. code-block:: sql
+::
 
     :) SELECT s, arr, a, num, mapped FROM arrays_test ARRAY JOIN arr AS a, arrayEnumerate(arr) AS num, arrayMap(x -> x + 1, arr) AS mapped
 
@@ -736,7 +758,7 @@ SELECT
 
 ARRAY JOIN также работает с вложенными структурами данных. Пример:
 
-.. code-block:: sql
+::
 
     :) CREATE TABLE nested_test (s String, nest Nested(x UInt8, y UInt32)) ENGINE = Memory
 
@@ -791,7 +813,7 @@ ARRAY JOIN также работает с вложенными структур
 
 При указании имени вложенной структуры данных в ARRAY JOIN, смысл такой же, как ARRAY JOIN со всеми элементами-массивами, из которых она состоит. Пример:
 
-.. code-block:: sql
+::
 
     :) SELECT s, nest.x, nest.y FROM nested_test ARRAY JOIN nest.x, nest.y
 
@@ -811,7 +833,7 @@ ARRAY JOIN также работает с вложенными структур
 
 Такой вариант тоже имеет смысл:
 
-.. code-block:: sql
+::
 
     :) SELECT s, nest.x, nest.y FROM nested_test ARRAY JOIN nest.x
 
@@ -831,7 +853,7 @@ ARRAY JOIN также работает с вложенными структур
 
 Алиас для вложенной структуры данных можно использовать, чтобы выбрать как результат JOIN-а, так и исходный массив. Пример:
 
-.. code-block:: sql
+::
 
     :) SELECT s, n.x, n.y, nest.x, nest.y FROM nested_test ARRAY JOIN nest AS n
 
@@ -851,7 +873,7 @@ ARRAY JOIN также работает с вложенными структур
 
 Пример использования функции arrayEnumerate:
 
-.. code-block:: sql
+::
 
     :) SELECT s, n.x, n.y, nest.x, nest.y, num FROM nested_test ARRAY JOIN nest AS n, arrayEnumerate(nest.x) AS num
 
@@ -914,7 +936,7 @@ JOIN-ы бывают нескольких видов:
 
 Пример:
 
-.. code-block:: sql
+::
 
     SELECT
         CounterID,
@@ -985,7 +1007,7 @@ PREWHERE имеет смысл использовать, если есть ус
 
 Например, полезно писать PREWHERE для запросов, которые вынимают много столбцов, но в которых фильтрация производится лишь по нескольким столбцам.
 
-PREWHERE поддерживается только таблицами семейства *MergeTree.
+PREWHERE поддерживается только таблицами семейства ``*MergeTree``.
 
 В запросе могут быть одновременно указаны секции PREWHERE и WHERE. В этом случае, PREWHERE идёт перед WHERE.
 
@@ -1241,7 +1263,7 @@ n и m должны быть неотрицательными целыми чи
 Оператор IN и подзапрос могут встречаться в любой части запроса, в том числе в агрегатных и лямбда функциях.
 Пример:
 
-.. code-block:: sql
+::
 
     SELECT
         EventDate,
@@ -1265,14 +1287,19 @@ n и m должны быть неотрицательными целыми чи
     │ 2014-03-23 │ 0.648416 │
     └────────────┴──────────┘
 
-- за каждый день после 17 марта считаем долю хитов, сделанных посетителями, которые заходили на сайт 17 марта.
+за каждый день после 17 марта считаем долю хитов, сделанных посетителями, которые заходили на сайт 17 марта.
 Подзапрос в секции IN на одном сервере всегда выполняется только один раз. Зависимых подзапросов не существует.
 
+
+.. _distributed-subrequests:
+
 Распределённые подзапросы
 """""""""""""""""""""""""
 
 Существует два варианта IN-ов с подзапросами (аналогично для JOIN-ов): обычный ``IN`` / ``JOIN`` и ``GLOBAL IN`` / ``GLOBAL JOIN``. Они отличаются способом выполнения при распределённой обработке запроса.
 
+.. attention:: Помните, что алгоритмы, описанные ниже, могут работать иначе в зависимости от настройки ``distributed_product_mode``.
+
 При использовании обычного IN-а, запрос отправляется на удалённые серверы, и на каждом из них выполняются подзапросы в секциях ``IN`` / ``JOIN``.
 
 При использовании ``GLOBAL IN`` / ``GLOBAL JOIN-а``, сначала выполняются все подзапросы для ``GLOBAL IN`` / ``GLOBAL JOIN-ов``, и результаты складываются во временные таблицы. Затем эти временные таблицы передаются на каждый удалённый сервер, и на них выполняются запросы, с использованием этих переданных временных данных.
@@ -1287,11 +1314,15 @@ n и m должны быть неотрицательными целыми чи
 
 Например, запрос
 
-``SELECT uniq(UserID) FROM distributed_table``
+.. code-block:: sql
+
+    SELECT uniq(UserID) FROM distributed_table
 
 будет отправлен на все удалённые серверы в виде
 
-``SELECT uniq(UserID) FROM local_table``
+.. code-block:: sql
+
+    SELECT uniq(UserID) FROM local_table
 
 , выполнен параллельно на каждом из них до стадии, позволяющей объединить промежуточные результаты; затем промежуточные результаты вернутся на сервер-инициатор запроса, будут на нём объединены, и финальный результат будет отправлен клиенту.
 
@@ -1322,6 +1353,7 @@ n и m должны быть неотрицательными целыми чи
 Этот запрос будет отправлен на все удалённые серверы в виде
 
 .. code-block:: sql
+
     SELECT uniq(UserID) FROM local_table WHERE CounterID = 101500 AND UserID IN (SELECT UserID FROM distributed_table WHERE CounterID = 34)
 
 На каждом удалённом сервере начнёт выполняться подзапрос. Так как в подзапросе используется распределённая таблица, то подзапрос будет, на каждом удалённом сервере, снова отправлен на каждый удалённый сервер, в виде
diff --git a/docs/ru/settings/settings.rst b/docs/ru/settings/settings.rst
index 093394c3af7..e5d7d1e726a 100644
--- a/docs/ru/settings/settings.rst
+++ b/docs/ru/settings/settings.rst
@@ -1,3 +1,27 @@
+distributed_product_mode
+------------------------
+Изменяет поведение :ref:`распределенных подзапросов <distributed-subrequests>`.
+
+ClickHouse применяет настройку в том случае, когда в подзапросах на любом уровне встретилась распределенная таблица, которая существует на локальном сервере и имеет больше одного шарда.
+
+Возможные значения:
+
+.. list-table::
+    :widths: 20 80
+    :header-rows: 1
+
+    * - Значение
+      - Поведение ClickHouse
+    * - ``deny``
+      - Генерирует исключение.
+    * - ``allow``
+      - Выполняет запрос без изменения логики.
+    * - ``global``
+      - Преобразует ``IN`` в ``GLOBAL IN``, ``JOIN`` в ``GLOBAL JOIN``.
+    * - ``local``
+      - Преобразует все вхождения Distributed-таблиц в соответствующие им удалённые таблицы.
+
+
 max_block_size
 --------------
 Данные в ClickHouse обрабатываются по блокам (наборам кусочков столбцов). Внутренние циклы обработки одного блока достаточно эффективны, но при этом существуют заметные издержки на каждый блок. ``max_block_size`` - это рекомендация, какого размера блоки (в количестве строк) загружать из таблицы. Размер блока должен быть не слишком маленьким, чтобы издержки на каждый блок оставались незаметными, и не слишком большим, чтобы запрос с LIMIT-ом, который завершается уже после первого блока, выполнялся быстро; чтобы не использовалось слишком много оперативки при вынимании большого количества столбцов в несколько потоков; чтобы оставалась хоть какая-нибудь кэш-локальность.
@@ -22,7 +46,7 @@ max_insert_block_size
 
 ``По умолчанию - 1 048 576.``
 
-Это намного больше, чем max_block_size. Это сделано, потому что некоторые движки таблиц (*MergeTree) будут на каждый вставляемый блок формировать кусок данных на диске, что является довольно большой сущностью. Также, в таблицах типа *MergeTree, данные сортируются при вставке, и достаточно большой размер блока позволяет отсортировать больше данных в оперативке.
+Это намного больше, чем ``max_block_size``. Это сделано, потому что некоторые движки таблиц (``*MergeTree``) будут на каждый вставляемый блок формировать кусок данных на диске, что является довольно большой сущностью. Также, в таблицах типа ``*MergeTree``, данные сортируются при вставке, и достаточно большой размер блока позволяет отсортировать больше данных в оперативке.
 
 max_threads
 -----------
@@ -41,14 +65,14 @@ max_threads
 Чем меньше ``max_threads``, тем меньше будет использоваться оперативки.
 
 max_compress_block_size
------------
+-----------------------
 Максимальный размер блоков не сжатых данных перед сжатием при записи в таблицу. По умолчанию - 1 048 576 (1 MiB). При уменьшении размера, незначительно уменьшается коэффициент сжатия, незначительно возрастает скорость сжатия и разжатия за счёт кэш-локальности, и уменьшается потребление оперативки. Как правило, не имеет смысла менять эту настройку.
 
 Не путайте блоки для сжатия (кусок памяти, состоящий из байт) и блоки для обработки запроса (пачка строк из таблицы).
 
 min_compress_block_size
---------------
-Для таблиц типа *MergeTree. В целях уменьшения задержек при обработке запросов, блок сжимается при записи следующей засечки, если его размер не меньше min_compress_block_size. По умолчанию - 65 536.
+-----------------------
+Для таблиц типа ``*MergeTree``. В целях уменьшения задержек при обработке запросов, блок сжимается при записи следующей засечки, если его размер не меньше min_compress_block_size. По умолчанию - 65 536.
 
 Реальный размер блока, если несжатых данных меньше max_compress_block_size, будет не меньше этого значения и не меньше объёма данных на одну засечку.
 
@@ -61,35 +85,35 @@ min_compress_block_size
 Как правило, не имеет смысла менять эту настройку.
 
 max_query_size
------------
+--------------
 Максимальный кусок запроса, который будет считан в оперативку для разбора парсером языка SQL.
 Запрос INSERT также содержит данные для INSERT-а, которые обрабатываются отдельным, потоковым парсером (расходующим O(1) оперативки), и не учитываются в этом ограничении.
 
 ``По умолчанию - 256 KiB.``
 
 interactive_delay
--------------
+-----------------
 Интервал в микросекундах для проверки, не запрошена ли остановка выполнения запроса, и отправки прогресса.
 По умолчанию - 100 000 (проверять остановку запроса и отправлять прогресс десять раз в секунду).
 
 connect_timeout
------------
+---------------
 
 receive_timeout
----------
+---------------
 
 send_timeout
----------
+------------
 Таймауты в секундах на сокет, по которому идёт общение с клиентом.
 ``По умолчанию - 10, 300, 300.``
 
 poll_interval
-----------
+-------------
 Блокироваться в цикле ожидания запроса в сервере на указанное количество секунд.
 ``По умолчанию - 10.``
 
 max_distributed_connections
-----------------
+---------------------------
 Максимальное количество одновременных соединений с удалёнными серверами при распределённой обработке одного запроса к одной таблице типа Distributed. Рекомендуется выставлять не меньше, чем количество серверов в кластере.
 
 ``По умолчанию - 100.``
@@ -97,36 +121,36 @@ max_distributed_connections
 Следующие параметры имеют значение только на момент создания таблицы типа Distributed (и при запуске сервера), поэтому их не имеет смысла менять в рантайме.
 
 distributed_connections_pool_size
--------------------
+---------------------------------
 Максимальное количество одновременных соединений с удалёнными серверами при распределённой обработке всех запросов к одной таблице типа Distributed. Рекомендуется выставлять не меньше, чем количество серверов в кластере.
 
 ``По умолчанию - 128.``
 
 connect_timeout_with_failover_ms
-----------------
+--------------------------------
 Таймаут в миллисекундах на соединение с удалённым сервером, для движка таблиц Distributed, если используются секции shard и replica в описании кластера.
 В случае неуспеха, делается несколько попыток соединений с разными репликами.
 ``По умолчанию - 50.``
 
 connections_with_failover_max_tries
-----------------
+-----------------------------------
 Максимальное количество попыток соединения с каждой репликой, для движка таблиц Distributed.
 ``По умолчанию - 3``
 
 extremes
------
+--------
 Считать ли экстремальные значения (минимумы и максимумы по столбцам результата запроса). Принимает 0 или 1. По умолчанию - 0 (выключено).
 Подробнее смотрите раздел "Экстремальные значения".
 
 use_uncompressed_cache
-----------
+----------------------
 Использовать ли кэш разжатых блоков. Принимает 0 или 1. По умолчанию - 0 (выключено).
 Кэш разжатых блоков (только для таблиц семейства MergeTree) позволяет существенно уменьшить задержки и увеличить пропускную способность при обработке большого количества коротких запросов. Включите эту настройку для пользователей, от которых идут частые короткие запросы. Также обратите внимание на конфигурационный параметр uncompressed_cache_size (настраивается только в конфигурационном файле) - размер кэша разжатых блоков. По умолчанию - 8 GiB. Кэш разжатых блоков заполняется по мере надобности; наиболее невостребованные данные автоматически удаляются.
 
 Для запросов, читающих хоть немного приличный объём данных (миллион строк и больше), кэш разжатых блоков автоматически выключается, чтобы оставить место для действительно мелких запросов. Поэтому, можно держать настройку use_uncompressed_cache всегда выставленной в 1.
 
 replace_running_query
------------
+---------------------
 При использовании HTTP-интерфейса, может быть передан параметр query_id - произвольная строка, являющаяся идентификатором запроса.
 Если в этот момент, уже существует запрос от того же пользователя с тем же query_id, то поведение определяется параметром replace_running_query.
 
@@ -137,16 +161,16 @@ replace_running_query
 Эта настройка, выставленная в 1, используется в Яндекс.Метрике для реализации suggest-а значений для условий сегментации. После ввода очередного символа, если старый запрос ещё не выполнился, его следует отменить.
 
 load_balancing
------------
+--------------
 На какие реплики (среди живых реплик) предпочитать отправлять запрос (при первой попытке) при распределённой обработке запроса.
 
 random (по умолчанию)
-~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~
 Для каждой реплики считается количество ошибок. Запрос отправляется на реплику с минимальным числом ошибок, а если таких несколько, то на случайную из них.
 Недостатки: не учитывается близость серверов; если на репликах оказались разные данные, то вы будете получать так же разные данные.
 
 nearest_hostname
-~~~~~~~~~
+~~~~~~~~~~~~~~~~
 Для каждой реплики считается количество ошибок. Каждые 5 минут, число ошибок целочисленно делится на 2 - таким образом, обеспечивается расчёт числа ошибок за недавнее время с экспоненциальным сглаживанием. Если есть одна реплика с минимальным числом ошибок (то есть, на других репликах недавно были ошибки) - запрос отправляется на неё. Если есть несколько реплик с одинаковым минимальным числом ошибок, то запрос отправляется на реплику, имя хоста которой в конфигурационном файле минимально отличается от имени хоста сервера (по количеству отличающихся символов на одинаковых позициях, до минимальной длины обеих имён хостов).
 
 Для примера, example01-01-1 и example01-01-2.yandex.ru отличаются в одной позиции, а example01-01-1 и example01-02-2 - в двух.
@@ -156,7 +180,7 @@ nearest_hostname
 Также можно сделать предположение, что при отправке запроса на один и тот же сервер, в случае отсутствия сбоев, распределённый запрос будет идти тоже на одни и те же серверы. То есть, даже если на репликах расположены разные данные, запрос будет возвращать в основном одинаковые результаты.
 
 in_order
-~~~~~~~
+~~~~~~~~
 Реплики перебираются в таком порядке, в каком они указаны. Количество ошибок не имеет значения.
 Этот способ подходит для тех случаев, когда вы точно знаете, какая реплика предпочтительнее.
 
@@ -166,19 +190,19 @@ totals_mode
 Смотрите раздел "Модификатор WITH TOTALS".
 
 totals_auto_threshold
---------------
+---------------------
 Порог для ``totals_mode = 'auto'``.
 Смотрите раздел "Модификатор WITH TOTALS".
 
 default_sample
-----------
+--------------
 Число с плавающей запятой от 0 до 1. По умолчанию - 1.
 Позволяет выставить коэффициент сэмплирования по умолчанию для всех запросов SELECT.
 (Для таблиц, не поддерживающих сэмплирование, будет кидаться исключение.)
 Если равно 1 - сэмплирование по умолчанию не делается.
 
 max_parallel_replicas
----------------
+---------------------
 Максимальное количество используемых реплик каждого шарда при выполнении запроса.
 Для консистентности (чтобы получить разные части одного и того же разбиения), эта опция работает только при заданном ключе сэмплирования.
 Отставание реплик не контролируется.
@@ -191,7 +215,7 @@ compile
 В случае, если эта часть конвейера была скомпилирована, запрос может работать быстрее, за счёт разворачивания коротких циклов и инлайнинга вызовов агрегатных функций. Максимальный прирост производительности (до четырёх раз в редких случаях) достигается на запросах с несколькими простыми агрегатными функциями. Как правило, прирост производительности незначителен. В очень редких случаях возможно замедление выполнения запроса.
 
 min_count_to_compile
----------------
+--------------------
 После скольких раз, когда скомпилированный кусок кода мог пригодиться, выполнить его компиляцию. По умолчанию - 3.
 В случае, если значение равно нулю, то компиляция выполняется синхронно, и запрос будет ждать окончания процесса компиляции перед продолжением выполнения. Это можно использовать для тестирования, иначе используйте значения, начиная с 1. Как правило, компиляция занимает по времени около 5-10 секунд.
 В случае, если значение равно 1 или больше, компиляция выполняется асинхронно, в отдельном потоке. При готовности результата, он сразу же будет использован, в том числе, уже выполняющимися в данный момент запросами.
@@ -200,10 +224,10 @@ min_count_to_compile
 Результаты компиляции сохраняются в директории build в виде .so файлов. Количество результатов компиляции не ограничено, так как они не занимают много места. При перезапуске сервера, старые результаты будут использованы, за исключением случая обновления сервера - тогда старые результаты удаляются.
 
 input_format_skip_unknown_fields
-----------------
+--------------------------------
 Если значение истинно, то при выполнении INSERT из входных данных пропускаются (не рассматриваются) колонки с неизвестными именами, иначе в данной ситуации будет сгенерировано исключение.
 Работает для форматов JSONEachRow и TSKV.
 
 output_format_json_quote_64bit_integers
------------------
+---------------------------------------
 Если значение истинно, то при использовании JSON* форматов UInt64 и Int64 числа выводятся в кавычках (из соображений совместимости с большинством реализаций JavaScript), иначе - без кавычек.

From 4490735db7bac6b2eed9c377fa89260fd9f4888f Mon Sep 17 00:00:00 2001
From: BayoNet <bayonet@virtUbuntu16.04>
Date: Fri, 28 Apr 2017 19:23:50 +0300
Subject: [PATCH 3/6] Cross-link for distributed_product_mode wad added

---
 docs/ru/query_language/queries.rst | 5 +++--
 docs/ru/settings/settings.rst      | 4 +++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/docs/ru/query_language/queries.rst b/docs/ru/query_language/queries.rst
index b4ac2e78d48..6a143c6bec8 100644
--- a/docs/ru/query_language/queries.rst
+++ b/docs/ru/query_language/queries.rst
@@ -1291,14 +1291,15 @@ n и m должны быть неотрицательными целыми чи
 Подзапрос в секции IN на одном сервере всегда выполняется только один раз. Зависимых подзапросов не существует.
 
 
-.. _distributed-subrequests:
+.. _queries-distributed-subrequests:
 
 Распределённые подзапросы
 """""""""""""""""""""""""
 
 Существует два варианта IN-ов с подзапросами (аналогично для JOIN-ов): обычный ``IN`` / ``JOIN`` и ``GLOBAL IN`` / ``GLOBAL JOIN``. Они отличаются способом выполнения при распределённой обработке запроса.
 
-.. attention:: Помните, что алгоритмы, описанные ниже, могут работать иначе в зависимости от настройки ``distributed_product_mode``.
+.. attention::
+    Помните, что алгоритмы, описанные ниже, могут работать иначе в зависимости от :ref:`настройки <settings-distributed_product_mode>` ``distributed_product_mode``.
 
 При использовании обычного IN-а, запрос отправляется на удалённые серверы, и на каждом из них выполняются подзапросы в секциях ``IN`` / ``JOIN``.
 
diff --git a/docs/ru/settings/settings.rst b/docs/ru/settings/settings.rst
index e5d7d1e726a..83173543234 100644
--- a/docs/ru/settings/settings.rst
+++ b/docs/ru/settings/settings.rst
@@ -1,6 +1,8 @@
+.. _settings-distributed_product_mode:
+
 distributed_product_mode
 ------------------------
-Изменяет поведение :ref:`распределенных подзапросов <distributed-subrequests>`.
+Изменяет поведение :ref:`распределенных подзапросов <queries-distributed-subrequests>`.
 
 ClickHouse применяет настройку в том случае, когда в подзапросах на любом уровне встретилась распределенная таблица, которая существует на локальном сервере и имеет больше одного шарда.
 

From edffa02b49ed774309552cd19f6e8e43e4abbcba Mon Sep 17 00:00:00 2001
From: BayoNet <bayonet@virtUbuntu16.04>
Date: Fri, 5 May 2017 11:15:30 +0300
Subject: [PATCH 4/6] Description of <allow_databes> was improved. Description
 of distributed_product_mode was improved. Some decorative edits was made.

---
 docs/ru/access_rights.rst             |  8 ++-
 docs/ru/settings/query_complexity.rst | 70 ++++++++++++++-------------
 docs/ru/settings/settings.rst         | 12 ++++-
 docs/ru/table_functions/remote.rst    | 68 +++++++++++++-------------
 4 files changed, 87 insertions(+), 71 deletions(-)

diff --git a/docs/ru/access_rights.rst b/docs/ru/access_rights.rst
index 7ee17b486ae..4078b357252 100644
--- a/docs/ru/access_rights.rst
+++ b/docs/ru/access_rights.rst
@@ -88,4 +88,10 @@
 
 Затем указывается используемая квота (смотрите раздел "Квоты"). Вы можете указать квоту по умолчанию - ``default``. Она настроена в конфиге по умолчанию так, что только считает использование ресурсов, но никак их не ограничивает. Квота может называться как угодно; одна и та же квота может быть указана для разных пользователей - в этом случае, подсчёт использования ресурсов делается для каждого пользователя по отдельности.
 
-Также в необязательном разделе ``<allow_databases>`` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию.
+Также в необязательном разделе ``<allow_databases>`` можно указать перечень баз, к которым у пользователя будет доступ. По умолчанию пользователю доступны все базы. Можно указать базу данных ``default``, в этом случае пользователь получит доступ к базе данных по умолчанию. 
+
+Доступ к БД ``system`` всегда считается разрешённым (так как эта БД используется для выполнения запросов).
+
+Пользователь может получить список всех БД и таблиц в них с помощью запросов ``SHOW`` или системных таблиц, даже если у него нет доступа к отдельным ДБ.
+
+Доступ к БД не связан с настройкой :ref:`query_complexity_readonly`. Невозможно дать полный доступ к одной БД и ``readonly`` к другой.
diff --git a/docs/ru/settings/query_complexity.rst b/docs/ru/settings/query_complexity.rst
index 48c2adb1e37..3f49a680e73 100644
--- a/docs/ru/settings/query_complexity.rst
+++ b/docs/ru/settings/query_complexity.rst
@@ -1,5 +1,5 @@
 Ограничения на сложность запроса
-=====================
+================================
 Ограничения на сложность запроса - часть настроек.
 Используются, чтобы обеспечить более безопасное исполнение запросов из пользовательского интерфейса.
 Почти все ограничения действуют только на SELECT-ы.
@@ -15,8 +15,10 @@
 
 ``any (только для group_by_overflow_mode)`` - продолжить агрегацию по ключам, которые успели войти в набор, но не добавлять новые ключи в набор.
 
+.. _query_complexity_readonly:
+
 readonly
--------
+--------
 При значении 0 можно выполнять любые запросы.
 При значении 1 можно выполнять только запросы на чтение (например, SELECT и SHOW). Запросы на запись и изменение настроек (INSERT, SET) запрещены.
 При значении 2 можно выполнять запросы на чтение (SELECT, SHOW) и изменение настроек (SET).
@@ -26,7 +28,7 @@ readonly
 При использовании метода GET HTTP интерфейса, автоматически выставляется readonly = 1. То есть, для запросов, модифицирующие данные, можно использовать только метод POST. Сам запрос при этом можно отправлять как в теле POST-а, так и в параметре URL.
 
 max_memory_usage
---------------
+----------------
 Максимальное количество потребляемой памяти при выполнении запроса на одном сервере. По умолчанию - 10 GB.
 
 Настройка не учитывает объём свободной памяти или общий объём памяти на машине.
@@ -41,134 +43,134 @@ max_memory_usage
 Потребление оперативки не полностью учитывается для состояний агрегатных функций min, max, any, anyLast, argMin, argMax от аргументов String и Array.
 
 max_rows_to_read
----------------
+----------------
 Следующие ограничения могут проверяться на каждый блок (а не на каждую строку). То есть, ограничения могут быть немного нарушены.
 При выполнении запроса в несколько потоков, следующие ограничения действуют в каждом потоке по-отдельности.
 
 Максимальное количество строчек, которое можно прочитать из таблицы при выполнении запроса.
 
 max_bytes_to_read
--------------
+-----------------
 Максимальное количество байт (несжатых данных), которое можно прочитать из таблицы при выполнении запроса.
 
 read_overflow_mode
--------------
+------------------
 Что делать, когда количество прочитанных данных превысило одно из ограничений: throw или break. По умолчанию: throw.
 
 max_rows_to_group_by
--------------
+--------------------
 Максимальное количество уникальных ключей, получаемых в процессе агрегации. Позволяет ограничить потребление оперативки при агрегации.
 
 group_by_overflow_mode
----------------
+----------------------
 Что делать, когда количество уникальных ключей при агрегации превысило ограничение: throw, break или any. По умолчанию: throw.
 Использование значения any позволяет выполнить GROUP BY приближённо. Качество такого приближённого вычисления сильно зависит от статистических свойств данных.
 
 max_rows_to_sort
---------------
+----------------
 Максимальное количество строк до сортировки. Позволяет ограничить потребление оперативки при сортировке.
 
 max_bytes_to_sort
--------------
+-----------------
 Максимальное количество байт до сортировки.
 
 sort_overflow_mode
-------------
+------------------
 Что делать, если количество строк, полученное перед сортировкой, превысило одно из ограничений: throw или break. По умолчанию: throw.
 
 max_result_rows
--------------
+---------------
 Ограничение на количество строк результата. Проверяются также для подзапросов и на удалённых серверах при выполнении части распределённого запроса.
 
 max_result_bytes
--------------
+----------------
 Ограничение на количество байт результата. Аналогично.
 
 result_overflow_mode
---------------
+--------------------
 Что делать, если объём результата превысил одно из ограничений: throw или break. По умолчанию: throw.
 Использование break по смыслу похоже на LIMIT.
 
 max_execution_time
---------------
+-------------------
 Максимальное время выполнения запроса в секундах.
 На данный момент не проверяется при одной из стадий сортировки а также при слиянии и финализации агрегатных функций.
 
 timeout_overflow_mode
----------------
+---------------------
 Что делать, если запрос выполняется дольше max_execution_time: throw или break. По умолчанию: throw.
 
 min_execution_speed
---------------
+-------------------
 Минимальная скорость выполнения запроса в строчках в секунду. Проверяется на каждый блок данных по истечении timeout_before_checking_execution_speed. Если скорость выполнения запроса оказывается меньше, то кидается исключение.
 
 timeout_before_checking_execution_speed
----------------
+---------------------------------------
 Проверять, что скорость выполнения запроса не слишком низкая (не меньше min_execution_speed), после прошествия указанного времени в секундах.
 
 max_columns_to_read
---------------
+-------------------
 Максимальное количество столбцов, которых можно читать из таблицы в одном запросе. Если запрос требует чтения большего количества столбцов - кинуть исключение.
 
 max_temporary_columns
-----------------
+---------------------
 Максимальное количество временных столбцов, которых необходимо одновременно держать в оперативке, в процессе выполнения запроса, включая константные столбцы. Если временных столбцов оказалось больше - кидается исключение.
 
 max_temporary_non_const_columns
----------------------
+-------------------------------
 То же самое, что и max_temporary_columns, но без учёта столбцов-констант.
 Стоит заметить, что столбцы-константы довольно часто образуются в процессе выполнения запроса, но расходуют примерно нулевое количество вычислительных ресурсов.
 
 max_subquery_depth
--------------
+------------------
 Максимальная вложенность подзапросов. Если подзапросы более глубокие - кидается исключение. По умолчанию: 100.
 
 max_pipeline_depth
------------
+------------------
 Максимальная глубина конвейера выполнения запроса. Соответствует количеству преобразований, которое проходит каждый блок данных в процессе выполнения запроса. Считается в пределах одного сервера. Если глубина конвейера больше - кидается исключение. По умолчанию: 1000.
 
 max_ast_depth
------------
+-------------
 Максимальная вложенность синтаксического дерева запроса. Если превышена - кидается исключение.
 На данный момент, проверяются не во время парсинга а уже после парсинга запроса. То есть, во время парсинга может быть создано слишком глубокое синтаксическое дерево, но запрос не будет выполнен. По умолчанию: 1000.
 
 max_ast_elements
------------
+----------------
 Максимальное количество элементов синтаксического дерева запроса. Если превышено - кидается исключение.
 Аналогично, проверяется уже после парсинга запроса. По умолчанию: 10 000.
 
 max_rows_in_set
-----------
+---------------
 Максимальное количество строчек для множества в секции IN, создаваемого из подзапроса.
 
 max_bytes_in_set
------------
+----------------
 Максимальное количество байт (несжатых данных), занимаемое множеством в секции IN, создаваемым из подзапроса.
 
 set_overflow_mode
------------
+-----------------
 Что делать, когда количество данных превысило одно из ограничений: throw или break. По умолчанию: throw.
 
 max_rows_in_distinct
------------
+--------------------
 Максимальное количество различных строчек при использовании DISTINCT.
 
 max_bytes_in_distinct
---------------
+---------------------
 Максимальное количество байт, занимаемых хэш-таблицей, при использовании DISTINCT.
 
 distinct_overflow_mode
-------------
+----------------------
 Что делать, когда количество данных превысило одно из ограничений: throw или break. По умолчанию: throw.
 
 max_rows_to_transfer
------------
+--------------------
 Максимальное количество строчек, которых можно передать на удалённый сервер или сохранить во временную таблицу, при использовании GLOBAL IN.
 
 max_bytes_to_transfer
------------
+---------------------
 Максимальное количество байт (несжатых данных), которых можно передать на удалённый сервер или сохранить во временную таблицу, при использовании GLOBAL IN.
 
 transfer_overflow_mode
----------
+----------------------
 Что делать, когда количество данных превысило одно из ограничений: throw или break. По умолчанию: throw.
diff --git a/docs/ru/settings/settings.rst b/docs/ru/settings/settings.rst
index 83173543234..33783b54d1d 100644
--- a/docs/ru/settings/settings.rst
+++ b/docs/ru/settings/settings.rst
@@ -2,10 +2,16 @@
 
 distributed_product_mode
 ------------------------
-Изменяет поведение :ref:`распределенных подзапросов <queries-distributed-subrequests>`.
+Изменяет поведение :ref:`распределенных подзапросов <queries-distributed-subrequests>`, т.е. в тех случаях, когда запрос содержит произведение распределённых таблиц.
 
 ClickHouse применяет настройку в том случае, когда в подзапросах на любом уровне встретилась распределенная таблица, которая существует на локальном сервере и имеет больше одного шарда.
 
+Условия применения:
+
+* Только подзапросы для IN, JOIN.
+* Только если в секции FROM используется распределённая таблица.
+* Не используется в случае табличной функции :ref:`remote <table_functions-remote>`.
+
 Возможные значения:
 
 .. list-table::
@@ -14,7 +20,7 @@ ClickHouse применяет настройку в том случае, ког
 
     * - Значение
       - Поведение ClickHouse
-    * - ``deny``
+    * - ``deny`` (по умолчанию)
       - Генерирует исключение.
     * - ``allow``
       - Выполняет запрос без изменения логики.
@@ -162,6 +168,8 @@ replace_running_query
 
 Эта настройка, выставленная в 1, используется в Яндекс.Метрике для реализации suggest-а значений для условий сегментации. После ввода очередного символа, если старый запрос ещё не выполнился, его следует отменить.
 
+.. _settings-load_balancing:
+
 load_balancing
 --------------
 На какие реплики (среди живых реплик) предпочитать отправлять запрос (при первой попытке) при распределённой обработке запроса.
diff --git a/docs/ru/table_functions/remote.rst b/docs/ru/table_functions/remote.rst
index 541f418cce4..74a063caee7 100644
--- a/docs/ru/table_functions/remote.rst
+++ b/docs/ru/table_functions/remote.rst
@@ -1,62 +1,62 @@
+.. _table_functions-remote:
+
 remote
 ------
 
-``remote('addresses_expr', db, table[, 'user'[, 'password']])``
+Позволяет обратиться к удалённым серверам без создания таблицы типа ``Distributed``.
 
-или 
+Сигнатуры: ::
 
-``remote('addresses_expr', db.table[, 'user'[, 'password']])``
+    remote('addresses_expr', db, table[, 'user'[, 'password']])
+    remote('addresses_expr', db.table[, 'user'[, 'password']])
 
-- позволяет обратиться к удалённым серверам без создания таблицы типа Distributed.
 
-``addresses_expr`` - выражение, генерирующее адреса удалённых серверов.
+``addresses_expr`` - выражение, генерирующее адреса удалённых серверов. Это может быть просто один адрес сервера. Адрес сервера - это ``хост:порт``, или только ``хост``. Хост может быть указан в виде имени сервера, или в виде IPv4 или IPv6 адреса. IPv6 адрес указывается в квадратных скобках. Порт - TCP-порт удалённого сервера. Если порт не указан, используется ``tcp_port`` из конфигурационного файла сервера (по умолчанию - 9000).
 
-Это может быть просто один адрес сервера. Адрес сервера - это хост:порт, или только хост. Хост может быть указан в виде имени сервера, или в виде IPv4 или IPv6 адреса. IPv6 адрес указывается в квадратных скобках. Порт - TCP-порт удалённого сервера. Если порт не указан, используется tcp_port из конфигурационного файла сервера (по умолчанию - 9000).
+.. important:: С IPv6-адресом обязательно указывать порт.
 
-Замечание: в качестве исключения, при указании IPv6-адреса, обязательно также указывать порт.
+Примеры: ::
 
-Примеры:
-::
-  example01-01-1
-  example01-01-1:9000
-  localhost
-  127.0.0.1
-  [::]:9000
-  [2a02:6b8:0:1111::11]:9000
+    example01-01-1
+    example01-01-1:9000
+    localhost
+    127.0.0.1
+    [::]:9000
+    [2a02:6b8:0:1111::11]:9000
 
-Могут быть указаны адреса через запятую - в этом случае, запрос пойдёт на все указанные адреса (как на шарды с разными данными) и будет обработан распределённо.
+Адреса можно указать через запятую, в этом случае ClickHouse обработает запрос как распределённый, т.е. отправит его по всем указанным адресам как на шарды с разными данными.
 
-Пример:
-::
-  example01-01-1,example01-02-1
+Пример: ::
 
-Часть выражения может быть указана в фигурных скобках. Предыдущий пример может быть записан следующим образом:
-::
-  example01-0{1,2}-1
+    example01-01-1,example01-02-1
 
-В фигурных скобках может быть указан диапазон (неотрицательных целых) чисел через две точки. В этом случае, диапазон раскрывается в множество значений, генерирующих адреса шардов. Если запись первого числа начинается с нуля, то значения формируются с таким же выравниванием нулями. Предыдущий пример может быть записан следующим образом:
-::
-  example01-{01..02}-1
+Часть выражения может быть указана в фигурных скобках. Предыдущий пример может быть записан следующим образом: ::
+
+    example01-0{1,2}-1
+
+В фигурных скобках может быть указан диапазон (неотрицательных целых) чисел через две точки. В этом случае, диапазон раскрывается в множество значений, генерирующих адреса шардов. Если запись первого числа начинается с нуля, то значения формируются с таким же выравниванием нулями. Предыдущий пример может быть записан следующим образом: ::
+
+    example01-{01..02}-1
 
 При наличии нескольких пар фигурных скобок, генерируется прямое произведение соответствующих множеств.
 
-Адреса или их фрагменты в фигурных скобках, могут быть указаны через символ |. В этом случае, соответствующие множества адресов понимаются как реплики - запрос будет отправлен на первую живую реплику. При этом, реплики перебираются в порядке, согласно текущей настройке load_balancing. 
+Адреса или их фрагменты в фигурных скобках можно указать через символ \|. В этом случае, соответствующие множества адресов понимаются как реплики - запрос будет отправлен на первую живую реплику. При этом, реплики перебираются в порядке, согласно текущей настройке :ref:`load_balancing <settings-load_balancing>`. 
 
-Пример:
-::
-  example01-{01..02}-{1|2}
+Пример: ::
+
+    example01-{01..02}-{1|2}
 
 В этом примере указано два шарда, в каждом из которых имеется две реплики.
 
-Количество генерируемых адресов ограничено некоторой константой - сейчас это 1000 штук.
+Количество генерируемых адресов ограничено константой - сейчас это 1000 штук.
 
-Использование табличной функции remote менее оптимально, чем создание таблицы типа Distributed, так как в этом случае, соединения с серверами устанавливаются заново при каждом запросе, в случае задания имён хостов, делается резолвинг имён, а также не ведётся подсчёт ошибок при работе с разными репликами. При обработке большого количества запросов, всегда создавайте Distributed таблицу заранее, не используйте табличную функцию remote.
+Использование табличной функции ``remote`` менее оптимально, чем создание таблицы типа ``Distributed``, так как в этом случае, соединения с серверами устанавливаются заново при каждом запросе, в случае задания имён хостов, делается резолвинг имён, а также не ведётся подсчёт ошибок при работе с разными репликами. При обработке большого количества запросов, всегда создавайте ``Distributed`` таблицу заранее, не используйте табличную функцию ``remote``.
 
-Табличная функция remote может быть полезна для следующих случаев:
+Табличная функция ``remote`` может быть полезна для следующих случаях:
  * обращение на конкретный сервер в целях сравнения данных, отладки и тестирования;
  * запросы между разными кластерами ClickHouse в целях исследований;
  * нечастых распределённых запросов, задаваемых вручную;
  * распределённых запросов, где набор серверов определяется каждый раз заново.
 
-Имя пользователя может быть не задано - тогда используется имя пользователя 'default'.
-Пароль может быть не задан - тогда используется пустой пароль.
+Если пользователь не задан,то используется ``default``.
+Если пароль не задан, то используется пустой пароль.

From e480557d00238cb56e27ad3c6b5a168cae929688 Mon Sep 17 00:00:00 2001
From: BayoNet <bayonet@virtUbuntu16.04>
Date: Fri, 5 May 2017 14:49:02 +0300
Subject: [PATCH 5/6] Descriptions of `source/source_type/where` and
 `structure/attribute/expression` are added.

---
 docs/ru/dicts/external_dicts.rst | 49 ++++++++++++++++++++++++--------
 1 file changed, 37 insertions(+), 12 deletions(-)

diff --git a/docs/ru/dicts/external_dicts.rst b/docs/ru/dicts/external_dicts.rst
index 70df8850eec..870e1901b31 100644
--- a/docs/ru/dicts/external_dicts.rst
+++ b/docs/ru/dicts/external_dicts.rst
@@ -6,7 +6,7 @@
 Словарь может полностью храниться в оперативке и периодически обновляться, или быть частично закэшированным в оперативке и динамически подгружать отсутствующие значения.
 
 Конфигурация внешних словарей находится в отдельном файле или файлах, указанных в конфигурационном параметре dictionaries_config.
-Этот параметр содержит абсолютный или относительный путь к файлу с конфигурацией словарей. Относительный путь - относительно директории с конфигурационным файлом сервера. Путь может содержать wildcard-ы * и ? - тогда рассматриваются все подходящие файлы. Пример: dictionaries/*.xml.
+Этот параметр содержит абсолютный или относительный путь к файлу с конфигурацией словарей. Относительный путь - относительно директории с конфигурационным файлом сервера. Путь может содержать wildcard-ы \* и ? - тогда рассматриваются все подходящие файлы. Пример: dictionaries/\*.xml.
 
 Конфигурация словарей, а также множество файлов с конфигурацией, может обновляться без перезапуска сервера. Сервер проверяет обновления каждые 5 секунд. То есть, словари могут подключаться динамически.
 
@@ -68,6 +68,18 @@
                     Для отказоустойчивости, вы можете создать Distributed таблицу на localhost и прописать её. - ->
               -->
   
+              <!-- Для <mysql> и <clickhouse> доступен атрибут <where>, позволяющий задать условие выбора
+              <clickhouse>
+                  <host>example01-01-1</host>
+                  <port>9000</port>
+                  <user>default</user>
+                  <password></password>
+                  <db>default</db>
+                  <table>ids</table>
+                  <where>id=10</where>
+              </clickhouse>
+              -->
+
               <!-- или источник - исполняемый файл. Если layout.cache - список нужных ключей будет записан в поток STDIN программы -->
               <executable>
                   <!-- Путь или имя программы (если директория есть в переменной окружения PATH) и параметры -->
@@ -139,6 +151,14 @@
                   <!-- Можно считать отображение id -> attribute инъективным, чтобы оптимизировать GROUP BY. (по умолчанию, false) -->
                   <injective>true</injective>
               </attribute>
+
+              <!-- Атрибут может быть выражением -->
+              <attribute>
+                  <name>expr</name>
+                  <type>UInt64</type>
+                  <expression>rand64()</expression>
+                  <null_value>0</null_value>
+              </attribute>
           </structure>
       </dictionary>
   </dictionaries>
@@ -164,18 +184,23 @@ cache
 Наименее эффективный способ. Подходит, если словарь не помещается в оперативку. Представляет собой кэш из фиксированного количества ячеек, в которых могут быть расположены часто используемые данные. Поддерживается источник MySQL, ClickHouse, executable, http; источник-файл не поддерживается. При поиске в словаре, сначала просматривается кэш. На каждый блок данных, все не найденные в кэше ключи (или устаревшие ключи) собираются в пачку, и с этой пачкой делается запрос к источнику вида SELECT attrs... FROM db.table WHERE id IN (k1, k2, ...). Затем полученные данные записываются в кэш.
 
 range_hashed
---------
+------------
 В таблице прописаны какие-то данные для диапазонов дат, для каждого ключа. Дать возможность доставать эти данные для заданного ключа, для заданной даты.
 
-Пример: в таблице записаны скидки для каждого рекламодателя в виде:
-::
-  id рекламодателя    дата начала действия скидки    дата конца    величина
-  123                 2015-01-01                     2015-01-15    0.15
-  123                 2015-01-16                     2015-01-31    0.25
-  456                 2015-01-01                     2015-01-15    0.05
+Пример: таблица содержит скидки для каждого рекламодателя в виде:
 
-Добавляем layout = range_hashed.
-При использовании такого layout, в structure должны быть элементы range_min, range_max.
+  +------------------+-----------------------------+------------+----------+
+  | id рекламодателя | дата начала действия скидки | дата конца | величина |
+  +==================+=============================+============+==========+
+  | 123              | 2015-01-01                  | 2015-01-15 | 0.15     |
+  +------------------+-----------------------------+------------+----------+
+  | 123              | 2015-01-16                  | 2015-01-31 | 0.25     |
+  +------------------+-----------------------------+------------+----------+
+  | 456              | 2015-01-01                  | 2015-01-15 | 0.05     |
+  +------------------+-----------------------------+------------+----------+
+
+Добавляем ``layout = range_hashed``.
+При использовании такого layout, в structure должны быть элементы ``range_min``, ``range_max``.
 
 Пример:
 
@@ -255,12 +280,12 @@ range_hashed
   </dictionaries>
 
 complex_key_hashed
-----------------
+------------------
 
 Для использования с составными ключами. Аналогичен hashed.
 
 complex_key_cache
-----------
+-----------------
 
 Для использования с составными ключами. Аналогичен cache.
 

From ffaf8c167b4a8f6ccc94930f1053c20c614341f8 Mon Sep 17 00:00:00 2001
From: BayoNet <bayonet@virtUbuntu16.04>
Date: Tue, 16 May 2017 15:30:31 +0300
Subject: [PATCH 6/6] Lagging replicas processing is described. Desctiption of
 settings application is actualized.

---
 docs/ru/introduction/distinctive_features.rst | 20 +++++++-------
 docs/ru/settings/index.rst                    | 17 +++++++++++-
 docs/ru/settings/settings.rst                 | 26 +++++++++++++++++++
 docs/ru/table_engines/replication.rst         | 12 +++++----
 4 files changed, 59 insertions(+), 16 deletions(-)

diff --git a/docs/ru/introduction/distinctive_features.rst b/docs/ru/introduction/distinctive_features.rst
index 55e2eaca1d9..5636b6688b4 100644
--- a/docs/ru/introduction/distinctive_features.rst
+++ b/docs/ru/introduction/distinctive_features.rst
@@ -1,5 +1,5 @@
 Отличительные возможности ClickHouse
-===================================
+====================================
 
 1. По-настоящему столбцовая СУБД.
 ---------------------------------
@@ -22,12 +22,12 @@
 Большие запросы естественным образом распараллеливаются.
 
 5. Распределённая обработка запроса на многих серверах.
------------------------------------------------
+-------------------------------------------------------
 Почти все перечисленные ранее столбцовые СУБД не поддерживают распределённую обработку запроса.
 В ClickHouse данные могут быть расположены на разных шардах. Каждый шард может представлять собой группу реплик, которые используются для отказоустойчивости. Запрос будет выполнен на всех шардах параллельно. Это делается прозрачно для пользователя.
 
 6. Поддержка SQL.
----------------
+-----------------
 Если вы знаете, что такое стандартный SQL, то говорить о поддержке SQL всё-таки нельзя.
 Не поддерживаются NULL-ы. Все функции названы по-другому.
 Тем не менее, это - декларативный язык запросов на основе SQL и во многих случаях не отличимый от SQL.
@@ -35,29 +35,29 @@
 Зависимые подзапросы не поддерживаются.
 
 7. Векторный движок.
------------------
+--------------------
 Данные не только хранятся по столбцам, но и обрабатываются по векторам - кусочкам столбцов. За счёт этого достигается высокая эффективность по CPU.
 
 8. Обновление данных в реальном времени.
------------------------
+----------------------------------------
 ClickHouse поддерживает таблицы с первичным ключом. Для того, чтобы можно было быстро выполнять запросы по диапазону первичного ключа, данные инкрементально сортируются с помощью merge дерева. За счёт этого, поддерживается постоянное добавление данных в таблицу. Блокировки при добавлении данных отсутствуют.
 
 9. Наличие индексов.
------------------
+--------------------
 Наличие первичного ключа позволяет, например, вынимать данные для конкретных клиентов (счётчиков Метрики), для заданного диапазона времени, с низкими задержками - менее десятков миллисекунд.
 
 10. Подходит для онлайн запросов.
-------------------
+---------------------------------
 Это позволяет использовать систему в качестве бэкенда для веб-интерфейса. Низкие задержки позволяют не откладывать выполнение запроса, а выполнять его в момент загрузки страницы интерфейса Яндекс.Метрики. То есть, в режиме онлайн.
 
 11. Поддержка приближённых вычислений.
------------------
+--------------------------------------
 
 #. Система содержит агрегатные функции для приближённого вычисления количества различных значений, медианы и квантилей.
 #. Поддерживается возможность выполнить запрос на основе части (выборки) данных и получить приближённый результат. При этом, с диска будет считано пропорционально меньше данных.
 #. Поддерживается возможность выполнить агрегацию не для всех ключей, а для ограниченного количества первых попавшихся ключей. При выполнении некоторых условий на распределение ключей в данных, это позволяет получить достаточно точный результат с использованием меньшего количества ресурсов.
 
 14. Репликация данных, поддержка целостности данных на репликах.
------------------
+----------------------------------------------------------------
 Используется асинхронная multimaster репликация. После записи на любую доступную реплику, данные распространяются на все остальные реплики. Система поддерживает полную идентичность данных на разных репликах. Восстановление после сбоя осуществляется автоматически, а в сложных случаях - "по кнопке".
-Подробнее смотрите раздел "Репликация данных".
+Подробнее смотрите раздел :ref:`table_engines-replication`.
diff --git a/docs/ru/settings/index.rst b/docs/ru/settings/index.rst
index 65b8816fc38..aa51d89e264 100644
--- a/docs/ru/settings/index.rst
+++ b/docs/ru/settings/index.rst
@@ -1,7 +1,22 @@
 Настройки
 ==========
 
-Здесь будут рассмотрены настройки, которые можно задать с помощью запроса SET или в конфигурационном файле. Напомню, что эти настройки могут быть выставлены в пределах сессии или глобально. Настройки, которые можно задать только в конфигурационном файле сервера, здесь рассмотрены не будут.
+Описанные в разделе настройки могут быть заданы следующими способами:
+* Глобально.
+  
+  В конфигурационных файлах сервера.
+
+* Для сессии.
+  
+  При запуске консольного клиента ClickHouse в интерактивном режиме отправьте запрос ``SET setting=value``.
+
+* Для запроса.
+  
+  * При запуске консольного клиента ClickHouse в неинтерактивном режиме установите параметр запуска ``--setting=value``.
+  * При использовании HTTP API передавайте cgi-параметры (``URL?setting_1=value&setting_2=value...``).
+
+
+Настройки, которые можно задать только в конфигурационном файле сервера, в разделе не рассматриваются.
 
 .. toctree::
     :glob:
diff --git a/docs/ru/settings/settings.rst b/docs/ru/settings/settings.rst
index 33783b54d1d..abb7a7c237b 100644
--- a/docs/ru/settings/settings.rst
+++ b/docs/ru/settings/settings.rst
@@ -30,6 +30,18 @@ ClickHouse применяет настройку в том случае, ког
       - Преобразует все вхождения Distributed-таблиц в соответствующие им удалённые таблицы.
 
 
+.. _settings-settings-fallback_to_stale_replicas_for_distributed_queries:
+
+fallback_to_stale_replicas_for_distributed_queries
+--------------------------------------------------
+Форсирует запрос в устаревшую реплику в случае, если актуальные данные недоступны.  Смотрите :ref:`table_engines-replication`.
+
+Из устаревших реплик таблицы ClickHouse выбирает наиболее актуальную.
+
+Используется при выполнении ``SELECT`` из распределенной таблицы, которая указывает на реплицированные таблицы.
+
+По умолчанию - 1 (включена).
+
 max_block_size
 --------------
 Данные в ClickHouse обрабатываются по блокам (наборам кусочков столбцов). Внутренние циклы обработки одного блока достаточно эффективны, но при этом существуют заметные издержки на каждый блок. ``max_block_size`` - это рекомендация, какого размера блоки (в количестве строк) загружать из таблицы. Размер блока должен быть не слишком маленьким, чтобы издержки на каждый блок оставались незаметными, и не слишком большим, чтобы запрос с LIMIT-ом, который завершается уже после первого блока, выполнялся быстро; чтобы не использовалось слишком много оперативки при вынимании большого количества столбцов в несколько потоков; чтобы оставалась хоть какая-нибудь кэш-локальность.
@@ -56,6 +68,20 @@ max_insert_block_size
 
 Это намного больше, чем ``max_block_size``. Это сделано, потому что некоторые движки таблиц (``*MergeTree``) будут на каждый вставляемый блок формировать кусок данных на диске, что является довольно большой сущностью. Также, в таблицах типа ``*MergeTree``, данные сортируются при вставке, и достаточно большой размер блока позволяет отсортировать больше данных в оперативке.
 
+
+.. _settings_settings_max_replica_delay_for_distributed_queries:
+
+max_replica_delay_for_distributed_queries 
+------------------------------------------
+Отключает отстающие реплики при распределенных запросах. Смотрите :ref:`table_engines-replication`.
+
+Устанавливает время в секундах. Если оставание реплики больше установленного значения, то реплика не используется.
+
+Значение по умолчанию: 0 (отключено).
+
+Используется при выполнении ``SELECT`` из распределенной таблицы, которая указывает на реплицированные таблицы.
+
+
 max_threads
 -----------
 Максимальное количество потоков обработки запроса
diff --git a/docs/ru/table_engines/replication.rst b/docs/ru/table_engines/replication.rst
index c834bf3f351..58fd0bc0e0a 100644
--- a/docs/ru/table_engines/replication.rst
+++ b/docs/ru/table_engines/replication.rst
@@ -1,3 +1,5 @@
+.. _table_engines-replication:
+
 Репликация данных
 -----------------
 
@@ -45,7 +47,7 @@ ReplicatedSummingMergeTree
 
 Если в конфигурационном файле не настроен ZooKeeper, то вы не сможете создать реплицируемые таблицы, а уже имеющиеся реплицируемые таблицы будут доступны в режиме только на чтение.
 
-При запросах SELECT, ZooKeeper не используется. То есть, репликация никак не влияет на производительность SELECT-ов - запросы работают так же быстро, как и для нереплицируемых таблиц.
+При запросах SELECT, ZooKeeper не используется. То есть, репликация никак не влияет на производительность SELECT-ов - запросы работают так же быстро, как и для нереплицируемых таблиц. При запросах к распределенным реплицированным таблицам поведение ClickHouse регулируется настройками :ref:`settings_settings_max_replica_delay_for_distributed_queries` и :ref:`settings-settings-fallback_to_stale_replicas_for_distributed_queries`.
 
 При каждом запросе INSERT (точнее, на каждый вставляемый блок данных; запрос INSERT содержит один блок, или по блоку на каждые max_insert_block_size = 1048576 строк), делается около десятка записей в ZooKeeper в рамках нескольких транзакций. Это приводит к некоторому увеличению задержек при INSERT-е, по сравнению с нереплицируемыми таблицами. Но если придерживаться обычных рекомендаций - вставлять данные пачками не более одного INSERT-а в секунду, то это не составляет проблем. На всём кластере ClickHouse, использующим для координации один кластер ZooKeeper, может быть в совокупности несколько сотен INSERT-ов в секунду. Пропускная способность при вставке данных (количество строчек в секунду) такая же высокая, как для нереплицируемых таблиц.
 
@@ -72,8 +74,8 @@ ReplicatedSummingMergeTree
 
 Также добавляются два параметра в начало списка параметров - путь к таблице в ZooKeeper, имя реплики в ZooKeeper.
 
-Пример:
-::
+Пример: ::
+
   ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/hits', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192)
 
 Как видно в примере, эти параметры могут содержать подстановки в фигурных скобках. Подставляемые значения достаются из конфигурационного файла, из секции macros. Пример:
@@ -122,8 +124,8 @@ ReplicatedSummingMergeTree
 
 Если обнаруживается, что локальный набор данных слишком сильно отличается от ожидаемого, то срабатывает защитный механизм - сервер сообщает об этом в лог и отказывается запускаться. Это сделано, так как такой случай может свидетельствовать об ошибке конфигурации - например, если реплика одного шарда была случайно сконфигурирована, как реплика другого шарда. Тем не менее, пороги защитного механизма поставлены довольно низкими, и такая ситуация может возникнуть и при обычном восстановлении после сбоя. В этом случае, восстановление делается полуавтоматически - "по кнопке".
 
-Для запуска восстановления, создайте в ZooKeeper узел ``/path_to_table/replica_name/flags/force_restore_data`` с любым содержимым или выполните команду для восстановления всех реплицируемых таблиц:
-::
+Для запуска восстановления, создайте в ZooKeeper узел ``/path_to_table/replica_name/flags/force_restore_data`` с любым содержимым или выполните команду для восстановления всех реплицируемых таблиц: ::
+
   sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data
 
 Затем запустите сервер. При старте, сервер удалит эти флаги и запустит восстановление.