http://seanlook.com/2016/05/27/mysql-pt-online-schema-change/
http://blog.itpub.net/22664653/viewspace-2056953
如果正在看這篇文章，相信你已經知道自己的需求了。
在 mysql 5.5 版本以前，修改表結構如添加索引、修改列，需要鎖表，期間不能寫入，對於大表這簡直是災難。從5.5特別是5.6里，情況有了好轉，支持Online DDL，相關介紹見 這篇文章，而我在實際alter table過程中還是會引起 data meta lock 問題。pt-online-schema-change是Percona-toolkit一員，通過改進原生ddl的方式，達到不鎖表在線修改表結構。
1. pt-osc工作過程
- 創建一個和要執行 alter 操作的表一樣的新的空表結構(是alter之前的結構)
- 在新表執行alter table 語句（速度應該很快）
- 在原表中創建觸發器3個觸發器分別對應insert,update,delete操作
- 以一定塊大小從原表拷貝數據到臨時表，拷貝過程中通過原表上的觸發器在原表進行的寫操作都會更新到新建的臨時表
- Rename 原表到old表中，在把臨時表Rename為原表
- 如果有參考該表的外鍵，根據alter-foreign-keys-method參數的值，檢測外鍵相關的表，做相應設置的處理
- 默認最后將舊原表刪除
2. 常用選項說明
只介紹部分常用的選項
--host=xxx --user=xxx --password=xxx
連接實例信息，縮寫-h xxx -u xxx -p xxx，密碼可以使用參數--ask-pass手動輸入。--alter
結構變更語句，不需要ALTER TABLE關鍵字。與原始ddl一樣可以指定多個更改，用逗號分隔。- 絕大部分情況下表上需要有主鍵或唯一索引，因為工具在運行當中為了保證新表也是最新的，需要舊表上創建 DELETE和UPDATE 觸發器，同步到新表的時候有主鍵會更快。個別情況是，當alter操作就是在c1列上建立主鍵時，DELETE觸發器將基於c1列。
- 子句不支持 rename 去給表重命名。
- alter命令原表就不支持給索引重命名，需要先drop再add，在pt-osc也一樣。(mysql 5.7 支持 RENAME INDEX old_index_name TO new_index_name)
但給字段重命名，千萬不要drop-add，整列數據會丟失，使用change col1 col1_new type constraint（保持類型和約束一致，否則相當於修改 column type，不能online） - 子句如果是add column並且定義了not null，那么必須指定default值，否則會失敗。
- 如果要刪除外鍵（名 fk_foo），使用工具的時候外鍵名要加下划線，比如
--alter "DROP FOREIGN KEY _fk_foo"
-
D=db_name,t=table_name
指定要ddl的數據庫名和表名 -
--max-load
默認為Threads_running=25。每個chunk拷貝完后，會檢查 SHOW GLOBAL STATUS 的內容，檢查指標是否超過了指定的閾值。如果超過，則先暫停。這里可以用逗號分隔，指定多個條件，每個條件格式：status指標=MAX_VALUE或者status指標:MAX_VALUE。如果不指定MAX_VALUE，那么工具會這只其為當前值的120%。
因為拷貝行有可能會給部分行上鎖，Threads_running 是判斷當前數據庫負載的絕佳指標。 -
--max-lag
默認1s。每個chunk拷貝完成后，會查看所有復制Slave的延遲情況（Seconds_Behind_Master）。要是延遲大於該值，則暫停復制數據，直到所有從的滯后小於這個值。--check-interval配合使用，指定出現從庫滯后超過 max-lag，則該工具將睡眠多長時間，默認1s，再檢查。如--max-lag=5 --check-interval=2。
熟悉percona-toolkit的人都知道--recursion-method可以用來指定從庫dsn記錄。另外，如果從庫被停止，將會永遠等待，直到從開始同步，並且延遲小於該值。 -
--chunk-time
默認0.5s，即拷貝數據行的時候，為了盡量保證0.5s內拷完一個chunk，動態調整chunk-size的大小，以適應服務器性能的變化。
也可以通過另外一個選項--chunk-size禁止動態調整，即每次固定拷貝 1k 行，如果指定則默認1000行，且比 chunk-time 優先生效 -
--set-vars
使用pt-osc進行ddl要開一個session去操作，set-vars可以在執行alter之前設定這些變量，比如默認會設置--set-vars "wait_timeout=10000,innodb_lock_wait_timeout=1,lock_wait_timeout=60"。
因為使用pt-osc之后ddl的速度會變慢，所以預計2.5h只能還不能改完，記得加大wait_timeout。 -
--dry-run
創建和修改新表，但不會創建觸發器、復制數據、和替換原表。並不真正執行，可以看到生成的執行語句，了解其執行步驟與細節，和--print配合最佳。。 -
--execute
確定修改表，則指定該參數。真正執行alter。–dry-run與–execute必須指定一個，二者相互排斥
3. 使用疑惑（限制）
3.1 原表上不能有觸發器存在
這個很容易理解，pt-osc會在原表上創建3個觸發器，而一個表上不能同時有2個相同類型的觸發器，為簡單通用起見，只能一棍子打死。
所以如果要讓它支持有觸發器存在的表也是可以實現的，思路就是：先找到原表觸發器定義；重寫原表觸發器；最后階段將原表觸發器定義應用到新表。
3.2 通過觸發器寫數據到臨時新表，會不會出現數據不一致或異常
這其實是我的一個顧慮，因為如果update t1，觸發update t2，但這條數據還沒copy到t2，不就有異常了嗎？后台通過打開general_log，看到它創建的觸發器：
1 |
6165 Query CREATE TRIGGER `pt_osc_confluence_sbtest3_del` AFTER DELETE ON `confluence`.`sbtest3` |
在原表上update，新臨時表上是replace into整行數據，所以達到有則更新，無則插入。同時配合后面的 insert ignore，保證這條數據不會因為重復而失敗。
3.3 為什么外鍵那么特殊
假設 t1 是要修改的表，t2 有外鍵依賴於 t1，_t1_new 是 alter t1 產生的新臨時表。
這里的外鍵不是看t1上是否存在外鍵，而是作為子表的 t2。主要問題在 rename t1 時，t1“不存在”導致t2的外鍵認為參考失敗，不允許rename。
pt-osc提供--alter-foreign-keys-method選項來決定怎么處理這種情況：
rebuild_constraints，優先采用這種方式- 它先通過 alter table t2 drop fk1,add _fk1 重建外鍵參考，指向新表
- 再 rename t1 t1_old, _t1_new t1 ，交換表名，不影響客戶端
- 刪除舊表 t1_old
但如果字表t2太大，以致alter操作可能耗時過長，有可能會強制選擇 drop_swap。
涉及的主要方法在pt-online-schema-change文件的 determine_alter_fk_method, rebuild_constraints,swap_tables三個函數中。
drop_swap，- 禁用t2表外鍵約束檢查
FOREIGN_KEY_CHECKS=0 - 然后 drop t1 原表
- 再 rename _t1_new t1
這種方式速度更快，也不會阻塞請求。但有風險，第一，drop表的瞬間到rename過程，原表t1是不存在的，遇到請求會報錯；第二，如果因為bug或某種原因，舊表已刪，新表rename失敗，那就太晚了，但這種情況很少見。
我們的開發規范決定，即使表間存在外鍵參考關系，也不通過表定義強制約束。
- 禁用t2表外鍵約束檢查
3.4 在使用之前需要對磁盤容量進行評估
使用OSC會使增加一倍的空間，包括索引
而且在 Row Based Replication 下，還會寫一份binlog。不要想當然使用--set-vars去設置 sql_log_bin=0，因為在這個session級別，alter語句也要在從庫上執行，除非你對從庫另有打算。
4. 使用 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從庫，主備切換，再改原主庫
借助percona博客一張圖說明一下：
5. 示例
-
添加新列
完整輸出過程1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53[root@ssd-34 sysbench]# pt-online-schema-change --user=user --password=password --host=10.0.201.34 --alter "ADD COLUMN f_id int default 0" D=confluence,t=sbtest3 --print --execute
No slaves found. See --recursion-method if host ssd-34 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 `confluence`.`sbtest3`...
Creating new table... ==> 創建新表
CREATE TABLE `confluence`.`_sbtest3_new` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) COLLATE utf8_bin NOT NULL DEFAULT '',
`pad` char(60) COLLATE utf8_bin NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_3` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=5000001 DEFAULT CHARSET=utf8 COLLATE=utf8_bin MAX_ROWS=1000000
Created new table confluence._sbtest3_new OK.
Altering new table... ==> 使用ddl修改新表結構
ALTER TABLE `confluence`.`_sbtest3_new` ADD COLUMN f_id int default 0
Altered `confluence`.`_sbtest3_new` OK.
2016-05-24T20:54:23 Creating triggers... ==> 在舊表上創建3個觸發器
CREATE TRIGGER `pt_osc_confluence_sbtest3_del` AFTER DELETE ON `confluence`.`sbtest3` FOR EACH ROW
DELETE IGNORE FROM `confluence`.`_sbtest3_new` WHERE `confluence`.`_sbtest3_new`.`id` <=> OLD.`id`
CREATE TRIGGER `pt_osc_confluence_sbtest3_upd` AFTER UPDATE ON `confluence`.`sbtest3` FOR EACH ROW
REPLACE INTO `confluence`.`_sbtest3_new` (`id`, `k`, `c`, `pad`) VALUES (NEW.`id`, NEW.`k`, NEW.`c`, NEW.`pad`)
CREATE TRIGGER `pt_osc_confluence_sbtest3_ins` AFTER INSERT ON `confluence`.`sbtest3` FOR EACH ROW
REPLACE INTO `confluence`.`_sbtest3_new` (`id`, `k`, `c`, `pad`) VALUES (NEW.`id`, NEW.`k`, NEW.`c`, NEW.`pad`)
2016-05-24T20:54:23 Created triggers OK.
2016-05-24T20:54:23 Copying approximately 4485573 rows... ==> 分塊拷貝數據到新表
INSERT LOW_PRIORITY IGNORE INTO `confluence`.`_sbtest3_new` (`id`, `k`, `c`, `pad`)
SELECT `id`, `k`, `c`, `pad` FROM `confluence`.