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