【MySQL变更】gh-online-schema-change(gh-ost)原理解读

2023-12-25 13:36
文章标签 mysql 原理 解读 schema change 变更 online database ost gh

本文主要是介绍【MySQL变更】gh-online-schema-change(gh-ost)原理解读，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

gh-ost简介

gh-ost是处理MySQL在线表结构变更的工具，与pt-osc 不同，gh-ost不会使用触发器。

gh-ost 可以进行测试，暂停，动态控制和重新配置，审计还有其他许多操作perks。

命名

最初它被命名为gh-osc：GitHub Online Schema Change，

后来将c变为为t。gh-ost（发音：Ghost），代表 GitHub 的 Online Schema Transmogrifier/Translator/Transformer/Transfigurator

原理简介

所有现有的在线表结构变更工具都以相似的的原理：它们创建一个与原始表结构相同的幽灵表，在该表为空时进行表结构变更，缓慢并增量地将数据从原始表复制到幽灵表，同时将正在进行的更改（任何INSERT, DELETE,UPDATE应用于源表）应用到幽灵表。最后，在适当的时候，他们用幽灵表替换原表。

gh-ost使用相同的模式。然而，它与所有现有工具的不同之处在于不使用触发器。因为触发器是许多限制和风险的来源。

gh-ost 使用二进制日志流来捕获表数据变化，并将它们异步应用到ghost表上。gh-ost承担其他工具留给数据库执行的一些任务。因此，gh-ost可以更好地控制迁移过程；可以真正暂停它；可以真正将 migration 的写入负载与 master 的工作负载解耦。

此外，它还提供许多操作优势，使其更安全、更值得信赖且使用起来更有趣。

亮点

  • 可以在从库上进行测试 ，从而建立你对gh-ost的信任。gh-ost在从库上表结构变更的过程和主库相同，并不会真正的替换原表。这样在从库上就会保留原始表与幽灵表，你可以对比统计两张表的数据从而验证工具操作的正确性。这也是我们如何在生产环境测试gh-ost的方法
  • 真正的暂停 。当gh-ost throttles时，它真正停止在 master 上写入：没有行的拷贝，也没有正在进行事件的处理。通过节流，您可以将 master 恢复到其原始工作负载
  • 动态控制。您可以交互式重新配置gh-ost，即使迁移仍在运行。您可以强行启动节流。
  • 审计。您可以查询gh-ost状态。gh-ost监听 unix 套接字或 TCP。
  • 控制切换时刻。gh-ost可以使用指示推迟可能是最有风险的步骤：交换原始表与幽灵表的表名称。直到您可以舒适地使用。也无需担心预计的切换时间不在办公时间。
  • gh-ost可以使用外部钩子脚本。

用法

  • noop迁移（仅测试迁移是否有效且可以进行）
  • 一个真正的迁移，利用一个副本（迁移在主服务器上运行；gh-ost找出所涉及的服务器的身份。如果您的主服务器使用基于语句的复制，则需要模式）
  • 在 master 上运行真正的迁移，（但gh-ost更喜欢前者）
  • 在从库上进行真正的迁移（master未受影响）
  • 在从库上进行测试迁移，这是您与的操作建立信任的方式。

更多提示

  • --exact-rowcount 准确的进度指示
  • --postpone-cut-over-flag-file 控制切换时间
  • 更多交互式 参考 ：交互式命令

基于触发器变更的弊端

  • 负载 对于原始表的每个INSERT, DELETE,UPDATE需要在幽灵表/影子表上回放，另外还有触发器的本身的代价。
  • 锁 锁竞争问题
  • 没有真正的暂停 比如 pt-osc 只能暂停全量的同步，不能暂停触发器的复制
  • 没有生产的测试
  • 对于多个变更（不同表）的支持
  • bound to server

更详细的解读 参考 ：https://github.com/github/gh-ost/blob/master/doc/why-triggerless.md

无触发器的设计

pt-online-schema-change 在原始表创建三个触发器 (AFTER INSERT, AFTER UPDATE, AFTER DELETE) ，触发器的操作与原表的操作在同一事务中

基于无触发器的异步迁移

gh-ost的无触发设计采用异步方法。但是它不需要触发器，因为它不需要像 Facebook ost 工具那样有一个变更日志表。它不需要变更日志表的原因是它在另一个地方找到变更日志：二进制日志。

特别是，它读取基于行的复制 (RBR) 条目（您仍然可以将它与基于语句的复制一起使用！）并搜索适用于原始表的条目。

RBR 条目对于这项工作非常方便：它们将复杂的语句（可能是多表）分解为不同的、每表、每行的条目，这些条目易于阅读和应用。

gh-ost伪装为一个 MySQL 从副本：它连接到 MySQL 服务器并开始请求 binlog 事件，就好像它是一个真正的从副本一样。因此，它获得二进制日志的连续流，并过滤掉适用于原始表的那些事件。

gh-ost可以直接连接到主服务器，但更建议连接到主服务器的从副本之一。副本需要设置参数：log-slave-updates和binlog-format=ROW（gh-ost可以此设置）。

