本文簡單介紹 pt-online-schema-change 工具。

1 原理介紹

表格必須帶有主鍵或者唯一索引！！

假設現有tbosc需要做ALTER操作，使用pt-online-schema-change的時候，根據tbddl表結構及索引情況，創建一個新的空表_tbosc_new，然後從原始表格 tbosc 中拷貝數據到新的表格 _tbosc_new，copy data結束後，使用_tbosc_new替換tbddl，同時，刪除舊錶。

簡單流程如上描述，那麼詳細流程是怎麼樣的呢？

帶着這幾個問題來了解：

ALTER操作期間，表格是否支持DML？
如果支持DML，是如何把DML同步到新的臨時表上？
整個操作流程鎖情況是怎麼樣的？
執行期間有什麼性能影響？
該工具有什麼限制情況？

1.1 詳細執行流程

如何查看其詳細的執行流程呢？數據庫開啓general log，然後執行pt-online-schema-change，它對數據庫的所有操作，就都呈現在眼前。

詳細執行流程如下：

相關環境參數檢查
檢查該表格是否存在
show create table tbosc
create table _tbosc_new
alter table _tbosc_new
創建刪除觸發器 pt_osc_dbddl_tbosc_del (如果數據修改的時候，還沒有拷貝過來，修改後再拷貝則是覆蓋，正確；如果是已經拷貝過來，再修改，也是正確，這裏同時會檢查是否具有主鍵或者唯一索引，如果都沒有，這一步會報錯，提示The new table `dbosc`.`_tbosc_new` does not have a PRIMARY KEY or a unique index which is required for the DELETE trigger.）
創建更新觸發器 pt_osc_dbddl_tbosc_upd
創建插入觸發器 pt_osc_dbddl_tbosc_ins
按塊拷貝數據到新表，拷貝過程對數據行持有S鎖
analyze 新表
rename 表名，RENAME TABLE `dbddl`.`tbosc` TO `dbddl`.`_tbosc_old`, `dbddl`.`_tbosc_new` TO `dbddl`.`tbosc`
刪除舊錶
刪除新表上的刪除、更新、插入觸發器

1.2 問題解答

根據其執行流程，可以對一開始的提問一一來解答。

ALTER操作期間，表格是否支持DML？
- ALTER過程採用Copy Table To New Table的方式，新建一個表格，然後在原表上創建3個觸發器：DELETE\UPDATE\INSERT觸發器，一旦新表，拷貝數據到新表的過程中，如果原表數據發生變化，則會通過觸發器更新到新表上。
- 如果支持DML，是如何把DML同步到新的臨時表上？
- ALTER過程採用Copy Table To New Table的方式，新建一個表格，然後在原表上創建3個觸發器：DELETE\UPDATE\INSERT觸發器，一旦新表，拷貝數據到新表的過程中，如果原表數據發生變化，則會通過觸發器更新到新表上。
- INSERT原表的時候，觸發器根據其主鍵ID把新紀錄INSERT到新表上；
- UPDATE原表的時候，觸發器根據其主鍵ID判斷新舊ID是否一致，如果一致則刪除，然後在REPLACE INTO新紀錄到新表
- DELETE原表的時候，觸發器根據其主鍵ID直接刪除行記錄
- 如果數據修改的時候，還沒有拷貝到新表，修改後再拷貝，雖然重複覆蓋，但是數據也沒有出錯；如果是數據已經拷貝，原表發生修改，這時觸發器同步修改數據，兩種情況下都保證了數據的一致性；
整個操作流程鎖情況是怎麼樣的？
- 創建新表後，按照每一個chunk的大小拷貝數據到新表，每次SELECT都是share mode，帶S鎖，但是每個chunk都比較小，所以鎖時間不大
- 最後數據拷貝結束，會有一個rename操作，這個操作過程中，是不支持DML操作的，但其速度很快，不會造成長時間鎖表情況
- 該工具會設置該DDL操作的鎖等待超時爲1s，當出現異常的時候，會是ALTER操作異常，而不是其他業務操作異常，這樣可以最大程度的不影響其他事務的進行

執行期間有什麼性能影響？

- 總體而言，對數據庫的鎖影響降低到了最小，執行期間允許DML操作
- 但是注意，任何DDL SQL在這裏，都是轉換成copy table to new table的形式，這個過程中，會極大佔用磁盤的IO跟CPU資源，同時跟住從延時帶來一定的影響，還是那句老話，重複瞭解DDL的影響程度後，再選擇合適時機執行。
- copy data過程中，如果主從延遲異常超過 max-lag則停止copy data，等待主從延遲恢復，默認爲1min，可以通過--max-lag設置
- 檢測到服務器負載異常，也會停止操作，可以通過 --max-load，--critical-load設置

該工具有什麼限制情況？
- 表格必須帶有主鍵或者唯一索引
- 存在複製過濾掉表格，ALTER操作
- copy data過程中，如果主從延遲異常超過 max-lag則停止copy data，等待主從延遲恢復，默認爲1s，可以通過--max-lag設置
- 檢測到服務器負載異常，也會停止操作，可以通過 --max-load，--critical-load設置
- 設置操作的鎖等待超時爲1s，當出現異常的時候，ALTER操作異常，而不是其他業務操作異常，這樣可以最大程度的不影響其他事務的進行
- 默認情況下，存在被外鍵引用的表格是不支持ALTER操作的，除非手動指定參數--alter-foreign-keys-method
- 不支持修改 Percona XtraDB Cluster （PXC）上節點的 myisam表格

2 環境準備

工具包下載網頁：https://www.percona.com/downloads/percona-toolkit/LATEST/ （目前最新版本爲3.0.2）

rpm下載地址：https://www.percona.com/downloads/percona-toolkit/3.0.2/binary/redhat/7/x86_64/percona-toolkit-3.0.2-1.el7.x86_64.rpm

官方使用說明文檔地址： https://www.percona.com/doc/percona-toolkit/LATEST/index.html

環境安裝依賴項目： Perl, DBI, DBD::mysql

安裝非常簡單，在安裝好相關的環境依賴項後，執行rpm安裝即可

rpm -ivh percona-toolkit-3.0.2-1.el7.x86_64.rpm

3 語法說明

3.1 主要選項

--alter
- 指定ALTER 語句，正常的ALTER TABLE TBNAME [ ADD | MODIFY | DROP | ALTER ] COLUMN COLUMN_NAME ...，去除前面的ALTER TABLE TABLE那麼，直接指定後部分的內容
- 注意事項
  - rename不支持，請直接使用RENAME TABLE tablename TO new_tablename;
  - 如果表格有數據，創建非空無默認值的列，會失敗，如果非空，需要指定默認值；
  - 如果表格有數據，爲一個可空的列添加默認值時，舊數據爲NULL的是不會被修改，依舊爲NULL，以後新加入到數據則會默認爲設置的默認值
  - 對於外鍵的刪除情況，由於執行是在新表上執行DDL，所以其外鍵值的命名跟原表的命名不一樣，假設刪除原表的外鍵名是 fk_foo，那麼新表的外鍵名就爲 _fk_foo，所以刪除的ALTER語句是： drop foreign key _fk_foo;

--alter-foreign-keys-method
- 如果修改的表格，是其他表格外鍵reference的表格，那麼，最後rename的過程，需要確保一定成功，要不然這些子表就沒能成功reference到其指定的表格名，對子表的操作將會報錯。比如 tba有一個外鍵 fk_tba引用表格 tbb，這個時候tbb需要做DDL操作，根據pt工具的原理得知，最後會有一個rename環節，這個環節可能會導致約束失效或者執行堵塞等問題。
- 所以，針對最後rename的這個環節，該工具提供了4中處理方法：
  - auto
    - 自動選擇 rebuild_constraints 或者 drop_swap，優先選擇rebuild_constraints
    - rebuild_constraints
    - rename table 前，先刪除子表的外鍵約束，然後重建外鍵約束指向到新表（ALTER TABLE語句添加），最後執行rename操作
    - 這個rename操作即使不成功，它也rename到新表，不會出現reference的表格不存在情況
    - 弊端：如果子表過大，添加外鍵約束的過程中，可能會對子表造成堵塞
  - drop_swap
    - 執行rename之前禁用外鍵檢查，然後刪除原表，rename新表爲原表名
    - 這個過程非常快並且沒有堵塞
    - 這個方法需要強制指定 --no-swap-tables 跟 --no-drop-old-table.
    - 弊端：當把原表刪除而新表還沒rename爲原表的名字時，這段時間實際非常短，但是這段時間內，等於原表名的表格時不存在的，子表做一些DML的時候，可能會出現錯誤。rename期間，如果新表rename原表失敗，但是已經刪除原表，那麼這段期間，其子表的操作將會出現大面積問題，直到人工修復
  - none
    - 類似drop_swap操作，不同在於對原表的處理。
    - 按正常的pt工具流程，禁用外鍵約束，rename原表爲臨時表，rename新表爲原表名，刪除臨時表
    - 弊端: 當把原表rename爲臨時表，而新表還沒rename爲原表的名字時，這段時間實際非常短，但是這段時間內，等於原表名的表格時不存在的，子表做一些DML的時候，可能會出現錯誤
  - --drop-old-table
    - 操作成功後，原表是否保留，默認是刪除，
    - default：yes，可選：--no-drop-old-table

--dry-run
- 僅創建新表格，但是不執行觸發器、拷貝數據跟替換原表
--execute
- 確定執行ALTER操作，注意，這個操作如果不指定，則僅做安全檢查然後推出。
- 充分了解工具的使用情況後，才執行，不要啥都不瞭解測試就線上執行，會挖坑的...
--host
- 連接主機名
--max-lag
- 默認1s
- 檢查從庫延遲的時間，如果超過，則停止copy data，休息--check-interval秒後，再重新開始copy數據
- 查看通過延遲時間，是通過從庫show slave status，查看Seconds_Behind_Master
- 如果指定--check-slave-lag，該工具只檢查該服務器的延遲，而不是所有服務器。
--check-interval
- 從庫延遲超過指定的--max-lag，中斷copy data休息的時間
- 默認爲1s
--max-load
- copy data的過程，監控數據庫當前正在運行的thread，如果超過指定的Threads_running值，則停止拷貝數據，會在輸出的內容中答應 Pausing because Threads_runing=15，直到運行的線程數小於給定的值，恢復copy data，如此循環，知道拷貝數據結束。
- Threads_runing默認爲25
- 舉例：--max-load=Threads_running=15
--password
- 數據庫用戶名的密碼
--port
- 數據庫端口號
--socket
- 數據庫socket文件
--user
- 數據庫用戶名

--recursion-method
- MASTER尋找SLAVE的方式（這個選項基本在涉及主從問題的pt工具中廣泛應用到）
- 有4個選項

- processlist，使用show processlist查找從庫
- hosts，如果不是使用默認端口號3306，那麼使用hosts方式來查找從庫會更可靠
- dsn，使用表格 tdsn存儲從庫信息（DSN的具體參數選項可以詳細查看 3.3 DSN選線）
  - 需要手動在需要DDL的數據庫內，創建 dsns 表格
  - CREATE TABLE `dsns` (`id` int(11) NOT NULL AUTO_INCREMENT,`parent_id` int(11) DEFAULT NULL,`dsn` varchar(255) NOT NULL, PRIMARY KEY (`id`));
  - 存儲從庫信息
  - insert into dsns(dsn) values(h=slave_host,u=repl_user,p=repl_password,P=port );
  - 該參數使用的時候，按以下格式（假設 dsns表格建立在數據庫 dbosc）
  - --recursion-method dsn=D=dbosc,t=dsns
- none，不查找從庫

3.2 輸出

--statistics 增加影響行數打印，可以查看copy進度
--print 詳細打印alter過程，不指定的時候，簡略打印

3.3 DSN選項

A
- 字符集設置
D
- 需要Alter的表格是在哪個數據庫，指定數據庫
F
- mysql read default file，如果數據源的相關選項存儲在文件中，則通過 F 來指定
h
- host，數據庫主機名或IP
p
- password，數據庫用戶的密碼
P
- port，數據庫實例端口號
S
- socket，實例socket文件
t
- 表格名
u
- 用戶名

4 使用舉例

4.1 常規DDL

常規情況，如果有被外鍵引用的表格，注意對--alter-foreign-keys-method的設置，本小節不考慮從庫延遲情況及外鍵情況。

pt-online-schema-change也支持同個表格的多個SQL合併爲一個SQL，由於所有DDL都是採用COPY TABLE TO NEW TABLE方式，所以使用的時候，不需要對DDL SQL做分類。

 1 CREATE TABLE `tbosc` (
 2   `id` int(11) NOT NULL AUTO_INCREMENT,
 3   `name` varchar(100) DEFAULT NULL,
 4   `age` int(11) DEFAULT NULL,
 5   PRIMARY KEY (`id`)
 6 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ;
 7  
 8 #添加列
 9 pt-online-schema-change --socket=/tmp/mysql3310.sock --user=root --password=ycf.com  D=dbosc,t=tbosc --alter "add column stunum int "  --recursion-method=none --no-check-replication-filters --alter-foreign-keys-method auto --print --execute
10  
11 #刪除列
12 pt-online-schema-change --socket=/tmp/mysql3310.sock --user=root --password=ycf.com  D=dbosc,t=tbosc --alter "drop column stunum "  --recursion-method=none --no-check-replication-filters --alter-foreign-keys-method auto --print --execute
13  
14 #修改列數據類型
15 pt-online-schema-change --socket=/tmp/mysql3310.sock --user=root --password=ycf.com  D=dbosc,t=tbosc --alter "modify column age varchar(10)"  --recursion-method=none --no-check-replication-filters --alter-foreign-keys-method auto --print --execute
16  
17 #加大列長度
18 pt-online-schema-change --socket=/tmp/mysql3310.sock --user=root --password=ycf.com  D=dbosc,t=tbosc --alter "modify column age varchar(100)"  --recursion-method=none --no-check-replication-filters --alter-foreign-keys-method auto --print --execute
19  
20 #創建索引
21 pt-online-schema-change --socket=/tmp/mysql3310.sock --user=root --password=ycf.com  D=dbosc,t=tbosc --alter "ADD INDEX IX_AGE(AGE)"  --recursion-method=none --no-check-replication-filters --alter-foreign-keys-method auto --print --execute
22  
23 #刪除索引
24 pt-online-schema-change --socket=/tmp/mysql3310.sock --user=root --password=ycf.com  D=dbosc,t=tbosc --alter "DROP INDEX IX_AGE"  --recursion-method=none --no-check-replication-filters --alter-foreign-keys-method auto --print --execute
25  
26 #設置默認值
27 pt-online-schema-change --socket=/tmp/mysql3310.sock --user=root --password=ycf.com  D=dbosc,t=tbosc --alter "ALTER column age SET DEFAULT 100"  --recursion-method=none --no-check-replication-filters --alter-foreign-keys-method auto --print --execute
28  
29 #能否多個合成一個
30 pt-online-schema-change --socket=/tmp/mysql3310.sock --user=root --password=ycf.com  D=dbosc,t=tbosc --alter "ADD COLUMN onecol int ,add column twocol varchar(100),add index ix_onecol(onecol),alter column name set default ‘xinysu‘ "  --recursion-method=none --no-check-replication-filters --alter-foreign-keys-method auto --print --execute

4.2 考慮從庫延遲情況

考慮從庫延遲情況，意味這要注意這幾個選項的設置

--max-lag
--check-interval
--recursion-method
--check-slave-lag

從庫延遲超過max-lag則停止copy data，等待 check-interval 秒後再開始copy data。check-slave-lag指定slave的機器，只會對比這臺slave的延遲情況。recursion-method是主庫尋找從庫的方法，有四個方法：processlist，hosts，dsn，none，具體查看上部分選項詳細說明，本節詳細描述dsn及check-slave-lag的使用。

假設需要在dbosc庫上的表格tbddl添加一列：hobby varchar(100) ，需要考慮從庫的延遲情況

#創建表格dsns，記錄從庫信息

CREATE TABLE `dsns` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`parent_id` int(11) DEFAULT NULL,

`dsn` varchar(255) NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8

#insert從庫信息，有2個從庫，分別爲242服務器上的 3310跟3320

insert into dsns(dsn) select "h=192.168.9.244,u=repl,p=****,P=3310";

insert into dsns(dsn) select "h=192.168.9.244,u=repl,p=****,P=3320";

如果需要考慮多個從庫的延遲情況，則可以考慮使用 dsns表格來記錄從庫信息，如果只需要考慮某一臺從庫的延遲情況，則既可以使用dsns表格也可以使用參數--check-slave-lag指定從庫。

不考慮外鍵關係，考慮從庫影響程度，檢查到從庫延遲超過1s，則休息5s，具體指令如下

pt-online-schema-change -P3310 --user=root --password=ycf.com D=dbosc,t=tbddl --max-lag=1s --check-interval=10s --alter "ADD hobby varchar(100) NOT NULL DEFAULT ‘sleep‘ " --recursion-method dsn=D=dbosc,t=dsns --alter-foreign-keys-method auto --execute

如果檢測到slave的 Seconds_Behind_Master超過1s，則會休息10s後再監測，這個過程會在輸出文件中打印出：

Replica lag is 395 seconds on sutest244. Waiting.

Replica lag is 425 seconds on sutest244. Waiting.

Replica lag is 456 seconds on sutest244. Waiting.

說明現在主從延時了多少秒，現在copy線程停止，正在等待中。

如果是僅指定一個從庫查看延遲情況，使用--check-slave-lag的指令如下：

pt-online-schema-change -P3310 --user=root --password=ycf.com D=dbosc,t=tbddl --max-lag=1 --check-interval=10 --check-slave-lag=h=192.168.9.244,u=root,p=ycf.com,P=3310 --alter "ADD hobby varchar(100) NOT NULL DEFAULT ‘sleep‘ " --recursion-method --alter-foreign-keys-method auto --print --execute

5 pt-osc還是online DDL？

經過這一篇介紹pt-online-schema-change的原理說明及測試，以及上篇的online ddl說明，可明白pt-osc無論是什麼DDL SQL，都會新建新表來替換，不分DDL類型，但是執行期間允許DDL操作，而ONLINE DDL則分爲了好幾類DDL，有的DDL僅需修改元數據，有的DDL僅需在本身ibd文件上新建索引頁，有的需要rebuild table，這三種類型執行期間支持DML操作，但是COPY TABLE 類型不支持DML操作。

因此，可以有以下幾個判斷：

如果MySQL版本是5.6之前，不支持online ddl操作的，pt-online-schema-change是一個非常好的選擇；
如果MySQL的版本是5.6以上的，支持online-ddl的，優先考慮使用online ddl，但是如果是ddl SQL 在online DDL中需要copy table to tmp table，則建議使用pt-online-schema-change來處理，比如修改列數據類型的DDL，online DDL則是需要copy table to tmp table，期間僅支持查詢，不支持DML操作，這個時候，就可以使用pt-online-schema-change來處理，因爲它也是拷貝臨時表格，並且執行期間支持DML操作；
如果執行Online DDL，但是對從庫的延遲非常敏感，針對需要copy table 跟rebuild table這兩類DDL SQL，需要考慮是否可以在從庫設置並行複製，如果不行，則優先選擇pt-online-schema-change。

isoleo

發佈了170 篇原創文章 · 獲贊 75 · 訪問量 63萬+

他的留言板關注

pt-online-schema-change 使用解析

1 原理介紹

1.1 詳細執行流程

1.2 問題解答

2 環境準備

3 語法說明

3.1 主要選項

3.2 輸出

3.3 DSN選項

4 使用舉例

4.1 常規DDL

4.2 考慮從庫延遲情況

5 pt-osc還是online DDL？

HTML頁面關於高分屏的設置

北歐瑞典挪威芬蘭瑞士TikTok海外網紅與YouTube博主的合作模式

歐洲英國德國法國TikTok與YouTube海外網紅達人的完美合作策略

druid數據源 xml配置

netstat下time_wait狀態的tcp連接

mysql 服務器 CentOS系統優化

inception審覈規則詳解

docker & docker-compose 安裝及解析

MongoDB aggregate 聚合管道

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結