MySQL Replication--TABLE_ID与行格式复制

青旅半醒 2021-10-25 14:16 119阅读 0赞

BINLOG中的TABLE\_ID

在ROW格式的二进制中，事件信息中没有列的信息，需要通过Table\_Map将表名对于的表信息加载到cache中，然后根据事件信息中的列下标来定位到数据列，每次表信息加载到Cache中时，会得到一个自增的ID值，即Table\_ID：

# at 1794
    #190717 13:08:44 server id 4294967295  end_log_pos 1855     GTID    last_committed=5    sequence_number=6    rbr_only=yes
    /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
    SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa01:9'/*!*/;
    # at 1855
    #190717 13:08:44 server id 4294967295  end_log_pos 1919     Query    thread_id=306    exec_time=0    error_code=0
    SET TIMESTAMP=1563340124/*!*/;
    BEGIN
    /*!*/;
    # at 1919
    #190717 13:08:44 server id 4294967295  end_log_pos 1956     Rows_query
    # delete from tb001
    # at 1956
    #190717 13:08:44 server id 4294967295  end_log_pos 2002     Table_map: `db001`.`tb001` mapped to number 108
    # at 2002
    #190717 13:08:44 server id 4294967295  end_log_pos 2069     Delete_rows: table id 108 flags: STMT_END_F
    
    BINLOG '
    XK0uXR3/JQAAAKQHAACAABFkZWxldGUgZnJvbSB0YjAwMQ==
    XK0uXRP/LgAAANIHAAAAAGwAAAAAAAEABWRiMDAxAAV0YjAwMQACAwMAAg==
    XK0uXSD/QwAAABUIAAAAAGwAAAAAAAEAAgAC//wIAAAAAQAAAPwPAAAAAQAAAPwWAAAAAQAA
    APwdAAAAAQAAAA==
    '/*!*/;
    ### DELETE FROM `db001`.`tb001`
    ### WHERE
    ###   @1=8 /* INT meta=0 nullable=0 is_null=0 */
    ###   @2=1 /* INT meta=0 nullable=1 is_null=0 */
    ### DELETE FROM `db001`.`tb001`
    ### WHERE
    ###   @1=15 /* INT meta=0 nullable=0 is_null=0 */
    ###   @2=1 /* INT meta=0 nullable=1 is_null=0 */
    ### DELETE FROM `db001`.`tb001`
    ### WHERE
    ###   @1=22 /* INT meta=0 nullable=0 is_null=0 */
    ###   @2=1 /* INT meta=0 nullable=1 is_null=0 */
    ### DELETE FROM `db001`.`tb001`
    ### WHERE
    ###   @1=29 /* INT meta=0 nullable=0 is_null=0 */
    ###   @2=1 /* INT meta=0 nullable=1 is_null=0 */
    # at 2069
    #190717 13:08:44 server id 4294967295  end_log_pos 2096     Xid = 30
    COMMIT/*!*/;

在基于行的复制模式下，为什么BINLOG中使用TABLE\_ID而不直接使用表名：

1、如果某事务中一条SQL语句修改了100万行记录，那么会在该事务对应的BINLOG中记录这100万记录相应的信息，通过TABLE\_ID方式来映射表名，那么仅需要存储一次表名即可，后面的使用TABLE\_ID代替，可以有效降低BINLOG长度。

导致TABLE\_ID发生变化的操作有：

1>DDL语句执行
    2>Flush Tables语句执行
    3>Table被加载到Table Cahche

MYSQL使用Table Cache来存放表定义信息，当Table Cache中无空闲空间来存放新的表信息后，会根据算法将一部分近期没有被使用的表信息换出Table Cache。如果TableCache设置过小，而数据库中存在大量的用户表需要加载到Table Cahche中，那么会导致表定义信息频繁地被换入换出，导致Table\_ID急剧增大。

查看TABLE CACHE相关信息：

#查看TableCache的配置
    SHOW VARIABLES LIKE '%table%cache%';
    +----------------------------+-------+
    | Variable_name              | Value |
    +----------------------------+-------+
    | table_definition_cache     | 16384 |
    | table_open_cache           | 16384 |
    | table_open_cache_instances | 16    |
    +----------------------------+-------+
    
    #查看缓存的表定义信息
    SHOW STATUS LIKE '%open%table%';
    +--------------------------+-------+
    | Variable_name            | Value |
    +--------------------------+-------+
    | Com_show_open_tables     | 0     |
    | Open_table_definitions   | 118   |
    | Open_tables              | 231   |
    | Opened_table_definitions | 6     |
    | Opened_tables            | 100   |
    | Slave_open_temp_tables   | 0     |
    +--------------------------+-------+
    Open_table_definitions： The number of cached .frm files. 
    Opened_table_definitions ： The number of .frm files that have been cached.
    Open_tables： The number of tables that are open.
    Opened_tables ： The number of tables that have been opened. If Opened_tables is big, your table_open_cache value is probably too small.

如果Open\_tables等于或接近table\_open\_cache，说明Table Cache已满或已快满。  
如果Opened\_tables值较大，则说明表定义信息被频繁换入换出Table Cache，参数table\_open\_cache可能设置过小。

TABLE\_ID导致的BUG

在定义Table id时采用8byte的ulong类型列来存放，但在同步的SQL线程中使用4byte的uint类型列来存放，因此当同步的SQL线程中Table id值超过2^32的时，会导致应用SQL失败，即主库上的二进制可以同步到从库的中继日志中，但应用二进制日志日志失败，导致主从数据丢失。

PS1： 基于STATEMENT格式的二进制日志不需要使用table\_id来查看表信息  
PS2： 主库和从库上的Table ID没有任何关联关系，每个实例上的Table id都是独立生成的。

转载于:https://www.cnblogs.com/gaogao67/p/11203834.html