MySQL内核月报 2014.11-MySQL· 5.7特性·高可用支持

背景

MySQL的Master-Slave结构提供了实现High Availability的基础,在实现上面通常使用client-proxy-db的三层架构,proxy不单单完成错误检测、实例切换等高可用功能,还可以实现sharding,即scale out。

MySQL Fabric就是Oracle想大力发展的proxy,这里主要介绍为了完成高可用的功能,MySQL 5.7做了哪些事情,我们是否可以使用,实现自己的proxy?

高可用组件

proxy完成高可用的功能,除了需要MySQL提供的master-slave的基础结构外,还需要:

1. 在错误检测、进行实例切换时候,需要DB的只读功能,防止m/s双写。
2. 在切换完成后,如何实现client重连,或者实现session维持,对client透明。

那么问题来了

1. 如何保证切换?

当前MySQL版本提供了一个read_only的功能,通过添加global read lock和commit锁来实现,可以满足实现单点写入。

2. client重连或者session维持?

client重连主要依赖client的API,检测connection的错误。而保持connection不断开,session维持怎么做?

MySQL 5.7增加的功能

1. offline mode

offline mode不光实现了read only的功能,并且会断掉所有的非super用户的connection,并禁止重连。虽然官方文档中介绍是为了支持upgrade,但完全可以使用在切换的过程中。

2.session回放功能支持

client-server protocol对于response packet增加了对session state状态改变的支持,对于以下的session state变化:
1. User-defined variables
2. session-specific values for server variables
3. Temporary tables that are created
4. Prepared statements
5. Current database

response packet中会添加一个tracker标示其变化。 有了这个功能就可以容易实现session的回放功能,特别在load balance或者cluster环境中,把一个用户的connection迁移到另外一台实例上,来保持connection不断开,实现切换对client透明。

使用MySQL 5.7新增的这两个功能,可以帮助proxy实现DB高可用。

时间: 2024-12-02 08:44:03

MySQL内核月报 2014.11-MySQL· 5.7特性·高可用支持的相关文章

MySQL内核月报 2014.11-MySQL· 5.7特性·在线Truncate undo log 表空间

背景 Innodb使用undo log来实现MVCC,这意味着如果一个很老的事务长时间不提交,那么新产生的undo log都无法被及时清理掉.在MySQL 5.5及之前版本中,undo log是存储在ibdata中.从5.6开始可以使用独立的undo log表空间来存储undo.但是直到5.6,一旦undo log膨胀,依然没有任何办法为其 "减肥".因此我们经常看到ibdata被膨胀到几十上百G. 改进 在MySQL5.7.5版本中终于增加了这个众望所归的功能,实现了在线trunca

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

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

MySQL内核月报 2014.08-MySQL· 参数故事·timed_mutexes

提要 MySQL 5.5.39 Release版本正式从源码里删除了全局参数timed_mutexes.timed_mutexes原本用来控制是否对Innodb引擎的mutex wait进行计时统计,以方便进行性能诊断.为什么要删除这个参数呢? 下面介绍下相关背景: Innodb的同步锁机制 Innodb封装了mutex和rw_lock结构来保护内存的变量和结构,进行多线程同步,考虑可移植性, mutex使用lock_word或者OS mutex来保证原子操作,并使用event条件变量进行阻塞和

MySQL内核月报 2014.08-MySQL· 捉虫动态·Count(Distinct) ERROR

背景 MySQL现行版本中存在一个count(distinct)语句返回结果错误的bug,表现为,实际结果存在值,但是用count(distinct)统计后返回的是0. 原因分析 Count(distinct f)的语义就是计算字段f的去重总数,计算流程大致如下: 流程一: 1. 构造一个unique集合A1(用tree实现) 2. 对每个值都试图插入集合A1中 3. 若和A1中现有item重复则直接跳过,不重复则插入并+1 4. 完成后计算集合中元素个数. 细心的同学会看到上面的语句中有一个s

MySQL内核月报 2014.11-MySQL· 5.7改进·Recovery改进

背景 InnoDB作为事务性引擎,使用write-ahead logging(WAL)机制保证ACID中的Atomicity和Durability,使用undo机制保证ACID中的Consistency和Isolation. 按照WAL和undo的机制,形成以下两个原则: 1. 数据块的更改需要先记录redo日志. 2. 数据块的更改需要先写入undo. 根据这两个原则,InnoDB更新数据的基本流程可以简单的总结为: 1. 记录需要更改undo record的redo log 2. 记录需要更

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-TokuDB· Binary Log Group Commit with TokuDB

MySQL在开启Binary Log的情况下,使用2PC(图1)来保证事务(XA)完整性的,每次提交事务需要做: 每个事务在提交的时候都要做3次fsync以确保日志真正的落盘,这样在log里,一个事务就会有3种状态: 这样,无论处于任何一个状态,事务的完整性都不会被破坏,但是每次提交会产生3次fsync,性能非常低. 为了提升性能,MySQL 5.6增加了group commit功能,当多个事务并发提交时,让多个都在等待fsync的事务合并做一次fsync,大大提升了吞吐量. 但是这个优化还需要

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的时候