MySQL级联复制下怎么进行大表的字段扩容(mysql,开发技术)

时间:2024-02-22 05:17:51 作者 : 石家庄SEO 分类 : 开发技术
  • TAG :

    MySQL%E7%BA%A7%E8%81%94%E5%A4%8D%E5%88%B6%E4%B8%8B%E6%80%8E%E4%B9%88%E8%BF%9B%E8%A1%8C%E5%A4%A7%E8%A1%A8%E7%9A%84%E5%AD%97%E6%AE%B5%E6%89%A9%E5%AE%B9

某客户的业务中有一张约4亿行的表,因为业务扩展,表中open_id varchar(50) 需要扩容到 varchar(500).
变更期间尽量减少对主库的影响(最好是不要有任何影响->最终争取了4个小时的窗口期)。

环境:Mysql 8.0.22
1主1从 基于Gtid复制

1.第一个问题,这是一张大表吗? 是的,请看

此表的ibd 文件280G + count长时间无返回 + 使用备库看了一下确认行数>4亿

既然是大表,我们应该使用什么方式做变更呢?

下文中的 M 表示主库,S1 为从1 ,S2 为从2

为什么我们没有选择前3种方案?

根据实际情况评估,本次业务侧的需求是此表24h都有业务流量,且不接受超过4小时的业务不可用时间

OnlineDDL的方式,ALGORITHM=COPY时,期间会阻塞DML(只读),最后主副表rename操作时(不可读写),直到DDL完成(其中需要的时间不确定)。

Gh-ost的方式,推荐的模式为连接从库,在主库转换,此模式对主库影响最小,可通过参数设置流控。致命的缺点是此工具的变更时间太长,4亿的表,测试环境使用了70个小时。最后我们还需要下发切换命令及手动删除中间表*_del。如果是1主2从还是比较推荐这种方式的,因为还有一个从库可以保障数据安全。

Pt-osc 和Gh-ost都属于第三方,Pt-osc 对大表的操作和OnlineDDL有一个共同的缺点就是失败回滚的代价很大。

如果是低版本如MySQL<5.7可以使用,理论上OnlineDDL是在MySQL5.6.7开始支持,刚开始支持的不是很好,可适当取舍。

最后我们选择了,DBA最喜爱(xin ku)的一种方式,在M-S1-S2级联复制下进行。

新建一个S1的从库,构建M-S1-S2级联复制

使用OnlineDDL在S2上进行字段扩容 (优点是期间M-S1的主从不受影响)

扩容完成后,等待延迟同步M-S1-S2 (降低S2与M的数据差异,并进行数据验证)

移除S1,建立M-S2的主从关系(使S2继续同步M的数据)

备份S2恢复S1,建立M-S2-S1级联复制

应用停服,等待主从数据一致(优点是差异数据量的同步时间很短)

最终S2成为主库,S1为从库(应用需要修改前端连接信息)

应用进行回归验证

以上内容看上去很复杂,本质上就是备份恢复。读者可将其做为备选方案。分享一下具体步骤?

补充场景: 基于磁盘IO能力的测试

直接在主库上修改,且无流量的情况下:
场景1,磁盘是NVME的物理机,4亿数据大约需要5个小时(磁盘性能1G/s)。
场景2,磁盘是机械盘的虚拟机,此数据量大约需要40个小时(磁盘性能100M/s)。

本文:MySQL级联复制下怎么进行大表的字段扩容的详细内容,希望对您有所帮助,信息来源于网络。
上一篇:Mybatis大数据量批量写优化的方法是什么下一篇:

33 人围观 / 0 条评论 ↓快速评论↓

(必须)

(必须,保密)

阿狸1 阿狸2 阿狸3 阿狸4 阿狸5 阿狸6 阿狸7 阿狸8 阿狸9 阿狸10 阿狸11 阿狸12 阿狸13 阿狸14 阿狸15 阿狸16 阿狸17 阿狸18