2010年, 美国的云计算公司 Rackspace 想重写他们的云平台代码, 并打算开源他们的技术和代码; 与此同时, NASA(美国航空航天局)下属的 Anso Lab 实验室发布了他们的 Beta 版的云计算平台代码;
Rackspace 想和 NASA 共同成立一个开源的云计算平台项目;
2010年7月, 在奥斯丁, Rackspace 和 NASA 一起创建了 OpenStack 项目, 之后在波特兰的世界开源大会上, OpenStack 被正式宣布;
开源之后, 大部分公司都选择了 OpenStack 作为自己的云计算平台, 国内使用 OpenStack 的公司有 腾讯, 阿里, 百度, 华为, 中国移动等等;
根据 Galera 的用户案例里面的描述, 中国移动使用 OpenStack 和 Galera Cluster 在生产环境上部署了 1000 多个节点;
Galera 是一家位于芬兰赫尔辛基的小公司, 他们的产品可以用下面一张图来介绍;
基于 OpenStack 被大量使用, OpenStack 版本升级成为需要考虑的事, 不能影响生产环境, 要做到 0 停机时间;
OpenStack 实现了自己的滚动升级策略, 主要的思路是;
1. 表结构变更兼容: N 和 N+1 版本的服务同时支持 N+1 版本的一个中间状态的表结构, 如下;
2. RPC 调用兼容: 类似表结构, RPC调用也做了兼容;
3. 服务之间的调用兼容: 服务之间的 restful 调用通过版本号控制, http://restful-api/v2, http://restful-api/v3;
这里举例说下第1点---表结构变更的支持:
假如有一张表, 有3个属性:
用户名,
特长,
性别;
N版本插入了这样一条数据:
用户名: 吴艺凡,
特长: 牙签,
性别: 男;
N+1 版本想删除属性 "性别", 流程大概是这样的;
1. N+1 的 expand 阶段不删除列, 但是服务不会再操作 "性别" 这一列;
这个时候 N 版本仍旧可以对表进行增删改查操作;
2. 逐步下线 N 版本的服务, 上线 N+1 版本的服务;
3. 变更表为 contract 阶段, 这个时候删除 "性别" 列;
如果场景不是删除列而是增加列, 则 N+1 版本的服务在 contract 阶段会用两种方法填充新列:
1. 服务在访问表时触发对列数据的填充;
2. 执行 contract 迁移的时候对列数据填充;
上面就是简单的表结构变更流程;
OpenStack 的滚动升级策略大概是从 Newton 版本开始的, 时间是在 2016年;
离开 OpenStack, 我们讲一下 Google;
2013年, Google 的分布式数据库 F1 取得成功, Google 发布了几篇关于分布式数据库的论文; 论述了 F1 的原理;
后来的很多分布式数据库都是以 Google 的论文作为基础开发出来的;
Google的其中一篇论文讲述了数据库升级时, 表结构变更的场景:
"Online, Asynchronous Schema Change in F1" --- F1 中的在线, 异步表结构变更;
Google论文原文链接: http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41376.pdf
因为某种原因打不开, 您可以自行搜索一下 PDF 版;
Google F1 的背景就不讲了, 它是一个 分布式数据库, 解决传统 MySQL 和 Oracle 的问题; 这里稍微讲一下为什么需要在线表结构变更:
传统数据库在表结构变更时, 操作期间数据库无法提供服务;
即使有很多服务做热备, 但是数据库升级时服务不能访问数据库, 所以服务不可用;
Google 的论文可以保证在表结构变更期间, 服务仍然可以访问数据库;
以增加表字段为例, 大体上讲讲这篇论文:
如果要增加一个主键列, 列状态需要有如下的状态变更流程:
absent --> delete only --> write only --(db reorg)--> public
不存在 --> 只能被删 --> 只能被写 --重组数据--> 公共状态
这里的状态在论文的中 3.1 节有定义: 3.1 Schema elements and states;
比如: 一个 delete-only 的表或列, 不能被读, 只能被删, 一个 delete-only 的索引, 只能被删或者更新, 并且更新操作只能删除索引对应的键值对, 而不能创建;
A delete-only table, column, or index
cannot have their key–value pairs read by user transactions
and
1. if E is a table or column, it can be modified only by
delete operations.
2. if E is an index, it is modified only by delete and update
operations. Moreover, update operations can delete
key–value pairs corresponding to updated index keys,
but they cannot create any new ones.
下面是增删改表结构的流程, 其中红框部分是增加表字段的流程; 参见论文中的 Figure 3;
对于主键, 是上面提到的: absent --> delete only --> write only --(db reorg)--> public;
对于可选字段, 流程简单一点 absent --> delete only --(db reorg)--> public;
除了状态约束, 还加入了新的约束: lease(租期);
两个相邻的租期之间的操作是相容的;
以增加可选列为例;
absent --> delete only --(db reorg)--> public;
1. 计算节点1 在 t1 时间点同步到的列状态为absent;
2. t1+1 时间点列状态变为 delete only;
3. 计算节点2 的租期在 t1+2 过期, 它重新同步表状态, 获取的列的状态为 delete only;
4. 计算节点2 在 t1+3 时间点执行SQL: insert xxx into xxx, 新增加的列的状态为 delete only, 所以这列不会进入数据;
5. 计算节点1 在 t1+4 时间点 执行SQL: delete xxx from xxx, 它缓存的列状态为absent, 新列对它不可见, 它不需要删除新列的数据;
这个场景的关键点是 delete only 状态, 他可以保证 absent 状态的计算节点的操作不会留下orphan data(孤儿数据);
两个相邻的租期的计算节点的操作, 对于对方是兼容的;
如果一个计算节点无法在租期过后重新同步表状态怎么办? 论文没提到, 其实很简单, 把这个计算节点杀掉就可以了;
我们再回头看看刚才 OpenStack 的滚动升级策略, 和 Google 的 这篇论文很像; 只是 OpenStack 把这种思想用在了业务服务的层面上;
完;