京東智聯云MySQL數據庫如何保障數據的可靠性

京東智聯云MySQL數據庫如何保障數據的可靠性，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

MySQL作為當前最流行的關系型數據庫，在各個行業的系統中扮演著最重要的角色。隨著大家對數據價值認可的逐步加深，數據的可靠性是最常被問到的一個問題。MySQL是如何保證數據可靠性的？京東智聯云RDS-MySQL又做了哪些優化和新特性來保證用戶數據的可靠性和一致性？本篇文章將為大家一一揭秘。

MySQL的Innodb存儲引擎支持ACID（原子性Atomicity，一致性Consistency，隔離性Isolation，持久性Durability）特性，正是因為保證了一致性和持久性，所以數據才是可靠的。很多關系型數據庫為保障數據庫的可靠性，同時最大限度地提升性能，采用了預寫日志（Write-Ahead Logging）的方法，MySQL也不例外。它將數據變化先寫入日志，然后立刻返回給客戶端更新成功，真正的數據再異步更新到磁盤的數據文件。如果中間系統發生故障，只要日志在數據就不會丟失，這就保證了數據的可靠性。

MySQL寫入的日志就是binlog和redo log文件，下面我們來介紹下兩種日志的寫入流程。

事務執行過程中，MySQL會將所有變更記錄到binlog cache中，在事務commit的時候一起寫入binlog文件中。

binlog cache是由參數binlog_cache_size控制，默認32KB，如果事務很大，變更內容超過了binlog cache，則會寫到磁盤中。通過命令show global status like 'Binlog_cache_disk_use';可以查看binlog cache寫入磁盤的次數，如果數量過多，建議調大binlog_cache_size參數值。

每個線程都會分配binlog cache，但是都共用一份binlog文件。流程圖如下：

在寫入到系統的日志文件中有兩個步驟，write和fsync。wirte是寫入操作系統的緩存，fsync是持久化到磁盤文件，這個操作會占用系統的IOPS，而它們操作的時機是通過參數sync_binlog控制。

• sync_binlog=0，事務提交時，只做write操作，由操作系統自己控制fsync操作。這個是最危險的，一旦操作系統宕機，binlog cache中的變更內容全部會丟失。

• sync_binlog=1，事務提交時，都會做write和fsync操作。安全性最高，但是性能損耗也是最大的。

• sync_binlog=N，事務提交時，會做write操作，累積N個事務時做fsync操作。一旦操作系統宕機，會丟失binlog cache中部分變更內容。

事務執行過程中，也是先寫入內存redo log buffer中，然后再寫入到磁盤文件。其中redo log buffer是所有線程共用的。與binlog寫到文件一樣，寫redo log也有write和fsync兩個操作，它們操作的實際是通過參數innodb_flush_log_at_trx_commit控制。

• nnodb_flush_log_at_trx_commit=0，事務提交時，只將變更內容寫到redo log buffer，由后臺Master線程每秒write和fsync到磁盤文件。

• innodb_flush_log_at_trx_commit=1，事務提交時，執行write和fsync操作。這是最安全的配置。

• innodb_flush_log_at_trx_commit=2，事務提交時，只執行write操作，即只寫到操作系統的緩存中，由后臺Master線程每秒fsync到磁盤文件。

關于這個參數與數據可靠性之間的關系如下表所示：

參數sync_binlog=1與innodb_flush_log_at_trx_commit=1就是DBA常說的“雙1”配置，也是線上環境數據最安全最可靠的配置。

再對比下binlog和redo log的不同之處：

binlog和redo log是如何配合起到數據可靠性的作用呢，就不得不提到兩階段提交。它可以保證binlog和redo log的數據一致性。下圖是事務提交時兩個日志的記錄流程：

如果在此過程中出現系統異常，每個狀態下都是可以保證數據一致性的。

innodb_suport_xa參數，這個參數控制是否打開兩段式提交。默認開啟，如果關閉了，事務則會以不同順序的方式寫入binlog。如果宕機恢復、xtarbackup恢復，都是會有數據不一致的風險。這個參數在MySQL5.7.10后就廢棄了，必須開啟。

