MySQL級聯(lián)復制下如何進行大表的字段擴容
MySQL級聯(lián)復制下進行大表的字段擴容
作者:雷文霆
愛可生華東交付服務(wù)部 DBA 成員,主要負責Mysql故障處理及相關(guān)技術(shù)支持。愛好看書,電影。座右銘,每一個不曾起舞的日子,都是對生命的辜負。
本文來源:原創(chuàng)投稿
*愛可生開源社區(qū)出品,原創(chuàng)內(nèi)容未經(jīng)授權(quán)不得隨意使用,轉(zhuǎn)載請聯(lián)系小編并注明來源。
一、背景
某客戶的業(yè)務(wù)中有一張約4億行的表,因為業(yè)務(wù)擴展,表中open_id varchar(50) 需要擴容到 varchar(500).
變更期間盡量減少對主庫的影響(最好是不要有任何影響->最終爭取了4個小時的窗口期)。
二、庫表信息
環(huán)境:Mysql 8.0.22
1主1從 基于Gtid復制
1.第一個問題,這是一張大表嗎? 是的,請看
此表的ibd 文件280G + count長時間無返回 + 使用備庫看了一下確認行數(shù)>4億
以下語句也可以查看: show table status from dbname like 'tablename'\G # Rows 的值不準,有時誤差有2倍 SELECT a.table_schema,a.table_name,concat(round(sum(DATA_LENGTH/1024/1024)+sum(INDEX_LENGTH/1024/1024),2) ,'MB')total_size,concat(round(sum(DATA_LENGTH/1024/1024),2),'MB') AS data_size,concat(round(sum(INDEX_LENGTH/1024/1024),2),'MB') AS index_size FROM information_schema.TABLES a WHERE a.table_schema = 'dbname' AND a.table_name = 'tablename'; #看下此表的數(shù)據(jù)量
既然是大表,我們應(yīng)該使用什么方式做變更呢?
三、方案選擇
下文中的 M 表示主庫,S1 為從1 ,S2 為從2
| 方式 | 優(yōu)點 | 缺點 | 可行性 |
|---|---|---|---|
| OnlineDDL | 原生,使用中間臨時表 | ALGORITHM=COPY時,會阻塞DML,推薦版本>MySQL5.7 | 5星 |
| Gh-ost | 使用binlog+回放線程代替觸發(fā)器 | 第三方工具,根據(jù)不同的參數(shù)導致執(zhí)行時間較長 | 4星 |
| Pt-osc | 版本兼容性好,使用觸發(fā)器保持主副表一致 | 第三方工具,且使用限制較多 | 3星 |
| M-S1-S2 | 時間可預估 | 級聯(lián)復制,人工操作 | 1星 |
為什么我們沒有選擇前3種方案?
根據(jù)實際情況評估,本次業(yè)務(wù)側(cè)的需求是此表24h都有業(yè)務(wù)流量,且不接受超過4小時的業(yè)務(wù)不可用時間
OnlineDDL的方式,ALGORITHM=COPY時,期間會阻塞DML(只讀),最后主副表rename操作時(不可讀寫),直到DDL完成(其中需要的時間不確定)。
Gh-ost的方式,推薦的模式為連接從庫,在主庫轉(zhuǎn)換,此模式對主庫影響最小,可通過參數(shù)設(shè)置流控。致命的缺點是此工具的變更時間太長,4億的表,測試環(huán)境使用了70個小時。最后我們還需要下發(fā)切換命令及手動刪除中間表*_del。如果是1主2從還是比較推薦這種方式的,因為還有一個從庫可以保障數(shù)據(jù)安全。
Pt-osc 和Gh-ost都屬于第三方,Pt-osc 對大表的操作和OnlineDDL有一個共同的缺點就是失敗回滾的代價很大。
如果是低版本如MySQL<5.7可以使用,理論上OnlineDDL是在MySQL5.6.7開始支持,剛開始支持的不是很好,可適當取舍。
最后我們選擇了,DBA最喜愛(xin ku)的一種方式,在M-S1-S2級聯(lián)復制下進行。
四、如何進行操作
- 新建一個S1的從庫,構(gòu)建M-S1-S2級聯(lián)復制
- 使用OnlineDDL在S2上進行字段擴容 (優(yōu)點是期間M-S1的主從不受影響)
- 擴容完成后,等待延遲同步M-S1-S2 (降低S2與M的數(shù)據(jù)差異,并進行數(shù)據(jù)驗證)
- 移除S1,建立M-S2的主從關(guān)系(使S2繼續(xù)同步M的數(shù)據(jù))
- 備份S2恢復S1,建立M-S2-S1級聯(lián)復制
- 應(yīng)用停服,等待主從數(shù)據(jù)一致(優(yōu)點是差異數(shù)據(jù)量的同步時間很短)
- 最終S2成為主庫,S1為從庫(應(yīng)用需要修改前端連接信息)
- 應(yīng)用進行回歸驗證
以上內(nèi)容看上去很復雜,本質(zhì)上就是備份恢復。讀者可將其做為備選方案。分享一下具體步驟?
環(huán)境裝備:開啟Gtid,注意M,S1 binlog保存時長,磁盤剩余空間大于待變更表的2倍 show global variables like 'binlog_expire_logs_seconds'; # 默認604800 set global binlog_expire_logs_seconds=1209600; # 主庫和級聯(lián)主庫都需要設(shè)置 1.搭建 1主2從的級聯(lián)復制,M -> S1 -> S2 ,安裝MySQL注意本次環(huán)境lower_case_table_names = 0 2.在S2 上做字段擴容。 預估 10個小時 `參數(shù)設(shè)置:` set global slave_type_conversions='ALL_NON_LOSSY'; # 防止復制報錯SQL_Errno: 13146,屬于字段類型長度不一致無法回放 set global interactive_timeout=144000;set global wait_timeout =144000; `磁盤IO參數(shù)設(shè)置:` set global innodb_buffer_pool_size=32*1024*1024*1024;# 增加buffer_pool 防止Error1206The total number of locks exceeds the lock table size 資源不足 set global sync_binlog=20000;set global innodb_flush_log_at_trx_commit=2; set global innodb_io_capacity=600000;set global innodb_io_capacity_max=1200000; # innodb_io_capacity需要設(shè)置兩次 show variables like '%innodb_io%'; # 驗證以上設(shè)置 screen 下執(zhí)行: time mysql -S /data/mysql/3306/data/mysqld.sock -p'' dbname -NBe "ALTER TABLE tablename MODIFY COLUMN open_id VARCHAR(500) NULL DEFAULT NULL COMMENT 'Id' COLLATE 'utf8mb4_bin';" 查看DDL進度: SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM performance_schema.events_stages_current; 3.擴容完成后,等待延遲同步M-S1-S2 數(shù)據(jù)同步至主從一致,對比主從Gtid 4.移除S1,建立M-S2的主從關(guān)系 S1 (可選) stop slave; reset slave all; systemctl stop mysql_3306 S2 stop slave; reset slave all; # MASTER_HOST='M主機IP' CHANGE MASTER TO MASTER_HOST='', MASTER_USER='', MASTER_PASSWORD=', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_CONNECT_RETRY=10; start slave; (flush privileges;# 驗證數(shù)據(jù)可正常同步) 5.備份S2恢復S1,建立M-S2-S1級聯(lián)復制 物理備份S2,重做S2->S1 級聯(lián)主從 rm -rf binlog/* rm -rf redolog/* xtrabackup --defaults-file=/data/mysql/3306/my.cnf.3306 --move-back --target-dir=/data/actionsky/xtrabackup_recovery/data chown -R mysql. data/ chown -R mysql. binlog/* chown -R mysql. redolog/* systemctl start mysql_3306 set global gtid_purged=''; reset slave all; # MASTER_HOST='S2主機IP' ,已擴容變更完的主機 CHANGE MASTER TO MASTER_HOST='', MASTER_USER='', MASTER_PASSWORD='', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_CONNECT_RETRY=10; `MySQL8.0版本需要在上面語句中添加 GET_MASTER_PUBLIC_KEY=1; #防止 Last_IO_Errno: 2061 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.` start slave; 6.應(yīng)用停服,等待主從數(shù)據(jù)一致 主庫停服+可設(shè)置read_only+flush privileges,對比主從Gtid 7.最終S2成為主庫,S1為從庫 應(yīng)用更改配置連接新主庫。 S2上: stop slave;reset slave all; set global read_only=0;set global super_read_only=0; `show master status\G 觀察是否有新事務(wù)寫入` 收尾:還原第2步的參數(shù)設(shè)置。 set global interactive_timeout=28800;set global wait_timeout =28800; set global innodb_buffer_pool_size=8*1024*1024*1024; set global slave_type_conversions=''; set global sync_binlog=1;set global innodb_flush_log_at_trx_commit=1; set global innodb_io_capacity=2000;set global innodb_io_capacity_max=4000;
補充場景: 基于磁盤IO能力的測試
直接在主庫上修改,且無流量的情況下:
場景1,磁盤是NVME的物理機,4億數(shù)據(jù)大約需要5個小時(磁盤性能1G/s)。
場景2,磁盤是機械盤的虛擬機,此數(shù)據(jù)量大約需要40個小時(磁盤性能100M/s)。
五、總結(jié)
- 使用級聯(lián),對于業(yè)務(wù)側(cè)來說,時間成本主要在應(yīng)用更改連接和回歸驗證。如果從庫無流量,不需要等待業(yè)務(wù)低峰。
- OnlineDDL可通過修改參數(shù),提高效率,其中雙一參數(shù)會影響數(shù)據(jù)安全,推薦業(yè)務(wù)低峰期操作。
- Gh-ost 適合變更時間寬裕的場景,業(yè)務(wù)低峰期操作,可調(diào)整參數(shù)加快進度,自定義切換的時間。
- 以上方式均不推薦多個DDL同時進行,即并行DDL。
- 大表操作和大數(shù)據(jù)量操作,需要我們貼合場景找到合適的變更方案,不需要最優(yōu),需要合適。
福利時間:分享一個速查表

