MySQL--pt-osc工具学习

##=====================================================##
pt-osc之工作流程：
1、检查更改表是否有主键或唯一索引，是否有触发器
2、检查修改表的表结构，创建一个临时表，在新表上执行ALTER TABLE语句
3、在源表上创建三个触发器分别对于INSERT UPDATE DELETE操作
4、从源表拷贝数据到临时表，在拷贝过程中，对源表的更新操作会写入到新建表中
5、将临时表和源表rename（需要元数据修改锁，需要短时间锁表）
6、删除源表和触发器，完成表结构的修改。

##=====================================================##
pt-osc之工具限制
1、源表必须有主键或唯一索引，如果没有工具将停止工作
2、如果线上的复制环境过滤器操作过于复杂，工具将无法工作
3、如果开启复制延迟检查，但主从延迟时，工具将暂停数据拷贝工作
4、如果开启主服务器负载检查，但主服务器负载较高时，工具将暂停操作
5、但表使用外键时，如果未使用--alter-foreign-keys-method参数，工具将无法执行
6、只支持Innodb存储引擎表，且要求服务器上有该表1倍以上的空闲空间。

##=====================================================##
pt-osc之拷贝数据
在拷贝数据过程中，工具会把数据按照主键或唯一键进行拆分，限制每次拷贝数据的行数以保证拷贝进行不过多消耗服务器资源。为保证源表和目标表数据相同，采用LOCK IN SHARE MODE来获取要拷贝数据段的最新数据并对数据加共享锁组织其他回话修改数据，采用LOW_PRIORITY IGNORE来将数据插入到新表中， 关键字LOW_PRIORIT使得插入操作会等待其他访问该表的操作完成会再执行，关键字INGORE使得表中出现主键或唯一索引键重复时新数据被忽略而不会被插入。

对表`testdb1`.`tb1001`进行修改时的数据拷贝脚本：

## 先获取下一次拷贝数据的边界，强制索引可以有效避免执行计划出现问题
SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `testdb1`.`tb1001` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '8394306')) ORDER BY `id` LIMIT 22256, 2 /*next chunk boundary*/

## 通过拷贝数据的边界限制，防止单次拷贝过多数据而长时间阻塞其他回话
INSERT LOW_PRIORITY IGNORE INTO `testdb1`.`_tb1001_new` (`id`, `c1`, `c6`) SELECT `id`, `c1`, `c6` FROM `testdb1`.`tb1001` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '8394306')) AND ((`id` <= '8416562')) LOCK IN SHARE MODE /*pt-online-schema-change 14648 copy nibble*/

##=====================================================##
pt-osc之触发器

pt-osc工具在源表上创建三个AFTER触发器分别对于INSERT UPDATE DELETE操作，DELETE触发器使用DELETE IGNORE来保证源表和新表的数据都被删除， 而INSERT和UPDATE触发器使用REPLACE INTO来保证新表数据和源表数据一致。

由于MySQL限制相同类型的触发器只能有一个，因此需要在运行前检查源表上是否有触发器，为保证删除和更新效率和方便和将源表数据进行分片处理，因此要求表上有主键或唯一索引。

##=====================================================##
pt-osc之主机性能影响

为避免过度影响主机性能，pt-osc工具通过以下几个方面来限制：
1、通过参数chunk-size和chunk-time控制每次拷贝数据大小
2、通过参数max-load来检查主机当前压力，每次chunk拷贝完成后，都会运行SHOW GLOBAL STATUS LIKE 'Threads_running' 命令检查当前正在运行的Threads数量，默认Threads_running=25，如果未指定最大值，则会取当前值的120%作为最大值，如果超过阀值则会暂停数据拷贝

##=====================================================##
pt-osc之从库复制延迟

对于复制延迟比较敏感的业务，可以通过下面参数来控制复制延迟：

