MySQL内核月报 2014.10-TokuDB·　主备复制·Read Free Replication

尽管MySQL 5.6和MariaDB 10.x在replication上已经做了不少优化，TokuDB 7.5也做了一个＂进一步＂的优化：Read Free Replication(RFR)，目的是提高备库(slave)重放速度，减少主备延迟。

RFR的原理比较简单：就是避免一些＂不必要＂的读来减少read IO。

Read IO

当在slave上执行：UPDATE/DELETE操作的时候，MySQL进行read-modify-write操作，可能会产生read IO操作，而INSERT的时候如果需要做＂唯一性＂检查，也可能会产生read IO。

什么条件下，TokuDB才可以read free呢？

  1. 主库配置必须BINLOG_FORMAT=ROW
  2. 主库上的操作不能违反唯一性约束（比如设置了＂unique_checks=OFF＂，否则主备同步会停止），这样到TokuDB备库的所有log event都默认不需要再做＂unique check＂
  3. 备库只读

同时满足以上3个条件，TokuDB的备库认为从主库过来的INSERT/UPDATE/DELETE log event均是安全的，可以不做read，直接做write操作。

从TokuDB官方测试看效果还是不错的，主库~140TPS，备库~70TPS，当开启RFR的时候，备库可以飚到1400TPS，随后与主库基本持平。

进一步的优化还在继续，希望＂妈妈＂(DBA)再也不用担心我(read only slave)的性能了。

时间： 2025-01-20 23:23:53

MySQL内核月报 2014.10-TokuDB·　主备复制·Read Free Replication的相关文章

MySQL内核月报 2014.12-MySQL·　优化改进· GTID启动优化

背景 GTID 可以说是 MySQL 5.6 版本的一个杀手级特性,它给主备复制带来了极大的便利,RDS只读实例就是强依赖于这个特性.然而GTID在给我们带来便利的同时,也埋下了许多坑,最近几期内核月报中GTID的频繁出现也说明了这一点,对其我们可以说是既爱又恨. GTID 并不是免费午餐,要使用它是要有代价的,为了保证GTID这个体系能够运转起来,需要做许多相关的工作,比如binlog里每个事务要多记 gtid_event 这种事件.写binlog的时候要生成 gtid.要维护几个GTID集合

MySQL内核月报 2014.10-MySQL·　捉虫动态·从库OOM

bug背景 官方最近发布的版本(5.7.5)修复了这样一个bug,主备复制场景下,如果主库和备库对应的表结构中有数据类型不一致,并且主库的 binlog 是 row 格式的,这时候如果主库对不一致的表做了一个大事务更新,备库在应用 relay-log 的时候报OOM(Out of Memory).bug地址在这里,主备数据类型不一致主要发生在这2种情况下: 主备库版本不一致,不同版本之间的数据类型可能存在不一致.用户在报这个bug时,就是在5.5到5.6的复制场景下,用到了时间类型,时间类型在5

MySQL内核月报 2014.09-MariaDB·主备复制·CREATE OR REPLACE

MariaDB 10.0.8 版本增加了一个CREATE OR REPLACE TABLE语法,这个语法的目的是让Replication更加可靠,为什么这个语句能让复制更可靠呢? 例如用户使用CREATE ... SELECT语句,而这个语句回滚了又重新执行,备库有可能先收到一个CREATE语句,但是没收到INSERT的Events,主库重做一遍之后,备库收到CREATE语句时就会失败,而CREATE OR REPLACE则可以避免这个问题,存在的表会被替换掉. 最基本的使用例子: 这个语句其实

MySQL内核月报 2014.11-MySQL·　捉虫动态·SIGHUP 导致 binlog 写错

bug描述 这是5.6中和gtid相关的一个bug,当 mysqld 收到 sighup 信号 (比如 kill -1) 的时候,会 flush binlog,但是新生成binlog开头没写 Previous_gtids_log_event,这会导致下面 2 个问题: 这个时候 mysqld 重启的话,会发现再也起不来了,error log 里有这样的错 The binary log file 'mysql/mysql-bin.000020' is logically corrupted: Th

MySQL内核月报 2014.09-MySQL·　捉虫动态·GTID 和 DELAYED

描述 这是一个MySQL 5.6才有的bug,影响包含最新版本.涉及到的概念有GTID.DELAYED. 现象 在5.6主备都开启GTID-MODE的时候,备库同步线程停止,且Last_SQL_Error显示"When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT var

MySQL内核月报 2014.12-MySQL·　性能优化·并行复制外建约束问题

背景: mysql 主备同步是通过binlog来进行的,备库的 IO 线程从主库拉取binlog,SQL线程将拉取的binlog应用到备库,在5.6之前,备库只有一个线程应用binlog,主库的更新量大,且备库的执行效率低时,就会造成了大量从主库拉取的binlog来不及执行,因此造成了主备延迟问题.为了解决主备延迟,需要提高备库的执行效率,阿里MySQL 设计并开发了并行复制功能,所谓并行复制,指的是应用binlog的线程数量是多个的,而不是原生的单个线程,经过测试可以极大的提高复制性能(有3X

MySQL内核月报 2014.09-MySQL·　捉虫动态·auto_increment

背景: Innodb引擎使用B_tree结构保存表数据,这样就需要一个唯一键表示每一行记录(比如二级索引记录引用). Innodb表定义中处理主键的逻辑是: 1.如果表定义了主键,就使用主键唯一定位一条记录 2.如果没有定义主键,Innodb就生成一个全局唯一的rowid来定位一条记录 auto_increment的由来: 1.Innodb强烈推荐在设计表中自定义一个主键,因为rowid是全局唯一的,所以如果有很多表没有定义主键,就会在生成rowid上产生争用. row_id由mutex保护,并

MySQL内核月报 2014.12-MySQL·　捉虫动态·Opened tables block read only

背景 MySQL通过read_only参数来设置DB只读,这样MySQL实例就可以作为slave角色,只应用binlog,不接受用户修改数据.这样就可以保护master-slave结构中的数据一致性,防止双写风险. global read_only的实现方式 MySQL5.5版本通过三个步骤来设置read_only: 步骤1:获取global read lock,阻塞所有的写入请求 步骤2:flush opened table cache,阻塞所有的显示读写锁 步骤3:获取commit lock

MySQL内核月报 2014.12-MySQL·　答疑释惑·server_id为0的Rotate

背景 在MySQL的M-S结构里面,event是binlog日志的基本单位.每个event来源于主库,每个Event都包含了serverid,用于表示该event是哪个实例生成的. 在5.6里面,细心的同学会发现,备库的relaylog中出现了server_id为0的event,其类型为Rotate Event. 这里说说server_id=0的Rotate Event. 心跳event MySQL Cluster中从NDB 6.3开始就出现的HEADBEAT event(hb event),