mysql two-phase commit

1 The two-phase commit protocol

    is generally divided into two roles: coordinator C and several transaction executors Si:
    when all sites Si executing a transaction T notify C that the transaction is completed, C starts the two-phase commit protocol.
    1. First, C sends a <prepare> message to all Sis (C first writes the <prepare> message to the local log), and after Si receives the <prepare> message, according to the execution of the local T, if it successfully returns <ready T >, returns <abort T> if unsuccessful. (The message to be returned should be written to the log before returning)
    2. After C collects all the return messages of Si (or after a timeout period), if all return <ready T>, the transaction is successful and send <commit T> to all sites, otherwise send <abort T> on transaction failure. Messages should still be written to the log before sending. After receiving C's <commit T> or <abort T>, site Si writes the message to the log, and then commits or rolls back according to the message.
    Note: C or Si writes the sent or received messages to the log first, mainly for recovery after failure. For example, after a certain Si recovers from the failure, first check the log of the local machine, if it has received <commit T>, submit it, and if <abort T>, it will roll back. If it is <ready T>, ask C again to determine the next step. If there is nothing, most likely in <prepare> Stage Si crashes and needs to be rolled back.
    The flaw with two-phase commit is that if C crashes, all Sis may need to wait for C, causing blocking.
2 The first stage of the two-stage submission process



    :
    first, the coordinator writes a log record in the log of its own node, and then all participants send a message prepare T to ask these participants (including themselves) whether they can submit this transaction;
    After the participant receives the prepare T message, it will preprocess the transaction according to its own situation. If the participant can submit the transaction, the log will be written to the disk and a ready T message will be returned to the coordinator. It enters the pre-commit state; if the transaction cannot be committed, it records the log, and returns a not commit T message to the coordinator, and at the same time undoes the database changes made on itself; the
    participant can delay the time to send the response, but in the end still needs to be sent.
    The second stage: The
    coordinator will collect the opinions of all participants. If the not commit T information sent by the participants is received, it means that the transaction cannot be committed. The coordinator will record the Abort T in the log and report it to all participants. The coordinator sends an Abort T message to let all participants revoke all pre-operations on itself;
    if the coordinator receives the prepare T message from all participants, the coordinator will write the Commit T log to disk and send it to all participants. The sender sends a Commit T message to commit the transaction. If the coordinator has not received a message from a participant, it is considered that the participant has sent a VOTE_ABORT message, thereby canceling the execution of the transaction.
    After the participant receives the Abort T information from the coordinator, the participant will terminate the submission and record the Abort T in the log; if the participant receives the Commit T information, the transaction will be submitted and written Record.
    Under normal circumstances, the two-phase commit mechanism can work well. When a participant crashes during the transaction process, after restarting, he can ask other participants or coordinators to know that the transaction has been committed. no. Of course, the premise of all this is that each participant will write a log in advance when performing each step of the operation.