Differs from SelectQuery/InsertQuery that it could be > 1 (in case of
MATERIALIZED VIEW attached to the table), since each local SELECT/INSERT
query is accounted, not only initial.
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
* Add zookeeper name in endpoint id
When we migrate a replicated table from one zookeeper cluster to
another (the reason why we migration is that zookeeper's load is
too high), we will create a new table with the same zpath, but it
will fail and the old table will be in trouble.
Here is some infomation:
1.old table:
CREATE TABLE a1 (`id` UInt64)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/default/a1/{shard}', '{replica}')
ORDER BY (id);
2.new table:
CREATE TABLE a2 (`id` UInt64)
ENGINE = ReplicatedMergeTree('aux1:/clickhouse/tables/default/a1/{shard}', '{replica}')
ORDER BY (id);
3.error info:
<Error> executeQuery: Code: 220. DB::Exception: Duplicate interserver IO endpoint:
DataPartsExchange:/clickhouse/tables/default/a1/01/replicas/02.
(DUPLICATE_INTERSERVER_IO_ENDPOINT)
<Error> InterserverIOHTTPHandler: Code: 221. DB::Exception: No interserver IO endpoint
named DataPartsExchange:/clickhouse/tables/default/a1/01/replicas/02.
(NO_SUCH_INTERSERVER_IO_ENDPOINT)
* Revert "Add zookeeper name in endpoint id"
This reverts commit 9deb75b249619b7abdd38e3949ca8b3a76c9df8e.
* Add zookeeper name in endpoint id
When we migrate a replicated table from one zookeeper cluster to
another (the reason why we migration is that zookeeper's load is
too high), we will create a new table with the same zpath, but it
will fail and the old table will be in trouble.
* Fix incompatible with a new setting
* add a test, fix other issues
* Update 02442_auxiliary_zookeeper_endpoint_id.sql
* Update 02735_system_zookeeper_connection.reference
* Update 02735_system_zookeeper_connection.sql
* Update run.sh
* Remove the 'no-fasttest' tag
* Update 02442_auxiliary_zookeeper_endpoint_id.sql
---------
Co-authored-by: Alexander Tokmakov <tavplubix@clickhouse.com>
Co-authored-by: Alexander Tokmakov <tavplubix@gmail.com>
Before you was able to break the format by using "\n" or "\t", that will
simply lead to DDL hang, because DDLWorker will simply log the error and
do nothing more:
<Error> DDLWorker: Cannot parse DDL task query-0000000056: Incorrect task format. Will try to send error status: Code: 27. DB::ParsingException: Cannot parse input: expected '\n' before: 'bar\n1\n'. (CANNOT_PARSE_INPUT_ASSERTION_FAILED) (version 23.5.1.1)
Fix this by adding proper escaping.
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
* Feature: Support new system table to show which zookeeper node be connected
Description:
============
Currently we have no place to check which zk node be connected otherwise using
lsof command. It not convenient
Solution:
=========
Implemented a new system table, system.zookeeper_host when CK Server has zk
this table will show the zk node dir which connected by current CK server
Noted: This table can support multi-zookeeper cluster scenario.
* fixed review comments
* added test case
* update test cases
* remove unused code
* fixed review comments and removed unused code
* updated test cases for print host, port and is_expired
* modify the code comments
* fixed CI Failed
* fixed code style check failure
* updated test cases by added Tags
* update test reference
* update test cases
* added system.zookeeper_connection doc
* Update docs/en/operations/system-tables/zookeeper_connection.md
* Update docs/en/operations/system-tables/zookeeper_connection.md
* Update docs/en/operations/system-tables/zookeeper_connection.md
---------
Co-authored-by: Alexander Tokmakov <tavplubix@gmail.com>
Use separate helpers that accept/return values, instead of reference,
anyway PackedHashMap is developed for small structure.
v0: fix for keys
v2: fix for values
v3: fix bitEquals
v4: fix for iterating over HashMap
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
In case of you have HashMap with <UInt64, UInt16> as <Key, Value> the
overhead of 38% can be crutial, especially if you have tons of keys.
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
And also update the test, since now you could have slightly less sleep
intervals, if query spend some time in other places.
But what is important is that query_duration_ms does not exceeded
calculated delay.
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
There is no bug in Linux, the issue that CLOCK_MONOTONIC returns values
less then previous calls likely happens due to adjtime(3) (NTP), since
CLOCK_MONOTONIC is affected by it, and I've seen lots of slight time
modifications due to NTP on the servers. And even on my desktop (I also
have NTP enabled):
CLOCK_MONOTONIC: 189292.803 (2 days + 4h 34m 52s)
CLOCK_MONOTONIC_RAW: 189290.016 (2 days + 4h 34m 50s)
However on Linux there is CLOCK_MONOTONIC_RAW, it is similar to
CLOCK_MONOTONIC, but does not affected by the adjtime(3).
About performance, it is the same:
CLOCK_MONOTONIC 10e6: real=0m0.191s user=0m0.190s sys=0m0.000s
CLOCK_MONOTONIC_RAW 10e6: real=0m0.191s user=0m0.191s sys=0m0.000s
Ops/s:
- AMD Threadripper: 52.3e6
- Xeon Silver 4216 2.10: 46.5e6
Fixes: c5d631ca54Fixes: #29811 (cc @tavplubix)
Signed-off-by: Azat Khuzhin <a.khuzhin@semrush.com>
