MySQL更新最佳實踐

MySQL更新最佳實踐：

更新的原因 ：

1、 舊版本的BUG

2、 舊版本的安全問題

3、 在新版中受益的地方（新特性，可擴充性，性能等）

4、 資料庫支援受限

繼續保留使用舊版本的原因：

1、 app處在一種隔離的網絡狀态，更新成本高

2、 app已不在有新的功能更新

3、 app活躍度下降已不在上升

4、 platform 中的硬體或者os 沒有發生變化等

哪些情況版本更新危險性大：

1、 主版本的變化，比如5.1到5.5的更新

2、 MySQL to  Percona  or mariadb的更新

3、 一次性跳過太多的副版本号，比如從5.1.20 到 5.1.61

4、 從原來的開發版本更新到其他更高的穩定版或開發版

5、 跳過一個或多個主版本号如： 4.1到5.5 而不是從5.1到5.5

更新需要考慮的問題：

1、 資料、資料類型（是否相容）

在磁盤上存儲的格式，MySQL資料類型的變化，

排序方面的變化；

Timestamp類型是否自動更新時間

新的一些限制；哪些是保留字；統計資訊的改變等

2、 Queries（reads and writes）

文法的變化；警告或錯誤等提示消息

查詢使用方式所帶來的結果是否與原先版本的結果一緻。

在函數等其他查詢中哪些是不确定的query

3、 性能和可擴充性

Query執行時間，query執行計劃，在可擴充和locking方面的性能

4、 複制方面的變化

在一定壓力負載下，複制的一些情況，在err_log中是否有報警或錯誤消息；

是否存在“data drift” 造成主從資料不一緻？性能是否有波動等？

5、 資源的使用

記憶體的使用情況，是減少了還是增多啦？

6、 進階的新特性

更多的新特點前提是 是否犧牲了其他的特性

對 存儲程式、plugin、觸發器、events、視圖 這些方面看看是否收到影響！

是直接更新還是使用複制的方式更新？

對于小的系統來說是直接進行更新，這樣會造成當機或造成其他的危險，使用LVM進行快照的話，可以很快的進行rollback。

對于使用shards 的環境：挨個對mysql進行更新 将危險降到最低；

使用replication 方式的更新方式是值得推薦的（将新版本server做slave，最後在切換）。

在Cloud 中進行更新：

建立一個“clone”的 updated server，直接進行測試；

更新過程中所涉及到其他的問題：

在更新MySQL的時候，是否還要更新硬體？OS?應用程式？ 配置檔案如何修改等？

如果單單進行MySQL更新的話，可以用很多時間進行測試；

還有更新其他元件的話，出現問題話，還要查詢是否是其他元件的問題，這樣做危險系數直線上升。

對存在複制架構的情況，進行更新：

1、 對于 MM雙主的情況，先對不活躍的master進行更新；

對shard 環境的資料庫，你可以走個捷徑：

就是不需要對所有的MySQL進行測試， 先更新一個shard，并進行監控，等确認後，在批量更新其他的shard，在進行整體的測試。

更新的具體過程：

1、 先閱讀新版本改進的地方，及新特性

2、 對新版本設定QA環節，列出哪些特性，及改進是需要使用并改變的。

3、 調整MySQL配置檔案；移去過時的參數，對某些參數進行改進（比如：在5.5. 中 storage_engine=Innodb; innodb_file_format=Barracuda;例如某些相容性的需求：在5.5 中 Read-Comitted 在 statement replication環境下是不起作用的。）

4、 遷移資料：

Mysqldump and   import back； 最保險的方式，是整個的移動資料，但也最慢，這樣對于跳過很多版本的資料庫更新方式，是很有幫助的。

然後執行 MySQL_upgrade 會檢查table 的相容性并嘗試進行修複；并且更新system table

5、 對資料進行校驗

比較原先備份檔案和更新後的備份檔案的差别

Checksum table（pt-table_checksum工具的使用）

6、 如果不打算停掉業務，可使用replication的方式

使用 pt-table-checksum 進行同步資料check

在slave上檢查錯誤日志或警告。

必要的情況下在進行一次復原，即replication old-new- 來100%确定。

大部分情況下， 采用複制的方式，從5.0-5.5 還是有效果的。

   Replication  new-new 這樣做的目的是 檢查是否還有額外的安全或其他錯誤；更新的事後驗證。

7、 驗證複制的性能：

測量slave catch up 的速度。檢視thread利用情況。

8、 從線上擷取真實的查詢：

可以打開general_log 或 slow log（long_query_time=0）

或使用tcpdump抓包，pt-query_digest 解包分析

截取部分資料：

Pt-query_digest  --sample 5 –print  --no-report  queries.log > samples.log

9、 檢查query

單connection測試：對這些 samples.log 運作 pt-upgrade 

高并發測試： 運作pt-log-player 兩次，第一次熱機，第二次才是真正的運作。

Look at pt-query_digest report on full query  log is good to check in both cases

10、進行壓力測試： full application load testing 

本文轉自 位鵬飛 51CTO部落格，原文連結：http://blog.51cto.com/weipengfei/1183247，如需轉載請自行聯系原作者