mycat技术分享讲述.ppt

后台数据访问逻辑层次 HA Pool MySQL Protocol Adapter Data Node S M S M S M S M S M ip:port/offer ip:port/offer ip:port/ibank ip:port/ibank ip:port/ibank 数据库连接 基于协议数据包 与MySQL交互 基于MySQL协议 MySQL 新Cobar select * from offer select * from offer 基于MySQL协议 MySQL 新Cobar HEADER FIELD EOF ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW ROW EOF select * from offer Result 2GB select * from offer 后台数据访问逻辑层次 S M HA Pool MySQL Protocol Adapter Data Node 主备连接池 S M S M S M S M S M 后台数据访问逻辑层次 S M 心跳检测后端连接 S M S M S M S M S M HA Pool MySQL Protocol Adapter Data Node X 后台数据访问逻辑层次 S M 心跳检测后端连接 主库失效自动切换至备库 重置池中连接 S M S M S M S M S M HA Pool MySQL Protocol Adapter Data Node 分库2 分库3 分库4 分库5 分库6 分库1 后台数据访问逻辑层次 S M 水平拆分的分库 S M S M S M S M S M HA Pool MySQL Protocol Adapter Data Node 分库2 分库3 分库4 分库5 分库6 分库1 物理机 灵活的层间对应关系 S M S M S M S M S M S M 物理机 物理机 物理机 物理机 物理机 大纲 中间件引入 MyCat策略 系统实现 MySQL协议 通信 解析 后端连接 实施应用 MyCat集群 MySQL Protocol MySQL Protocol MySQL Protocol MySQL Protocol MySQL Protocol MySQL Protocol HTTP Haproxy mycat 数据迁移 场景 MySQL数据库节点扩容 拆分规则更改 目标 迁移过程中应用保持可用 数据不能丢失、多余或者不一致 迁移步骤 数据的全量dump 变更数据的增量dump 路由规则切换 清理 分库1 分库2 分库1 分库2 分库3 数据分片数量变更 分库2 分库1 全量dump 分库3 分库1 分库2 分库3 分库2 分库1 全量dump 分库3 分库1 分库2 分库3 dump dump 此时仍使用两份分库的拆分规则 分库2 分库1 全量dump 分库3 invisible invisible 让绿色数据对SQL语句不可见 … WHERE ( … ) AND 非绿色数据 全量dump过程中，数据会持续变更 将binlog同步到新库中 分库2 分库1 增量dump 分库3 invisible invisible binlog binlog Apply Apply 暂停写入，等待binlog全部同步到新库 将路由规则更新为三个分库 分库2 分库1 路由规则切换 分库3 invisible invisible binlog binlog Apply Apply 删除老数据 清理 分库2 分库1 分库3 大纲 中间件引入 MyCat策略 系统实现 实施应用 部署结构 平滑迁移 第一个秘密：纳尼，Cobra会假死？ Cobra的确会假死，很多人遇到这个问题，如何简单的来验证这点呢？我们来做个小实验，假如你的分片表中配置有表company,则打开mysql终端，执行下面的SQL： select sleep(500) from company; 此SQL会执行等待500秒，你再努力以最快的速度打开N个mysql终端，都执行相同的SQL，确保N当前Cobra的执行线程数：show @@threadpool的所有Processor1-E的线程池的线程数量总和，然后你再执行任何简单的SQL，或者试图新建立连接，都会无法响应，此时show @@threadpool里面看到TASK_QUEUE_SIZE已经在积压中。 不可能吧，据说Cobra是NIO的非阻塞的，怎么可能阻塞！别激动，去看看代码，Cobra前端是NIO的，而后端跟Mysql的交互，是阻塞