I have few questions regarding master-slave architecture:
Default MySQL replication does not provide any form of leader election.
MySQL replication is asynchronous by default. That is, you can commit a transaction on the primary without waiting for the transaction to be transmitted to replicas and replayed there. If it were synchronous, it would hinder fast commit on the primary too much.
Because you cannot assume the replica is in sync, this blocks the feature of automatic leader election.
There are alternative clustering technologies like InnoDB Cluster or Galera that enforce more or less synchronous commits more strictly. This creates a more reliable opportunity to elect a new primary in case of a failure but it also has a disadvantage that it imposes a limit the transactions per second on the primary.
MySQL optionally supports "semi-synchronous" mode. When you commit, at least one replica that is in semi-synchronous mode must confirm that it received the transaction. It doesn't need to replay that transaction, it just needs to receive the log. This is a compromise, because it does block the commit on the primary a little bit, but hopefully not as much. Still, the replica may be lagging behind, if transactions are accumulating faster than it takes to apply them on the replica.
