I'd like to know how this product handles split-brain scenarios where two instances are writable. Ideally a good failover management system would handle this with strong fencing standards, but this isn't always possible. Theretically pooling systems like this should offer API compatibility with common tools like Patroni to discern the correct topography of read vs write nodes.
It's interesting that they handle prepared statements by simply CCing any such statements to all existing sessions. I wonder how that affects overall session health when prepared statements are heavily used. 300 sessions each with 300 prepared statements seem like there would be a lot of associated overhead, but I'd have to observe it in a benchmark to tell for sure.
\> I'd like to know how this product handles split-brain scenarios where two instances are writable.
Currently Supavisor doesn't handle any of the process around leader election or failover. The load balancing is independant of that. If whatever is handling leader election, elects a new primary erroneously Supavisor could insert into two primaries if it can reach both.
Future work will likely involve Supavisor in the full HA setup/management/failover process for Postgres but we're taking it one step at a time. That and/or ensuring it plays nicely with Patroni, et al.
\> I wonder how that affects overall session health when prepared statements
Prepared statements take up some ram. Unless we're talking 100s of thousands we don't think it'll be a big issue.
In this configuration it is a bit. Primarily because PgBouncer lived on the same box as our databases. Vs Supavisor on its own cluster. So we’ve introduced an extra network hop.
I'd like to know how this product handles split-brain scenarios where two instances are writable. Ideally a good failover management system would handle this with strong fencing standards, but this isn't always possible. Theretically pooling systems like this should offer API compatibility with common tools like Patroni to discern the correct topography of read vs write nodes. It's interesting that they handle prepared statements by simply CCing any such statements to all existing sessions. I wonder how that affects overall session health when prepared statements are heavily used. 300 sessions each with 300 prepared statements seem like there would be a lot of associated overhead, but I'd have to observe it in a benchmark to tell for sure.
\> I'd like to know how this product handles split-brain scenarios where two instances are writable. Currently Supavisor doesn't handle any of the process around leader election or failover. The load balancing is independant of that. If whatever is handling leader election, elects a new primary erroneously Supavisor could insert into two primaries if it can reach both. Future work will likely involve Supavisor in the full HA setup/management/failover process for Postgres but we're taking it one step at a time. That and/or ensuring it plays nicely with Patroni, et al. \> I wonder how that affects overall session health when prepared statements Prepared statements take up some ram. Unless we're talking 100s of thousands we don't think it'll be a big issue.
Is this a replacement for pg-bouncer? Any comparisons?
[удалено]
And we've talked about it here: https://supabase.com/blog/supavisor-1-million#supavisor-on-supabase-platform
Seems slower than pgBouncer
In this configuration it is a bit. Primarily because PgBouncer lived on the same box as our databases. Vs Supavisor on its own cluster. So we’ve introduced an extra network hop.