--max-log
默认为1s，每个chunks拷贝完成后，会查看check-slave-lag参数所指定的从库的延迟信息，如果超过max-log的阀值，则暂停复制数据，直到复制延迟小于max-log的阀值。检查复制延迟信息依赖于SHOW SLAVE STATUS语句中返回的Seconds_Behind_Master列的值。

--check-interval
当出现复制延迟暂停复制数据后，按照check-interval指定的时间进行周期检查复制延迟，直到延迟时间低于max-log阀值，然后恢复数据拷贝

--check-slave-lag
需要检查复制延迟的从库IP
如果指定check-slave-lag参数，且从库无法正常连接或从库IO线程和SQL线程停止，会认为主从存在延迟，导致复制数据操作一直暂停。
如果未指定check-slave-lag参数，默认还是会检查从库的延迟，但复制延迟不会导致数据复制暂停。

##=====================================================##
pt-osc之chunk设置
在pt-osc的帮助文档中，关于chunk的参数有如下：
--chunk-index=s Prefer this index for chunking tables

--chunk-index-columns=i Use only this many left-most columns of a --chunk-index

--chunk-size=z Number of rows to select for each chunk copied (default 1000)

--chunk-size-limit=f Do not copy chunks this much larger than the desired chunk size (default 4.0)

--chunk-time=f Adjust the chunk size dynamically so each data-copy query takes this long to execute (default 0.5)

当chunk-size和chunk-time两者都未指定时，chunk-size默认值为1000，chunk-time默认值为0.5S，第一次按照chunk-size来进行数据复制，然后根据第一次复制的时间动态调整chumk-size的大小，以适应服务器的性能变化，如上一次复制1000行消耗0.1S，则下次动态调整chumk-size为5000。
如果明确指定chumk-size的值或将chunk-time指定为0，则每次都按照chunk-size复制数据。

##=====================================================##
pt-osc之alter语句限制
1、不需要包含alter table关键字，可以包含多个修改操作，使用逗号分开，如"drop clolumn c1, add column c2 int"
2、不支持rename语句来对表进行重命名操作
3、不支持对索引进行重命名操作
4、如果删除外键，需要对外键名加下划线，如删除外键fk_uid, 修改语句为"DROP FOREIGN KEY _fk_uid"
##=====================================================##
pt-osc之命令模板
## --execute表示执行
## --dry-run表示只进行模拟测试
## 表名只能使用参数t来设置，没有长参数
pt-online-schema-change \
--host="127.0.0.1" \
--port=3358 \
--user="root" \
--password="root@root" \
--charset="utf8" \
--max-lag=10 \
--check-salve-lag='xxx.xxx.xxx.xxx' \
--recursion-method="hosts" \
--check-interval=2 \
--database="testdb1" \
t="tb001" \
--alter="add column c4 int" \
--execute

##=====================================================##
pt-osc之命令输出
上面命令执行输出如下：
No slaves found. See --recursion-method if host 171DB166 has slaves.
Will check slave lag on:
170DB166
Operation, tries, wait:
copy_rows, 10, 0.25
create_triggers, 10, 1
drop_triggers, 10, 1
swap_tables, 10, 1
update_foreign_keys, 10, 1
Altering `testdb1`.`tb001`...
Creating new table...
Created new table testdb1._tb001_new OK.
Altering new table...
Altered `testdb1`.`_tb001_new` OK.
2016-04-28T23:18:04 Creating triggers...
2016-04-28T23:18:04 Created triggers OK.
2016-04-28T23:18:04 Copying approximately 1 rows...
2016-04-28T23:18:04 Copied rows OK.
2016-04-28T23:18:04 Swapping tables...
2016-04-28T23:18:04 Swapped original and new tables OK.
2016-04-28T23:18:04 Dropping old table...
2016-04-28T23:18:04 Dropped old table `testdb1`.`_tb001_old` OK.
2016-04-28T23:18:04 Dropping triggers...
2016-04-28T23:18:04 Dropped triggers OK.
Successfully altered `testdb1`.`tb001`.

##=====================================================##