温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

怎么理解MySQL中的table_id

发布时间:2021-11-18 16:20:25 来源:亿速云 阅读:391 作者:iii 栏目:MySQL数据库

本篇内容介绍了“怎么理解MySQL中的table_id”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

一 table_id 介绍
    当MySQL 开启日志模式时,binlog会记录所有对数据库的变更操作。binlog 分两种模式 statement 模式和row 模式。
当数据库的binlog format 是statement 模式时
例子:数据库中执行 一条语句
root@rac2 [yangyi]> insert into t1 values(9);                
Query OK, 1 row affected (0.00 sec)
root@rac2 [yangyi]> show binlog events in 'mysql-bin.000003';
+------------------+-----+-------------+-----------+-------------+----------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                   |
+------------------+-----+-------------+-----------+-------------+----------------------------------------+
| mysql-bin.000003 |   4 | Format_desc |         2 |         106 | Server ver: 5.1.68-log, Binlog ver: 4  |
| mysql-bin.000003 | 106 | Query       |         2 |         176 | BEGIN                                  |
| mysql-bin.000003 | 176 | Query       |         2 |         265 | use `yangyi`; insert into t1 values(8) |
| mysql-bin.000003 | 265 | Xid         |         2 |         292 | COMMIT /* xid=12 */                    |
| mysql-bin.000003 | 292 | Query       |         2 |         369 | use `yangyi`; flush tables             |
| mysql-bin.000003 | 369 | Query       |         2 |         439 | BEGIN                                  |
| mysql-bin.000003 | 439 | Query       |         2 |         528 | use `yangyi`; insert into t1 values(9) |
| mysql-bin.000003 | 528 | Xid         |         2 |         555 | COMMIT /* xid=15 */                    |
+------------------+-----+-------------+-----------+-------------+----------------------------------------+
8 rows in set (0.00 sec)
binlog 的log event 记录如下:
#140511 14:44:12 server id 2  end_log_pos 439   Query   thread_id=1     exec_time=0     error_code=0
SET TIMESTAMP=1399790652/*!*/;
BEGIN
/*!*/;
# at 439
#140511 14:44:12 server id 2  end_log_pos 528   Query   thread_id=1     exec_time=0     error_code=0
SET TIMESTAMP=1399790652/*!*/;
insert into t1 values(9)
/*!*/;
# at 528
#140511 14:44:12 server id 2  end_log_pos 555   Xid = 15
COMMIT/*!*/;
从日志分析来看 ,DML会记录为原始的SQL,也就是记录在QUERY_EVENT中。 

当数据库的binlog format 是row模式时
执行insert 操作
root@rac2 [yangyi]> insert into t1 values(6);                
Query OK, 1 row affected (0.00 sec)
root@rac2 [yangyi]> show binlog events in 'mysql-bin.000002';          
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                  |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| mysql-bin.000002 |   4 | Format_desc |         2 |         106 | Server ver: 5.1.68-log, Binlog ver: 4 |
| mysql-bin.000002 | 106 | Query       |         2 |         176 | BEGIN                                 |
| mysql-bin.000002 | 176 | Table_map   |         2 |         219 | table_id: 18 (yangyi.t1)              |
| mysql-bin.000002 | 219 | Write_rows  |         2 |         253 | table_id: 18 flags: STMT_END_F        |
| mysql-bin.000002 | 253 | Xid         |         2 |         280 | COMMIT /* xid=61 */                   |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
5 rows in set (0.00 sec)
binlog中记录的信息:
BEGIN
/*!*/;
# at 176
# at 219
#140511 14:31:43 server id 2  end_log_pos 219   Table_map: `yangyi`.`t1` mapped to number 18
#140511 14:31:43 server id 2  end_log_pos 253   Write_rows: table id 18 flags: STMT_END_F
BINLOG '
TxlvUxMCAAAAKwAAANsAAAAAABIAAAAAAAEABnlhbmd5aQACdDEAAQMAAQ==
TxlvUxcCAAAAIgAAAP0AAAAAABIAAAAAAAEAAf/+BgAAAA==
'/*!*/;
### INSERT INTO `yangyi`.`t1`
### SET
###   @1=6 /* INT meta=0 nullable=1 is_null=0 */
# at 253
#140511 14:31:43 server id 2  end_log_pos 280   Xid = 61
COMMIT/*!*/;
   从解析的binlog中可以看出row模式下,DML操作会记录为:TABLE_MAP_EVENT+ROW_LOG_EVENT(包括WRITE_ROWS_EVENT ,UPDATE_ROWS_EVENT,DELETE_ROWS_EVENT).
   为什么一个update在ROW模式下需要分解成两个event:一个Table_map,一个Update_rows。我们想象一下,一个update如果更新了10000条数据,那么对应的表结构信息是否需要记录10000次?其实是对同一个表的操作,所以这里binlog只是记录了一个Table_map用于记录表结构相关信息,而后面的Update_rows记录了更新数据的行信息。他们之间是通过table_id来联系的。 

