MySQL 关于slave端Retrieved_Gtid_Set的读取改进初探

阅读全文请点击

本文为以后学习SLAVE做一个记录不保证正确性。因为算法没看懂。

---

一、问题由来

今天朋友问我这样一个问题@K.I.S.S，在官方文档中有这样一段描述：

When using GTIDs, the slave tells the master which transactions it has already received, executed, or both. To compute this set, it reads 
the global value of gtid_executed and the value of the Retrieved_gtid_set column from SHOW SLAVE STATUS. The GTID of the last transmitted 
transaction is included in Retrieved_gtid_set only when the full transaction is received. The slave computes the following set:
UNION(@@global.gtid_executed, Retrieved_gtid_set)
Prior to MySQL 5.7.5, the GTID of the last transmitted transaction was included in Retrieved_gtid_set even if the transaction was only 
partially transmitted, and the last received GTID was subtracted from this set. (Bug #17943188) Thus, the slave computed the following set:
UNION(@@global.gtid_executed, Retrieved_gtid_set - last_received_GTID)

问为什么要减去last_received_GTID。

二、查看Bug #17943188的commit

对于这个问题我先查看了一下这个bug到底修复了什么问题如下：

 BUG#17943188 SHOW SLAVE STATUS/RETRIEVED_GTID_SET MAY HAVE PARTIAL TRX
                 OR MISS COMPLETE TRX
    
    Problem:
    =======
    
    The SHOW SLAVE STATUS command contains the column RETRIEVED_GTID_SET.
    This is supposed to contain the set of GTIDs that exist in the relay
    log. However, the field is updated when the slave receiver thread
    (I/O thread) receives a Gtid_log_event, which happens at the beginning
    of the transaction.
    
    If the I/O thread gets disconnected in the middle of a transaction,
    RETRIEVED_GTID_SET can contain a GTID for a transaction that is only
    partially received in the relay log. This transaction will
    subsequently be rolled back, so it is wrong to pretend that the
    transaction is there.
    
    Typical fail-over algorithms use RETRIEVED_GTID_SET to determine which
    slave has received the most transactions to promote the slave to a
    master. This is true for e.g. the mysqlfailover utility.
    
    When RETRIEVED_GTID_SET can contain partially transmitted transactions,
    the fail-over utility can choose the wrong slave to promote. This can
    lead to data corruption later.
    
    This means that even if semi-sync is enabled, transactions that have
    been acknowledged by one slave can be lost.
    
    Fix:
    ===
    
    It was implemented a transaction boundaries parser that will give
    information about transaction boundaries of an event stream based on
    the event types and their queries (when they are Query_log_event).
    
    As events are queued by the I/O thread, it feeds the Master_info
    transaction boundary parser. The slave I/O recovery also uses the
    transaction parser to determine if a given GTID can be added to the
    Retrieved_Gtid_Set or not.
    
    When the event parser is in GTID state because a Gtid_log_event was
    queued, the event's GTID isn't added to the retrieved list yet.
    It is stored in an auxiliary GTID variable.
    
    After flushing an event into the relay log, the IO thread verifies if
    the transaction parser is not inside a transaction anymore (meaning
    that the last event of the transaction has been flushed).
    
    If transaction parser is outside a transaction, the I/O thread
    verifies if a GTID was stored in the start of the transaction, adding
    it to the retrieved list, ensuring that all the transaction has arrived
    and was flushed to the relay log.
    
    Also, before this patch, after the I/O thread flushed a single received
    event into the relaylog, it was possible to rotate the relaylog if the
    current relaylog file size exceeded max_binlog_size/max_relaylog_size.
    After this patch, when GTIDs are enabled we only allow this rotation by
    size if the transaction parser is not in the middle of a transaction.
    
    Note: The current patch removed the changes for BUG#17280176, as it
          also dealt with similar problem in a different way.