fix indvalid links, add some

PR re-created from scratch
https://github.com/ClickHouse/ClickHouse/pull/21122

docs/en/operations/system-tables/replication_queue.md

@@ -76,6 +76,6 @@ last_postpone_time:     1970-01-01 03:00:00
 
 **See Also**
 
--   [Managing ReplicatedMergeTree Tables](../../sql-reference/statements/system.md/#query-language-system-replicated)
+-   [Managing ReplicatedMergeTree Tables](../../sql-reference/statements/system.md#query-language-system-replicated)
 
 [Original article](https://clickhouse.tech/docs/en/operations/system_tables/replication_queue) <!--hide-->

docs/en/sql-reference/operators/in.md

@@ -203,7 +203,7 @@ It also makes sense to specify a local table in the `GLOBAL IN` clause, in case
 When max_parallel_replicas is greater than 1, distributed queries are further transformed. For example, the following:
 
 ```sql
-SEELECT CounterID, count() FROM distributed_table_1 WHERE UserID IN (SELECT UserID FROM local_table_2 WHERE CounterID < 100)
+SELECT CounterID, count() FROM distributed_table_1 WHERE UserID IN (SELECT UserID FROM local_table_2 WHERE CounterID < 100)
 SETTINGS max_parallel_replicas=3
 ```
 

docs/ru/operations/settings/settings.md

@@ -1086,9 +1086,14 @@ load_balancing = round_robin
 
 ## max_parallel_replicas {#settings-max_parallel_replicas}
 
-Максимальное количество используемых реплик каждого шарда при выполнении запроса.
-Для консистентности (чтобы получить разные части одного и того же разбиения), эта опция работает только при заданном ключе сэмплирования.
-Отставание реплик не контролируется.
+Максимальное кол-во реплик для каждого шарда во время исполениня запроса из distributed. В некоторых случаях, это может привести к более быстрому исполнению запроса за счет выполнения на большем кол-ве серверов. Эта настройка полезна только для реплицируемых таблиц созданных с использованием SAMPLING KEY выражения. Есть случаи когда производительность не улучшится или даже ухудшится: 
+
+- позиция ключа семплирования в ключе партицирования не позволяет делать эффективные сканирования по диапозонам
+- добавление семплирующего ключа к таблице, делает фильтрацию других колонок менее эффективной
+- выражение используемое для вычисления ключа семплирования требует больших вычислительных затрат
+- Распределение сетевых задержек внутри кластера имеет длинный хвост, так что запрос большего количества серверов может увеличить общую задержку запроса
+
+Кроме того, эта настройка может привести к некорректным результатам когда используются join или подзапросы и все таблицы не соответсвуют определенным условиям. Подробнее [Распределенные подзапросы и max_parallel_replicas](../../sql-reference/operators/in.md#max_parallel_replica-subqueries) for more details.
 
 ## compile {#compile}
 

docs/ru/operations/system-tables/replication_queue.md

@@ -76,6 +76,6 @@ last_postpone_time:     1970-01-01 03:00:00
 
 **Смотрите также**
 
--   [Управление таблицами ReplicatedMergeTree](../../sql-reference/statements/system.md/#query-language-system-replicated)
+-   [Управление таблицами ReplicatedMergeTree](../../sql-reference/statements/system.md#query-language-system-replicated)
 
 [Оригинальная статья](https://clickhouse.tech/docs/ru/operations/system_tables/replication_queue) <!--hide-->

docs/ru/sql-reference/operators/in.md

@@ -197,3 +197,25 @@ SELECT uniq(UserID) FROM local_table WHERE CounterID = 101500 AND UserID GLOBAL
 5.  Если в GLOBAL IN есть частая необходимость, то спланируйте размещение кластера ClickHouse таким образом, чтобы в каждом дата-центре была хотя бы одна реплика каждого шарда, и среди них была быстрая сеть - чтобы запрос целиком можно было бы выполнить, передавая данные в пределах одного дата-центра.
 
 В секции `GLOBAL IN` также имеет смысл указывать локальную таблицу - в случае, если эта локальная таблица есть только на сервере-инициаторе запроса, и вы хотите воспользоваться данными из неё на удалённых серверах.
+
+### Распределенные подзапросы и max_parallel_replicas {#max_parallel_replica-subqueries}
+
+Когда настройка max_parallel_replicas больше чем 1, распределенные запросы преобразуются. Например, следующий запрос:
+
+```sql
+SELECT CounterID, count() FROM distributed_table_1 WHERE UserID IN (SELECT UserID FROM local_table_2 WHERE CounterID < 100)
+SETTINGS max_parallel_replicas=3
+```
+
+преобразуются на каждом сервере в
+
+```sql
+SELECT CounterID, count() FROM local_table_1 WHERE UserID IN (SELECT UserID FROM local_table_2 WHERE CounterID < 100)
+SETTINGS parallel_replicas_count=3, parallel_replicas_offset=M
+```
+
+где M значение между 1 и 3 зависящее от того на какой реплике выполняется локальный запрос. Эти параметры влияют на каждую таблицу семейства MergeTree в запросе и имеют тот же эффект, что и применение `SAMPLE 1/3 OFFSET (M-1)/3` для каждой таблицы.
+
+Поэтому применение настройки max_parallel_replicas даст корректные результаты если обе таблицы имеют одинаковую схему репликации и семплированы по UserID выражению от UserID. В частности, если local_table_2 не имеет семплирующего ключа, будут получены неверные результаты. Тоже правило применяется для JOIN.
+
+Один из способов избежать этого, если local_table_2 не удовлетворяет требованиям, использовать `GLOBAL IN` или `GLOBAL JOIN`.