基于 gh-ost 的在线 Schema 变更
本文阐述了 Bytebase 采用 gh-ost 作为在线 schema 变更解决方案的原因,并展示了如何使用 Bytebase Console 完成一次基于 gh-ost 的在线 schema 变更。
基于 gh-ost 的在线 Schema 变更
Bytebase 是一款开源的数据库 DevOps 工具,它面向整个研发组织设计,旨在帮助应用开发者和 DBA 更安全、更高效地管理应用开发生命周期中的数据库操作 (Database DevOps)。
对于应用开发者和 DBA 而言,数据库 Schema 变更是日常工作中最常见的操作之一。然而,它也是最具有挑战性的一项日常工作。例如大表在线变更就是一个让人头疼的数据库操作,整个变更过程可能需要几个小时甚至几天。常规的解决方案必须给被变更的表加锁,导致其对应的服务不得不暂停。但对于大多数在线应用来说,是无法接受暂停服务这么长时间的。业界提供了各种在线 Schema 变更解决方案来解决这个问题,常见的方案有:
虽然这些解决方案可以将在线变更引起的服务暂停时间从几天或者几小时减少到几秒,但是,完成这些操作需要大量的专业知识和丰富的数据库操作经验,即仅限于经验丰富的 DBA 进行操作,应用开发人员无法独立完成这些操作。
Bytebase 是一款数据库 DevOps 工具,我们希望应用开发人员通过 Bytebase 也可以完成在线 Schema 更改。在这篇文章中,我们介绍了 Bytebase 基于 gh-ost 实现的在线 Schema 变更解决方案(beta)。Bytebase 的解决方案将整个变更过程分成了 2 步,并以更友好的视图向用户展示了变更进度和过程。
采用 gh-ost 解决方案的原因
目前,所有的在线 Scheme 变更解决方案都是采用了相似的流程,具体流程如下:
创建一张全新的空表(被称做 ghost/影子表),这个表的 schema 跟将要变更(原始表)的表一摸一样
将 Schema 变更应用到 ghost 表
将原始表中的数据复制到 ghost 表
持续获取原始表中的变更操作,保持 ghost 表与原始表同步
用 ghost 表替换原始表
为什么 Bytebase 会选择 gh-ost 作为在线 Schema 变更方案呢?最关键的原因是 gh-ost 采用了无触发器的设计,通过 binlog 来获取原始表的变更,并将这些变更异步地应用到 ghost 表。因此,gh-ost 解决方案不仅避免了触发器和锁竞争带来的性能开销,还可以很好地控制整个 schema 变更的过程。这样,Bytebase 可以提供更好的用户体验,让用户清晰地了解在线变更的进度和过程。
在线变更操作步骤
Bytebase 支持两种 Schema 变更方式:常规变更和在线变更。用户可以在 Bytebase Console 中创建一个工单来完成 Schema 变更。下文向大家演示 3 步完成基于 gh-ost 的在线 Schema 变更。
示例中要进行 Schema 变更的表「sbtest1」有 4 列,数据量大约是 694 MB。详见下图:
第一步 创建一个 ghost 表
在数据库概览页,点击「变更 Schema」
选择「在线变更」,并点击「下一步」
输入变更所需的 SQL 语句,选择一个审核人后点击「创建」
第二步 完成任务「同步数据」
审核人点击「批准」完成审核后,任务「同步数据」开始执行。Bytebase Console 会显示同步数据的进度,如下图所示,同步数据已完成了 34%。
第三步 完成任务「切换表」
当任务「同步数据」完成后,审核人点击「批准」后开始执行第二个任务「切换表」。
当任务「切换表」完成后,gh-ost 在线 schema 变更就完成了,如下图所示。
了解更多
Bytebase 支持基于 gh-ost 的大表在线 Schema 变更,它是一种无触发器的解决方案,该解决方案可将大表在线变更停服时间从若干小时缩短到秒级。同时,Bytebase 还提供了可视化的界面,用户可全程观测在线 schema 变更的进度和过程。如果想了解更多详情,请参阅我们的用户帮助文档。
我们期待收到你的使用反馈,你可以将反馈提交到 GitHub issues。
版权声明: 本文为 InfoQ 作者【Bytebase】的原创文章。
原文链接:【http://xie.infoq.cn/article/3a83cbc8f77dd77ccf7e17c0f】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论