Gh-ost:无缝迁移,效率与安全并行- 精选真开源,释放新价值。
概览
gh-ost是由GitHub团队精心打造的在线MySQL表结构迁移工具,它以一种无需触发器的方式,实现了对数据库表结构变更的在线操作。gh-ost的设计初衷是解决现有工具在使用过程中可能遇到的限制和风险,通过利用MySQL的二进制日志流捕捉表变更,异步地将变更应用到一个“幽灵”表上,从而实现了真正的在线迁移。它不仅减轻了主服务器在迁移过程中的负载,还提供了暂停、动态控制/重新配置、审计和许多其他操作优势。
gh-ost 放弃了触发器,使用 binlog 来同步。gh-ost 作为一个伪装的备库,可以从主库/备库上拉取 binlog,过滤之后重新应用到主库上去,相当于主库上的增量操作通过 binlog 又应用回主库本身,不过是应用在幽灵表上。
gh-ost 首先连接到主库上,根据 alter 语句创建幽灵表,然后作为一个”备库“连接到其中一个真正的备库上,一边在主库上拷贝已有的数据到幽灵表,一边从备库上拉取增量数据的 binlog,然后不断的把 binlog 应用回主库。图中 cut-over 是最后一步,锁住主库的源表,等待 binlog 应用完毕,然后替换 gh-ost 表为源表。gh-ost 在执行中,会在原本的 binlog event 里面增加以下 hint 和心跳包,用来控制整个流程的进度,检测状态等。这种架构带来诸多好处,例如:
-
整个流程异步执行,对于源表的增量数据操作没有额外的开销,高峰期变更业务对性能影响小。
-
降低写压力,触发器操作都在一个事务内,gh-ost 应用 binlog 是另外一个连接在做。
-
可停止,binlog 有位点记录,如果变更过程发现主库性能受影响,可以立刻停止拉binlog,停止应用 binlog,稳定之后继续应用。
-
可测试,gh-ost 提供了测试功能,可以连接到一个备库上直接做 Online DDL,在备库上观察变更结果是否正确,再对主库操作,心里更有底。
主要功能
你可以进入该地址下载:https://github.com/github/gh-ost/releases/tag/v1.1.6
- 无需触发器的迁移
gh-ost摒弃了传统迁移工具依赖的触发器机制,通过直接监听MySQL的二进制日志来捕获数据变更,避免了触发器可能带来的性能问题和复杂性。
- 测试与验证
gh-ost提供了在副本上进行测试迁移的能力,允许用户在不影响生产环境的情况下验证迁移流程的正确性,确保迁移操作的安全性和可靠性。
- 实时暂停与恢复
在迁移过程中,gh-ost允许用户实时暂停和恢复迁移过程,这为处理紧急情况或优化迁移窗口提供了极大的灵活性。
- 动态配置调整
用户可以在迁移过程中动态调整gh-ost的配置,例如调整复制速率或修改其他参数,以适应不同的迁移需求和环境。
- 详尽的状态审计
gh-ost提供了详细的状态查询功能,用户可以通过查询接口获取迁移的当前状态,包括进度、复制延迟等关键信息。
- 关键步骤控制
gh-ost允许用户控制表交换的时机,即在迁移的最后阶段,用户可以选择在最佳时机执行表的替换,以减少对业务的影响。
- 环境集成
gh-ost支持外部钩子,可以与用户的特定环境或运维流程集成,提供定制化的迁移体验。
- 多模式迁移
gh-ost支持多种迁移模式,包括在主服务器上直接进行迁移,或在副本上进行迁移后同步到主服务器,以适应不同的数据库架构和业务需求。
信息
截至发稿概况如下:
-
软件地址:https://github.com/github/gh-ost
-
软件协议:MIT
-
编程语言:
语言 | 占比 |
---|---|
Go | 93.5% |
Shell | 6.5% |
- 收藏数量:12.1K
gh-ost以其创新的在线迁移技术,为数据库管理员提供了一种安全、可控且高效的工具,以应对日益复杂的数据库结构变更需求。然而,任何工具都不是万能的,gh-ost在实际应用中可能会遇到特定的挑战,例如在处理大规模数据迁移时的性能问题,或是与特定数据库配置的兼容性问题。
各位在使用 Gh-ost 的过程中是否发现了什么问题?或者对 Gh-ost 的功能有什么提议?热烈欢迎各位在评论区分享交流心得与见解!!!
声明:本文为辣码甄源原创,转载请标注"辣码甄源原创首发"并附带原文链接。