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语句,发现执行成功了。
<think>好的,我现在需要解决用户遇到的ingress-nginx报错cannot execute binary file”的问题。首先,我得理解这个错误的原因。根据经验,这类错误通常与文件权限或架构不匹配有关。用户可能尝试直接执行一个不可执行的文件,或者该文件是为不同的系统架构编译的。 首先,我应该考虑文件权限问题。如果ingress-nginx的可执行文件没有执行权限,系统会拒绝执行,导致报错。这时候需要检查文件的权限设置,使用chmod +x命令添加执行权限。 接下来,架构不匹配的可能性。例如,用户可能在x86_64的系统上运行ARM架构编译的二进制文件,或者反过来。这时候需要确认ingress-nginx的版本是否与当前系统的CPU架构兼容。可以使用file命令查看二进制文件的架构信息,再通过uname -m查看系统架构,进行对比。 然后,文件损坏或下载不完整也是一个可能的原因。下载过程中网络中断可能导致文件损坏,这时候重新下载或验证文件的完整性可能会有帮助。 另外,用户可能错误地执行了非二进制文件,比如配置文件或文本文件。需要确认执行的文件确实是ingress-nginx的可执行文件,通常位于/nginx-ingress-controller目录下。 Kubernetes配置错误也可能导致此问题。例如,Pod的securityContext中可能缺少必要的权限,或者volume挂载不正确,导致文件无法正确访问。需要检查Pod的配置,确保securityContext中的权限足够,并且volumes正确挂载。 用户提到的引用中提到了Ingress Controller通过生成Nginx配置并reload,这可能涉及到配置更新或重载过程中的问题。但具体到二进制文件执行错误,可能更多是文件本身的问题。 综合以上因素,我需要给出逐步的解决方案,包括检查权限、验证架构、重新下载文件、确认执行路径以及检查Kubernetes配置。同时,提醒用户检查日志和使用诊断命令,如kubectl describe和kubectl logs,来获取更多信息。 最后,生成相关问题,帮助用户深入理解可能的相关问题,比如Kubernetes Pod权限问题、二进制文件兼容性检查方法,以及Ingress-Controller的调试技巧。</think>### ingress-nginx "cannot execute binary file" 错误分析与解决方案 #### 错误原因分析 1. **文件权限问题** 当尝试执行没有执行权限的二进制文件时会出现该错误,可通过 `ls -l` 检查文件权限: ```bash $ ls -l /nginx-ingress-controller -rw-r--r-- 1 root root 45M Jul 1 10:00 nginx-ingress-controller # 缺少x权限 ``` 2. **架构不匹配** 二进制文件与系统CPU架构不兼容(如ARM/x86_64混用),使用 `file` 命令验证: ```bash $ file nginx-ingress-controller ELF 64-bit LSB executable, ARM aarch64 # 显示架构信息 $ uname -m x86_64 # 系统架构为x86_64时出现冲突 ``` 3. **文件损坏/不完整** 下载过程中网络中断可能导致文件损坏,通过校验哈希值验证: ```bash $ sha256sum nginx-ingress-controller 对比官方发布的哈希值 ``` 4. **错误执行非二进制文件** 误将配置文件或文本文件当作可执行文件操作,常见于路径配置错误。 5. **Kubernetes配置问题** Pod的 `securityContext` 权限不足或挂载异常: ```yaml securityContext: runAsNonRoot: true readOnlyRootFilesystem: true # 可能导致无法修改文件权限 ``` --- #### 分步解决方案 1. **添加执行权限** ```bash chmod +x /nginx-ingress-controller ``` 2. **验证文件架构兼容性** ```bash # 检查二进制文件架构 file /nginx-ingress-controller # 检查系统架构 uname -m ``` 若架构不匹配,需下载对应版本: ```bash wget https://官方地址/nginx-ingress-controller-$(uname -m).tar.gz ``` 3. **重新下载完整文件** ```bash rm -f nginx-ingress-controller wget 官方下载链接 sha256sum 验证完整性 ``` 4. **确认执行路径正确** 检查Kubernetes部署文件中 `args` 字段指向正确路径: ```yaml args: - /nginx-ingress-controller # 标准路径 ``` 5. **调整Kubernetes权限配置** 修改Pod的 `securityContext`: ```yaml securityContext: allowPrivilegeEscalation: true runAsUser: 101 # 确保与容器用户ID一致 ``` 6. **查看容器日志定位问题** ```bash kubectl logs -n ingress-nginx <pod-name> --previous ``` --- #### 附加验证方法 ```bash # 在宿主机直接测试二进制文件 docker exec -it <ingress-nginx-pod> sh cd /nginx-ingress-controller ./nginx-ingress-controller --version # 观察是否报错 ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值