資訊專欄INFORMATION COLUMN
背景及現(xiàn)象
03月01接到客戶要求，處理其MySQL問題，原本告知只是三節(jié)點的的主從同步異常，需要將數(shù)據(jù)庫拉起來重新同步，想必是個簡單的問題。
但show slave status三個節(jié)點后發(fā)現(xiàn)，并沒有主從同步的信息，第二天前往現(xiàn)場和客戶了解詳細情況，并通過詳細的檢查發(fā)現(xiàn)，其1節(jié)點數(shù)據(jù)庫從2021年12月1日已經(jīng)出現(xiàn)未同步的情況，2節(jié)點從2022年2月23日出現(xiàn)異常，3個節(jié)點各自獨立,可以正常啟動,但無法建立集群關(guān)系和對外提供訪問。
分析過程
2.1 登錄各節(jié)點查看數(shù)據(jù)庫信息
檢查各節(jié)點數(shù)據(jù)庫版本信息如下：
mysql Ver 14.14 Distrib 5.7.36, for Linux (x86_64) using EditLine wrapper2.2 檢查各節(jié)點數(shù)據(jù)庫狀態(tài)如下，三個節(jié)點數(shù)據(jù)庫均為啟動狀態(tài)：
2.3 檢查數(shù)據(jù)庫集群3個成員狀態(tài)如下，目前集群中所有成員狀態(tài)均為offline：
2.4 檢查數(shù)據(jù)集群3個成員GTID情況，3節(jié)點數(shù)據(jù)為最新數(shù)據(jù)。
db03
db02
db01
2.5 檢查集群router配置文件無誤。
2.6 對比各節(jié)點大表數(shù)據(jù)量情況如下，2節(jié)點數(shù)據(jù)量最多，3節(jié)點其次，1節(jié)點最少。
2.7 檢查數(shù)據(jù)庫后臺日志情況如下：
Db01：數(shù)據(jù)庫一節(jié)點在2021-11-30日開始就存在磁盤空間不足導(dǎo)致應(yīng)用的日志無法寫入磁盤,同步出現(xiàn)異常。
Db02：數(shù)據(jù)庫2節(jié)點從2022-02-12日開始就存在磁盤空間不足導(dǎo)致應(yīng)用的日志無法寫入磁盤,同步出現(xiàn)異常。
Db03：數(shù)據(jù)庫3節(jié)點從2022-02-24日開始存在主從復(fù)制異常，無法連接到db01、db02節(jié)點。
綜上情況分析：
該數(shù)據(jù)庫集群屬于一主兩從的MySQL Router+Innodb Cluster集群, db03,db01為主,db02為從，但db01在2021年11月30日就已有問題，此節(jié)點已無效，需要重建。
主節(jié)點于2月24日無法連接其他兩節(jié)點，且binglog日志已經(jīng)被刪除，最終由于異常宕機導(dǎo)致集群不可用，目前是3節(jié)點以單實例方式對業(yè)務(wù)提供寫的需求。和客戶講述集群情況，最后確認兩種方案同時進行：
嘗試恢復(fù)現(xiàn)有集群，踢出1節(jié)點成員，3、2節(jié)點一主一從對外提供服務(wù)，不允許在現(xiàn)有集群中做備份任務(wù)(主機空間不足，且備份鎖表影響業(yè)務(wù));
新建一套集群，將客戶自行備份的數(shù)據(jù)(近500G的SQL文件)恢復(fù)到新集群中。
處理過程
和客戶溝通后，備份操作會影響已運行的主庫，取消了該操作，直接開始對2節(jié)點做節(jié)點恢復(fù)工作，集群成員恢復(fù)至2個節(jié)點，但2節(jié)點因存儲空間問題同步失敗，無法成為正常工作節(jié)點。
Db02無法找到需要同步的日志文件。
3.2 針對節(jié)點無法加入集群的故障，使用重置節(jié)點的方案，將db01、db02踢出集群后重新加入集群，操作方案如下：
按照以上方案，在擴容db01節(jié)點存儲空間后，執(zhí)行集群添加節(jié)點操作報錯如下：
MySQL5.7不支持clong節(jié)點的方法重置新節(jié)點，需要升級至8.0版本，隨放棄方案1，直接開始方案2。
客戶直接使用RPM安裝了一套MySQL 8.0.28版本的集群后，直接開始將數(shù)據(jù)導(dǎo)入到新集群中，第二天查看日志，導(dǎo)入90G左右后異常終止了，排查日志發(fā)現(xiàn)集群的3節(jié)點自動重啟了….
導(dǎo)入腳本只有如下一個錯誤（query aborted）：
懷疑是參數(shù)的問題，進過一系列的系統(tǒng)參數(shù)調(diào)優(yōu)、數(shù)據(jù)庫參數(shù)調(diào)優(yōu)：
#核心參數(shù)建議
skip_name_resolve =ON
explicit_defaults_for_timestamp =ON
log_timestamps =SYSTEM
max_connections=1000
max_connect_errors = 10000000
max_heap_table_size = 2048M
tmp_table_size = 2048M
lower_case_table_names=0
#*************** gtid ***************
binlog_format = ROW
binlog_rows_query_log_events = ON
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON
transaction_write_set_extraction = XXHASH64
###開啟主鍵信息采集功能，8.0.2開始默認值為XXHASH64
binlog_checksum = NONE
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_flush_method = O_DIRECT
innodb_buffer_pool_size = 16G
innodb_buffer_pool_instances = 6
#數(shù)據(jù)導(dǎo)入性能參數(shù)建議：
set global group_replication_flow_control_mode=QUOTA ;
set global group_replication_flow_control_applier_threshold=150000; --控制復(fù)制流
set global group_replication_flow_control_certifier_threshold=150000;
set global max_allowed_packet=536870912; --控制最大的包大小
set global max_prepared_stmt_count=65528;
set global slave_parallel_workers=8; --增大復(fù)制并行度調(diào)整完成后開啟第二次導(dǎo)入，在晚上21:31分，導(dǎo)入260G左右時再次異常終止，導(dǎo)入任務(wù)報錯和第一次一樣，數(shù)據(jù)庫日志發(fā)現(xiàn)2節(jié)點在當時被kill掉一個session! 始終沒想明白，一個簡單的nohup mysql –uxxxx –pxxxx < xxxx.sql &為什么會異常終止。也未排查出該問題具體原因，有大師們碰到過這種類型的問題可以交流一下，初步判斷還是云主機性能問題和MySQL性能瓶頸導(dǎo)致這種一次性導(dǎo)入500G大文件異常終止。
最終和客戶溝通確認，將400多G大表做rename后導(dǎo)出前一個月數(shù)據(jù)再恢復(fù)至新集群中，因考慮到大文件導(dǎo)入性能問題，我們將該文件按行數(shù)切割后再依次分批導(dǎo)入(SQL文件切割針對單表不會導(dǎo)致數(shù)據(jù)被切斷，但如果是按庫導(dǎo)出，涉及到多個create table會存在切斷的情況)，完成此次恢復(fù)工作。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/129468.html
摘要：截至年底，貝殼金服業(yè)務(wù)已覆蓋全國多個城市及地區(qū)，為超過萬用戶提供了金融服務(wù)。老機房下線完成則表示數(shù)據(jù)遷移完成。機房遷移實施過程操作描述配置防火墻，將兩個機房所需端口開通。執(zhí)行下線命令，一次性下線所有舊機房的?？鐧C房遷移，網(wǎng)絡(luò)延遲不能高于。 作者介紹 ：李振環(huán)，貝殼金服數(shù)據(jù)基礎(chǔ)架構(gòu)負責人，目前負責數(shù)據(jù)平臺和企業(yè)級數(shù)據(jù)倉庫開發(fā)。 公司介紹 貝殼金服是專注居住場景的金融科技服務(wù)商，起步于2...
摘要：愛奇藝，中國高品質(zhì)視頻娛樂服務(wù)提供者，年月日正式上線，推崇品質(zhì)青春時尚的品牌內(nèi)涵如今已深入人心，網(wǎng)羅了全球廣大的年輕用戶群體，積極推動產(chǎn)品技術(shù)內(nèi)容營銷等全方位創(chuàng)新。邊控中心是愛奇藝第一個在線業(yè)務(wù)使用的項目，所以我們制定了詳細的上線計劃。 愛奇藝，中國高品質(zhì)視頻娛樂服務(wù)提供者，2010 年 4 月 22 日正式上線，推崇品質(zhì)、青春、時尚的品牌內(nèi)涵如今已深入人心，網(wǎng)羅了全球廣大的年輕用戶群...
摘要：因為傳統(tǒng)的數(shù)據(jù)庫管理方式在當前這種架構(gòu)下依靠手工或者借助簡單的工具是無法應(yīng)對多活架構(gòu)大規(guī)模管理帶來的復(fù)雜性，因此平臺化顯得非常重。我們在做的方案時做了充分調(diào)查及論證，最終沒有選擇這種方式。 蔡鵬，2015年加入餓了么，見證了餓了么業(yè)務(wù)&技術(shù)從0到1的發(fā)展過程，并全程參與了數(shù)據(jù)庫及DBA團隊高速發(fā)展全過程。同時也完成個人職能的轉(zhuǎn)型-由運維DBA到DEV-DBA的轉(zhuǎn)變,也從DB的維穩(wěn)轉(zhuǎn)變到專心為...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
