1. 什么是table_id

MySQL binlog文件按格式分为文件头部和事件信息。文件头部占4字节,内容固定为:"\xfe\x62\x69\x6e",接下来就是各个event了。event有多种类型,比如ROTATE_EVENT对应的记录了binlog切换到下一个binlog文件的信息,XID_EVENT记录了一个事务提交的相关信息。

binlog_format可以设置为statement和row的方式。当设置为statement情况下,DML会记录为原始的SQL,也就是记录在QUERY_EVENT中。而row会记录为TABLE_MAP_EVENT+ROW_LOG_EVENT(包括WRITE_ROWS_EVENT,UPDATE_ROWS_EVENT,DELETE_ROWS_EVENT)。

binlog_format设置为row时,执行一句insert,对应的binlog如下所示:

为什么一个insert在row模式下需要分解成两个event:一个Table_map,一个Write_rows?假如一个insert更新了10000条数据,那么对应的表结构信息是否需要记录10000次列?其实是对同一个表的操作,所以这里binlog只是记录了一个Table_map用于记录表结构相关信息,而后面的Write_rows记录了更新数据的行信息。他们之间是通过table_id来联系的。

table_id用来做hash key,通过set_table(table_id)的方法将某个表的信息hash到cache中;又可以通过get_table()方法来根据table_id获得对应的表信息。

要注意table_id并不是固定的绑定在一个表上,它是表载入table cache时临时分配的,一个不断增长的变量。

2. table_id的增长机制

连续往同一个table中进行多次DML操作,table_id不变。 一般来说,出现DDL操作时,table_id才会变化。

下图中有3个表(t1、t2、t3),执行flush tables,再进行DML操作,每个表的table_id都在增长。

如果表太多,又有频繁的flush tables,会导致table_id增长比较快。

根据MySQL binlog table_id源码分析 ,可以知道:

table id的变化依赖于table cache中是否存储了binlog操作表的表定义。如果table cache中存在,则table id不变;而当table cache中不存在时,该值根据上一次操作的table id自增1。因此,table id与实际操作的数据表没有直接对应关系,而与操作的数据表是否在table cache中有关。此外,table_definition_cache中默认存放400个表定义,如果超出该范围,会将最久未用的表定义置换出table cache。

3. table_id快速增长的风险

binlog中table_id是一个ulong类型(无符号长整形),在slave进行重做binlog events之前,会先将这个ulong的table_id(为了避免混淆,用m_table_id表示)传给一个它内部维护的一个数据结构RPL_TABLE_LIST,这个里面有一个变量table_id用来存储binlog中的m_table_id,问题出现了:数据结构的变量table_id是一个uint(无符号整形),如果m_table_id超过uint的范围会发生截断。而MySQL内部在构造hash,从hash表中取值是这样的做法:set_table(table_id),get_table(m_table_id),在两个阶段用到的key因为发生了数据截断所以必然也就不能取到预期的值。也就是说之前用uint型的table_id构建出来的key-value的hash对,用ulong型的m_table_id是无法查询到的。

具体的源码分析可以参考:淘宝物流MySQL slave数据丢失详细原因

 
4. 如何避免table_id的风险
第一,增大table cache
第二,定期检查table_id,其值不能超过uint的范围(重启主库)
第三,将RPL_TABLE_LIST这个内部数据结构里面的table_id类型改为ulong(修改MySQL源码)
 

