Uber MySQL
发布于 • 作者: Ethan
引言
本文是MySQL At Uber的快速笔记。
背景
- Uber 的 MySQL 集群规模极大：超过 2300 个独立集群。
- MySQL 是 Uber 数据基础设施的核心，支撑关键业务。
- 挑战：保证 高可用（99.99%） 和 无数据丢失，需要构建高效的 控制平面（Control Plane） 来管理集群生命周期。
整体架构
-
数据流（Data Plane）：应用服务（Kubernetes 部署）通过 JDBC 客户端与 MySQL 集群交互，使用反向代理进行路由（主库/从库/批处理）。
-
控制流（Control Plane）：负责集群生命周期管理（创建、扩缩容、迁移、下线等）。
-
核心组成部分：
- 控制平面（Control Plane）
- 数据平面（Data Plane）
- 发现平面（Discovery Plane）
- 可观测性（Observability）
- 数据捕获（CDC）
- 备份与恢复（Backup/Restore）
控制平面（Control Plane）
技术管理器（Technology Manager）
- 核心编排器，负责集群目标状态（Goal State）的下发与收敛：
- 节点数、角色（Primary/Follower）、资源配置、MySQL 参数（binlog 格式、SQL mode）等。
- 与 Odin（Uber 内部状态管理平台）集成，做节点调度与放置。
- 支持长事务/容错的 工作流（Workflow），由 Cadence 提供。
- 典型工作流：添加节点、主库切换、变量更新、复制关系变更。
控制器（Controller）
- 新增组件，用于 集群外部健康观测与规则评估。
- 关键功能：
- 监控主节点健康，自动触发 主库切换。
- 维持集群复制组的平衡。
工作流编排
- Cadence 驱动的事件驱动异步流程，保证 持久性、可扩展性、容错性。
- 关键场景：
- 主库切换（Primary Failover）
- 优雅切换（Graceful）：维护/升级时，先设置只读、停流量、选择新主、同步 binlog，再切换写流量。
- 紧急切换（Emergency）：当前主机不可达，直接选新主，不等待原主数据同步。
- 节点替换（Node Replacement）
- 保证用户无感知迁移，硬件故障或机房迁移时使用。
- 涉及节点增加（新节点引导 + 数据同步）和节点删除。
- Schema 变更
- 自动化、安全、无阻塞。
- 使用 instant alter 或 pt-online-schema-change。
- 支持 Dry-run，结合 CI/CD 流程自动化执行。
- 主库切换（Primary Failover）
数据平面（Data Plane）
- 单节点多容器结构（Docker 部署）：
- Database 容器（MySQL/InnoDB/RocksDB）。
- Worker 容器（状态收敛、Odin 集成）。
- Metrics 容器（收集 QPS、锁等待、连接数等指标）。
- Health Prober（主库健康检查）。
- 临时 Backup 容器（定期备份）。
发现平面（Discovery Plane）
- 屏蔽底层硬件变化，提供 静态 VIP 给上层服务。
- 组件：
- 反向代理：转发读写请求。
- 连接池服务：根据 etcd 拓扑更新动态调整代理配置。
- 标准客户端：简化连接管理（读写分离、超时、监控）。
- etcd 存储拓扑，支持 实时 Watch，保障拓扑一致性。
可观测性（Observability）
- 指标收集：
- 容器级、集群级指标。
- Prober 模拟流量检查可用性。
- 警报场景：
- 写入不可用
- 复制延迟
- 高 CPU
- 异常连接
- 支持下游团队订阅警报。
数据捕获（Change Data Capture, CDC）
- 工具：Storagetapper
- 从 binlog 捕获数据变更。
- 通过 Kafka 流入 Hive。
- 支持 schema 变更、数据转换、格式转换。
备份与恢复
- 工具：Percona XtraBackup
- 自动化实现，保障：
- RPO = 4 小时
- RTO = 数分钟到数小时（取决于数据大小）
结论
- Uber 的 MySQL 控制平面通过 工作流编排 + 控制器 + 发现平面 + 自动化工具链，实现了：
- 高可用性（99.99% SLA）
- 可扩展性（支持数千集群）
- 自动化（Schema、备份、CDC、监控）