Question about MySQL Semisynchronous Replication I was researching about MySQL Semisynchronous Replication, my understanding about the workflow is the follow:


Master Receive a successful transaction from a client session.
Master write it to his binaty log
Master wait for rpl_semi_sync_master_timeout milliseconds to receive an acknowledgment from at least one slave
Slave pick this successful transaction, write it to his relay log, flush it to disk
Slave return an acknowledgment to master
Master return successful to his client session.


My question is, at any point, this type of replication ensures that the transaction is executed on slave(SQL_TREAD applies it). Having in mind that it will add a delay on each transaction and in a case of master failure, is not 100% guaranteed that the slave will be consistent with master, what is the benefit(s) of using this type of replication?
Baron Schwartz wrote an excellent article on this, and I think one key sentence answers your question:


  What does semi-synchronous replication guarantee me then? If there are no errors or timeouts, then the guarantee is essentially that only one transaction per client is likely to be lost if the master crashes.


So semi-synchronous replication minimises (but doesn't entirely eliminate) the chance of this exact problem:


Replicant B's replication IO Thread starts running behind its master - Server A - for some reason
Server A dies - unrecoverably
Transactions are lost forever


As noted in Baron's post (and based on your wording I'm sure you're aware of this), it isn't bulletproof - MySQL will fall back to regular replication if it stops getting a response from the replicants - but irrecoverable data loss is less likely to occur.

The upshot is that it prevents the situation above, it's "out of the box", and it doesn't require any third-party or infrastructure-level solutions (e.g. Galera/Xtradb Cluster, or DRBD). Whether the benefits are worth the cost is likely to vary depending on your situation.