到此這篇關(guān)于MySQL級聯(lián)復制下進行大表的字段擴容的文章就介紹到這了,更多相關(guān)mysql字段擴容內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
千萬級記錄的Discuz論壇導致MySQL CPU 100%的優(yōu)化筆記
談到自己在解決一個擁有 60 萬條記錄的 MySQL 數(shù)據(jù)庫訪問時,導致 MySQL CPU 占用 100% 的經(jīng)過。在解決問題完成優(yōu)化(optimize)之后,我發(fā)現(xiàn) Discuz 論壇也存在這個問題,當時稍微提了一下2010-12-12
SQL?Server攜程核心系統(tǒng)無感遷移到MySQL實戰(zhàn)
這篇文章主要介紹了SQL?Server攜程核心系統(tǒng)無感遷移到MySQL實戰(zhàn),文章通過基于數(shù)據(jù)庫部署架構(gòu)鏡像構(gòu)建了訂單緩存統(tǒng)一管理熱點數(shù)據(jù),解決各端差異,具體詳情需要的小伙伴可以參考下面文章詳細內(nèi)容2022-05-05
Mysql連接無效(invalid connection)問題及解決
這篇文章主要介紹了Mysql連接無效(invalid connection)問題及解決方案,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2023-02-02
MySQL 5.5.49 大內(nèi)存優(yōu)化配置文件優(yōu)化詳解
最近mysql服務(wù)器升級到了MySQL 5.5.49版本,性能比mysql 5.0.**肯定效率高了不少,但mysql的默認配置文件不合理,這里是針對大內(nèi)存訪問量大的機器的配置方案,需要的朋友可以參考下2016-05-05
MySQL數(shù)據(jù)庫的卸載與安裝(Linux?Centos)
如果大家曾經(jīng)安裝過MySQL,現(xiàn)在想要更新MySQL的版本或者因為某些原因?qū)е滦枰匮bMySQL,請記住重裝之前一定要把之前的MySQL版本卸載干凈,這篇文章主要給大家介紹了關(guān)于MySQL數(shù)據(jù)庫的卸載與安裝的相關(guān)資料,需要的朋友可以參考下2024-05-05
MySQL表字段設(shè)置默認值(圖文教程及注意細節(jié))
默認值的設(shè)置很重要,比如在插入的時候一些字段是可以省略的,這會帶來很多的方便,接下來將要介紹MySQL表字段設(shè)置默認值感興趣的你可以千萬不要走開啊,希望本文對你有所幫助2013-01-01

