基于惭测厂蚕尝开放复制协议的同步扩展
- 1. 基于惭测厂蚕尝开放复制协议的数据同步 简朝阳 @mbaobao.com 2011.06.12 1
- 2. 基于惭测厂蚕尝开放复制协议的数据同步 简朝阳(sky000) Oracle ACE (Expertise MySQL) 技术保障部 @麦包包 http://isky000.com http://twitter.com/sky000 http://weibo.com/isky000 2
- 3. 基于惭测厂蚕尝开放复制协议的数据同步 原生现状介绍 主 题 纲 要 3
- 4. 基于惭测厂蚕尝开放复制协议的数据同步 原生现状介绍 现实业务需求 主 题 纲 要 4
- 5. 基于惭测厂蚕尝开放复制协议的数据同步 原生现状介绍 现实业务需求 主 题 纲 要 应该如何扩展 5
- 6. 基于惭测厂蚕尝开放复制协议的数据同步 原生现状介绍 现实业务需求 主 题 纲 要 应该如何扩展 架构示例展示 6
- 7. 原生 MySQL Replication 现状 原 生 现 状 7
- 8. 原生 MySQL Replication 现状 实现机制 原 生 现 状 8
- 9. 原生 MySQL Replication 现状 ? 3个线程：2 个 io 线程,1个 sql线程 实现机制 ? 2种日志：binlog，relaylog ? 1种实现：全程异步 原 生 现 状 9
- 10. 原生 MySQL Replication 现状 ? 3个线程：2 个 io 线程,1个 sql线程 实现机制 ? 2种日志：binlog，relaylog ? 1种实现：全程异步 原 生 优点 现 状 10
- 11. 原生 MySQL Replication 现状 ? 3个线程：2 个 io 线程,1个 sql线程 实现机制 ? 2种日志：binlog，relaylog ? 1种实现：全程异步 原 ? 稳定可靠：已经历多年实践验证 生 优点 ? 代码集成：和 MySQL Server 绑定 现 ? 维护简单：配置简单，信息清晰 状 ? 能耗较低：单线程，Slave 端请求 11
- 12. 原生 MySQL Replication 现状 ? 3个线程：2 个 io 线程,1个 sql线程 实现机制 ? 2种日志：binlog，relaylog ? 1种实现：全程异步 原 ? 稳定可靠：已经历多年实践验证 生 优点 ? 代码集成：和 MySQL Server 绑定 现 ? 维护简单：配置简单，信息清晰 状 ? 能耗较低：单线程，Slave 端请求 缺点 12
- 13. 原生 MySQL Replication 现状 ? 3个线程：2 个 io 线程,1个 sql线程 实现机制 ? 2种日志：binlog，relaylog ? 1种实现：全程异步 原 ? 稳定可靠：已经历多年实践验证 生 优点 ? 代码集成：和 MySQL Server 绑定 现 ? 维护简单：配置简单，信息清晰 状 ? 能耗较低：单线程，Slave 端请求 ? 数据可能丢失：异步机制无法保证安全 ? 主从容易延时：单线程串行机制造成 缺点 ? 1从只能1个主：避免可能的数据冲突？ ? Master切换难：日志ID不是全局唯一 13
- 14. 现实场景对 Replication的需求 现 实 需 求 14
- 15. 现实场景对 Replication的需求 无丢失 现 实 需 求 15
- 16. 现实场景对 Replication的需求 ? 日志：故障情况下不丢失日志内容 无丢失 ? 数据：故障情况下不丢失数据 现 实 需 求 16
- 17. 现实场景对 Replication的需求 ? 日志：故障情况下不丢失日志内容 无丢失 ? 数据：故障情况下不丢失数据 低延时 现 实 需 求 17
- 18. 现实场景对 Replication的需求 ? 日志：故障情况下不丢失日志内容 无丢失 ? 数据：故障情况下不丢失数据 ? 主从延时小：希望Master 与 低延时 Slave 之间数据延时较小，更有效 现 的提升扩展性 实 需 求 18
- 19. 现实场景对 Replication的需求 ? 日志：故障情况下不丢失日志内容 无丢失 ? 数据：故障情况下不丢失数据 ? 主从延时小：希望Master 与 低延时 Slave 之间数据延时较小，更有效 现 的提升扩展性 实 需 求 易切换 19
- 20. 现实场景对 Replication的需求 ? 日志：故障情况下不丢失日志内容 无丢失 ? 数据：故障情况下不丢失数据 ? 主从延时小：希望Master 与 低延时 Slave 之间数据延时较小，更有效 现 的提升扩展性 实 需 ? 异常切换快：Slave能够在无人工 求 易切换 干预的环境下快速更换 Master的， 并确保数据无丢失 20
- 21. 现实场景对 Replication的需求 ? 日志：故障情况下不丢失日志内容 无丢失 ? 数据：故障情况下不丢失数据 ? 主从延时小：希望Master 与 低延时 Slave 之间数据延时较小，更有效 现 的提升扩展性 实 需 ? 异常切换快：Slave能够在无人工 求 易切换 干预的环境下快速更换 Master的， 并确保数据无丢失 多个主 21
- 22. 现实场景对 Replication的需求 ? 日志：故障情况下不丢失日志内容 无丢失 ? 数据：故障情况下不丢失数据 ? 主从延时小：希望Master 与 低延时 Slave 之间数据延时较小，更有效 现 的提升扩展性 实 需 ? 异常切换快：Slave能够在无人工 求 易切换 干预的环境下快速更换 Master的， 并确保数据无丢失 ? 多主复制：能够让1个 Slave 从多 多个主 个 Master 复制数据，实现数据合并 22
- 24. 我们该如何对 Replication 进行扩展 自行解析 如 何 扩 展 24
- 25. 我们该如何对 Replication 进行扩展 ? 可行性：协议开源 自行解析 ? 目的性：易于控制(分拆/合并/持久化…) ? 必要性：避免入侵原生代码，方便后续升级 如 何 扩 展 25
- 26. 我们该如何对 Replication 进行扩展 ? 可行性：协议开源 自行解析 ? 目的性：易于控制(分拆/合并/持久化…) ? 必要性：避免入侵原生代码，方便后续升级 如 何 中继缓冲 扩 展 26
- 27. 我们该如何对 Replication 进行扩展 ? 可行性：协议开源 自行解析 ? 目的性：易于控制(分拆/合并/持久化…) ? 必要性：避免入侵原生代码，方便后续升级 如 ? 易控制：合并，分拆，转发… 何 中继缓冲 ? 降低能耗：一个请求多个解析，解放主节点 扩 ? 持久化：集中处理变更(备份/转发…) 展 ? 易切换：日志不丢失，可全局控制 27
- 28. 我们该如何对 Replication 进行扩展 ? 可行性：协议开源 自行解析 ? 目的性：易于控制(分拆/合并/持久化…) ? 必要性：避免入侵原生代码，方便后续升级 如 ? 易控制：合并，分拆，转发… 何 中继缓冲 ? 降低能耗：一个请求多个解析，解放主节点 扩 ? 持久化：集中处理变更(备份/转发…) 展 ? 易切换：日志不丢失，可全局控制 并行加载 28
- 29. 我们该如何对 Replication 进行扩展 ? 可行性：协议开源 自行解析 ? 目的性：易于控制(分拆/合并/持久化…) ? 必要性：避免入侵原生代码，方便后续升级 如 ? 易控制：合并，分拆，转发… 何 中继缓冲 ? 降低能耗：一个请求多个解析，解放主节点 扩 ? 持久化：集中处理变更(备份/转发…) 展 ? 易切换：日志不丢失，可全局控制 并行加载 ? 高性能：多线程提高处理能力 ? 低延时：避免大事务阻塞问题 ? 易排错：一个错误不影响整体复制进度 29
- 30. 复制扩展后架构示例 示 例 扩 展 30
- 31. 复制扩展后架构示例 准实时数据分析 示 例 扩 展 31
- 32. 复制扩展后架构示例 ? 实时反映数据变化至数据分析中心 准实时数据分析 ? 合并多个数据源至单个目的数据库 ? 目标端可能不是 MySQL 数据库 示 例 扩 展 32
- 33. 准实时数据分析系统架构示例 app1 … app2 … app3 … app4 … App Cluster 33
- 34. 准实时数据分析系统架构示例 app1 … app2 … app3 … app4 … App Cluster … … … DB Cluster db1 db2 db3 34
- 35. 准实时数据分析系统架构示例 app1 … app2 … app3 … app4 … App Cluster … … … DB Cluster db1 db2 db3 凌晨低峰时期提取数据 昨日数据 报表 Data Analyze Center 35
- 36. 准实时数据分析系统架构示例 app1 … app2 … app3 … app4 … App Cluster … … … DB Cluster db1 db2 db3 Data Analyze Center 36
- 37. 准实时数据分析系统架构示例 app1 … app2 … app3 … app4 … App Cluster … … … DB Cluster db1 db2 db3 BinlogSyncer 实时分析 报表 Data Analyze Center 37
- 38. 复制扩展后架构示例 ? 实时反映数据变化至数据分析中心 准实时数据分析 ? 合并多个数据源至单个目的数据库 ? 目标端可能不是 MySQL 数据库 示 例 扩 展 ? 写入量相对较少，数据相对静止 高并发主读应用 ? 读取请求特别多，并发量很高 38
- 39. 高并发主读系统架构示例 app1 … app2 … app3 … app4 … App Cluster 39
- 40. 高并发主读系统架构示例 app1 … app2 … app3 … app4 … App Cluster write Master (all data) 40
- 41. 高并发主读系统架构示例 app1 … app2 … app3 … app4 … App Cluster write Master (all data) 同步所有日志 db1 db2 db3 db… Read DB Cluster : each db with part of all data 41
- 42. 高并发主读系统架构示例 app1 … app2 … app3 … app4 … App Cluster write Master (all data) read read 同步所有日志 db1 db2 db3 db… Read DB Cluster : each db with part of all data 42
- 43. 高并发主读系统架构示例 app1 … app2 … app3 … app4 … App Cluster write Master (all data) read read db1 db2 db3 db… Read DB Cluster : each db with part of all data 43
- 44. 高并发主读系统架构示例 app1 … app2 … app3 … app4 … App Cluster write Master (all data) read read BinlogSyncer db1 db2 db3 db… Read DB Cluster : each db with part of all data 44
- 45. 互动环节 Q&A http://isky000.com Thanks! 45