Q: orchestrator failover defaults

[chasebolt]

I am interested to know why these two settings in the mysql-cluster chart are not set to the defaults that orchestrator recommends. Currently killing the master mysql pod (db-0) promotes the slave (db-1) but then db-0 does not rejoin back correctly and is unable to be fixed. Setting ApplyMySQLPromotionAfterMasterFailover: true corrects this issue. I am sure setting to false is intended, just trying to understand why that is.

charts/mysql-cluster/values.yaml

# `reset slave all` and `set read_only=0` on promoted master
ApplyMySQLPromotionAfterMasterFailover: false
MasterFailoverDetachReplicaMasterHost: true

orchestrator defaults listed in the docs:

ApplyMySQLPromotionAfterMasterFailover: true
MasterFailoverDetachReplicaMasterHost: false

[chasebolt]

the comment in the chart reflects the orchestrator defaults. maybe it is flipped by accident?

/cc @AMecea @rstefan1

[AMecea]

Hi @chasebolt,

This is what we intended, except the comment. We chose this configuration to let the operator mark the new master as readable. For example, if you set the cluster read_only: true then in case of a failover orchestrator will make the new master writable.

By setting ApplyMySQLPromotionAfterMasterFailover: false it won't issue a reset slave all so the new master still has set as master the old master. Using MasterFailoverDetachReplicaMasterHost: true will detach it.

In other words, the operator is responsible to make nodes writable or not.

You sad that in your case the old master doesn't rejoin, please give me more details so I can debug that. Maybe some steps to reproduce it.

Thank you for your question and for reporting this issue!

[michaellzc]

@AMecea This could be related #613