MySQL table_id原理及风险分析的更多相关文章

  1. MySQL索引原理及慢查询优化

    原文:http://tech.meituan.com/mysql-index.html 一个慢查询引发的思考 select count(*) from task where status=2 and ...

  2. (转)MySQL索引原理及慢查询优化

    转自美团技术博客,原文地址:http://tech.meituan.com/mysql-index.html 建索引的一些原则: 1.最左前缀匹配原则,非常重要的原则,mysql会一直向右匹配直到遇到 ...

  3. MySQL索引原理及慢查询优化 转载

    原文地址: http://tech.meituan.com/mysql-index.html MySQL凭借着出色的性能.低廉的成本.丰富的资源,已经成为绝大多数互联网公司的首选关系型数据库.虽然性能 ...

  4. MySQL索引原理及慢查询优化(转)

    add by zhj:这是美团点评技术团队的一篇文章,讲的挺不错的. 原文:http://tech.meituan.com/mysql-index.html MySQL凭借着出色的性能.低廉的成本.丰 ...

  5. mysql 主从复制原理

    主从形式   mysql主从复制 灵活 一主一从 主主复制 一主多从---扩展系统读取的性能,因为读是在从库读取的: 多主一从---5.7开始支持 联级复制---     用途及条件   mysql主 ...

  6. [转]MySQL主从复制原理介绍

    MySQL主从复制原理介绍 一.复制的原理 MySQL 复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新.删除等等).每个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新,以 ...

  7. 05-雷海林-mysql备份原理与在TDSQL中的实践

    05-雷海林-mysql备份原理与在TDSQL中的实践 下载地址: http://files.cnblogs.com/files/MYSQLZOUQI/05-%E9%9B%B7%E6%B5%B7%E6 ...

  8. 【转载】MySQL索引原理及慢查询优化

    原文链接:美团点评技术团队:http://tech.meituan.com/mysql-index.html MySQL凭借着出色的性能.低廉的成本.丰富的资源,已经成为绝大多数互联网公司的首选关系型 ...

  9. MySQL查询原理及其慢查询优化案例分享(转)

    MySQL凭借着出色的性能.低廉的成本.丰富的资源,已经成为绝大多数互联网公司的首选关系型数据库.虽然性能出色,但所谓“好马配好鞍”,如何能够更 好的使用它,已经成为开发工程师的必修课,我们经常会从职 ...

随机推荐

  1. ASIHTTPRequest的使用(转)

    转载自:http://fushengfei.iteye.com/blog/1147112 博客分类: IOS   原文地址:http://wiki.magiche.net/pages/viewpage ...

  2. iOS基本网络请求

    常见的网络请求有同步GET, 同步POST, 异步GET, 异步POST. GET请求和POST请求的区别: 1. GET请求的接口会包含参数部分,参数会作为网址的一部分,服务器地址与参数之间通过 ? ...

  3. 使用Yeoman搭建 AngularJS 应用 (6) —— 让我们搭建一个网页应用

    原文地址:http://yeoman.io/codelab/review-generated-files.html 打开mytodo文件夹,你会看到现在的基架.如下图所示 在mytodo文件夹,我们能 ...

  4. [转载]easyui datagrid 时间格化(JS 日期时间本地化显示)

    easyui datagrid 日期时间显示不正常,后台java 类型为 DATE 经过JSON工具一转化传到前台来就是这样,不便 于是想格式化一下, 格式化代码 如下: [javascript] v ...

  5. ASP + ACCESS保存图片文件之实现

    con.execute "CREATE tblImg (lngId COUNTER PRIMARY KEY, binImg IMAGE)" set ads=createobject ...

  6. 网站404,500错误页面的处理,及500异常写入errorLog日志

    1.web.xml 配置 <error-page> <error-code>404</error-code> <location>/404.jsp< ...

  7. What is the innovator’s solution——什么才是创新的解决方案2

    前略:http://www.cnblogs.com/Kassadin/p/4233497.html 案例1 从书上的一个案例开始: 让我们来看看AT&T公司(美国电话电报公司)的案例吧.198 ...

  8. 分布式事务的管理--atomikos

    在一些业务场景及技术架构下,跨库的事务时不可避免的,这时候如何统一管理事务,保证事务的强一致性是整个系统稳定.可用基石.一些中间件如tuxedo.cics就是凭借这个能力占据了金融.电信.银行等很大的 ...

  9. windows编译 obs-studio

    github下载源码 https://github.com/jp9000/obs-studio 还需要一个开发包 http://code.fosshub.com/OBS/download/depend ...

  10. jdk1.8.0_101/bin下各文件解释

    appletviewer - Runs applets outside of a web browser. extcheck - Detects version conflicts between a ...