webfunny_monitor ClickHouse 集群部署实战：双节点复制、数据迁移与故障排查

可观测性数据分析【免费下载链接】webfunny_monitor【免费社区版】【企业版】Webfunny是一款集全链路监控和用户行为分析埋点系统于一体的大数据分析系统我们致力于解决线上的疑难杂症和精细化分析业务数据监控系统面向技术、埋点系统面向业务两者配合使用相得益彰。项目地址https://gitcode.com/gh_mirrors/we/webfunny_monitor点击查看免费下载本文是 webfunny_monitorWebfunny 监控系统在生产环境中将 ClickHouse 从单节点升级为双节点集群的完整实战指南。内容涵盖 ZooKeeper ReplicatedMergeTree 的集群架构、Docker 部署的关键配置、单节点到集群的自动化数据迁移以及复制不同步、端口不通、引擎未转换等高频问题的定位与修复。读完本文你将具备独立完成 ClickHouse 双节点集群部署、存量数据迁移与日常复制监控的完整能力。目录1. 集群架构概述2. 环境准备3. ClickHouse 集群配置4. 单节点到集群的数据迁移5. 常见问题与解决方案6. 验证与监控7. 最佳实践8. 总结附录快速命令参考1. 集群架构概述1.1 双节点集群拓扑webfunny_monitor 的监控数据默认落在 ClickHouse库名如webfunny_cloud_db当数据量增长后单节点往往成为容量与可用性瓶颈。本文采用的方案是双节点同分片、互为副本的集群形态两个 ClickHouse 节点通过ReplicatedMergeTree表引擎自动复制同一份数据由 ZooKeeper 协调复制任务与元数据。┌─────────────────────────────────────────────────────────┐ │ ZooKeeper 集群 │ │ (协调 ReplicatedMergeTree 复制) │ └─────────────────────────────────────────────────────────┘ │ ┌──────────────────┴──────────────────┐ │ │ ┌───────▼──────────┐ ┌────────▼─────────┐ │ 节点1 (zk1) │◄───复制数据────►│ 节点2 (zk2) │ │ 192.168.1.10 │ │ 192.168.1.20 │ │ │ │ │ │ HTTP: 8123 │ │ HTTP: 8123 │ │ Native: 9000 │ │ Native: 9000 │ │ Interserver:9009 │ │ Interserver:9009 │ └──────────────────┘ └──────────────────┘1.2 关键概念ReplicatedMergeTree支持数据自动复制的表引擎写入仅需发给一个副本其余副本从 ZooKeeper 获取复制任务后自动拉取数据分片。Interserver 端口9009节点之间传输复制数据的专用 HTTP 端口双节点集群的数据血脉几乎全部复制故障都与它相关。ZooKeeper协调副本元数据与复制任务队列两个副本必须指向同一个 ZooKeeper 集群才能形成复制关系。Shard分片数据分布的基本单位本文的双节点属于同一 shard。Replica副本同一分片内的数据副本两个节点各自持有{replica}宏区分身份。1.3 应用侧的集群感知从源码结构看webfunny_monitor 在应用侧实现了完整的集群感知能力clusterManager.js 实现偏好式智能负载均衡为每个节点维护健康状态、读写负载评分与响应时间smartInsert/smartQuery优先选择偏好节点故障时自动切换并累加failovers统计每 10 秒执行一次SELECT 1心跳健康检查连续 3 次失败即标记为不健康。local_db.js 中的createSmartClient在检测到mysqlConfig.cluster.enabled true时启动集群模式把写入节点客户端挂上isCluster标记和_clusterManager引用供后续建表与数据访问统一调度未启用集群时自动回退单节点模式。也就是说本文部署的ClickHouse 双节点是底层存储形态上层 Webfunny 服务monitor 等通过集群配置感知双节点并自动做读写分发。2. 环境准备2.1 服务器要求组件配置要求CPU4核内存8GB磁盘SSD, 100GB网络节点间延迟 5ms2.2 端口清单端口用途是否必须对外开放8123HTTP 接口是用户访问、数据迁移走此端口9000Native 客户端可选9009Interserver 通信是节点间必须2181ZooKeeper是内部通信⚠️最容易遗漏的配置节点间的9009 端口必须互通它承担ReplicatedMergeTree的跨节点数据拉取一旦不通副本将长期停留在只读/等待状态数据永远无法同步。2.3 防火墙 / 安全组配置在两个节点都执行# 开放 9009 端口 sudo firewall-cmd --permanent --add-port9009/tcp sudo firewall-cmd --reload # 验证 sudo firewall-cmd --list-ports云服务器安全组添加入站规则TCP 9009来源为对方节点 IP迁移期间源、目标服务器之间还需开放 8123 端口供迁移工具读取/写入数据。3. ClickHouse 集群配置3.1 Docker 部署注意事项❌ 常见错误# 缺少 9009 端口映射 docker run -d \ -p 8123:8123 \ -p 9000:9000 \ clickhouse/clickhouse-server这样启动的容器虽然单机可用但节点间无法通过 9009 交换复制数据。✅ 正确配置docker run -d \ --name clickhouse-server \ -p 8123:8123 \ -p 9000:9000 \ -p 9009:9009 \ # ← 关键 -v /data/clickhouse:/var/lib/clickhouse \ -v /etc/clickhouse-server:/etc/clickhouse-server \ clickhouse/clickhouse-server:24.3本指南适用于 ClickHouse 24.3、Docker 20.10 环境。3.2 配置文件3.2.1 启用 Interserver 端口编辑config.xml或在config.d/下创建clickhouse !-- 节点间通信端口 -- interserver_http_port9009/interserver_http_port !-- 重要指定使用真实IP而不是容器主机名 -- interserver_http_host192.168.1.10/interserver_http_host /clickhouse为什么需要interserver_http_hostDocker 容器默认使用容器 ID 作为主机名如d0d1c46ac5c6其他节点无法解析这个主机名复制时会出现Not found address of host: d0d1c46ac5c6. (DNS_ERROR)显式指定真实 IP 可彻底规避 DNS 问题。3.2.2 集群配置config.d/remote_servers.xmlclickhouse remote_servers log_cluster shard replica host192.168.1.10/host port9000/port /replica replica host192.168.1.20/host port9000/port /replica /shard /log_cluster /remote_servers /clickhouse这里定义了一个名为log_cluster的集群单一 shard 内包含两个 replica。后续CREATE DATABASE ... ON CLUSTER log_cluster等分布式 DDL 都会以此为依据在两端执行。3.2.3 宏定义macros节点1 (config.d/macros.xml)clickhouse macros clusterlog_cluster/cluster shard01/shard replicareplica_1/replica /macros /clickhouse节点2 (config.d/macros.xml)clickhouse macros clusterlog_cluster/cluster shard01/shard replicareplica_2/replica !-- ← 必须不同 -- /macros /clickhouse宏会代入ReplicatedMergeTree(/clickhouse/tables/{database}/{shard}/table, {replica})的 ZooKeeper 路径与副本名。两个节点shard 相同、replica 不同这正是它们能成为同一分片的两个副本的前提如果 replica 也相同会在 ZooKeeper 中冲突或退化为独立表。3.2.4 ZooKeeper 配置clickhouse zookeeper node hostzk1/host port2181/port /node node hostzk2/host port2181/port /node /zookeeper /clickhouse两个 ClickHouse 节点必须配置同一组 ZooKeeper 地址副本元数据与复制队列才可见、可协调。ZooKeeper 本身建议以集群方式部署以保证高可用。3.3 主机名映射如果使用主机名如 zk1, zk2必须配置/etc/hosts节点1127.0.0.1 zk1 192.168.1.20 zk2节点2192.168.1.10 zk1 127.0.0.1 zk2Docker 容器内也需要配置# 进入容器 docker exec -it clickhouse-server bash # 添加映射 echo 127.0.0.1 zk1 /etc/hosts echo 192.168.1.20 zk2 /etc/hosts # 退出并重启 exit docker restart clickhouse-server推荐做法挂载主机的/etc/hosts到容器容器内外解析一致docker run -v /etc/hosts:/etc/hosts:ro ...3.4 Webfunny 应用侧集群配置集群搭建完成后还需要让 webfunny_monitor 应用感知双节点。从 webfunny_init/config.init.js 中的配置模板可以看到mysqlConfig.monitor节点预留了完整的cluster配置段monitor: { write: { ip: ..., port: 8123, dataBaseName: ..., userName: ..., password: ... }, read: [], // 集群版配置 cluster: { enabled: false, // 是否启用集群版配置 nodes: [ { id: replica1, name: ClickHouse-Replica-1, ip: 8.xxx.xxx.xx, port: 8123, dataBaseName: webfunny_monitor_db_cluster, userName: xxxx_user, password: xxxxxx, preferred: write }, { id: replica2, name: ClickHouse-Replica-2, ip: 8.xxx.xxx.xx, port: 8123, dataBaseName: webfunny_monitor_db_cluster, userName: xxxx_user, password: xxxxxx, preferred: read } ], config: { timeout: 30000, healthCheckInterval: 10000, maxRetries: 2 } } }配置要点两个节点dataBaseName相同如webfunny_monitor_db_cluster、preferred分别为write和read便于 clusterManager.js 按偏好分发读写同一份配置模板在apm、event模块同样存在库名对应webfunny_apm_db_cluster、webfunny_event_db_cluster可按需启用配置生成于webfunny.config/index.js修改后需重启对应服务pm2 restart monitor_server才生效。4. 单节点到集群的数据迁移4.1 迁移工具项目在 servers/monitor/migration 目录下提供了一套完整的自动化迁移工具README 见 README.mdcross_database_migrate.js同服务器、跨数据库迁移数据库 A → 数据库 B速度最快走INSERT ... SELECTcross_server_migrate.js跨服务器迁移cross_server_migrate.js逐批读取源库数据写入目标库migration.config.js集中配置根据 migration.config.example.js 复制创建preview_cross_server_migration.sh/start_cross_server_migration.sh跨服务器预览与正式迁移脚本diagnose_replication.js复制状态诊断工具diagnose_replication.jscheck_sync_progress_v2.js复制进度检查工具check_sync_progress_v2.jsclean_target_database.js清理目标数据库clean_target_database.js。注意migration.config.js包含数据库密码等敏感信息已被.gitignore忽略请勿提交到版本库仓库中只保留migration.config.example.js作为模板。4.2 迁移配置migration.config.jsmodule.exports { source: { host: http://192.168.1.10:8123, username: default, password: , database: webfunny_cloud_db // 旧的单节点库 }, target: { host: http://192.168.1.10:8123, username: default, password: , database: webfunny_cloud_db_cluster // 新的集群库 }, target2: { host: http://192.168.1.20:8123, username: default, password: , database: webfunny_cloud_db_cluster }, options: { batchSize: 10000, isCluster: true, // 自动转换为 ReplicatedMergeTree debug: false, timeout: 300000 } }字段含义与取值建议配置项说明建议source源库连接单节点只读权限即可target目标库连接集群主写入节点需 CREATE/INSERT 权限target2第二个集群节点供诊断/进度工具双节点对比使用options.batchSize每批迁移行数局域网 2 万5 万公网 50001 万大表适当调小options.isCluster是否转换引擎为 ReplicatedMergeTreetrue集群false保持 MergeTree不设置则自动从webfunny.config检测options.debug打印详细 SQL排查问题时置trueoptions.timeout单批超时毫秒默认 3000005 分钟从 cross_server_migrate.js 的源码可以看出isCluster的判定优先级配置文件显式指定 自动检测。自动检测逻辑会尝试加载../config/local_db若其中client.isCluster为真则视为集群模式加载失败则回退为单节点模式。命令行参数如--cluster/--no-cluster优先级高于配置文件。4.3 迁移步骤# 0. 准备配置文件首次使用 cp migration.config.example.js migration.config.js # 编辑 migration.config.js 填入真实的 source / target / target2 连接信息 # 1. 预览只创建表结构不迁移数据 bash preview_cross_server_migration.sh # 2. 检查表结构是否正确 # 特别确认引擎是否为 ReplicatedMergeTree # 3. 正式迁移 bash start_cross_server_migration.shpreview_cross_server_migration.sh实际执行node cross_server_migrate.js --batch --structure-only即只建表不搬数据确认无误后start_cross_server_migration.sh执行node cross_server_migrate.js --batch进入完整迁移。4.4 引擎自动转换迁移工具会自动将单节点表引擎转换为集群复制引擎核心实现见 engineHelper.js 的convertEngine-- 源表单节点 CREATE TABLE test ( id UInt64, name String ) ENGINE MergeTree() ORDER BY id; -- 自动转换为集群 CREATE TABLE test ( id UInt64, name String ) ENGINE ReplicatedMergeTree( /clickhouse/tables/{database}/{shard}/test, {replica} ) ORDER BY id;转换规则细节与源码一致仅转换MergeTree系列且尚未带 Replicated 前缀的引擎ZooKeeper 路径模板为/clickhouse/tables/{database}/{shard}/{table}其中{database}会被替换为目标数据库名如webfunny_cloud_db_cluster保证不同库、不同表的 ZooKeeper 节点互不冲突{shard}、{replica}保留为宏由各节点macros.xml实际代入SummingMergeTree(column)、ReplacingMergeTree(version)等带参引擎同样支持参数会原样保留在副本引擎参数之后。在集群模式下迁移工具还会借助clusterManager.nodes在每个节点上执行CREATE DATABASE IF NOT EXISTS与建表语句参考 node_clickhouse.js 的createTable多节点实现表已存在被视作可接受状态而跳过。4.5 数据复制流程┌──────────┐ │ 源数据库 │ └─────┬────┘ │ │ 迁移工具读取 ▼ ┌──────────┐ INSERT ┌──────────┐ │ 节点1 │─────────────►│ 节点1 │ │ 集群库 │ │ 新表 │ └──────────┘ └────┬─────┘ │ │ ReplicatedMergeTree │ 自动复制 ▼ ┌──────────┐ │ 节点2 │ │ 新表 │ └──────────┘关键点迁移工具只向节点1 插入数据节点2 的数据由 ReplicatedMergeTree 自动复制无需手动同步迁移中途若中断重新运行脚本即可已存在的表会被跳过参考migrateTable中IF NOT EXISTS与表已存在容错逻辑。5. 常见问题与解决方案5.1 数据不自动同步症状SELECT count() FROM table; -- 节点1: 1000000 -- 节点2: 0诊断使用诊断工具node diagnose_replication.js该工具会依次检查对应 diagnose_replication.js 的实现两个节点的 ZooKeeper 连接system.zookeeper查询两个节点的{shard}、{replica}宏是否配置齐全两节点表数量、每张表的引擎是否为 Replicated、行数是否一致按 critical / error / warning 分级输出问题与修复建议。或手动检查-- 查看复制队列 SELECT table, count() as queue_size, max(last_exception) as last_error FROM system.replication_queue WHERE database webfunny_cloud_db_cluster GROUP BY table; -- 查看副本状态 SELECT table, total_replicas, active_replicas, queue_size, absolute_delay FROM system.replicas WHERE database webfunny_cloud_db_cluster;原因1DNS 解析失败错误信息Not found address of host: d0d1c46ac5c6. (DNS_ERROR)原因节点使用了容器主机名容器 ID其他节点无法解析。解决方案 A添加主机名映射快速在无法解析的节点上echo 192.168.1.10 d0d1c46ac5c6 | sudo tee -a /etc/hosts解决方案 B配置真实 IP永久在 ClickHouse 配置中指定interserver_http_host192.168.1.10/interserver_http_host然后清空数据库重新迁移复制失败产生的脏元数据需要清理后重来。原因2端口 9009 无法连接错误信息Connection refused Poco::Exception. Code: 1000, e.code() 111诊断步骤# 1. 检查端口是否监听在节点1 sudo netstat -tlnp | grep 9009 # 2. 检查能否连接在节点2 telnet 192.168.1.10 9009 # 或 nc -zv 192.168.1.10 9009解决方案问题 A端口未监听原因interserver_http_port未配置或被注释。解决# 检查配置 docker exec clickhouse-server grep interserver_http_port /etc/clickhouse-server/config.xml # 如果被注释取消注释或添加 # 重启容器 docker restart clickhouse-server问题 B防火墙阻止sudo firewall-cmd --permanent --add-port9009/tcp sudo firewall-cmd --reload问题 C安全组未开放登录云服务商控制台添加入站规则TCP 9009来源为对方节点 IP。问题 DDocker 端口未映射# 检查 docker port clickhouse-server | grep 9009 # 如果没有需要重新创建容器 docker stop clickhouse-server docker run -d -p 9009:9009 ...原因3集群配置错误错误信息Cannot resolve host (zk1), error 0: Host not found.原因集群配置remote_servers.xml/ ZooKeeper 配置中的主机名无法解析。解决方案在容器内添加/etc/hostsdocker exec -it clickhouse-server bash echo 127.0.0.1 zk1 /etc/hosts echo 192.168.1.20 zk2 /etc/hosts exit docker restart clickhouse-server或直接用真实 IP 修改remote_servers.xml。5.2 表引擎是 MergeTree 而不是 ReplicatedMergeTree症状SHOW CREATE TABLE test; -- 显示 ENGINE MergeTree() 而不是 ReplicatedMergeTree原因迁移时isCluster: true未生效未写入配置文件或自动检测失败或配置文件加载错误。解决方案# 1. 检查配置 cat migration.config.js | grep isCluster # 2. 确认为 true # 3. 清空数据库 node clean_target_database.js # 4. 重新迁移 bash start_cross_server_migration.sh顺带说明仓库中 schema/config.js 等 schema 文件默认引擎为ENGINE MergeTree()集群模式下由 node_clickhouse.js 的createTable在应用侧通过EngineHelper.convertEngine转换为ReplicatedMergeTree后再建表这也是集群模式必须由应用先感知、再建表的原因。5.3 副本数显示为 1症状SELECT total_replicas FROM system.replicas LIMIT 1; -- 显示 1原因两个节点的表是独立创建的没有形成复制关系例如分别手动建表而非通过ON CLUSTER或迁移工具创建两节点 ZooKeeper 路径不一致如{database}、{shard}、{replica}宏配置有差异。解决方案必须清空重建# 在两个节点都删除数据库 clickhouse-client --queryDROP DATABASE IF EXISTS webfunny_cloud_db_cluster # 重新创建使用 ON CLUSTER clickhouse-client --queryCREATE DATABASE webfunny_cloud_db_cluster ON CLUSTER log_cluster # 重新迁移 bash start_cross_server_migration.sh5.4 复制队列积压症状SELECT count() FROM system.replication_queue; -- 显示大量任务可能原因网络慢节点性能不足一次性插入数据过多。解决方案等待自动处理推荐ClickHouse 会自动消费复制队列正常情况下每秒可处理数百个任务。手动触发如果卡住-- 重启副本复制 SYSTEM RESTART REPLICAS; -- 或针对特定表 SYSTEM RESTART REPLICA table_name;优化性能-- 调整复制相关参数 SET max_replica_delay_for_distributed_queries 300; SET replication_alter_partitions_sync 2;6. 验证与监控6.1 复制状态检查-- 1. 查看副本配置 SELECT database, table, zookeeper_path, replica_name, total_replicas, active_replicas FROM system.replicas WHERE database webfunny_cloud_db_cluster LIMIT 5;正常输出database | table | total_replicas | active_replicas ----------------------------|------------|----------------|---------------- webfunny_cloud_db_cluster | test | 2 | 2total_replicas 2且active_replicas 2表示两个副本均已注册并存活。6.2 数据一致性检查# 使用诊断工具 node diagnose_replication.js # 或手动对比行数 clickhouse-client --host192.168.1.10 --query SELECT table, count() as cnt FROM webfunny_cloud_db_cluster.* GROUP BY table ORDER BY table clickhouse-client --host192.168.1.20 --query SELECT table, count() as cnt FROM webfunny_cloud_db_cluster.* GROUP BY table ORDER BY table另外迁移工具的verifyData逻辑见 cross_server_migrate.js会在每张表迁移后自动对比源表与目标表行数聚合引擎因合并去重导致的轻微行数差异会被明确提示而非报错。6.3 监控指标关键指标-- 复制延迟 SELECT table, absolute_delay, queue_size FROM system.replicas WHERE absolute_delay 60; -- 延迟超过60秒 -- 失败的复制任务 SELECT table, count() as failures FROM system.replication_queue WHERE num_tries 3 GROUP BY table; -- 只读副本通常表示有问题 SELECT table, is_readonly, last_queue_update_exception FROM system.replicas WHERE is_readonly 1;迁移进行中可用 check_sync_progress_v2.js 快速查看节点2 的system.replication_queue队列大小队列清空即代表数据同步完成队列长期不减时它会提示排查主机名映射与网络连通性。7. 最佳实践7.1 部署前检查清单两个节点的 9009 端口互通Docker 容器映射了 9009 端口配置了interserver_http_port9009/interserver_http_port配置了interserver_http_host真实IP/interserver_http_host集群配置中的主机名能解析或用 IP两个节点的{replica}宏不同ZooKeeper 正常运行且两节点指向同一 ZooKeeper 集群防火墙 / 安全组规则正确webfunny.config中cluster.enabled true且节点信息正确7.2 配置建议使用真实 IP避免主机名❌不推荐hostzk1/host hostzk2/host✅推荐host192.168.1.10/host host192.168.1.20/hostDocker 容器持久化配置docker run -d \ --name clickhouse-server \ -p 8123:8123 \ -p 9000:9000 \ -p 9009:9009 \ -v /data/clickhouse:/var/lib/clickhouse \ # 数据持久化 -v /etc/clickhouse-server:/etc/clickhouse-server \ # 配置持久化 -v /etc/hosts:/etc/hosts:ro \ # 主机名映射 --restartalways \ # 自动重启 clickhouse/clickhouse-server:24.3配置文件分离/etc/clickhouse-server/ ├── config.xml # 主配置 └── config.d/ ├── network.xml # 网络配置interserver 端口等 ├── remote_servers.xml # 集群配置 ├── macros.xml # 宏定义cluster/shard/replica └── zookeeper.xml # ZooKeeper 配置7.3 迁移建议先测试后迁移# 预览模式只创建表结构 bash preview_cross_server_migration.sh小批量迁移先迁移几个小表测试验证复制正常后再迁移大表。监控复制进度# 定期检查 node check_sync_progress_v2.js业务低峰期迁移避免影响线上业务迁移前停止应用写入README 同样强调迁移过程中不要写入源数据库预留足够时间处理问题目标服务器建议预留 2 倍数据大小的磁盘空间。7.4 故障恢复单节点故障节点2 故障节点1 继续提供服务clusterManager.js 会自动把读写全部切到健康节点节点2 恢复后自动从节点1 同步数据。节点1 故障应用侧自动切换到节点2偏好为 read 的节点被提升节点1 恢复后自动追赶数据。数据不一致# 1. 停止写入 # 2. 对比数据 node diagnose_replication.js # 3. 如果差异大重新迁移 # 清空节点2 clickhouse-client --host节点2 --queryDROP DATABASE IF EXISTS xxx # 从节点1重新复制 # ClickHouse 会自动处理7.5 性能优化插入优化-- 批量插入推荐 INSERT INTO table VALUES (...), (...), (...); -- 避免单行插入不推荐 INSERT INTO table VALUES (...);复制优化clickhouse !-- 增加复制线程数 -- background_schedule_pool_size16/background_schedule_pool_size !-- 增加复制超时 -- replicated_fetches_http_connection_timeout30/replicated_fetches_http_connection_timeout /clickhouse8. 总结关键要点9009 端口是灵魂必须监听必须互通容器必须映射。主机名 vs IPDocker 环境强烈建议用 IP如用主机名确保所有地方含容器内都能解析。ReplicatedMergeTree 是自动的配置正确后数据会自动同步不需要手动触发复制前提是两节点指向同一 ZooKeeper、宏配置正确、引擎确为 Replicated 前缀。先诊断再修复使用node diagnose_replication.js定位问题不要盲目重启或清空数据。排查顺序遇到复制问题时按此顺序检查端口 9009 是否监听端口 9009 是否互通主机名是否能解析表引擎是否为 ReplicatedMergeTree副本数是否为 2复制队列是否有错误仓库延伸阅读迁移与诊断工具集servers/monitor/migration含 README.md、migration.config.example.js、cross_server_migrate.js、diagnose_replication.js应用侧集群管理clusterManager.js、local_db.js引擎自动转换engineHelper.js、node_clickhouse.js应用集群配置模板webfunny_init/config.init.js附录快速命令参考# 端口检查 sudo netstat -tlnp | grep 9009 # 检查端口监听 telnet IP 9009 # 测试连接 nc -zv IP 9009 # 测试连接推荐 # Docker docker ps | grep clickhouse # 查看容器 docker port CONTAINER # 查看端口映射 docker logs CONTAINER # 查看日志 docker exec -it CONTAINER bash # 进入容器 docker restart CONTAINER # 重启容器 # ClickHouse clickhouse-client --query... # 执行SQL clickhouse-client -m # 交互模式 # 查看副本状态 SELECT * FROM system.replicas WHERE database xxx; # 查看复制队列 SELECT * FROM system.replication_queue WHERE database xxx; # 重启复制 SYSTEM RESTART REPLICAS; # 防火墙 sudo firewall-cmd --list-ports # 查看开放端口 sudo firewall-cmd --permanent --add-port9009/tcp sudo firewall-cmd --reload # 迁移工具 bash preview_cross_server_migration.sh # 预览仅建表 bash start_cross_server_migration.sh # 迁移 node diagnose_replication.js # 诊断 node check_sync_progress_v2.js # 进度 node clean_target_database.js # 清空目标库适用版本ClickHouse 24.3Docker 20.10赞分享可观测性数据分析【免费下载链接】webfunny_monitor【免费社区版】【企业版】Webfunny是一款集全链路监控和用户行为分析埋点系统于一体的大数据分析系统我们致力于解决线上的疑难杂症和精细化分析业务数据监控系统面向技术、埋点系统面向业务两者配合使用相得益彰。项目地址https://gitcode.com/gh_mirrors/we/webfunny_monitor点击查看免费下载相关推荐Awesome Claude Code 精选资源导航分类体系、自动化生成管线与维护机制深度解析Awesome Claude Code 精选资源导航分类体系、自动化生成管线与维护机制深度解析 本篇技术指南围绕 awesome claude code 仓库可观测性数据分析CubeFS 集群故障排查与节点下线迁移实战指南DataNode / MetaNode / 纠删码子系统CubeFS 集群故障排查与节点下线迁移实战指南DataNode / MetaNode / 纠删码子系统 本篇技术指南以 CubeFS 官方 FAQ《常见问存储分布式文件系统对象存储云原生StarRocks 运维 FAQ 实战指南节点管理、数据迁移与故障排查全解StarRocks 运维 FAQ 实战指南节点管理、数据迁移与故障排查全解 本篇技术指南以 StarRocks 官方运维 FAQ 为骨架系统整理集群日常运维数据库OLAP数据仓库大数据湖仓一体数据分析上一篇py-faster-rcnn中的数据集格式转换VOC到COCO标注格式教程下一篇Laravel Scout ElasticSearch 索引映射配置如何优化 ElasticSearch 索引设置创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考