めっちゃ参考になるやつ。
yakst.com

フェイルオーバーはしても Non-GTID だと CHANGE MASTER が実行されずに孤立した。
けど、↑ の yakst を見ると何も問題ないように書かれてる。
公式ドキュメントにも、GTID(Pseudo−GTID）じゃないと孤立するよとは書かれている。

github.com

A “simple” recovery case is that of a DeadIntermediateMaster. Its slaves are orphaned, but when using GTID or Pseudo-GTID they can still be re-connected to the topology

特定のノードは Master に昇格したくない！

$ orchestrator -c register-candidate -i "10.194.10.95:3306" --promotion-rule "must_not"

※ Orchestrator（レプリケーション）で IP ベースの場合、FQDN で指定しても効かない

複数ある場合

$ orchestrator -c register-candidate -i "10.194.10.30:3306" --promotion-rule "must_not"
$ orchestrator -c register-candidate -i "10.194.10.25:3306" --promotion-rule "must_not"
$ orchestrator -c register-candidate -i "10.194.10.20:3306" --promotion-rule "must_not"

cron で回す

もしかしたら orchestrator の設定でどのクラスタに所属したとしても、特定のノードだけは Master に昇格させない方法があるかもしれないけどドキュメント見てもよく分からんかった。
ちなみにこの register-candidate はクラスタが変わるごとにリセットされるっぽいので cron で定期的に回すのが良さそう。
Booking.com でもこの手法らしい。