* Перевод без изменений содержания
* в ру-версию добавлены ngrambf_v1 и tokenbf_v1
* Update mergetree.md
* Update docs/ru/operations/settings/settings.md
Co-authored-by: olgarev <56617294+olgarev@users.noreply.github.com>
* Update docs/ru/operations/settings/settings.md
Co-authored-by: olgarev <56617294+olgarev@users.noreply.github.com>
* Update docs/ru/operations/settings/settings.md
Co-authored-by: olgarev <56617294+olgarev@users.noreply.github.com>
* Update docs/ru/operations/settings/settings.md
Co-authored-by: olgarev <56617294+olgarev@users.noreply.github.com>
* Update docs/ru/operations/settings/settings.md
Co-authored-by: olgarev <56617294+olgarev@users.noreply.github.com>
* Update docs/ru/engines/table-engines/mergetree-family/mergetree.md
Co-authored-by: olgarev <56617294+olgarev@users.noreply.github.com>
* Update docs/ru/engines/table-engines/mergetree-family/mergetree.md
Co-authored-by: olgarev <56617294+olgarev@users.noreply.github.com>
* Update docs/ru/engines/table-engines/mergetree-family/mergetree.md
Co-authored-by: olgarev <56617294+olgarev@users.noreply.github.com>
* Corrections and translation
* in EN ver. lines 349-351 were included into the codeblock -- moved them to the proper place
* ...
Co-authored-by: olgarev <56617294+olgarev@users.noreply.github.com>
`ALTER TABLE ... FETCH` and `ALTER TABLE ... ATTACH` queries were
disabled in the Replicated database engine, because it could cause
accidental duplication of data.
This enables these queries but without replicating them.
In the case of `FETCH`, the part will only be fetched on the server
where the query is issued.
Similarly, in the case of `ATTACH`, the attached part only needs to
be available on the server where the query is issued.
If the table itself is using one of the Replicated MergeTree engines,
the attached data is then replicated by the table engine itself,
without intervention of the database engine.
This change is meant to help with live backup/restore when using the
Replicated database engine, using FREEZE for backup and ATTACH for
restore.
This will allow to avoid superfluous sleep during query execution, since
this not only not desired behavoiur, but also may hang the server, since
if you will execute enough queries that will use MySQL database but will
not allow enough connections (or your MySQL server is too slow) then you
may run out of threads in the global thread pool.
Also note that right now it is possible to get deadlock when the mysql
pool is full, consider the following scenario:
- you have m1 and m2 mysql tables
- you have q1 and q2 queries, bot queries join m1 and m2
- q1 allocated connection for m1 but cannot allocate connection for m2
- q2 allocated connection for m2 but cannot allocate connection for m1
- but to resolve the lock one should give up on the locking while it is not possible right now...
And then you got no free threads and this:
# grep -h ^202 /proc/$(pgrep clickhouse-serv)/task/*/syscall | cut -d' ' -f2 | sort | uniq -c | sort -nr | head
1554 0x7ffb60b92fe8 # mutex in mysqlxx::PoolWithFailover::get
1375 0x7ffb9f1c4748 # mutex in ::PoolEntryHelper::~PoolEntryHelper from DB::MultiplexedConnections::invalidateReplica
1160 0x7ffb612918b8 # mutex in mysqlxx::PoolWithFailover::get
42 0x7ffb9f057984 # mutex in ThreadPoolImpl<std::__1::thread>::worker
*NOTE: 202 is a `futex` with WAIT*
(Went with `syscall` because debugging 10k+ threads is not easy, and
eventually it may TRAP)
