MySQL变更之：Online DDL 和 PT-OSC 该选谁？

 

参考：

http://www.fromdual.ch/online-ddl_vs_pt-online-schema-change

 

在MySQL 5.6版本以前，最昂贵的数据库操作之一就是执行数据定义语言（DDL，例如CREATE，DROP，ALTER等）语句，特别是ALTER语句，因为在修改表时，MySQL会阻塞整个表的读写操作。

对于巨大的表，可能需要几个小时才能完成表的DDL，如此势必会影响应用程序，因此需要对这些操作进行良好的规划，以避免在高峰时段进行这些更改。对于那些有全天候服务（24*7）或有限维护时间的人来说，大表上的DDL是一场真正的噩梦。

Percona开发了一个非常好的工具，称为 pt-online-schema-change，在线执行此类操作，而不会阻塞或影响应用程序，且允许对正在更改的表进行读/写操作。

MySQL也对DDL语句进行了一些增强，并在MySQL 5.6中引入了在线DDL功能。

 

PT-ONLINE-SCHEMA-CHANGE

OVERVIEW

pt-osc 用于 alter table 时不锁表，简单地说，这个工具创建一个与原始表一样的新的空表，并根据需要更改表结构，然后将原始表中的数据以小块形式复制到新表中，然后删除原始表，然后将新表重命名为原始名称。在复制过程中，对原始表的所有新的更改（insert，delete，update）都将应用于新表，因为在原始表上创建了一个触发器，以确保所有新的更改都将应用于新表。有关 pt-online-schema-change 工具的更多信息，请查阅手册文档 。大致的工作流程总结如下：

pt-osc工作过程

  1. 创建一个和要执行 alter 操作的表一样的新的空表结构(是alter之前的结构)
  2. 在新表执行alter table 语句（速度应该很快）
  3. 在原表中创建触发器3个触发器分别对应insert,update,delete操作
  4. 以一定块大小从原表拷贝数据到临时表，拷贝过程中通过原表上的触发器在原表进行的写操作都会更新到新建的临时表（会限制每次拷贝数据的行数以保证拷贝不会过多消耗服务器资源，采用 LOCK IN SHARE MODE 来获取要拷贝数据段的最新数据并对数据加共享锁阻止其他会话修改数据，不过每次加S锁的行数不多，很快就会被释放）
  5. Rename 原表到old表中，在把临时表Rename为原表（整个过程只在rename表的时间会锁一下表，其他时候不锁表）
  6. 如果有参考该表的外键，根据alter-foreign-keys-method参数的值，检测外键相关的表，做相应设置的处理
  7. 默认最后将旧原表删除

EXAMPLE

给表 test.scutech 的 name 字段加一个索引 idx_name （下面的输出完整的描述了该工具在后台执行的所有步骤）：

# pt-online-schema-change --print --execute --alter="add index idx_name(name)" D=test,t=scutech,h=localhost,u=root,p=xxxxxx       
No slaves found.  See --recursion-method if host CentOS6.6-zabbix has slaves.
Not checking slave lag because no slaves were found and --check-slave-lag was not specified.
Operation, tries, wait:
  analyze_table, 10, 1
  copy_rows, 10, 0.25
  create_triggers, 10, 1
  drop_triggers, 10, 1
  swap_tables, 10, 1
  update_foreign_keys, 10, 1
Altering `test`.`scutech`...
Creating new table...
CREATE TABLE `test`.`_scutech_new` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `number` int(11) DEFAULT NULL,
  `name` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=10000001 DEFAULT CHARSET=utf8mb4
Created new table test._scutech_new OK.
Altering new table...
ALTER TABLE `test`.`_scutech_new` add index idx_name(name)
Altered `test`.`_scutech_new` OK.
2018-05-11T17:15:18 Creating triggers...
CREATE TRIGGER `pt_osc_test_scutech_del` AFTER DELETE ON `test`.`scutech` FOR EACH ROW DELETE IGNORE FROM `test`.`_scutech_new` WHERE `test`.`_scutech_new`.`id` <=> OLD.`id`
CREATE TRIGGER `pt_osc_test_scutech_upd` AFTER UPDATE ON `test`.`scutech` FOR EACH ROW BEGIN DELETE IGNORE FROM `test`.`_scutech_new` WHERE !(OLD.`id` <=> NEW.`id`) AND `test`.`_scutech_new`.`id` <=> OLD.`id`;REPLACE INTO `test`.`_scutech_new` (`id`, `number`, `name`) VALUES (NEW.`id`, NEW.`number`, NEW.`name`);END 
CREATE TRIGGER `pt_osc_test_scutech_ins` AFTER INSERT ON `test`.`scutech` FOR EACH ROW REPLACE INTO `test`.`_scutech_new` (`id`, `number`, `name`) VALUES (NEW.`id`, NEW.`number`, NEW.`name`)
2018-05-11T17:15:18 Created triggers OK.
2018-05-11T17:15:18 Copying approximately 9977440 rows...
INSERT LOW_PRIORITY IGNORE INTO `test`.`_scutech_new` (`id`, `number`, `name`) SELECT `id`, `number`, `name` FROM `test`.`scutech` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) AND ((`id` <= ?)) LOCK IN SHARE MODE /*pt-online-schema-change 124376 copy nibble*/
SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `test`.`scutech` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) ORDER BY `id` LIMIT ?, 2 /*next chunk boundary*/
Copying `test`.`scutech`:  12% 03:24 remain
Copying `test`.`scutech`:  26% 02:49 remain
Copying `test`.`scutech`:  38% 02:22 remain
Copying `test`.`scutech`:  48% 02:09 remain
Copying `test`.`scutech`:  58% 01:46 remain
Copying `test`.`scutech`:  65% 01:33 remain
Copying `test`.`scutech`:  72% 01:19 remain
Copying `test`.`scutech`:  78% 01:04 remain
Copying `test`.`scutech`:  86% 00:43 remain
Copying `test`.`scutech`:  92% 00:25 remain
2018-05-11T17:20:43 Copied rows OK.
2018-05-11T17:20:44 Analyzing new table...
2018-05-11T17:20:44 Swapping tables...
RENAME TABLE `test`.`scutech` TO `test`.`_scutech_old`, `test`.`_scutech_new` TO `test`.`scutech`
2018-05-11T17:20:45 Swapped original and new tables OK.
2018-05-11T17:20:45 Dropping old table...
DROP TABLE IF EXISTS `test`.`_scutech_old`
2018-05-11T17:20:46 Dropped old table `test`.`_scutech_old` OK.
2018-05-11T17:20:46 Dropping triggers...
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_scutech_del`;
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_scutech_upd`;
DROP TRIGGER IF EXISTS `test`.`pt_osc_test_scutech_ins`;
2018-05-11T17:20:46 Dropped triggers OK.
Successfully altered `test`.`scutech`.

 

 

PT-ONLINE-SCHEMA-CHANGE 的局限性

  • 在使用此工具之前，应为表定义PRIMARY KEY或唯一索引，因为它是DELETE触发器所必需的；
  • 如果表已经定义了触发器，则不支持 pt-osc ；（显然不是不能有任何触发器，只是不能有针对insert、update、delete的触发器存在，因为一个表上不能有两个相同类型的触发器）
  • 如果表具有外键约束，需要使用选项 --alter-foreign-keys-method ；
  • 还是因为外键，对象名称可能会改变（indexes names 等）；
  • 在Galera集群环境中，不支持更改MyISAM表，系统变量 wsrep_OSU_method 必须设置为 TOI（total order isolation）。

 

ONLINE DDL

OVERVIEW

在MySQL 5.6中，引入了在线 DDL方法，以便访问和写入正在更改的表。在线DDL语法与指定两个参数后的正常 alter语句完全相同：

ALGORITHM:

  • INPLACE: 表的更改将在原表进行，而不用重建整个表格（在大多数情况下，不需要将数据复制到临时表）
  • COPY: 将数据复制到临时表中，重建表格并重建二级索引（相当于传统方法）

LOCK:

  • NONE: Read and write operations are allowed during the altering process.
  • SHARED: Only read operations are allowed during the altering operations (DML is not allowed).
  • EXCLUSIVE: The entire table will be locked for both reading and writing (neither select nor DML are allowed).

Online DDL 在手册文档中有详细说明，您可以在这里查看更多信息。

 

哪些 ddl 操作可以使用 inplace算法？

https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html#innodb-online-ddl-summary-grid

 

EXAMPLE

给表 test.test2 的 name 字段加一个索引 name_idx 

mysql> alter table test2
    -> add index name_idx (name),algorithm=inplace, lock=none;
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

 

LIMITATIONS OF ONLINE DDL

  • 仅适用于InnoDB（语法上它可以与其他存储引擎一起使用，如MyISAM，但MyISAM只允许algorithm = copy，与传统方法相同）；
  • 无论使用何种锁（NONE，共享或排它），在开始和结束时都需要一个短暂的时间来锁表（排它锁）；参考这里
  • 在添加/删除外键时，应该禁用 foreign_key_checks 以避免表复制；
  • 仍然有一些 alter 操作需要 copy 或 lock 表（老方法）， 有关哪些表更改需要表复制或表锁定，请查看手册；
  • 如果在表上有 ON ... CASCADE 或 ON ... SET NULL 约束，则在 alter table 语句中不允许LOCK = NONE；
  • Online DDL 会被复制到从库（同主库一样，如果 LOCK = NONE，从库也不会加锁），但复制本身将被阻止，因为 alter 在从库以单线程执行，这将导致主从延迟问题。

 

COMPARISON RESULTS

下图是 Online DDL 和 PT-OSC 的一些操作的比较，表有 1,078,880 行。

rows affected 为 0，说明使用 in-place 方法，非0 则使用 copy-table 方法。当 rows affected 非0 时，建议使用 pt-osc 进行表变更。

另外，如果原表已经是 InnoDB 引擎，执行 alter table tb_name engine=innodb; 影响的行数是 0 ，可以使用 in-place ，此方法可以清理表空间的磁盘碎片。

 

WHICH METHOD SHOULD BE USED?

虽然pt-online-schema-change允许对被修改的表进行读写操作，但它仍然将表数据复制到后台的临时表中，这会在MySQL服务器上增加开销。 所以基本上，如果Online DDL不能有效地工作，我们才应该使用pt-online-schema-change。换句话说，如果在线DDL需要将数据复制到临时表（algorithm=copy），并且该表将被阻塞很长一段时间（lock = exclusive）或者在复制环境中更改大表时，则应该使用 pt-online-schema-change 工具。

 

使用 pt-osc 和原生 5.6 online ddl相比，如何选择？

  • online ddl在必须copy table时成本较高，不宜采用
  • pt-osc工具在存在触发器时，不适用
  • 修改索引、外键、列名时，优先采用online ddl，并指定 ALGORITHM=INPLACE
  • 其它情况使用pt-osc，虽然存在copy data
  • pt-osc比online ddl要慢一倍左右，因为它是根据负载调整的
  • 无论哪种方式都选择的业务低峰期执行
  • 特殊情况需要利用主从特性，先alter从库，再改原主库（sql_log_bin），可避免主从延迟

在执行 ALTER TABLE 语句时，如果不清楚是否可以用上 Online DDL 的 inplace 算法，可以直接在语句后面加上 ALGORITHM = INPLACE，如果语句不能使用 in-place 机制，该语句会立即停止。 

 

posted @ 2018-02-01 20:55  LeRoi  阅读(1356)  评论(0)  编辑  收藏  举报