azure-data-explorer - commands failures caused by Admin node change
问题描述
I have noticed that many times we face transient issue that anything that is running on an ADX cluster abruptly fails due to the following error:-
ADX async command has completed with a 'Abandoned' state. Status: 'Admin node has changed'
This is mostly noticed in case of commands that run for long time , obviously because the probability that admin node will change during the lifespan of the command execution increases. Is this standard behavior of an ADX cluster and that we have to take into account the fact that this may happen now and then. Is there any guidance on frequency of this happening or any hint about which circumstances cause this admin node to be changed. As for when the admin node actually changes , is there anything we can do to avoid command failures caused by it ?
解决方案
An admin node may change occasionally (e.g. once in a ~week), but it is not expected to occur frequently.
If it is happening frequently on your cluster, it may indicate something bad in the usage pattern that is overloading the admin node, poor choice of SKU (not enough CPU/RAM to handle the workload), or an issue with the service or underlying platform.
- If you're unsure of which it is - you can consider opening a support ticket.
As a side note, commands that are long-running (e.g. ~5-10 mins, or longer) are discouraged. You should follow the notes in the documentation recommending splitting a single command into multiple (shorter/lighter) ones, each handling a subset of the work to be done.
推荐阅读
- laravel - 在 Laravel 中使用验证更新头像文件上传未显示正确响应
- django - 通过按月份和类别分组来绘制模型
- javascript - 读取状态并赋予用户角色
- javascript - 如何在不显示 AM/PM 的情况下使用 .toLocaleTimeString()?
- docker - docker私有注册表:x509:证书由未知权限错误签名
- selenium - Python Selenium 在无头运行时截屏时导致错误
- c++ - 从一个进程向另一个 C++ 发出信号
- c++ - 我修改了 BFS 以在加权无向图中找到最短路径,而不是使用 Dijkstra 的算法并且它有效
- list - 我如何从颤动的列表中打印随机任务/项目?- 而不是显示列表的内容,它只打印“任务的实例”?
- reactjs - tampermonkey/greasemonkey 脚本来填写 REACTJS 表单?