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，在备库上观察变更结果是否正确，再对主库操作，心里更有底。
主要功能
你可以进入该地址下载 ：github.com/github/gh-o...
- 无需触发器的迁移
gh-ost摒弃了传统迁移工具依赖的触发器机制，通过直接监听MySQL的二进制日志来捕获数据变更，避免了触发器可能带来的性能问题和复杂性。
- 测试与验证
gh-ost提供了在副本上进行测试迁移的能力，允许用户在不影响生产环境的情况下验证迁移流程的正确性，确保迁移操作的安全性和可靠性。
- 实时暂停与恢复
在迁移过程中，gh-ost允许用户实时暂停和恢复迁移过程，这为处理紧急情况或优化迁移窗口提供了极大的灵活性。
- 动态配置调整
用户可以在迁移过程中动态调整gh-ost的配置，例如调整复制速率或修改其他参数，以适应不同的迁移需求和环境。
- 详尽的状态审计
gh-ost提供了详细的状态查询功能，用户可以通过查询接口获取迁移的当前状态，包括进度、复制延迟等关键信息。
- 关键步骤控制
gh-ost允许用户控制表交换的时机，即在迁移的最后阶段，用户可以选择在最佳时机执行表的替换，以减少对业务的影响。
- 环境集成
gh-ost支持外部钩子，可以与用户的特定环境或运维流程集成，提供定制化的迁移体验。
- 多模式迁移
gh-ost支持多种迁移模式，包括在主服务器上直接进行迁移，或在副本上进行迁移后同步到主服务器，以适应不同的数据库架构和业务需求。
信息
截至发稿概况如下：
-
软件协议：MIT
-
编程语言：
| 语言 | 占比 |
|---|---|
| Go | 93.5% |
| Shell | 6.5% |
- 收藏数量：12.1K
gh-ost以其创新的在线迁移技术，为数据库管理员提供了一种安全、可控且高效的工具，以应对日益复杂的数据库结构变更需求。然而，任何工具都不是万能的，gh-ost在实际应用中可能会遇到特定的挑战，例如在处理大规模数据迁移时的性能问题，或是与特定数据库配置的兼容性问题。
各位在使用 Gh-ost 的过程中是否发现了什么问题？或者对 Gh-ost 的功能有什么提议？热烈欢迎各位在评论区分享交流心得与见解！！！
声明：本文为辣码甄源原创，转载请标注"辣码甄源原创首发 " 并附带原文链接。