Presto协调器没有内置的高可用性支持。这是一个单点故障。有没有办法克服这个问题？
j8yoct9x1#
HA可以有多种含义。正在进行的查询没有HA，Presto项目也没有为协调器提供HA，因为这本质上需要绑定到部署和监视系统。您的选项包括：
目前这些解决方案都是有限的，它们无法帮助正在进行或当前排队的查询避免失败，所以您仍然需要在客户端进行某种重试。您可以关注https://github.com/trinodb/trino/issues/455，了解Presto未来的改进，这将允许更大的弹性。
ffx8fchx2#
Presto协调器高可用性设置（如果协调器关闭，正在进行的查询将受到影响）主动/主动要求
或者
N是快速聚类的数目。
客户端配置了一个未用作服务器名的elb主机名。在当前设置中，presto.client.abc.com.
Presto查询协议https://github.com/prestodb/presto/wiki/HTTP-Protocol
这是一个基于游标的实现。一个查询产生一个游标，客户端迭代这个游标。每个游标迭代响应包含一个下一个uri，用于获取下一组结果。所有查询的下一个uri链接必须路由到处理原始查询的协调器。使用nginx服务器名绑定一个查询到一个协调器。也可以设置多个端口（ELB有多个端口而不是多个主机名）。
mqkwyuun3#
由于您询问了Prestodb，因此正在研究单个协调器的问题，以便为prestodb设计多个协调器。在当前的协调器设计中，这是一个很难解决的问题。正如您提到的，在两个协调器上使用HAProxy是目前实现某种协调器HA的最佳方法。如果您在Kubernetes中运行container，K8可以检测到一个关闭的pod，并自动重启协调器，从而在一定程度上为您提供高可用性。虽然AWS EMR提供了多主机环境，但由于Presto不支持多个协调器，因此目前不支持。（该功能不在可以使用该功能的服务列表中）
3条答案
按热度按时间j8yoct9x1#
HA可以有多种含义。
正在进行的查询没有HA，Presto项目也没有为协调器提供HA，因为这本质上需要绑定到部署和监视系统。
您的选项包括：
目前这些解决方案都是有限的，它们无法帮助正在进行或当前排队的查询避免失败，所以您仍然需要在客户端进行某种重试。您可以关注https://github.com/trinodb/trino/issues/455，了解Presto未来的改进，这将允许更大的弹性。
ffx8fchx2#
Presto协调器高可用性设置
（如果协调器关闭，正在进行的查询将受到影响）
主动/主动
要求
或者
N是快速聚类的数目。
客户端配置了一个未用作服务器名的elb主机名。在当前设置中，presto.client.abc.com.
Presto查询协议https://github.com/prestodb/presto/wiki/HTTP-Protocol
这是一个基于游标的实现。一个查询产生一个游标，客户端迭代这个游标。每个游标迭代响应包含一个下一个uri，用于获取下一组结果。所有查询的下一个uri链接必须路由到处理原始查询的协调器。
使用nginx服务器名绑定一个查询到一个协调器。也可以设置多个端口（ELB有多个端口而不是多个主机名）。
mqkwyuun3#
由于您询问了Prestodb，因此正在研究单个协调器的问题，以便为prestodb设计多个协调器。
在当前的协调器设计中，这是一个很难解决的问题。
正如您提到的，在两个协调器上使用HAProxy是目前实现某种协调器HA的最佳方法。
如果您在Kubernetes中运行container，K8可以检测到一个关闭的pod，并自动重启协调器，从而在一定程度上为您提供高可用性。
虽然AWS EMR提供了多主机环境，但由于Presto不支持多个协调器，因此目前不支持。（该功能不在可以使用该功能的服务列表中）