pt-osc之工作流程：
1、檢查更改表是否有主鍵或唯一索引，是否有觸發(fā)器
2、檢查修改表的表結構，創(chuàng)建一個臨時表，在新表上執(zhí)行alter table語句
3、在源表上創(chuàng)建三個觸發(fā)器分別對于insert update delete操作
4、從源表拷貝數據到臨時表，在拷貝過程中，對源表的更新操作會寫入到新建表中
5、將臨時表和源表rename（需要元數據修改鎖，需要短時間鎖表）
6、刪除源表和觸發(fā)器，完成表結構的修改。
##=====================================================##
pt-osc之工具限制
1、源表必須有主鍵或唯一索引，如果沒有工具將停止工作
2、如果線上的復制環(huán)境過濾器操作過于復雜，工具將無法工作
3、如果開啟復制延遲檢查，但主從延遲時，工具將暫停數據拷貝工作
4、如果開啟主服務器負載檢查，但主服務器負載較高時，工具將暫停操作
5、但表使用外鍵時，如果未使用–alter-foreign-keys-method參數，工具將無法執(zhí)行
6、只支持Innodb存儲引擎表，且要求服務器上有該表1倍以上的空閑空間。
##=====================================================##
pt-osc之拷貝數據
在拷貝數據過程中，工具會把數據按照主鍵或唯一鍵進行拆分，限制每次拷貝數據的行數以保證拷貝進行不過多消耗服務器資源。為保證源表和目標表數據相同，采用LOCK IN SHARE MODE來獲取要拷貝數據段的最新數據并對數據加共享鎖組織其他回話修改數據，采用LOW_PRIORITY IGNORE來將數據插入到新表中， 關鍵字LOW_PRIORIT使得插入操作會等待其他訪問該表的操作完成會再執(zhí)行，關鍵字INGORE使得表中出現主鍵或唯一索引鍵重復時新數據被忽略而不會被插入。
對表`testdb1`.`tb1001`進行修改時的數據拷貝腳本：
## 先獲取下一次拷貝數據的邊界，強制索引可以有效避免執(zhí)行計劃出現問題
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`
##=====================================================##
pt-osc之觸發(fā)器
pt-osc工具在源表上創(chuàng)建三個AFTER觸發(fā)器分別對于INSERT UPDATE DELETE操作，DELETE觸發(fā)器使用DELETE IGNORE來保證源表和新表的數據都被刪除， 而INSERT和UPDATE觸發(fā)器使用REPLACE INTO來保證新表數據和源表數據一致。
由于MySQL限制相同類型的觸發(fā)器只能有一個，因此需要在運行前檢查源表上是否有觸發(fā)器，為保證刪除和更新效率和方便和將源表數據進行分片處理，因此要求表上有主鍵或唯一索引。
##=====================================================##
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之從庫復制延遲
對于復制延遲比較敏感的業(yè)務，可以通過下面參數來控制復制延遲：
–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來進行數據復制，然后根據第一次復制的時間動態(tài)調整chumk-size的大小，以適應服務器的性能變化，如上一次復制1000行消耗0.1S，則下次動態(tài)調整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表示執(zhí)行
## –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之命令輸出
上面命令執(zhí)行輸出如下：
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`.
