企业官网建设流程全解析

• 运维

Jetpants 是 Tumblr 开源的 MySQL 分片管理自动化工具包，专为数百台数据库机器、数千亿行数据的场景而生。新手入门先要弄清两个核心概念：Pool（数据库实例池）与Shard（范围分片），以及高可用的基石——双 Standby Slave设计。本文带你一文掌握，快速进入大规模 MySQL 分片运维的世界。

一、Jetpants 是什么？不是代理，而是自动化工具包

很多人以为 MySQL 分片必须依赖中间件代理，Jetpants 恰恰相反：它不是服务器，不做查询路由，读写分离和路由交给你的应用。它保留标准 MySQL 复制、标准存储引擎，只提供运维自动化能力（详见 doc/faq.rdoc）。

它的核心价值可以概括为三点：

• 🚀快：在 Tumblr 的硬件上，能把一个 750GB、十亿行的 Shard 在约 6 小时内一分为二
• 🧩Range-based sharding：可动态调整大小的范围分片，无需中心化的 lookup 服务，也无需预先分配大量小分片
• 🔧双重身份：开箱即用的命令行命令套件 + 开发自定义迁移脚本的 Ruby 库

官方 README.rdoc 中提到，Jetpants 在 2013 年就管理着 215 台专用数据库服务器和近 2000 亿行数据。

二、理解 Pool：一组数据库实例的基本积木

Pool（实例池）= 1 个 master + N 个 slave，是 Jetpants 最基本的对象，定义在 lib/jetpants/pool.rb。

Slave 细分为三种角色，看懂这张表就理解了后面的一切：

三条实用规则：

1. active slave是读流量主力，权重记录在active_slave_weights中，供资产跟踪插件写入应用配置
2. standby slave故意不接收任何生产查询——别"闲置利用"它，否则故障时将无备用节点快速克隆替补
3. backup slave默认按"主机名以 backup 开头"识别（见 for_backups?），只用于备份与克隆，永不进入生产

当 master 宕机时，Jetpants 通过 master_promotion! 完成完整切换：旧主库置全局只读 → 等待从库追平 → 所有从库重指新主 → 旧主降为 standby。这就是jetpants promotion命令的底层动作，且旧主离线时同样可用。

三、理解 Shard：带 ID 区间的 Pool

Shard 是一个"范围化"的 Pool——所有 Shard 拥有完全相同的表结构，只是各自只保存自己 ID 区间内的数据，定义见 lib/jetpants/shard.rb。

以user_id为分片键的站点为例：

• shard-1-10000：用户 1 ~ 10000 的数据
• shard-10001-30000：用户 10001 ~ 30000
• shard-30001-infinity：30001 到末尾（最后一个 Shard 的 max ID 恒为INFINITY）

两个设计亮点值得记住：

• 状态机：每个 Shard 有state，如:ready（正常在线）、:read_only、:offline、:initializing（新建中）、:exporting/:importing（拆分搬数据）、:replicating（克隆副本）、:needs_cleanup（拆完待清理）、:deprecated（父分片退役）、:recycle（可回收）
• 写转发：拆分期间，子分片的 master 本身还是父分片的从库，此时 db(:write) 会自动把写转发到父分片 master，保证数据一致

分片如何扩容：4 条命令完成零停机拆分

当 Shard 接近容量上限（磁盘使用率 80%+ 或 iostat 90%+）就需要拆分，流程见 doc/commands.rdoc：

1. jetpants shard_split—— 创建 N 个子分片并各自导入数据子集（子分片仍复制自父分片）
2. jetpants shard_split_child_reads—— 先把读切到子分片
3. jetpants shard_split_child_writes—— 再把写切到子分片
4. jetpants shard_split_cleanup—— 切断父子复制、清掉混入数据、父分片进入:recycle状态

⚠️ 顺序很关键：先移读、后移写，全程无锁、零停机、无查询失败。

另外jetpants shard_cutover命令用于截断最后一个分片的INFINITY区间并在其后追加新分片，解决"最后一个分片永远承接新用户"的问题。

注意：Shard 默认不支持 active slave——读压力太大时，正确做法是拆分分片而不是加读副本（见 active_slaves 的说明）。

四、ShardPool 与 Topology：两层对象如何组织

• ShardPool：一个逻辑分片键空间，内含多个 Shard，共同瓜分同一个数据区间，定义见 lib/jetpants/shardpool.rb
• Topology：全局对象，持有全部 Pool / Shard，负责配置文件的读写与备用机器的申领，见 lib/jetpants/topology.rb

除了分片，Jetpants 还支持functional partition（全局池）——存放无法分片的全局表（如按邮箱查用户的表）的普通"1 主 N 从"实例池，两者可以共存于同一拓扑中。

💡 提示：分片拆分等复杂操作依赖资产跟踪（asset tracker）插件，因为要申领备用机、协调多个池。Jetpants 自带 jetpants_collins 插件对接 Collins 资产系统；自研插件可参考 doc/plugins.rdoc。

五、双 Standby Slave 高可用设计：为什么恰好是 2 台？

这是 Jetpants 最"反直觉"、也最值得记住的设计。默认配置在 lib/jetpants.rb 中：

• standby_slaves_per_pool: 2—— 每个 Pool 保留 2 台 standby slave
• backup_slaves_per_pool: 1—— 另备 1 台 backup slave

"为什么是 2"的完整答案在 doc/faq.rdoc：保持 2 台 standby，任何一种单点故障都能快速恢复，而无需走缓慢的热拷贝：

底层逻辑一句话：恢复越快 = 降级状态越短 = 二次故障概率越低。

为什么克隆必须依赖 standby slave？

Jetpants 的克隆方式极快但"粗暴"：停掉源节点 MySQL，用 tar + netcat 直接复制数据文件（原理见 doc/faq.rdoc）。速度无可挑剔，但只能作用于不承载生产查询的节点——这正是 standby slave 存在的意义，也是必须至少保留 2 台的原因：一台负责被提升，一台负责当克隆源。

对应命令是jetpants clone_slave，还支持向多台备用机同时克隆（见 doc/commands.rdoc）。

⚠️ 再次强调：不要向 standby slave 发送任何生产查询。读量真不够时，请增加 active slave，而不要挪用 standby。

六、上手验证：部署后先做这三件事

环境就绪后，建议先跑这几条信息类命令（完整清单见 doc/commands.rdoc）：

1. jetpants pools—— 查看全部实例池、成员与角色
2. jetpants pools_compact—— 精简视图：池名、master IP、数据大小
3. jetpants console—— 进入交互式 REPL，直接操作你的拓扑对象

配置文件位于/etc/jetpants.yaml或~/.jetpants.yaml，完整样例见 etc/jetpants.yaml.sample，记得把 MySQL 库名、账号密码等参数改成你自己的环境。

总结

• Pool：1 主 + 3 类从库（active / standby / backup），高可用的基本积木
• Shard：带 ID 区间的 Pool，是 Range-based sharding 的载体；4 条命令完成零停机拆分
• 双 Standby Slave：一台用于提升、一台用于克隆，是 Jetpants 高可用设计的核心
• ShardPool / Topology：键空间与全局拓扑两层对象，配合资产跟踪插件形成闭环

掌握这四个概念，你就能顺畅阅读 lib/jetpants/ 下的源码，用 Jetpants 开始自己的大规模 MySQL 分片管理实践了。

• 运维