pglookout: support explicit failover priorities #125
Conversation
hnousiainen
force-pushed
the
htn_pglookout_failover_priorities
branch
from
1b86c58 to
bfc997d
Compare
In Aiven case, this would be based on the configuration delivered to the services. The priorities help to replace the implicit prioritization via instance identifies with explicit order, but both list are indeed generated from a common config. |
|
The pipeline fails for a rather silly reason: |
hnousiainen
force-pushed
the
htn_pglookout_failover_priorities
branch
from
bfc997d to
3cae7d6
Compare
Thank you. I added a quick commit to move some helper functions from test/test_lookout.py into test/utils.py in order to compact the test file a bit. |
hnousiainen
force-pushed
the
htn_pglookout_failover_priorities
branch
from
3cae7d6 to
65662c3
Compare
hnousiainen
force-pushed
the
htn_pglookout_failover_priorities
branch
4 times, most recently
from
f7704d3 to
663eee4
Compare
Export test helper functions from test/test_lookout.py into a separate common test/utils.py module. This doesn't change any actual functionality, but makes test_lookout little more compact.
Support explicit prioritization between instances. This can be configured via ``failover_priorities`` key, and will be consulted upon picking up the standby that should do the promotion in cases where multiple nodes have a matching replication position. Previously, and also as the current default, the selection was based on the sorting order of the remote nodes. The configuration option allows some additional flexibility, and supports e.g. topologies where we have more favorable and less desirable standbys in multiple different network locations.
hnousiainen
force-pushed
the
htn_pglookout_failover_priorities
branch
from
663eee4 to
56fc154
Compare
Support explicit prioritization between instances. This can be configured via
failover_prioritieskey, and will be consulted upon picking up the standby that should do the promotion in cases where multiple nodes have a matching replication position.Previously, and also as the current default, the selection was based on the sorting order of the remote nodes.
The configuration option allows some additional flexibility, and supports e.g. topologies where we have more favorable and less desirable standbys in multiple different network locations.