从二进制日志中读取，特别是在副本上读取二进制日志的情况，进一步强调了算法的异步性质。虽然事务可能（基于配置）与 binlog 条目写入同步，但它需要时间gh-ost- 假装是副本 - 会收到通知，将事件复制到下游并应用它。

异步设计意味着许多值得注意的结果，稍后将讨论。

工作流程

流程图

该工作流程包括从服务器读取表数据、从二进制日志读取事件数据、检查复制延迟或其他节流参数、将增量的表更应用到服务器（通常是主服务器）、通过二进制日志流发送提示等等。

初始化阶段

  1. 连接到主库或者从库
  2. 预验证 alter语句
  3. 验证权限，表存在
  4. 创建changelog 与 ghost 表（变更日志表与幽灵表）
  5. 对比原始表与幽灵表的结构差异，找到两张表都有的列，都有的唯一索引，验证外键。选择一个都有的唯一索引后续根据该字段对该表进行分块等处理。
  6. 设置binlog监听 开始监听changelog envents
  7. 将good to go 插入到changlog 表
  8. 开始监听原始表DML的二进制日志事件
  9. 读取原始表被选取我的唯一索引最大/最小的值

拷贝阶段

  1. 设置心跳机制：频繁写入 change log 表（我们认为这是低的，出于节流目的可忽略的写入负载）
  2. 持续更新状态
  3. 定期（经常）检查潜在的节流场景或提示
  4. 逐块(chunk)处理原始表的全量数据，将复制任务排队到 ghost 表上
  5. 从binlog中读取 DML 事件，将应用任务排队到 ghost 表
  6. 处理复制任务队列和应用任务队列并依次应用到ghost表 按节流状态暂停
  7. 一旦全表复制完成，注入/拦截“"copy all done”
  8. 存在postpone-cut-over-flag-file文件标识时 ，停止/推迟cut-over（我们继续应用正在进行的 DML）

切换完成阶段

  • 原始表 write lock ,禁止写入
  • 交换原始表与幽灵表名称
  • 清理阶段 删除表

使用要求

gh-ost目前需要 MySQL 5.7 及更高版本。

服务器需要设置参数binlog 格式为 binlog_format=ROW 基于row的复制 与 binlog_row_image=FULL。将来 binlog_row_image=MINIMAL 可能会被支持 

如果是复制的架构，需要变更的表的表结构 在主从上需要完全相同。

账号权限 

  • 对需要变更的表具有一下权限 ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE 
  • 下面任选其一：
    • SUPER, REPLICATION SLAVE ON *.*，或：
    • REPLICATION CLIENT, REPLICATION SLAVE ON *.*

MySQL需要设置参数 binlog_format=ROW，如果不是row格式，在使用gh-ost时需要指定参数  --switch-to-rbr

无论服务器上设置什么隔离级别， gh-ost连接MySQL服务器时 ，使用 REPEATABLE_READ  事务隔离级别 

使用参数 --test-on-replica 时，在cut-over 阶段之前，gh-ost会停止主从复制，以便于你能比较两个表确认迁移是否正确

限制

外键约束不被支持 

触发器不被支持 

支持MySQL 5.7 JSON 列，但不作为PRIMARY KEY 其一部分

变更前后的 两张表 必须有相同的主键或者唯一索引，当拷贝数据时，这个key 被gh-ost用来迭代循环迭代

迁移用的字段必须不能包含 NULL 的值，意味着：

  • 这个列是 NOT  NULL 或者 这个列 可以为 NULL 但不包含任何 NULL值 
  • 默认情况下 ，如果唯一索引的列包含NULL 值，gh-ost 是 不会运行的。

不能迁移存在另外一张表名相同但是大小不同的表。例如，MyTable 和 MYtable。

Amazon RDS 可以使用给工具，但是有他自己的一些限制

可以兼容谷歌的 RDS ，需要使用参数 --gcp

可以兼容Aliyun 的RDS，但是需要使用参数 --aliyun-rds。

Azure  MySQL数据库 可以使用该工具，但是需要参数 --azure

多源复制 （Multisource） 不被支持，他只能工作只有一个主的时候 （--allow-on-master）

双主模式 （Master-master ） 只有在模式（active-passive）下工作 ，.双写模式 （Active-active ） 不被支持。

如果有一个enum字段作为迁移键的一部分（通常是PRIMARY KEY），则迁移性能将会降低并且可能会很糟糕。

不支持迁移FEDERATED表，并且与gh-ost问题解决无关。

不支持加密二进制日志

ALTER TABLE ... RENAME TO some_other_name 不被支持

常见问题 

cut-over 阶段是如何工作的？ 是你真的原子性的吗？

cut-over 阶段 即 原表与 幽灵表交换的阶段  是一个原子的，阻塞的 ，受控的阶段。

Atomic（原子性）：老表 与 幽灵表交互表名是一起的。不会存在老表的表名不存在的情况。

