跳至主要内容

replicas

包含驻留在本地服务器上的复制表的相关信息和状态。此表可用于监控。该表包含每个复制*表的行。

示例

SELECT *
FROM system.replicas
WHERE table = 'test_table'
FORMAT Vertical
Query id: dc6dcbcb-dc28-4df9-ae27-4354f5b3b13e

Row 1:
───────
database: db
table: test_table
engine: ReplicatedMergeTree
is_leader: 1
can_become_leader: 1
is_readonly: 0
is_session_expired: 0
future_parts: 0
parts_to_check: 0
zookeeper_path: /test/test_table
replica_name: r1
replica_path: /test/test_table/replicas/r1
columns_version: -1
queue_size: 27
inserts_in_queue: 27
merges_in_queue: 0
part_mutations_in_queue: 0
queue_oldest_time: 2021-10-12 14:48:48
inserts_oldest_time: 2021-10-12 14:48:48
merges_oldest_time: 1970-01-01 03:00:00
part_mutations_oldest_time: 1970-01-01 03:00:00
oldest_part_to_get: 1_17_17_0
oldest_part_to_merge_to:
oldest_part_to_mutate_to:
log_max_index: 206
log_pointer: 207
last_queue_update: 2021-10-12 14:50:08
absolute_delay: 99
total_replicas: 5
active_replicas: 5
lost_part_count: 0
last_queue_update_exception:
zookeeper_exception:
replica_is_active: {'r1':1,'r2':1}

  • database (String) - 数据库名称
  • table (String) - 表名称
  • engine (String) - 表引擎名称
  • is_leader (UInt8) - 副本是否为领导者。多个副本可以同时是领导者。可以使用 merge_tree 设置 replicated_can_become_leader 来阻止副本成为领导者。领导者负责调度后台合并。请注意,可以对任何可用的且在 ZK 中具有会话的副本执行写入操作,而无论其是否是领导者。
  • can_become_leader (UInt8) - 副本是否可以成为领导者。
  • is_readonly (UInt8) - 副本是否处于只读模式。如果配置中没有 ClickHouse Keeper 部分、在 ClickHouse Keeper 中重新初始化会话时发生未知错误以及在 ClickHouse Keeper 中重新初始化会话期间,则会启用此模式。
  • is_session_expired (UInt8) - 与 ClickHouse Keeper 的会话已过期。基本上与 is_readonly 相同。
  • future_parts (UInt32) - 由于尚未完成的 INSERT 或合并操作而将出现的数据部分数。
  • parts_to_check (UInt32) - 等待验证的队列中的数据部分数。如果怀疑某个部分可能已损坏,则会将其放入验证队列中。
  • zookeeper_path (String) - ClickHouse Keeper 中表数据的路径。
  • replica_name (String) - ClickHouse Keeper 中的副本名称。同一表的不同副本具有不同的名称。
  • replica_path (String) - ClickHouse Keeper 中副本数据的路径。与连接“zookeeper_path/replicas/replica_path”相同。
  • columns_version (Int32) - 表结构的版本号。指示执行 ALTER 的次数。如果副本具有不同的版本,则表示某些副本尚未完成所有 ALTER 操作。
  • queue_size (UInt32) - 等待执行的操作队列的大小。操作包括插入数据块、合并以及某些其他操作。它通常与 future_parts 一致。
  • inserts_in_queue (UInt32) - 需要进行的数据块插入次数。插入操作通常会很快复制。如果此数字很大,则表示出现问题。
  • merges_in_queue (UInt32) - 等待进行的合并次数。有时合并过程很长,因此该值可能会长时间大于零。
  • part_mutations_in_queue (UInt32) - 等待进行的突变次数。
  • queue_oldest_time (DateTime) - 如果 queue_size 大于 0,则显示将最旧的操作添加到队列中的时间。
  • inserts_oldest_time (DateTime) - 请参阅 queue_oldest_time
  • merges_oldest_time (DateTime) - 请参阅 queue_oldest_time
  • part_mutations_oldest_time (DateTime) - 请参阅 queue_oldest_time

接下来的 4 列仅在与 ZK 存在活动会话的情况下才具有非零值。

  • log_max_index (UInt64) - 常规活动日志中的最大条目号。
  • log_pointer (UInt64) - 副本复制到其执行队列的常规活动日志中的最大条目号,加一。如果 log_pointer 远小于 log_max_index,则表示出现问题。
  • last_queue_update (DateTime) - 上次更新队列的时间。
  • absolute_delay (UInt64) - 当前副本的延迟时间(以秒为单位)。
  • total_replicas (UInt8) - 此表的已知副本总数。
  • active_replicas (UInt8) - ClickHouse Keeper 中具有会话的此表副本数(即,正常运行的副本数)。
  • lost_part_count (UInt64) - 自创建表以来,所有副本在表中丢失的数据部分总数。该值保存在 ClickHouse Keeper 中,并且只能增加。
  • last_queue_update_exception (String) - 当队列包含损坏的条目时。当 ClickHouse 破坏了版本之间的向后兼容性,并且由较新版本写入的日志条目无法由旧版本解析时,这一点尤其重要。
  • zookeeper_exception (String) - 最后一个异常消息,在从 ClickHouse Keeper 获取信息时发生错误时获取。
  • replica_is_active (Map(String, UInt8)) — 副本名称和副本是否处于活动状态之间的映射。

如果请求所有列,则该表可能会运行缓慢,因为每行都会从 ClickHouse Keeper 中读取多次。如果不请求最后 4 列(log_max_index、log_pointer、total_replicas、active_replicas),则该表会快速运行。

例如,您可以像这样检查一切是否正常运行

SELECT
database,
table,
is_leader,
is_readonly,
is_session_expired,
future_parts,
parts_to_check,
columns_version,
queue_size,
inserts_in_queue,
merges_in_queue,
log_max_index,
log_pointer,
total_replicas,
active_replicas
FROM system.replicas
WHERE
is_readonly
OR is_session_expired
OR future_parts > 20
OR parts_to_check > 10
OR queue_size > 20
OR inserts_in_queue > 10
OR log_max_index - log_pointer > 10
OR total_replicas < 2
OR active_replicas < total_replicas

如果此查询未返回任何内容,则表示一切正常。