二 table_id 的特性
  1 table_id 并不是固定的,它是当表被载入内存(table_definition_cache)时,临时分配的,是一个不断增长的变量。  
  2 当有新的table变更时,在cache中没有,就会触发一次load table def的操作,此时就会在原先最后一次table_id基础上+1,做为新的table def的id。
  3 flush tables,之后对表的更新操作也会触发table_id 的增长。
  4 如果table def cache过小,就会出现频繁的换入换出,从而导致table_id增长比较快。
例子
root@rac2 [yangyi]> show binlog events in 'mysql-bin.000002';
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                  |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| mysql-bin.000002 |   4 | Format_desc |         2 |         106 | Server ver: 5.1.68-log, Binlog ver: 4 |
| mysql-bin.000002 | 106 | Query       |         2 |         176 | BEGIN                                 |
| mysql-bin.000002 | 176 | Table_map   |         2 |         219 | table_id: 18 (yangyi.t1)              |
| mysql-bin.000002 | 219 | Write_rows  |         2 |         253 | table_id: 18 flags: STMT_END_F        |
| mysql-bin.000002 | 253 | Xid         |         2 |         280 | COMMIT /* xid=61 */                   |
| mysql-bin.000002 | 280 | Query       |         2 |         357 | use `yangyi`; flush tables            |
| mysql-bin.000002 | 357 | Query       |         2 |         427 | BEGIN                                 |
| mysql-bin.000002 | 427 | Table_map   |         2 |         470 | table_id: 19 (yangyi.t1)              |
| mysql-bin.000002 | 470 | Write_rows  |         2 |         504 | table_id: 19 flags: STMT_END_F        |
| mysql-bin.000002 | 504 | Xid         |         2 |         531 | COMMIT /* xid=65 */                   |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
10 rows in set (0.00 sec)

三 table_id在主从复制过程中转变  
     每一个dml操作表的信息都被会记录table_mapping的hash数据结构中,hash的key就是ulong型的table_id,hash的值就是TABLE*的数据结构(包含了表的各种信息,包括数据库名,表名,字段数,字段类型等),通过set_table()方法来hash,通过get_table()方法来根据table_id获得对应的表信息。
    当主库的日志传递到备库时,每一个log_event都是通过do_apply_event()方法来将event应用到本地数据库中。在apply relay log中的event时,do_apply_event()将ulong型的m_table_id(binlog记录的table_id)赋值给RPL_TABLE_LIST结构中的uint型的table_id。核心问题出现了: 如果binlog 中的table_id 的值大于max(uint),在变量传递是,就会发生截断。
而MySQL内部使用set_table(table_id)构造hash,使用get_table(m_table_id)从hash表中取值,在两个阶段用到的key因为发生了数据截断,所以必然也就不能取到预期的值。也就是说之前用uint型的table_id构建出来的key-value的hash对,用ulong型的m_table_id是无法查询到的。

四 风险与解决
  从第二,三点我们知道当table_id 过快增长,会导致从库应用binlog无法解析到对应的表,造成数据不一致的情况。
解决方法:
 1 加大 table cache 的大小。
 2 重启主库使table_id 归0,缺点 成本比较高,出现此问题的时候,主备已经不一致,线上环境 不能完成切换。
 3 修改MySQL源码,将 RPL_TABLE_LIST结构中的uint型的table_id修改为ulong型 ,一劳永逸。

“怎么理解MySQL中的table_id”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站,小编将为大家输出更多高质量的实用文章!

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI