共计 1154 个字符，预计需要花费 3 分钟才能阅读完成。
一、缩小元数据变更的措施
元数据变更是数据库治理中不可避免的工作项，缩小元数据变更次数可升高数据库保护和治理老本，加重对业务的影响。这里咱们能够优先思考以下 3 点：
- 精密打算
在数据库设计和开发阶段，精密设计元数据结构可无效防止设计不合理或不充沛的状况； - 防止适度设计
为升高保护难度和变更次数，元数据结构设计该当秉承简略、实用、合乎业务需要的准则，防止适度设计； - 合并应用束缚
在设计元数据结构时，合并应用束缚，包含主键、外键、唯一性束缚、非空束缚等能够保证数据的完整性和一致性。
二、MySQL Metadata Lock 流程
- 由 LEX 和 YACC 依据语句的类型给须要拜访的表初始化 MDL 锁申请；
- MDL_context 调用 acquire_lock 发动 MDL_request；
- 顺利获取到 MDL_ticket，就实现了 MDL 的获取，能够持续查问过程。如果无奈获取到，就须要进行锁期待；
- 每个线程在进入锁期待前，会进行一次死锁检测，防止以后线程陷入死等。
三、PT-OSC 流程
- 创立一个与原表构造雷同的空表，表名是 _new 后缀；
- 批改步骤 1 创立的空表的表构造；
- 在原表上加三个触发器：delete/update/insert，用于复制数据时，将原表中要执行的语句在新表中执行；
- 将原表数据以数据块的模式复制到新表；
- 将原表重命名为 old 表，并把新表重命名为原表名，而后删除旧表；
- 删除触发器。
四、F1 Schema 变更算法
- 租约：F1 约定了数分钟的 Schema 租约，在租约过期前所有服务器要实现变更操作，如果超时没有实现则认为服务器下线进行工作；
- 中间状态：把一次 Schema 变更拆解为多个逐渐递进的中间状态，使两两中间状态可兼容，整个变更过程转化为演化过程。
五、OSC 流程图
第 1 步：将元数据由 Absent 状态演进到 DELETE_ONLY 状态，Version 加一，同时增加的 Mutation 只对 Delete 操作可见；
第 2 步：通过 waitToUpdateLeases 函数期待集群的其余节点将元数据更新到 Version2，这期间 Version2 的元数据和 Version1 共存，此时在节点 2 插入数据，因为 DELETE_ONLY 状态下 Mutation 对 insert 操作不可见，所以不会减少索引数据；
第 3 步：Mutation 将由 DELETE_ONLY 状态演进到 WRITE_ONLY 状态，同时 Version 加 1，此时 Mutation 对 Insert 和 Delete 操作可见；
第 4 步：再次期待其余节点将表元数据更新到 Version3；
第 5 步：只有须要做数据回填的 DDL 语句才会执行，比方减少索引、删除列、减少带默认值的列等；
第 6 步：Mutation 将变成索引并增加到表元数据中，以后节点实现变更操作；
第 7 步：再次期待其余节点获取到最新的表元数据，此次变更操作完结。
正文完
