目录
- 1.前言
- 2.Online DDL和PT-OSC原理、执行机制以及优缺点
- 2.1.Online DDL
- 2.2.PT-OSC
- 3.各种常用DDL操作如何选择
1.前言
MySQL DDL(Data Definition Language
)表结构变更,主要支持Online DDL和PT-OSC模式,但是即使知道两者的工作原理,在什么情况下选择什么模式新增或者更改mysql的表结构,感觉能完整清楚表述出的文章并不太多。
因此站在巨人的肩膀上,将大佬的总结,进行理解、补充和记录。
以下文章以 MySQL 5.7.24 版本作为讲述依据
官方文档:https://dev.mysql.com/doc/refman/5.7/en/innodb-introduction.html
2.Online DDL和PT-OSC原理、执行机制以及优缺点
在线DDL(Data Definition Language
)操作和Percona Toolkit中的pt-online-schema-change
工具都是为了在不停机的情况下进行数据库模式更改而设计的,旨在减少或消除对应用程序的影响。
他们的一个显著区别在Online DDL采用数据迁移的方式将原数据逐步迁移到新表中,而PT-OSC采用的是直接复制原表数据
2.1.Online DDL
在线DDL操作利用数据库管理系统(DBMS)内部的机制来实现在服务不中断的情况下修改表结构。这通常通过创建一个新表(具有新的模式),然后在后台将旧表的数据迁移到新表,最后原子性地交换两个表的引用,从而完成模式变更。整个过程对外部查询是透明的,可以继续访问旧数据,直到切换完成。
包含以下几个步骤:
- 创建新表:创建一个与原表结构相似但包含所需更改的新表。
- 数据迁移:将原表的数据逐步迁移到新表中。
- DML重放:在数据迁移过程中,捕获并重放所有对原表的DML(数据操纵语言)操作,以保持数据一致性。
- 表交换:完成数据迁移和DML重放后,使用原子操作替换原表和新表的引用,确保客户端无缝过渡到新表。
- 清理:删除旧表或将其标记为废弃。
优点:
- 无停机时间:可以在不影响应用服务的情况下进行模式更改。
- 数据一致性:保证数据在迁移过程中的完整性和一致性。
缺点:
- 性能影响:在数据迁移期间,可能会影响数据库的写入性能。主要集中在DML重放
- 资源消耗:需要额外的存储空间来容纳新表。
- 复制延迟:如果有从库,这有一个很致命的弱点。因为主库执行的动作,会在从库再来一遍,如果这个动作是非常耗时的,那在从库执行(重放主库的动作)的时间点开始,其后续所有动作都被堵塞住,直到从库也执行完这个DDL后,才会继续按顺序执行其他SQL。这就就意味着,从从库执行开始,从库复制就出现了延迟,延迟的时间会慢慢变大,直到DDL执行完后,延迟才会慢慢变小。
- 特殊情况:云侧MySQL RDS,本身有一个隐藏从库用于高可用,因为这个隐藏从库不对外提供服务,所以基本上业务侧也不需要去关注他。但极端情况,如果大表DDL操作使用Online DDL模式时,在隐藏从库正在执行DDL期间,主库挂了,那常理就需要切换到隐藏从库,才能继续提供服务,但为了保证数据的一致性,隐藏从库必须要等DDL执行完,再回放DDL之后的binlog,然后,才能将其提升为主库,对外提供服务,所以这个恢复时间有可能很长。总得来讲,这个情况对业务而言也是致命的,只不过概率极低。
2.2.PT-OSC
pt-online-schema-change
是一个外部工具,它利用自身的算法和技术来实现在线DDL操作,它通过创建一个与原表结构相似的新表,并逐步将数据从旧表复制到新表,同时应用任何结构更改。在复制过程中,它会捕获并重放DML(Data Manipulation Language
)操作,确保数据的连续性和一致性。复制完成后,它会原子性地替换原表。
包含以下几个步骤:
- 创建副本:同样创建一个与原表结构相同的新表,但在此基础上进行所需的结构更改。
- 数据复制:开始将原表的数据复制到新表,同时使用多线程技术来加速复制过程。
- DML捕获与重放:使用二进制日志或其他机制捕获原表的所有DML操作,并在新表上重放,以保持数据同步。
- 表替换:数据复制和DML重放完成后,执行原子性的表替换操作。
- 后期处理:清理临时资源,如删除旧表或调整索引。
优点:
-
高度自动化:提供了丰富的选项和自动化功能,简化了在线模式更改的过程。
- 它可以自动从源表复制数据到新表。这个过程是增量的,意味着它会持续监控源表上的更改(包括插入、更新和删除),并将这些更改同步到新表,直到模式更改完成。
- 提供了详细的进度报告,包括复制了多少数据、剩余多少数据、复制速率等信息,这有助于DBA实时监控操作状态
- 允许用户调整各种参数,如内存使用、并发级别、复制策略等,以便更好地适应不同的硬件条件和数据库负载。这些高级配置选项可能在标准的在线DDL操作中是不可用的
- 内置了错误恢复机制,能够在遇到问题时自动尝试恢复,或者至少保持数据的一致性,避免半途而废导致的问题。这在标准的在线DDL操作中可能需要额外的手动步骤来实现。
-
灵活:支持多种数据复制策略,如多线程复制,以提高效率,也就是说可以并行处理多个分区或表的一部分,从而加速数据迁移过程,减少对数据库性能的影响,并且允许用户根据数据库的具体情况定制执行计划,比如先复制哪些数据、后复制哪些数据,这在标准的在线DDL操作中可能不是一个可选功能
-
兼容性:适用于多种MySQL版本和配置环境。
缺点:
- 需要将老表的所有数据都拷贝到新表上,这就意味着拷贝期间,磁盘IO可能较高。 要拷贝全量数据,所以执行时间也会很长。
- 新临时表存放数据也需要空间(最大空间需求可能和原表一样),拷贝数据时还会产生大量binlog,所以对于本来空间就紧张的实例而言,这方式真的是雪上加霜
3.各种常用DDL操作如何选择
原理理解之后,到选择阶段就很容易了,以下是我整理的常用的选择,如果想了解更多,可以看这篇文章:
https://developer.jdcloud.com/article/3923?mid=30