In a two node setup, if the slave server breaks due to some SQL thread problem (e.g. error 1032 ER_KEY_NOT_FOUND) and then the master goes down, MaxScale will emergency promote the slave so that the cluster stays usable. This is unwanted behavior and often users would prefer that MaxScale simply waits (perhaps for a long time) for the master to come back.

The logic should be changed so that even a broken slave (SQL or IO thread stopped, but not both) prevents new master selection. Only if both are stopped (usually requires "STOP SLAVE"), new master can be selected as this means the dba is modifying the cluster.

A more resilient setup can be assumed to have multiple slaves so that at least one can be properly promoted by failover.

Original description:
Is there a way to configure maxscale to not promote a slave to master if the slave is still applying relay logs (behind master)?
Related Jira issue: MDEV-32370