ITPub博客

CATS事务调度算法解决了数据库在遇到高压力情况下性能急剧下降的问题。本文将介绍CATS机制原理及其带来的性能提升。

前些天某客户反馈一个诡异的问题，一个MySQL实例一会可访问，一会不可访问，查看相关日志发现该实例反复执行高可用切换，在进行初略排查时，通过监控发现服务器故障时刻磁盘负载都较高，但是并没有完全用满。而在高可用切换之前，数据库中跑着一些insert…select语句和大量心跳检测语句，而心跳检测语句与业务表是独立的，且心跳检测语句只固定更新一行数据，怎么会被阻塞一堆心跳检测语句呢 ？经过了一番折腾总算把原因找到了，具体过程请看下文！

1、首先介绍了Redo，Undo，Log Sequence Number (LSN)，Checkpoint，Rollback Pointer (ROLL_PTR)，Transaction ID (TRX_ID)，Transaction Serialization Number(TRX_NO) 是什么？2、然后介绍了MySQL Update过程中发生了什么？Redo,Undo,双写之间如何配合，脏页何时刷新？3、最后介绍了Crash Recovery时如何做恢复？

我们都知道在MySQL搭建复制环境的时候，需要设置每个server的server_id不一致，如果主库与从库的server_id一致，那么复制会失败。但是最近在解决一个客户的问题的时候，遇到一个有意思的现象，客户环境有三台数据库服务器，一主两从，客户的两台从库设置了相同server_id，在排查问题的过程中，查看MySQL错误日志，发现有很多奇怪的信息。 我们模拟了客户的环境，并进行测试、分析，最终在代码中找到了我们想要的答案。下面就是我们测试、分析、总结的步骤以及内容。

mrr_cost_based代表是否使用基于代价的方式去计算使用MRR特性，新的系统中将他设置为off代表不使用基于代价方式而是使用基于规则的，这样设置的原因是考虑到MySQL基于代价的方式比较保守，不能使用到MRR这个特性。本身设置这个参数是没有任何问题，只不过正好遇到mrr_cost_based设置为off时碰到了这么诡异BUG，希望可以帮助到遇到同样问题的朋友们。

通过示例演示并查看过程中binlog中如何记录load data语句等方式来验证 load data语句如何保证主备复制数据一致性 * 将分别在四种隔离级别下（会话级别修改tx_isolation）针对binlog_format（会话级别修改binlog_format）的三种格式分别进行演示执行load data语句，观察MySQL server层如何处理，主库binlog中如何记录load data语句，备库的binlog中如何如何记录load data语句 * 本文假定你已经搭建好了主备复制环境，如果未搭建请先自行搭建主备复制环境

当mysql server从文本文件读取数据时，FIELDS和LINES默认值会导致LOAD DATA INFILE的行为如下：寻找换行边界字符\n来进行换行不跳过行前缀，把行前缀也当作数据（发生在如果导出数据时使用了行前缀，导入时没有指定正确的行前缀或者根本没有指定行前缀选项时）使用制表符\t来分割一行数据中的各列要注意：在FIELDS和LINES的默认值下，在解析文本文件时不会把字符串之间的引号当作真正的引号，而是当作数据