1. 華為RH2288 V3伺服器的RAID1設置
華為作為國產品牌，已成為大多數中國人心中的驕傲，當然，我也是其中一份子。支持國產品牌，更因為骨子裡是對自己的信任，對未來前景的看好，雖然我不是華為人。前段時間，公司買了一台華為伺服器 RH2288 V3 ，是一個裸機。
作為一名伺服器小白，對伺服器的了解甚少，把伺服器的參數看了 N 遍，有些參數明白，比如內存 16G ， 8 盤位，可以安裝 8 塊硬碟。還特別問了客服，硬碟是否可以擴容？客服回答，是可以的，你所選擇的伺服器目前只安裝了一塊硬碟。想一想公司里沒有什麼系統安裝軟體，自己對伺服器了解甚少，就拜託客服把系統安裝好了，再寄過來。
幾天後，伺服器寄過來了，打開一看，只有一個盤且剩餘容量只有 70G 了，這還沒有干什麼呢。先咨詢客服這款伺服器可以配置什麼樣子的硬碟，又和老闆商量再買一個固態硬碟，最後鎖定 華為（ HUAWEI ）伺服器硬碟 600GBSAS 2.5 英寸。客服又問我，伺服器有沒有在使用，我說還沒呢，客服說先不要用，要重裝系統的，喔，好吧。
硬碟郵寄過來了，重裝系統，重裝系統後就報了個錯，Missing operation system 什麼意思呢，錯誤的操作系統？我的英文也很蹩腳，如圖 -2 ，問了客服，客服猶豫了一下，回答說，需要一個引導盤，再寄個引導盤過來，好吧，我靜靜地等著。
過了一天半，引導盤寄過來了，還送了一個系統安裝盤，之前給過一個的。這兩張盤從北京發到蘇州，一天半就到了，速度沒得說，快。客服之前打過我的電話，聽我的聲音是女生，特意給我配置了一個技術人員，重新安裝系統。
第一次裝系統時，需要做 RAID ，也就是做陣列，首先啟動伺服器，在出現華為的 logo 後的第二個屏幕，當屏幕上出現 CTRL C 時， 如圖-3所示
按下CTRL+C後，進入CU界面，可以看到LSISAS2308的選項，只有這么一個選項，如圖-4所示
按下enter鍵，進入RAID屬性設置頁面，如圖-5所示
如果系統曾經安裝過，設置過raid，這里需要選擇delete raid properties,也就說需要刪除raid的痕跡，刪除過後，再重新來到這一步，按下enter鍵，選擇要設置raid的模式，我選擇的是raid1模式，如下圖-6所示
此時按下Enter鍵之後，出現如下圖-7所示
按下空格鍵，NO就會變成Yes，Yes的意思是表示加入當前的RAID,默認No未加入當前的RAID, 最後按下C鍵，進入保存設置的頁面，如圖-8所示
繼續按Enter，然後又會回到這個界面，這時，可以選擇第四個選項Exit the configuration utility and reboot，保存所做的設置並退出，按過Enter鍵盤之後，就可以直接按ESC直接退出了。
這時需要裝入系統引導盤，系統引導盤顧名思義是安裝系統之前的引導盤，這個安裝很簡單，選項都選默認的，語言選擇中國，地址選擇北京，再設置個電腦的用戶名及登錄密碼，其他的直接選擇下一步就可以了。
在安裝完系統引導盤，裝入系統盤後，出現了下面的錯誤，如圖-9所示
詢問了技術人員，技術人員說忽略這一步，於是叉掉了這個對話框，繼續下去，繼而又出現了一個錯誤，找不到指定的硬碟，這是什麼原因，再次像技術人員請教，技術人員有發給我一個壓縮包，拷貝到U盤進行安裝，又出現了一個錯誤，如圖-10所示
就這樣反反復復多次，系統依舊沒有安裝成功，技術人員為難了，這是為啥呢，為啥這個機器總是安裝不成功呢，我也是在他的視頻指導下安裝的，不行只能郵寄到北京了...
這樣反反復復的安裝，安裝步驟我都記在心裡了，額，有兩張系統盤，抱著試試看的心態，又安裝了一次，換了一張系統盤。
過了半個小時，沒想到，安裝一直繼續中，莫非安裝要成功了，果真，安裝成功了。納尼，這是為什麼，迅速查看了新寄過來的系統盤，好吧，裡面空的耶。
系統完全安裝好之後，再確認一下，新裝的固態硬碟是否識別，雙擊我的電腦，一看，怎麼還是一個盤，還是只有剩餘的70個G，再次聯系了技術人員，技術人員電話視頻了我，把未識別的硬碟識別出來了。
事後我反思，如果一開始，就這樣按照技術人員的方法是不是就可以把硬碟識別出來了，也就不用這么折騰的重新RAID，重新安裝系統引導盤，重新安裝系統了？這款硬碟可是支持熱插拔的，和U盤一樣，客服讓我重裝系統時，我心裡也有過疑問，加快硬碟也要重裝系統，不合常規呀，太不智能了吧，但是心裡沒底，也沒敢和客服說出自己的想法！這說明幾個問題，第一個我不懂，沒吃過豬肉，也沒見過豬跑；第二個客服不懂，不懂硬碟的熱插拔；第三個技術人員也不了解事情的經過，技術人員懂熱插拔，肯定不了解事情的經過，不知道這個伺服器曾經安裝過系統。
當然這樣反反復復的安裝，讓我這個伺服器小白學到了怎麼做RAID，怎麼做系統，對RAID0、RAID1有一個初步的了解。在技術人員問我要做RAID0還是RAID1時，我的心裡是茫然的，不知道這兩個的區別。網路之後，才知道其中的差異，RAID0存儲利用率高，但是沒有備份，RAID1存儲利用率不高，但是有備份。作為公司的測試伺服器，文檔和數據還是需要備份的，這點很重要。
做陣列並不難，關鍵在英文水平和理解能力，像我英文這么蹩腳的安裝幾次，也記住了其中的步驟。英文好一些的，知道安裝步驟里的英文意思，安裝起來改該選擇哪些選項，按照命令提示就可以完成的。看來，還是自個兒英文學的不咋地呀。
安裝伺服器系統並不難，難的是抗拒對未知的恐懼，還有就是英文有待提高呀，在做事情時，思考和執行同樣重要，執行出現問題時，一定要細細思考，查找原因，不懂原理更容易出現盲目執行、盲目試錯、盲目失敗呀，一定要牢記！
2. 華為伺服器怎麼做raid10
一、raid0的配置
1.伺服器開機自檢後，下一步就會進入Raid卡自檢過程，此時顯示器上會出現Ctrl -A提示，如下圖：
2.Optimal表示raid狀態正常，Degraded表示有一塊硬碟掉線，陣列降級，Offline表示有兩塊或以上硬碟掉線，陣列不可用 按下Ctrl -A組合鍵後，自檢完成就會進入Raid卡配置界面，如下圖：
3.選擇Array Configuration Utility進入配置主界面
4.選擇Create Array進入raid配置界面，選擇硬碟，這里以四塊硬碟為例，按空格鍵選擇
5.選擇raid0（注意，如果您需要單盤配置raid0，則這里選擇volume）
6.輸入Array Label，比如volume1
7.輸入Array Size（卷大小），默認容量為最大容量
8.選擇條帶大小，默認為256KB
9.選擇Read Caching（讀策略），默認為enabled：
10.選擇Write Caching（寫策略），默認為Enable always
選擇Enable always後，會有確認提示，按Y鍵
再次確認，按Y鍵
11.選擇Raid創建方式，建議選擇Quick init（快速初始化）
12.最後選擇【Done】回車，出現完成提示時按任意鍵退出。
完成配置後可以在Manage Array中查看陣列狀態，其中Optimal為正常，Degraded為陣列降級，代表有硬碟掉線，Offline為陣列掉線。
二、Raid1的配置
1.進入raid配置界面，選擇Create Array進入raid配置界面。選擇2塊硬碟，按空格鍵選擇
2.選擇Raid級別
3.輸入Array Label（卷標），如volume1
4.輸入Array Size（卷大小），默認容量為最大容量
5.Array Size（條帶大小）默認為N/A，不可選
6.選擇Read Caching（讀策略），默認為enabled：
7.選擇Write Caching（寫策略），默認為Enable always
選擇Enable always後，會有確認提示，按Y鍵
再次確認，按Y鍵
8.選擇創建raid方式，建議選擇Quick Init（快速初始化）
9.最後選擇【Done】回車，出現完成提示按任意鍵退出，然後在Manage Array中查看raid狀態是否配置正常。其中Optimal為正常，Degraded為陣列降級，代表有硬碟掉線，Offline為陣列掉線。
三、Raid5的配置
1.進入raid配置界面。選擇Create Array進入raid配置界面。最少選擇3塊硬碟，這里以3塊硬碟為例，按空格鍵選擇
2.選擇Raid級別：
3.輸入Array Label（卷標），如volume5
4.輸入Array Size（卷大小），默認容量為最大容量
5.Array Size（條帶大小）默認為N/A，不可選
6.選擇Read Caching（讀策略），默認為enabled：
7.選擇Write Caching（寫策略），默認為Enable always
選擇Enable always後，會有確認提示，按Y鍵
再次確認，按Y鍵
8.選擇創建raid方式，建議選擇Quick Init（快速初始化）
9.最後選擇【Done】回車，出現完成提示按任意鍵退出，然後在Manage Array中查看raid狀態是否配置正常。其中Optimal為正常，Degraded為陣列降級，代表有硬碟掉線，Offline為陣列掉線。
四、Raid6的配置
1.進入raid配置界面。選擇Create Array進入raid配置界面。最少選擇4塊硬碟，按空格鍵選擇
2.選擇Raid級別：
3.輸入Array Label（卷標），如volume5
4.輸入Array Size（卷大小），默認容量為最大容量
5.Array Size（條帶大小）默認為N/A，不可選
6.選擇Read Caching（讀策略），默認為enabled：
7.選擇Write Caching（寫策略），默認為Enable always，保持默認即可，會有確認提示，按Y鍵
再次確認，按Y鍵
8.選擇創建raid方式，建議選擇Quick Init（快速初始化）
9.最後選擇【Done】回車，出現完成提示按任意鍵退出，然後在Manage Array中查看raid狀態是否配置正常。其中Optimal為正常，Degraded為陣列降級，代表有硬碟掉線，Offline為陣列掉線。
五、Raid10的配置
1.進入raid配置界面。選擇Create Array進入raid配置界面。最少選擇4塊硬碟，必須是偶數，按空格鍵選擇。
2.選擇Raid級別：
3.後續步驟與創建raid5和raid6類相同，不再贅述。
最後，在Manage Array中查看raid狀態是否配置正常。其中Optimal為正常，Degraded為陣列降級，代表有硬碟掉線，Offline為陣列掉線。
六、熱備盤（Hotspare）配置
1.RAID卡配置界面下有Global Hotspare選項，回車進入熱備盤配置界面。
2.有提示信息，按任意鍵繼續。
3.左側列表顯示當前所有硬碟，可配置熱備的硬碟為白色高亮顯示，已配置RAID的磁碟盤則是灰色不可選。
4.空格選擇硬碟
5.回車後會有提示是否保存，按Y鍵確認。
3. 華為雲帶你探秘Xtrabackup備份原理和常見問題分析
摘要：本文來自華為雲MySQL研發團隊，主要分享了MySQL備份工具Xtrabackup的備份過程、華為雲資料庫團隊對其做的優化改進，以及在使用中可能遇到的問題與解決方法。
本文來自華為雲MySQL研發團隊，主要分享了MySQL備份工具Xtrabackup的備份過程、華為雲資料庫團隊對其做的優化改進，以及在使用中可能遇到的問題與解決方法。文章討論的內容主要是針對華為雲RDSforMySQL,以及用戶自建的社區版MySQL資料庫，希望有助於大家理解和使用Xtrabackup，以後面對Xtrabackup問題也更加從容。
一、Xtrabackup簡介Xtrabackup是Percona團隊開發的用於MySQL資料庫物理熱備份的開源備份工具，具有備份速度快、支持備份數據壓縮、自動校驗備份數據、支持流式輸出、備份過程中幾乎不影響業務等特點，是目前各個雲廠商普遍使用的MySQL備份工具。
當前Xtrabackup存在兩個版本：Xtrabackup2.4.x與8.0.x，分別用於備份MySQL5.x與MySQL8.0.x版本。下面我們分別介紹Xtrabackup如何備份MySQL社區版以及華為雲上的Xtrabackup的備份原理
二、社區版MySQL的Xtrabackup備份Xtrabackup是為PerconaMySQL設計的，同時也支持對官方社區版本MySQL進行備份，過程如下圖所示：
兼容性檢查：Xtrabackup社區版本只支持MyISAM,InnoDB,CSV,MRG_MYISAM四種存儲引擎的表，其他存儲引擎的表不會備份；在這一步中，通過查詢tables，若發現存在表的存儲引擎不是上述四種引擎之一，會列印warning,表明Xtrabackup不會備份該表。
啟動redo後台備份線程：啟動redo後台備份線程，從備份實例的最近一次checkpointLSN的位置開始備份所有增量的redolog，一直持續到備份任務結束。
載入所有的innodb表空間：打開並掃描所有innodb表的數據文件，檢查所有表空間的第一個頁面，初始化所有表的內存結構。
備份innodb表：遍歷步驟3所構建的表的內存結構，備份每一個innodb表的數據文件，備份的過程中會檢查每個頁面的數據是否正確。
加備份鎖FLUSHTABLESWITHREADLOCK(FTWRL)：FTWRL鎖是MySQL實例級的讀鎖，加鎖過程復雜，且加鎖之後，所有表的所有更新操作以及DDL都會堵塞。
備份非innodb表：因為在步驟5我們已經對實例加了讀鎖，因此，此時備份非innodb表是安全的，此時一定沒有寫業務。
記錄binlog當前的GTID信息：請注意，此時我們仍持有全局讀鎖。這一步主要是方便我們使用該備份集快速地創建出備機。
停止redo備份線程。
釋放鎖資源，備份結束。
需要注意的是，Xtrabackup2.4.x與8.0.x在第7、8這兩個步驟存在差異，這個差異有MySQL8.0.x的原因，詳情我們在下文介紹。
三、華為雲RDSforMySQL備份在備份社區版MySQL實例時，Xtrabackup會對實例加全局讀鎖(FTWRL)，該鎖對資料庫的業務影響很大，嚴重時甚至會導致資料庫「掛起」，這對客戶來說是不可接受的。因此華為雲MySQL團隊對這個過程進行了優化，主要有兩點：
對MySQL5.x以及0.x增加了備份鎖：LOCKTABLESFORBACKUP
對MySQL5.x新增了binlog鎖：LOCKBINLOGFORBACKUP
優化之後，華為雲Xtrabackup對MySQL的備份過程如下：
與FTWRL鎖相比，備份鎖LOCKTABLESFORBACKUP對客戶實例影響很小，其加鎖過程簡單，加鎖期間innodb表的DML操作不受影響，但是非innodb表的所有的更新操作以及DDL操作仍然是不允許的。
備份完所有的表文件後，Xtrabackup需要獲取binlogGTID信息。
對於MySQL5.x版本，Xtrabackup2.4.x會執行LOCKBINLOGFORBACKUP操作，對binlog加鎖，然後獲取GTID信息。
對於MySQL8.0.x版本，華為雲Xtrabackup8.0.x沿用官方的一致性備份點查詢方法。Xtrabackup查詢log_status時，MySQL伺服器會分別對redolog,binlog等加輕量級鎖，獲取一致性備份點，這個過程是非常短暫的，對實例的運行幾乎沒有影響。MySQL8.0.x的備份一致性點，會告訴我們一致性的redologLSN以及binlog的GTID；查詢完備份一致點後，Xtrabackup會備份最後一個binlog文件，用於恢復時仲裁事務是否需要回滾；最後，redolog備份線程任務會在其讀取到的redolog的LSN大於查詢到的備份一致性點的redologLSN處停止。
由於Xtrabackup2.4.x與8.0.x在處理binlog時存在差異，恢復過程也存在差異，我們會在後續文章中詳細闡述。
四、常見問題與解決方法華為雲已經使用Xtrabackup為公司幾乎所有的MySQL實例提供備份服務，在使用過程中，我們積極與社區保持聯系，向Percona社區報告使用過程中的一些問題，幫助Xtrabackup向更好的方向演進。此外，對於發現的一些致命問題，若社區未能及時修復，華為雲資料庫團隊會進行及時修復以保證備份數據的正確性。
下面是我們總結在使用Xtrabackup備份過程各個階段可能遇到的問題，分析其原因以及對應的解決方法，
1.兼容性檢查階段問題現象：Xtrabackup啟動後，立即長時間「掛起」，查看日誌發現redolog備份線程也沒有啟動。
原因：Xtrabackup兼容性檢查時無法獲取MDL鎖。Xtrabackup兼容性檢查是通過查詢imformation_schema.tables這個插件表實現：
「SELECTCONCAT(table_schema,'/',table_name),engineFROMinformation_schema.tablesWHEREengineNOTIN('MyISAM','InnoDB','CSV','MRG_MYISAM')ANDtable_schemaNOTIN('performance_schema','information_schema','mysql')」
在查詢每張表時，需要獲取對應表的MDL鎖，如果此時MySQL實例中存在長時間的DML或者DDL語句，或者更嚴重者出現了MDL死鎖，上面的查詢會一直堵塞在等待MDL鎖階段，此時Xtrabackup會長時間「掛起」。
解決辦法：若等待鎖的原因只是因為其他SQL語句的堵塞，等待其他SQL執行完成即可；若是發生了死鎖，此時需要分析出死鎖原因，將死鎖解除；華為雲RDSforMySQL提供了MDL鎖視圖功能，可以很好地幫助用戶分析業務的MDL死鎖。
2.redolog備份階段問題現象1：redolog回卷，備份失敗，Xtrabackup報如下錯誤信息：
「xtrabackup:error:,orlogfilesbeingtoosmall. ");」
原因：在備份的過程中，如果主機業務負載很高，導致redolog寫入的速度很快，會發生Xtrabackup的redolog備份線程的備份速度小於redolog的寫入速度，因為MySQLredolog文件寫入使用了round-robin的方式，使得新寫入的日誌覆蓋了之前寫入卻還未備份的日誌，因此備份失敗。
解決辦法：推薦在業務低峰期進行備份，或者增大redolog的文件大小。
問題現象2：備份因DDL操作失敗，錯誤信息如下：
「Anoptimized(withoutredologging)DDLoperationhasbeenperformed..
.Retrythebackupoperation」
原因：備份過程中MySQL實例發生了創建索引的DDL操作，因為創建索引不會寫redo，若繼續備份會引起數據不一致問題，所以Xtrabackup在這種場景中備份失敗是預期行為。
解決辦法：不要在備份過程中創建索引，如果確實需要，建議在建表語句中直接帶上索引，或者使用lock-ddl參數進行備份(阻塞實例上新的DDL操作)。
問題現象3：undotruncate導致備份失敗，Xtrabackup錯誤信息如下：
「Anundoddltruncation(couldbeautomatic)operationhasbeenperformed.」
原因：在Xtrabackup備份期間，如果MySQL實例發生undotruncate時，有可能會出現寫入新undo文件(spaceid不同)的undo日誌丟失導致恢復出來的數據存在問題。官方在Xtrabackup8.0.14版本(基於MySQL8.0.21)對該問題進行了修復，修復方法是redo備份線程，解析redolog時若發現該操作是undolog的truncate操作，則會備份失敗。遺憾的是，該修復並沒有完全解決問題，在以下兩種場景中，社區版本的Xtrabackup仍可能會發生恢復出來的數據存在不一致的現象：
MySQL版本低於MySQL8.0.21;
用戶在備份過程中，自己創建了新的undotablespace。
解決辦法：在備份期間關閉undotablespace的truncate操作，並禁止用戶創建undotablespace，能夠有效地防止備份數據恢復出來不一致的問題；另外華為雲Xtrabackup對這個問題進行了進一步的修復，可以有效地防止此類現象發生。
3.載入表空間階段問題現象1：Xtrabackup報錯：Toomanyopenfiles
原因：操作系統允許同時打開的文件數量是有限的，Xtrabackup在loadtablespace階段會同時打開所有的表文件，如果Xtrabackup打開的表的個數超過了該限制，則會備份失敗。
解決辦法：調大操作系統，允許同時打開最大文件數的配置，或者使用lock-ddl參數(阻塞實例上新的DDL操作)。
問題現象2：renametable導致備份失敗，錯誤信息如下：
「Tryingtoaddtablespace'xxxx',!;」
原因：在Xtrabackup打開表空間的全過程是沒有加鎖的，如果發生了renametable有概率會發生重復載入相同的表空間，此時Xtrabackup會檢測到重復的tablespaceid，因此備份失敗。
解決辦法：一般來說，載入表空間是一個很快的操作，renametable並不是一個很頻繁的操作，這種情況重試即可(PerconaXtrabackup2.4.x僅支持單線程載入表空間，華為雲Xtrabackup支持多線程載入表空間)。
4.備份innodb表階段問題現象：innodb表數據文件損壞，備份失敗，錯誤信息如下：
「xtrabackup:,retrying.」
原因：Xtrabackup在備份innodb表數據文件時，會檢查每個頁面的checksum，如果發現checksum不對，則備份失敗，這時說明MySQL實例的數據已經發生了損壞(例如磁碟靜默錯誤)。
解決辦法：需要通過恢復前一次的備份數據或者其他的辦法將數據進行修復之後，備份才能成功，在後續的文章中，我們也會詳細介紹數據修復辦法。
五、結語本文主要對比介紹了Xtrabackup備份原理，備份社區版MySQL以及華為雲對其的改進，並分享了Xtrabackup常見問題的排查與解決，後續我們也會為大家帶來更深入的分析，更實用的使用技巧，希望對大家理解和使用Xtrabackup有幫助。我們也將持續為客戶提供更好的資料庫服務，並時刻守護客戶的數據安全。