Repository navigation
Replies: 1 comment
|
Thanks @ksyblast for your input. We have actually opened an issue for the problem you experienced (#2863). We are actually making several changes to the way we control both shutdown and startup of the Postgres cluster. All of them will be in the next 1.21.0 release (and related minor updates), primarily #2848 #2847 and #2846. Those settings are described in the new "Instance manager" source page. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello!
Currently I am choosing a postgresql operator and I am performing some tests.
I have performed some failover tests (draining node with primary pod, deleting primary pod, shutting down the node). During these tests I have noticed that setting low CPU requests value results in quite a long switchover - sometimes it took up to 10 seconds, and once I have even caught a crash (please see attached - promoting-err.txt). By switchover here I mean the delay when the -rw endpoint becomes available after the primary is switched.
Even increasing CPU gives more than one second for the -rw endpoint to become available. I am also making a comparison with zalando operator based on patroni and it switches the master withing 1 second even with low CPU and RAM requests values and using the same nodes.
I haven't made any specific configuration, used the basic examples.
I am wondering if this behavior can be tuned or probably I have missed some configuration options. I would appreciate any feedback.
Version: cloudnative-pg:1.20.2
Cluster config:
Here is the replica log being promoted to the master role, in this case -rw endpoint became available in about 3.5s:
All reactions