问题描述
为了自动扩展我们的 presto 集群，我们喜欢在让 EC2 终止它之前优雅地关闭一个 presto 工作线程.执行以下命令后
As part of effort to auto-scale our presto cluster, we like to graceful shutdown a presto worker before let EC2 terminate it. After following command
curl -v -XPUT --data '"SHUTTING_DOWN"' -H "Content-type: application/json" http://250.0.46.167:8081/v1/info/state
工作日志立即显示com.facebook.presto.server.GracefulShutdownHandler Shutdown requests"，很快协调器中的节点更改为shutting_down"状态.工作进程在 4 分钟后最终退出(由于 2 分钟的双重宽限期而不是挂起的查询).
The worker log indicates "com.facebook.presto.server.GracefulShutdownHandler Shutdown requested" immediately and soon the node in coordinator change to "shutting_down" state. The worker process finally exit after 4 minutes (due to double grace period of 2 minutes instead of pending query).
到目前为止一切顺利，但对于任何托管守护程序来说都符合预期.工作进程立即重新启动，很快该节点在协调器中恢复为活动"状态.
So far so good, however as expected for any managed daemon. The worker process is immediately restarted, and soon the node is back to "active" in coordinator.
我们希望 Presto 中的优雅关闭大致如下工作:关闭请求将发送到协调器(而不是工作器).协调器告诉工作器关闭，然后逻辑地将其从活动节点列表中删除.如果 Worker 重新启动并重新注册，则协调器将在接下来的一个小时内忽略它.
We wish the graceful shutdown in Presto roughly work like below: shutdown request will be sent to the coordinator (instead of worker). coordinator tells the worker to shutdown and later logically removes it from active node list. If the worker restarts and register back, coordinator will ignore it for the next hour.
我想知道当前的 Presto 集群所有者/运营商如何处理这个问题?
I wonder how current Presto clusters owner/operators handle this issue?
推荐答案
正常关闭文档包含 HTTP PUT 的所有相关详细信息，以及它的整体工作原理.
The graceful shutdown documentation includes all relevant details of the HTTP PUT, and how it works overall.
通常集群节点通常会运行很长时间.协调器在关闭时自动停止对工作线程的调度并将其从池中移除.
Typically cluster nodes a generally running for very long periods of time. The coordinator automatically stops scheduling to the worker in shutdown and removes it form the pool.
这篇关于Presto Worker 正常关机的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！