Distributed Conformance Protocol: a question submitted by 2pc in the second phase

clipboard.png

Why does the above figure emphasize that "after the only participant who received the commit message is dead", even if a new coordinator is elected, the transaction status cannot be determined

  1. personal total feeling: suppose there are three participants. In the second stage, even if two participants receive commit, after the third participant hangs up and restarts, the coordinator will not know whether its transaction has been committed or not.
  2. another question about the two-phase submission:
    in the second stage, participants will respond to ack
    when either commit or rollback, is executed. Then what happens if the coordinator times out or downtime when returning to the coordinator at this time?

    I feel that a lot of materials are very simple (inconsistent, single point, Synchronize blocking), but I feel personally. These problems also have to be subdivided to see which stage and which period of time they occurred, so that the problems will be exposed


there are three types of exceptions:

  1. there is no downtime for the coordinator and downtime for the participants;
  2. the coordinator is down and the participants are not down;
  3. the coordinator is down, and so are the participants;

for (1), when a participant goes down during a transaction, after he restarts, he can know whether the transaction has been committed or not by asking other participants or coordinators.

for (2), after the coordinator goes down, you can start a new coordinator, and then query whether the status of all participants has commit, and if so, continue to commit,. If none, then abort.

for (3), it is the only thing that cannot be solved by 2PC: when the coordinator goes down after sending the commit message, and the only participant who receives this command also goes down, the transaction is in an unknown state, and no one knows whether the transaction is committed or uncommitted, which requires the intervention of the database administrator to prevent the database from entering an inconsistent state. Of course, if there is a premise that all nodes or network anomalies will eventually recover, then the problem will not exist, the coordinator and participants will eventually restart, and other nodes will eventually receive commit T messages.

MySQL Query : SELECT * FROM `codeshelper`.`v9_news` WHERE status=99 AND catid='6' ORDER BY rand() LIMIT 5
MySQL Error : Disk full (/tmp/#sql-temptable-64f5-1e93ae3-45ef9.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
MySQL Errno : 1021
Message : Disk full (/tmp/#sql-temptable-64f5-1e93ae3-45ef9.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
Need Help?