【MySQL】实验DDL选择Online DDL照旧PT-OSC？

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。