clickhouse Cannot execute replicated DDL query, maximum retries exceeded报错解决

报错信息

在clickhouse中执行DDL命令对表进行改动时,出现报错Cannot execute replicated DDL query, maximum retries exceeded

解决方案

一、官方解决方案

官方说这是一个特定版本的bug,但是实际我自己用的22.9.34版本,也存在这个问题,贴上官方的解决方案,遇到该问题的时候可以先试试官方的方案
官方方案

二、新的方案

照着官方给的方案试过后,并没有解决我的问题,该报错仍然存在。经过一番尝试后,整理一下我自己的方案

  1. 进入到zookeeper的bin目录中,执行命令连接到zookeeper或者keeper的命令行中(连接zk或者keeper都是同样的命令)
./zkCli.sh -server ZK的IP:2181
  1. 如果zookeeper设置了密码的话,则执行以下语句登录
addauth digest 账号:密码
  1. 查看库或者表是否存在
ls /
  1. 目录层级一般为/clickhouse/tables/分片/库/表
    可以使用ls命令一层一层查看,如我自己的路径为以下,执行之后可以看到db_test库下面的所有表,查看报错的表是否在其中
ls /clickhouse/tables/01/db_test/
  1. 删除该有问题的表
deleteall  /clickhouse/tables/01/db_test/表名

删除之后再次执行ls /clickhouse/tables/01/db_test查看,看是否确实已经删除

  1. 如果存在多个zookeeper或者keeper,则使用ctrl+c退出目前的zk,然后重复1到5步,去删除其他节点上的表。删除的时候可能会提示该节点上没有这个表,则直接跳过即可
  2. 登录到任意一台CK机器上,连接到命令行中
clickhouse-client -u 账号 --password 密码 -h IP地址  --port 端口
  1. 分别执行以下命令
system restart replica 库名.表名

等待执行完后继续执行下述命令

system restore replica 库名.表名

在执行的过程中部分节点会报错,提示该节点的表不是readonly状态,忽略该报错即可。可以看到之前这个表出问题的节点会显示执行成功。
9. 等待执行完成后,继续到zk的客户端中进行查询,会发现之前删除的表自动显示了

 ls /clickhouse/tables/01/db_test/
  1. 再次执行修改表的ddl语句,发现执行成功了。
### 解决方案分析 当遇到 `Reached maximum retries (0) for URL` 的错误提示时,通常意味着 HTTP 请求未能成功完成,并且已达到预设的最大重试次数。以下是可能的原因以及解决方案: #### 1. **检查网络连接** 确保目标服务器 (`localhost:35011`) 可达并正常运行。可以通过简单的命令测试连通性: ```bash ping localhost curl http://localhost:35011/execute_query ``` 如果上述命令返回异常,则可能是服务未启动或端口被占用。 #### 2. **调整最大重试次数配置** 默认情况下,某些库可能会设置较低的重试次数(如 0),这可能导致请求立即失败而无额外尝试。可以修改客户端代码中的重试策略。例如,在 Python 中使用 `requests` 库时,可通过自定义适配器实现重试逻辑[^1]: ```python import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session = requests.Session() retries = Retry(total=5, backoff_factor=1, status_forcelist=[500, 502, 503, 504]) adapter = HTTPAdapter(max_retries=retries) session.mount('http://', adapter) response = session.get('http://localhost:35011/execute_query') if response.status_code == 200: print("Request successful!") else: print(f"Failed with code {response.status_code}") ``` #### 3. **验证数据库连接泄漏问题** 根据提供的引用信息[^2],版本更新中修复了一个与数据库连接泄漏相关的问题。如果当前使用的依赖版本较旧,可能存在资源耗尽的情况,从而影响 HTTP 请求的成功率。建议升级至最新稳定版(如 JGit 至 4.7.6.201810191618-r)。此外,还需确认是否存在其他潜在的文件句柄泄漏情况。 #### 4. **日志排查** 启用详细的调试日志有助于定位具体原因。通过增加日志级别来捕获更多上下文信息。例如,在 Spark 日志管理中可设置如下参数: ```scala logDebug(s"Retrieving data from $source: $current -> $available") ``` 此语句表明正在检索数据批次的信息,因此应进一步审查 `$source.getBatch()` 方法的行为及其输入参数的有效性。 --- ### 总结 综合以上分析,推荐采取以下措施以解决问题: - 验证本地服务状态; - 调整 HTTP 客户端的重试机制; - 升级第三方组件到修补后的版本; - 借助详尽的日志记录缩小故障范围。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值