摘要：在業界中有一個比較成熟的工具，針對大表的場景，可以在線進行Alter變更，且不會出現鎖表的風險。除此之外，它還有其他的一些優點，讓我們開始探索吧。
背景
大家在日常工作中，往往需要對數據庫的表結構做變更，一般涉及到增刪字段，修改字段屬性等ALTER的操作。然而，在大表場景下，特別是千萬級、億級的大表，如果處理不當。這些操作往往會引發鎖表的巨大隱患，特別是在生產環境中，一旦在變更表結構過程中，出現了長時間鎖表，會導致用戶產生的數據長時間無法正常變更到表中，進而導致服務功能異常，結果將是災難性的。
一般執行這種Alter類型的變更，我們可能有以下的想法：
1、停服，在停服期間做表結構的變更，自然就可以防止對用戶產生影響。但是，很多場景是不允許停服的。並且如果表的數據量達到上億，那么需要停服時間可能需要十幾個小時，甚至更長，這是極不現實的；
2、凌晨執行，在用戶較少的時間段內，做變更，盡量減少對用戶產生影響。但是如果出現鎖表的話，萬一有用戶使用服務，服務將不可用；
3、使用換表，但是缺點是復制數據到新表期間，如果用戶在這期間做了update或delete操作，且數據發生在已經復制完成的部分，那么將無法感知到這部分數據，導致丟失掉用戶的操作數據，風險太大；
4、使用存儲過程，缺點是執行時間會很久，且有可能影響到用戶的DDL操作。因為為了防止每次循環修改時，鎖住太多數據行，我們需要控制每次更新數據的行數，粒度不能太大，否則很有可能會鎖住用戶正在操作的數據行。
那么針對以上實際的需求，就沒有一個很好的工具，來解決我們的痛點嗎？其實在業界中，就有一個比較成熟的工具，針對大表的場景，可以在線進行Alter變更，且不會出現鎖表的風險。除此之外，它還有其他的一些優點，讓我們開始探索吧。
一、pt-osc是什么
pt-online-schema-change是Percona-toolkit一員，通過改進原生ddl的方式，達到不鎖表在線修改表結構的效果。在Percona的官網中，關於pt-osc工具，也特別提到了ALTER表不會出現鎖表的特性。
針對上面談到的避免鎖表、感知用戶更新刪除動作等，ps-osc工具是怎么解決的呢？
pt-osc主要執行步驟如下：
1、創建一個跟原表一模一樣的新表，命名方式為'_正式表名_new';
2、使用alter語句將要變更的內容在新創建的新表上做變更，避免了對原表的alter操作；
3、在原表中創建3個觸發器，分別是insert、update和delete，主要是用於原表在往新表復制數據時，如果用戶有DDL操作，觸發器能夠將在這期間出現的DDL操作數據也寫入到新表中，確保新表的數據是最新的，不會丟失掉用戶的新操作數據；
4、按塊拷貝數據到新表，拷貝過程對數據行持有S鎖；
5、重命名，將原表重命名為老表，命名為“_正式表名_old”，將新表重命名為正式表，可通過配置決定執行完成后是否刪除掉老表；
6、刪除3個觸發器；
二、pt-osc的安裝
在linux系統中安裝步驟：
--下載安裝包 wget http://szxge1-sw.artifactory.cd-cloud-artifact.tools.huawei.com/artifactory/CommonComponent/common/tool/percona-toolkit-3.1.0.tar.gz --解壓安裝包 tar -zxvf percona-toolkit-3.1.0.tar.gz --安裝依賴環境 yum install perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker yum -y install perl-Digest-MD5 cd percona-toolkit-3.1.0 perl Makefile.PL --編譯 make make install yum install mariadb --安裝Mysql yum install perl-DBD-MySQL
三、pt-osc的使用
pt-osc工具使用起來很簡單，直接在linux命令行輸入pt-osc格式的命令，即可直接執行。
以Mysql數據庫增加一個名字是MARK的字段為例：
pt-online-schema-change --user="root" --password="*****" --host="數據庫IP" --port=3306 --alter "ADD COLUMN MARK TINYINT NULL DEFAULT 1 COMMENT 'mark source region is 1';" D=my_test,t=t_test --no-drop-old-table --execute --print --no-check-replication-filters --charset=utf8 --no-check-unique-key-change --max-load="Threads_running=100" --critical-load="Threads_running=300" --recursion-method=none;
在上面的語句中：
1、user和password分別為數據庫執行變更操作的用戶名、密碼，需要高權限；
2、host為數據庫的IP地址；
3、port為數據庫的端口號；
4、alter后面跟上具體的alter語句；
5、D為database名字；
6、t為要執行變更的表名；
7、no-drop-old-table就是不要刪除
8、charset，字符集，使用utf8；
9、max-load，在復制數據時，工具會監控數據庫中正在運行的線程數，如果大於配置的Threads_running值，那么會暫停復制，直到小於該值。以此防止對數據庫造成較大壓力，影響現網業務正常使用；
10、critical-load，默認為50，在每個塊之后檢查SHOW GLOBAL STATUS，與max-load不同的是，如果負載太高，,直接中止，而不是暫停。可根據自己數據庫情況斟酌配置閾值；
注意：在--alter后面跟着的變更語句中，列名不可以加`符號，否則會出現報錯。如--alter "ADD COLUMN MARK TINYINT NULL DEFAULT 1 COMMENT 'mark source region is 1';"，MARK字段加了`符號，就會出現錯誤，COMMENT后面有`符號無影響。
下面是使用pt-osc工具，實際執行一個作業時，打印出來的信息。為了安全起見，部分日志信息做了隱藏忽略。
[root@ttt ~]# `pt-online-schema-change --user="root" --password="*****" --host="數據庫IP" --port=3306 --alter "ADD COLUMN MARK TINYINT NULL DEFAULT 1 COMMENT 'mark source region is 1';" D=my_test,t=t_test --no-drop-old-table --execute --print --no-check-replication-filters --charset=utf8 --no-check-unique-key-change --max-load="Threads_running=100" --critical-load="Threads_running=300" --recursion-method=none;` No slaves found. See --recursion-method if host EulerOS-BaseTemplate 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 `my_test`.`t_test`... Creating new table... CREATE TABLE `my_test`.`_t_test_new` ( `ID` int(11) NOT NULL AUTO_INCREMENT COMMENT '遞增ID', .............建表語句數據................ Created new table my_test._t_test_new OK. Altering new table... ALTER TABLE `my_test`.`_t_test_new` ADD COLUMN MARK TINYINT NULL DEFAULT 1 COMMENT 'mark source region is 1'; Altered `my_test`.`_t_test_new` OK. 2020-10-14T11:14:48 Creating triggers... 2020-10-14T11:14:48 Created triggers OK. 2020-10-14T11:14:48 Copying approximately 346697 rows... INSERT LOW_PRIORITY IGNORE INTO `my_test`.`_t_test_new` (`id`, ..建表語句信息.... FROM `my_test`.`_t_test_new` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) AND ((`id` <= ?)) LOCK IN SHARE MODE /*pt-online-schema-change 31340 copy nibble*/ SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `my_test`.`t_test` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) ORDER BY `id` LIMIT ?, 2 /*next chunk boundary*/ 2020-10-14T11:14:53 Copied rows OK. 2020-10-14T11:14:53 Analyzing new table... 2020-10-14T11:14:53 Swapping tables... RENAME TABLE `my_test`.`t_test` TO `my_test`.`_t_test_old`, `my_test`.`_t_test_new` TO `my_test`.`t_test` 2020-10-14T11:14:53 Swapped original and new tables OK. Not dropping old table because --no-drop-old-table was specified. 2020-10-14T11:14:53 Dropping triggers... DROP TRIGGER IF EXISTS `my_test`.`pt_osc_my_test_t_test_del` DROP TRIGGER IF EXISTS `my_test`.`pt_osc_my_test_t_test_upd` DROP TRIGGER IF EXISTS `my_test`.`pt_osc_my_test_t_test_ins` 2020-10-14T11:14:54 Dropped triggers OK. Successfully altered `my_test`.`t_test`.
四、性能對比
前面介紹了很多pt-osc的優點，以及良好的特性。那么實際使用效果到底怎么樣呢？在測試環境中，專門做了一個測試，讓大家有更加直觀的感受。
在測試庫中，准備了一張1600萬數據的大表，目標為對大表添加一個字段，分別使用存儲過程和pt-osc工具，進行測試。
4.1 使用存儲過程
首先使用存儲過程做測試，為防止鎖表，每次只更新200行。整個變更從開始到完成，需要耗費90分鍾。其實，存儲過程在執行過程中，如果恰好用戶也在DDL操作存儲過程正在變更的數據行，還有可能會鎖住用戶的數據，導致用戶不能變更成功。
4.2 使用pt-osc工具
pt-osc從開始執行到變更完成，耗時7分鍾左右，速度非常快。在執行的過程中，測試環境的服務連接到該數據庫，並執行多個會操作該表的任務，整個過程中，任務能夠正常執行，未出現異常情況。
5、結語
ps-osc的上述優點，在現網環境的不停服等要求下，能夠優雅地幫助我們實施變更，且保證在變更期間，數據庫不會受到鎖表、過載等的影響，進而保證了業務能夠正常運轉。
本文分享自華為雲社區《千萬級、億級大表在線不鎖表變更字段與索引》，原文作者：active_zhao 。