Mysql5.6 Semi-synchronous strategy
Mysql 5.6 uses the after commit policy when it is semi-synchronous. After a commit is made on the main library, wait for the acknowledgement to be returned from the library.
In this case, the first question of Phantom reading is that the current connected transaction cannot read this record, while the other connection can read this record because the main library has already committed the transaction.
Second, if the primary library is waiting for confirmation from the library, the main library goes down. There are two scenarios:
1. The transaction has not yet been submitted to the slave library. At this point the client will get the result of the failure. At this point, if you switch from the library to the primary library, the main library reverts to the library, and the client submits the data to the original library, it will find that the data on the original main library has been repeatedly submitted.
2. The transaction has been submitted to the slave library. At this point the main library returns a commit failure to the client, and the transaction has been committed from the library. When you commit again, you will have one more transaction from the library.
Mysql5.7 improvement of Upper half synchronization
Mysql5.7, the master-slave synchronization waits for the main library to wait until it is submitted and waits for the main library to commit, that is, before commit. This ensures that the main library commits the transaction and returns after the transaction has been committed from the library. To some extent, it solves the problem that the Lord never agrees.
Also, the RPL Semi sync Master wait_point configuration is provided on Mysql5.7 to determine where the half-sync is waiting to be returned from the library.
Rpl_semi_sync_master_wait_point
After
SYNC
The new semi-synchronous scheme, waiting Slave dump, precedes storage commit.
COMMIT
Old semi-synchronous scheme, waiting Slave dump after storage commit.
Mysql5.7 Semi-synchronous improvement