MySQL發展到現在，集群也從主備異步復制、半同步復制、group replication不斷發展和演變。但是它們的核心基礎都是binlog，可以說MySQL的數據復制都依賴于它，而集群間的數據一致性更是與binlog有關。主要有兩個點需要特別注意。

1. binlog的格式。statement、row和mixed。statement格式直接將SQL語句記錄在binlog文件中，因為主從庫是兩個獨立的服務，運行環境完全不同，所以會出現不一致的風險，比如執行delete from t limit 100。所以線上環境建議使用row格式。

2. 數據延遲。當從庫出現延遲，會造成集群數據不一致。從庫延遲的原因很多，這里列舉以下幾個線上經常出現的延遲原因：

a）大事務。binlog只有在事務commit時才會記錄到文件，然后從庫才能讀取到數據變更，所以當有大事務的時候，主庫提交后從庫才開始執行。

b）大并發。5.6和5.7版本都支持并行復制，但是并行度有限，當主庫并發較高時，從庫會出現延遲。

c）表結構。主庫表沒有主鍵，binlog是row格式的，主庫執大量行數的更新SQL時，從庫會執行多次全表掃描，造成延遲。

d）等待鎖。從庫一般會承擔備份功能，使用xtrabackup進行備份會執行FLUSH NO_WRITE_TO_BINLOG TABLES和FLUSH TABLES WITH READ LOCK操作，在特殊情況下，這兩個操作會堵塞復制的SQL線程，造成延遲。

京東智聯云RDS-MySQL集群使用主從復制架構，為了保證用戶存儲數據可靠性和安全性，我們對關鍵流程做了一系列優化和改善工作。以用戶數據安全為己任，以用戶體驗為中心。

1. 物理環境

• 硬件，采用高性能的NVME硬盤，最新型號物理機配置。

• 網絡，跨AZ機器的網絡延遲在1.2ms以內，配置萬兆網卡。

2. 軟件環境

• 數據面，參考京東高并發、高可靠的業務系統優化經驗，京東智聯云對RDS操作系統配置、MySQL參數配置做了一些列優化，保證數據庫集群數據的可靠性。

• 控制面，針對集群的延遲，有多組延遲監控、報警；針對不同延遲原因，會觸發不同的優化邏輯，自動降低延遲。

當物理機出現問題或者做數據遷移時，都會涉及MySQL集群的高可用操作，因為MySQL集群的復制特點，有可能會出現數據丟失的情況。京東智聯云RDS-MySQL在切換時是要保證用戶數據一致性優先的，在判斷集群數據完全可靠的情況下，再做切換操作，保證用戶的數據不丟失，不寫花。

MySQL高可用切換流程的復雜性，不在切換的過程，而是觸發切換條件的判斷，下面介紹下RDS-MySQL自動高可用切換的判斷流程。

1. 哨兵服務檢查數據庫和操作系統狀態，發現實例服務異常，則觸發多組哨兵服務的數據庫服務檢查和投票機制，確認服務真實不可用再進行切換流程。

2. 主庫實時上報GTID信息，如果發生自動高可用，即主庫服務不可用時，首先會對比從庫的Retrieved_Gtid_Set值，確保從庫的IO thread已經拉取了主庫全部的binlog內容。

3. 然后再對比從庫的Retrieved_Gtid_Set和Executed_Gtid_Set范圍值，保證從庫拉取的binlog全部應用完成。

高可用流程切換完成后，會對集群數據做一致性校驗，并觸發建立新從庫的流程。

數據庫備份是數據安全的最重要屏障，當出現極端情況下，集群所有節點的數據都不可用，就需要依賴備份保證數據的可靠性和安全性。我們對RDS-MySQL的備份、恢復流程做了一系列優化，保證用戶系統在災備時恢復時間盡量短，恢復數據盡可能最新。

1. 每日全量備份，實時binlog備份；

2. 所有備份上傳到對象存儲，多備份保存，多區域存放；

3. 定期做備份數據的有效性驗證；

4. 高可用、擴容、刪除等重要流程強制做數據庫的數據備份；

5. 支持軟刪除功能，單庫表恢復功能。

京東智聯云RDS-MySQL的用戶在使用過程中，出現過很多數據可靠性相關的案例，下面舉一些典型案例來分享：

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。