Add support for node priority #492
Comments
arssher
added a commit
to postgrespro/stolon
that referenced
this issue
Mar 11, 2019
Sentinel will promote keeper with higher priority than the current one if this is possible. In async mode this is a bit non-deterministic because we always elect node with highest LSN, and under heavy load prioritized node might never report LSN higher than its stronger competitors. However, if nodes are equal this should happen at some moment. In sync mode, we can just elect any of synchronous standbies. Implements sorintlab#492
Open
arssher
added a commit
to postgrespro/stolon
that referenced
this issue
Jun 30, 2019
Sentinel will promote keeper with higher priority than the current one if this is possible. In async mode this is a bit non-deterministic because we always elect node with highest LSN, and under heavy load prioritized node might never report LSN higher than its stronger competitors. However, if nodes are equal this should happen at some moment. In sync mode, we can just elect any of synchronous standbies. Priority can be set during keeper start (--priority) or later with new command 'stolonctl set keeperpriority'. The latter allows to update priority without restarting the keeper (and its Postgres instance), which can be used for controlled failover. Implements sorintlab#492
arssher
added a commit
to postgrespro/stolon
that referenced
this issue
Jun 30, 2019
Sentinel will promote keeper with higher priority than the current one if this is possible. In async mode this is a bit non-deterministic because we always elect node with highest LSN, and under heavy load prioritized node might never report LSN higher than its stronger competitors. However, if nodes are equal this should happen at some moment. In sync mode, we can just elect any of synchronous standbies. Priority can be set during keeper start (--priority) or later with new command 'stolonctl set keeperpriority'. The latter allows to update priority without restarting the keeper (and its Postgres instance), which can be used for controlled failover. Implements sorintlab#492
arssher
added a commit
to postgrespro/stolon
that referenced
this issue
Jul 1, 2019
Sentinel will promote keeper with higher priority than the current one if this is possible. In async mode this is a bit non-deterministic because we always elect node with highest LSN, and under heavy load prioritized node might never report LSN higher than its stronger competitors. However, if nodes are equal this should happen at some moment. In sync mode, we can just elect any of synchronous standbies. Priority can be set during keeper start (--priority) or later with new command 'stolonctl set keeperpriority'. The latter allows to update priority without restarting the keeper (and its Postgres instance), which can be used for controlled failover. Implements sorintlab#492
arssher
added a commit
to postgrespro/stolon
that referenced
this issue
Jul 1, 2019
Sentinel will promote keeper with higher priority than the current one if this is possible. In async mode this is a bit non-deterministic because we always elect node with highest LSN, and under heavy load prioritized node might never report LSN higher than its stronger competitors. However, if nodes are equal this should happen at some moment. In sync mode, we can just elect any of synchronous standbies. Priority can be set during keeper start (--priority) or later with new command 'stolonctl set keeperpriority'. The latter allows to update priority without restarting the keeper (and its Postgres instance), which can be used for controlled failover. Implements sorintlab#492
ololobus
pushed a commit
to postgrespro/stolon
that referenced
this issue
Jul 9, 2020
Sentinel will promote keeper with higher priority than the current one if this is possible. In async mode this is a bit non-deterministic because we always elect node with highest LSN, and under heavy load prioritized node might never report LSN higher than its stronger competitors. However, if nodes are equal this should happen at some moment. In sync mode, we can just elect any of synchronous standbies. Priority can be set during keeper start (--priority) or later with new command 'stolonctl set keeperpriority'. The latter allows to update priority without restarting the keeper (and its Postgres instance), which can be used for controlled failover. Implements sorintlab#492
ololobus
pushed a commit
to postgrespro/stolon
that referenced
this issue
Jul 9, 2020
Sentinel will promote keeper with higher priority than the current one if this is possible. In async mode this is a bit non-deterministic because we always elect node with highest LSN, and under heavy load prioritized node might never report LSN higher than its stronger competitors. However, if nodes are equal this should happen at some moment. In sync mode, we can just elect any of synchronous standbies. Priority can be set during keeper start (--priority) or later with new command 'stolonctl set keeperpriority'. The latter allows to update priority without restarting the keeper (and its Postgres instance), which can be used for controlled failover. Implements sorintlab#492
ololobus
pushed a commit
to postgrespro/stolon
that referenced
this issue
Jul 10, 2020
Sentinel will promote keeper with higher priority than the current one if this is possible. In async mode this is a bit non-deterministic because we always elect node with highest LSN, and under heavy load prioritized node might never report LSN higher than its stronger competitors. However, if nodes are equal this should happen at some moment. In sync mode, we can just elect any of synchronous standbies. Priority can be set during keeper start (--priority) or later with new command 'stolonctl set keeperpriority'. The latter allows to update priority without restarting the keeper (and its Postgres instance), which can be used for controlled failover. Implements sorintlab#492
|
I tried this in different places and tools and at first it feels okay, but in edge situations it makes things worse:
I short:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Submission type
Enhancement Description
I think it would be a valuable feature to be able to give preference to a node (or nodes) for master election. This could be via a flag or a numeric value. This could be applied at a per keeper setting, or a cluster setting that says "try and keep master at this node."
My reasoning for this is that it could be cost efficient (this is my use case) to setup a cluster where one node is better specked than the others in order to better handle incoming writes. It would make sense for Stolon to try and make sure this node is always master. If it goes down, then Stolon would move master to another node, but when it comes back up, Stolon would move master back to this node.
The text was updated successfully, but these errors were encountered: