Hi. I'm novie of presto.
Do you, guys have plan to support multiple coodinator?
I have known discovery.uri have only one host. I hope to support multiple coodinators of discovery.uri.
If I wrong, please take a example. It is very helpful for me.
knight1128
All 8 comments
The same issue reported here (on a later date but better explained).
sbmaggarwal
on 26 Sep 2018
That describes multiple coordinators for performance scaling clusters.
It would be nice if presto supported coordinator HA to start with.
One could use a load balancer for coordinator high availability, I have HAProxy config for this and other related Big Bata and NoSQL tech here:
HariSekhon
on 26 Sep 2018
That describes multiple coordinators for performance scaling clusters.
It would be nice if presto supported coordinator HA to start with.
One could use a load balancer for coordinator high availability, I have HAProxy config for this and other related big data and nosql tech here:
Hi Hari, sorry to disturb you. I tried to deploy a presto cluster with multiple active coordinator nodes, and use haproxy to achieve high availability. But I got a lot of warnings in SqlTaskManager, talking about the node is switching coordinator affinity from one to other. Is that ok?
Thanks a lot
ZJULothar
on 23 Nov 2018
Hi @ZJULothar I am not sure about the HAProxy but as of now, PrestoDB doesn't support having multiple coordinators and this is what happens if you try to configure multiple coordinators, the nodes infinitly switch between those coordinators whenever each coordinator ask for a heartbeat.
sbmaggarwal
on 23 Nov 2018
@sbmaggarwal OK, thanks for your reply
ZJULothar
on 23 Nov 2018
Did you use the config at the link I provided? That should do an Active / Backup style HAProxy which means the second coordinator should not be used unless the first goes down. The issue you face might be if the first coordinator fails, then the second is contacted to learn the node addresses, then the first coordinator recovers at which point the first and second coordinator both request node heartbeats. One thing to try might be to restart the second coordinator once the first one comes back up to see if that clears its node info (unless its stored to disk? - it's been a while since I worked on this so I can't remember the behaviour).
The other alternative is to use heartbeat / pacemaker traditional active/standby clustering to keep one coordinator shut down until the other one fails, at which point the cluster tech would start up the other coordinator and fail over the VIP to that server so that worker nodes would transparently contact the second coordinator at the same IP address.
I would definitely like to see better native support for coordinator HA, including documentation, rather than admins having to come up with their own solutions.
HariSekhon
on 23 Nov 2018
@HariSekhon I got it, thanks buddy
ZJULothar
on 23 Nov 2018
This issue has been automatically marked as stale because it has not had any activity in the last 2 years. If you feel that this issue is important, just comment and the stale tag will be removed; otherwise it will be closed in 7 days. This is an attempt to ensure that our open issues remain valuable and relevant so that we can keep track of what needs to be done and prioritize the right things.
![stale[bot] picture](https://avatars.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 26 Nov 2020
Related issues
shigechuanqi
路
3Comments
tomz
路
3Comments
aandis
路
4Comments
tesseract2048
路
3Comments
cps333
路
3Comments
Most helpful comment
Did you use the config at the link I provided? That should do an Active / Backup style HAProxy which means the second coordinator should not be used unless the first goes down. The issue you face might be if the first coordinator fails, then the second is contacted to learn the node addresses, then the first coordinator recovers at which point the first and second coordinator both request node heartbeats. One thing to try might be to restart the second coordinator once the first one comes back up to see if that clears its node info (unless its stored to disk? - it's been a while since I worked on this so I can't remember the behaviour).
The other alternative is to use heartbeat / pacemaker traditional active/standby clustering to keep one coordinator shut down until the other one fails, at which point the cluster tech would start up the other coordinator and fail over the VIP to that server so that worker nodes would transparently contact the second coordinator at the same IP address.
I would definitely like to see better native support for coordinator HA, including documentation, rather than admins having to come up with their own solutions.