Removed server setting belongs to resharding.

Some links are fixed.

docs/ru/formats/capnproto.md

-<a name="format_capnproto"></a>
-
-# CapnProto
-
-Cap'n Proto - формат бинарных сообщений, похож на Protocol Buffers и Thrift, но не похож на JSON или MessagePack.
-
-Сообщения Cap'n Proto строго типизированы и не самоописывающиеся, т.е. нуждаются во внешнем описании схемы. Схема применяется "на лету" и кешируется для каждого запроса.
-
-```sql
-SELECT SearchPhrase, count() AS c FROM test.hits
-       GROUP BY SearchPhrase FORMAT CapnProto SETTINGS schema = 'schema:Message'
-```
-
-Где `schema.capnp` выглядит следующим образом:
-
-```
-struct Message {
-  SearchPhrase @0 :Text;
-  c @1 :Uint64;
-}
-```
-
-
-Файлы со схемами находятся в файле, который находится в каталоге указанном в параметре [format_schema_path](../operations/server_settings/settings.md#server_settings-format_schema_path) конфигурации сервера.
-
-Десериализация эффективна и обычно не повышает нагрузку на систему.
+<a name="format_capnproto"></a>
+
+# CapnProto
+
+Cap'n Proto - формат бинарных сообщений, похож на Protocol Buffers и Thrift, но не похож на JSON или MessagePack.
+
+Сообщения Cap'n Proto строго типизированы и не самоописывающиеся, т.е. нуждаются во внешнем описании схемы. Схема применяется "на лету" и кешируется для каждого запроса.
+
+```sql
+SELECT SearchPhrase, count() AS c FROM test.hits
+       GROUP BY SearchPhrase FORMAT CapnProto SETTINGS schema = 'schema:Message'
+```
+
+Где `schema.capnp` выглядит следующим образом:
+
+```
+struct Message {
+  SearchPhrase @0 :Text;
+  c @1 :Uint64;
+}
+```
+
+
+Файлы со схемами находятся в файле, который находится в каталоге указанном в параметре [format_schema_path](../operations/server_settings/settings.md#server_settings-format_schema_path) конфигурации сервера.
+
+Десериализация эффективна и обычно не повышает нагрузку на систему.

docs/ru/operations/access_rights.md

@@ -61,7 +61,7 @@
 
 Здесь видно объявление двух пользователей - `default` и `web`. Пользователя `web` мы добавили самостоятельно.
 
-Пользователь `default` выбирается в случаях, когда имя пользователя не передаётся. Также пользователь `default` может использоваться при распределённой обработке запроса - если в конфигурации кластера для сервера не указаны `user` и `password`. (см. раздел о движке [Distributed](../table_engines/distributed.html)).
+Пользователь `default` выбирается в случаях, когда имя пользователя не передаётся. Также пользователь `default` может использоваться при распределённой обработке запроса - если в конфигурации кластера для сервера не указаны `user` и `password`. (см. раздел о движке [Distributed](../table_engines/distributed.md#table_engines-distributed)).
 
 Пользователь, который используется для обмена информацией между серверами, объединенными в кластер, не должен иметь существенных ограничений или квот - иначе распределённые запросы сломаются.
 

docs/ru/operations/server_settings/settings.md

@@ -67,7 +67,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
 
 База данных по умолчанию.
 
-Перечень баз данных можно получить запросом [SHOW DATABASES](../query_language/queries.md#query_language_queries_show_databases).
+Перечень баз данных можно получить запросом [SHOW DATABASES](../../query_language/queries.md#query_language_queries_show_databases).
 
 **Пример**
 
@@ -593,22 +593,6 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
 
 Значение атрибута `incl` смотрите в разделе "[Конфигурационные файлы](../configuration_files.md#configuration_files)".
 
-<a name="server_settings-resharding"></a>
-
-## resharding
-
-Путь в ZooKeeper к очереди задач.
-
-Подробнее читайте в разделе "[Перешардирование](../../table_engines/resharding.md#table_engines-resharding)".
-
-**Пример**
-
-```xml
-<resharding>
-    <task_queue_path>/clickhouse/task_queue</task_queue_path>
-</resharding>
-```
-
 <a name="server_settings-timezone"></a>
 
 ## timezone

docs/ru/operations/settings/settings.md

@@ -101,7 +101,7 @@ ClickHouse применяет настройку в том случае, ког
 
 Установка логгирования запроса.
 
-Запросы, переданные в ClickHouse с этой установкой, логгируются согласно правилам конфигурационного параметра сервера [query_log](../server_setings/settings.md#server_settings-query_log).
+Запросы, переданные в ClickHouse с этой установкой, логгируются согласно правилам конфигурационного параметра сервера [query_log](../server_settings/settings.md#server_settings-query_log).
 
 **Пример** :
 

docs/ru/table_engines/kafka.md

-# Kafka
-
-Движок работает с [Apache Kafka](http://kafka.apache.org/). 
-
-Kafka позволяет:
-
-- Публиковать/подписываться на потоки данных.
-- Организовать отказо-устойчивое хранилище.
-- Обрабатывать потоки по мере их появления.
-
-```
-Kafka(broker_list, topic_list, group_name, format[, schema])
-```
-
-Параметры:
-- `broker_list` - Перечень брокеров, разделенный запятыми (`localhost:9092`).
-- `topic_list` - Перечень необходимых топиков Kafka (`my_topic`).
-- `group_name` - Группа потребителя Kafka (`group1`). Отступы для чтения отслеживаются для каждой группы отдельно. Если необходимо, чтобы сообщения не повторялись на кластере, используйте везде одно имя группы.
-- `format` - Формат сообщений. Имеет те же обозначения, что выдает SQL-выражение `FORMAT`, например, `JSONEachRow`.
-- `schema` - Опциональный параметр, необходимый, если используется формат, требующий определения схемы. Например, [Cap'n Proto](https://capnproto.org/) требует путь к файлу со схемой и название корневого объекта `schema.capnp:Message`.
-
-Пример:
-
-```sql
-  CREATE TABLE queue (
-    timestamp UInt64,
-    level String,
-    message String
-  ) ENGINE = Kafka('localhost:9092', 'topic', 'group1', 'JSONEachRow');
-
-  SELECT * FROM queue LIMIT 5;
-```
-
-Полученные сообщения отслеживаются автоматически, поэтому из одной группы каждое сообщение считывается только один раз. Если необходимо получить данные дважды, то создайте копию таблицы с другим именем группы.
-
-Группы пластичны и синхронизированы на кластере. Например, если есть 10 топиков и 5 копий таблицы в кластере, то в каждую копию попадет по 2 топика. Если количество копий изменится, то распределение топиков по копиям изменится автоматически. Подробно читайте об этом на [http://kafka.apache.org/intro](http://kafka.apache.org/intro).
-
-Чтение сообщения с помощью `SELECT` не слишком полезно (разве что для отладки), поскольку каждое сообщения может быть прочитано только один раз. Практичнее создавать потоки реального времени с помощью материализованных преставлений. Для этого:
-
-1. Создайте потребителя Kafka с помощью движка и рассматривайте его как поток данных.
-2. Создайте таблицу с необходимой структурой.
-3. Создайте материализованное представление, которое преобразует данные от движка и помещает их в ранее созданную таблицу.
-
-Когда к движку присоединяется материализованное представление (`MATERIALIZED VIEW`), оно начинает в фоновом режиме собирать данные. Это позволяет непрерывно получать сообщения от Kafka и преобразовывать их в необходимый формат с помощью `SELECT`.
-
-Пример:
-
-```sql
-  CREATE TABLE queue (
-    timestamp UInt64,
-    level String,
-    message String
-  ) ENGINE = Kafka('localhost:9092', 'topic', 'group1', 'JSONEachRow');
-
-  CREATE TABLE daily (
-    day Date,
-    level String,
-    total UInt64
-  ) ENGINE = SummingMergeTree(day, (day, level), 8192);
-  
-  CREATE MATERIALIZED VIEW consumer TO daily
-    AS SELECT toDate(toDateTime(timestamp)) AS day, level, count() as total
-    FROM queue GROUP BY day, level;
-
-SELECT level, sum(total) FROM daily GROUP BY level;
-```
-
-Для улучшения производительности полученные сообщения группируются в блоки размера [max_insert_block_size](../operations/settings/settings.md#settings-settings-max_insert_block_size). Если блок не удалось сформировать за [stream_flush_interval_ms](../operations/settings/settings.md#settings-settings_stream_flush_interval_ms) миллисекунд, то данные будут сброшены в таблицу независимо от полноты блока.
-
-Чтобы остановить получение данных топика или изменить логику преобразования, отсоедините материализованное представление:
-
-```
-DETACH TABLE consumer;
-ATTACH MATERIALIZED VIEW consumer;
-```
-
+# Kafka
+
+Движок работает с [Apache Kafka](http://kafka.apache.org/). 
+
+Kafka позволяет:
+
+- Публиковать/подписываться на потоки данных.
+- Организовать отказо-устойчивое хранилище.
+- Обрабатывать потоки по мере их появления.
+
+```
+Kafka(broker_list, topic_list, group_name, format[, schema])
+```
+
+Параметры:
+- `broker_list` - Перечень брокеров, разделенный запятыми (`localhost:9092`).
+- `topic_list` - Перечень необходимых топиков Kafka (`my_topic`).
+- `group_name` - Группа потребителя Kafka (`group1`). Отступы для чтения отслеживаются для каждой группы отдельно. Если необходимо, чтобы сообщения не повторялись на кластере, используйте везде одно имя группы.
+- `format` - Формат сообщений. Имеет те же обозначения, что выдает SQL-выражение `FORMAT`, например, `JSONEachRow`.
+- `schema` - Опциональный параметр, необходимый, если используется формат, требующий определения схемы. Например, [Cap'n Proto](https://capnproto.org/) требует путь к файлу со схемой и название корневого объекта `schema.capnp:Message`.
+
+Пример:
+
+```sql
+  CREATE TABLE queue (
+    timestamp UInt64,
+    level String,
+    message String
+  ) ENGINE = Kafka('localhost:9092', 'topic', 'group1', 'JSONEachRow');
+
+  SELECT * FROM queue LIMIT 5;
+```
+
+Полученные сообщения отслеживаются автоматически, поэтому из одной группы каждое сообщение считывается только один раз. Если необходимо получить данные дважды, то создайте копию таблицы с другим именем группы.
+
+Группы пластичны и синхронизированы на кластере. Например, если есть 10 топиков и 5 копий таблицы в кластере, то в каждую копию попадет по 2 топика. Если количество копий изменится, то распределение топиков по копиям изменится автоматически. Подробно читайте об этом на [http://kafka.apache.org/intro](http://kafka.apache.org/intro).
+
+Чтение сообщения с помощью `SELECT` не слишком полезно (разве что для отладки), поскольку каждое сообщения может быть прочитано только один раз. Практичнее создавать потоки реального времени с помощью материализованных преставлений. Для этого:
+
+1. Создайте потребителя Kafka с помощью движка и рассматривайте его как поток данных.
+2. Создайте таблицу с необходимой структурой.
+3. Создайте материализованное представление, которое преобразует данные от движка и помещает их в ранее созданную таблицу.
+
+Когда к движку присоединяется материализованное представление (`MATERIALIZED VIEW`), оно начинает в фоновом режиме собирать данные. Это позволяет непрерывно получать сообщения от Kafka и преобразовывать их в необходимый формат с помощью `SELECT`.
+
+Пример:
+
+```sql
+  CREATE TABLE queue (
+    timestamp UInt64,
+    level String,
+    message String
+  ) ENGINE = Kafka('localhost:9092', 'topic', 'group1', 'JSONEachRow');
+
+  CREATE TABLE daily (
+    day Date,
+    level String,
+    total UInt64
+  ) ENGINE = SummingMergeTree(day, (day, level), 8192);
+  
+  CREATE MATERIALIZED VIEW consumer TO daily
+    AS SELECT toDate(toDateTime(timestamp)) AS day, level, count() as total
+    FROM queue GROUP BY day, level;
+
+SELECT level, sum(total) FROM daily GROUP BY level;
+```
+
+Для улучшения производительности полученные сообщения группируются в блоки размера [max_insert_block_size](../operations/settings/settings.md#settings-settings-max_insert_block_size). Если блок не удалось сформировать за [stream_flush_interval_ms](../operations/settings/settings.md#settings-settings_stream_flush_interval_ms) миллисекунд, то данные будут сброшены в таблицу независимо от полноты блока.
+
+Чтобы остановить получение данных топика или изменить логику преобразования, отсоедините материализованное представление:
+
+```
+DETACH TABLE consumer;
+ATTACH MATERIALIZED VIEW consumer;
+```
+
 Если необходимо изменить целевую таблицу с помощью `ALTER`, то материализованное представление рекомендуется отключить, чтобы избежать несостыковки между целевой таблицей и данными от представления.
\ No newline at end of file