摘要：在業界中有一個比較成熟的工具，針對大表的場景，可以在線進行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 。