Blocking（阻塞的）：应用的查询要不对老表进行操作，要不被阻塞，要不继续对新表进行操作。

Controlled（受控的）：cut-over的超时时间可以预先定义阈值，超过该时间可以自动终止然后重试， cut-over只有在从库不延迟的情况下进行，

是否可以添加唯一索引？

在确保表中该字段不存在重复数据是可以添加的。

是否可以并发迁移？

可以 ，但是要需要注意添加参数 --replica-server-id

为什么更推荐 Connect to Replica

避免对主库超声额外的负载影响 。gh-ost作为复制客户端连接。每个额外的副本都会给主服务器增加一些负载。

方便监控复制延迟，--max-lag-millis 参数可以监控从副本的延迟

下载 

Release GA release v1.1.6 · github/gh-ost · GitHub

参数解读

这篇关于【MySQL变更】gh-online-schema-change(gh-ost)原理解读的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/535698。

相关文章

SQL中的外键约束

SQL中的外键约束

外键约束用于表示两张表中的指标连接关系。外键约束的作用主要有以下三点： 1.确保子表中的某个字段（外键）只能引用父表中的有效记录2.主表中的列被删除时，子表中的关联列也会被删除3.主表中的列更新时，子表中的关联元素也会被更新 子表中的元素指向主表 以下是一个外键约束的实例展示
阅读更多...
基于MySQL Binlog的Elasticsearch数据同步实践

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展，我们的业务数据越来越多，单纯使用 MySQL 已经不能满足我们的数据查询需求，例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后，随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步，我们目前的解决方案是建立数据中间表。把需要检索的业务数据，统一放到一张M
阅读更多...
如何去写一手好SQL

如何去写一手好SQL

MySQL性能 最大数据量 抛开数据量和并发数，谈性能都是耍流氓。MySQL没有限制单表最大记录数，它取决于操作系统对文件大小的限制。 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB，才推荐分库分表。性能由综合因素决定，抛开业务复杂度，影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考，并非铁律。 博主曾经操作过超过4亿行数据
阅读更多...
性能分析之MySQL索引实战案例

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题，本文将一起从代码层去分析为什么没有建立索引？ 开源ERP项目地址：https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置
阅读更多...
深入探索协同过滤：从原理到推荐模块案例

深入探索协同过滤：从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤（UserCF）2. 基于物品的协同过滤（ItemCF）3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代，推荐系统成为连接用户与内容的桥梁。本文聚焦于
阅读更多...
MySQL数据库宕机，启动不起来，教你一招搞定！

MySQL数据库宕机，启动不起来，教你一招搞定！

作者介绍：老苏，10余年DBA工作运维经验，擅长Oracle、MySQL、PG、Mongodb数据库运维（如安装迁移，性能优化、故障应急处理等）公众号：老苏畅谈运维欢迎关注本人公众号，更多精彩与您分享。 MySQL数据库宕机，数据页损坏问题，启动不起来，该如何排查和解决，本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志，排查哪个表（表空间
阅读更多...
hdu4407(容斥原理)

hdu4407(容斥原理)

题意：给一串数字1,2，......n，两个操作:1、修改第k个数字，2、查询区间[l,r]中与n互质的数之和。 解题思路：咱一看，像线段树，但是如果用线段树做，那么每个区间一定要记录所有的素因子，这样会超内存。然后我就做不来了。后来看了题解，原来是用容斥原理来做的。还记得这道题目吗？求区间[1,r]中与p互质的数的个数，如果不会的话就先去做那题吧。现在这题是求区间[l,r]中与n互质的数的和
阅读更多...
MySQL高性能优化规范

MySQL高性能优化规范

前言：      笔者最近上班途中突然想丰富下自己的数据库优化技能。于是在查阅了多篇文章后，总结出了这篇！ 数据库命令规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用mysql保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来） 数据库对象的命名要能做到见名识意，并且最后不要超过32个字符 临时库表必须以tmp_为前缀并以日期为后缀，备份
阅读更多...
[MySQL表的增删改查-进阶]

[MySQL表的增删改查-进阶]

🌈个人主页：努力学编程’ ⛅个人推荐： c语言从初阶到进阶 JavaEE详解 数据结构 ⚡学好数据结构，刷题刻不容缓：点击一起刷题 🌙心灵鸡汤：总有人要赢，为什么不能是我呢 💻💻💻数据库约束 🔭🔭🔭约束类型 not null: 指示某列不能存储 NULL 值unique: 保证某列的每行必须有唯一的值default: 规定没有给列赋值时的默认值.primary key:
阅读更多...
MCU7.keil中build产生的hex文件解读

MCU7.keil中build产生的hex文件解读

1.hex文件大致解读 闲来无事,查看了MCU6.用keil新建项目的hex文件 用FlexHex打开 给我的第一印象是:经过软件的解释之后,发现这些数据排列地十分整齐 :02000F0080FE71:03000000020003F8:0C000300787FE4F6D8FD75810702000F3D:00000001FF 把解释后的数据当作十六进制来观察 1.每一行数据
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2