當(dāng)前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

后台数据到mysql怎样保持实时更新_京东智联云MySQL数据库如何保障数据的可靠性？...

發(fā)布時間：2025/3/19 数据库 16 豆豆

生活随笔收集整理的這篇文章主要介紹了后台数据到mysql怎样保持实时更新_京东智联云MySQL数据库如何保障数据的可靠性？... 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

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

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

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

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

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

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

在寫入到系統(tǒng)的日志文件中有兩個步驟，write和fsync。wirte是寫入操作系統(tǒng)的緩存，fsync是持久化到磁盤文件，這個操作會占用系統(tǒng)的IOPS，而它們操作的時機(jī)是通過參數(shù)sync_binlog控制。sync_binlog=0，事務(wù)提交時，只做write操作，由操作系統(tǒng)自己控制fsync操作。這個是最危險的，一旦操作系統(tǒng)宕機(jī)，binlog cache中的變更內(nèi)容全部會丟失。

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

sync_binlog=N，事務(wù)提交時，會做write操作，累積N個事務(wù)時做fsync操作。一旦操作系統(tǒng)宕機(jī)，會丟失binlog cache中部分變更內(nèi)容。

事務(wù)執(zhí)行過程中，也是先寫入內(nèi)存redo log buffer中，然后再寫入到磁盤文件。其中redo log buffer是所有線程共用的。與binlog寫到文件一樣，寫redo log也有write和fsync兩個操作，它們操作的實際是通過參數(shù)innodb_flush_log_at_trx_commit控制。nnodb_flush_log_at_trx_commit=0，事務(wù)提交時，只將變更內(nèi)容寫到redo log buffer，由后臺Master線程每秒write和fsync到磁盤文件。

innodb_flush_log_at_trx_commit=1，事務(wù)提交時，執(zhí)行write和fsync操作。這是最安全的配置。

innodb_flush_log_at_trx_commit=2，事務(wù)提交時，只執(zhí)行write操作，即只寫到操作系統(tǒng)的緩存中，由后臺Master線程每秒fsync到磁盤文件。

關(guān)于這個參數(shù)與數(shù)據(jù)可靠性之間的關(guān)系如下表所示：

參數(shù)sync_binlog=1與innodb_flush_log_at_trx_commit=1就是DBA常說的“雙1”配置，也是線上環(huán)境數(shù)據(jù)最安全最可靠的配置。

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

binlogredo log

記錄者M(jìn)ySQL serverInnodb引擎

記錄時間事務(wù)commit的時候多種條件觸發(fā)，隨時記錄

記錄內(nèi)容邏輯日志row格式或者statement格式物理日志數(shù)據(jù)頁的變化，冪等的

binlogredo log

記錄者M(jìn)ySQL serverInnodb引擎

記錄時間事務(wù)commit的時候多種條件觸發(fā)，隨時記錄

記錄內(nèi)容邏輯日志row格式或者statement格式物理日志數(shù)據(jù)頁的變化，冪等的

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

如果在此過程中出現(xiàn)系統(tǒng)異常，每個狀態(tài)下都是可以保證數(shù)據(jù)一致性的。

le data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">

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

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

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

2. 數(shù)據(jù)延遲。當(dāng)從庫出現(xiàn)延遲，會造成集群數(shù)據(jù)不一致。從庫延遲的原因很多，這里列舉以下幾個線上經(jīng)常出現(xiàn)的延遲原因：

a)大事務(wù)。binlog只有在事務(wù)commit時才會記錄到文件，然后從庫才能讀取到數(shù)據(jù)變更，所以當(dāng)有大事務(wù)的時候，主庫提交后從庫才開始執(zhí)行。

b)大并發(fā)。5.6和5.7版本都支持并行復(fù)制，但是并行度有限，當(dāng)主庫并發(fā)較高時，從庫會出現(xiàn)延遲。

c)表結(jié)構(gòu)。主庫表沒有主鍵，binlog是row格式的，主庫執(zhí)大量行數(shù)的更新SQL時，從庫會執(zhí)行多次全表掃描，造成延遲。

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

京東智聯(lián)云RDS-MySQL集群使用主從復(fù)制架構(gòu)，為了保證用戶存儲數(shù)據(jù)可靠性和安全性，我們對關(guān)鍵流程做了一系列優(yōu)化和改善工作。以用戶數(shù)據(jù)安全為己任，以用戶體驗為中心。

1. 物理環(huán)境硬件，采用高性能的NVME硬盤，最新型號物理機(jī)配置。

網(wǎng)絡(luò)，跨AZ機(jī)器的網(wǎng)絡(luò)延遲在1.2ms以內(nèi)，配置萬兆網(wǎng)卡。

2. 軟件環(huán)境數(shù)據(jù)面，參考京東高并發(fā)、高可靠的業(yè)務(wù)系統(tǒng)優(yōu)化經(jīng)驗，京東智聯(lián)云對RDS操作系統(tǒng)配置、MySQL參數(shù)配置做了一些列優(yōu)化，保證數(shù)據(jù)庫集群數(shù)據(jù)的可靠性。

控制面，針對集群的延遲，有多組延遲監(jiān)控、報警；針對不同延遲原因，會觸發(fā)不同的優(yōu)化邏輯，自動降低延遲。

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

MySQL高可用切換流程的復(fù)雜性，不在切換的過程，而是觸發(fā)切換條件的判斷，下面介紹下RDS-MySQL自動高可用切換的判斷流程。哨兵服務(wù)檢查數(shù)據(jù)庫和操作系統(tǒng)狀態(tài)，發(fā)現(xiàn)實例服務(wù)異常，則觸發(fā)多組哨兵服務(wù)的數(shù)據(jù)庫服務(wù)檢查和投票機(jī)制，確認(rèn)服務(wù)真實不可用再進(jìn)行切換流程。

主庫實時上報GTID信息，如果發(fā)生自動高可用，即主庫服務(wù)不可用時，首先會對比從庫的Retrieved_Gtid_Set值，確保從庫的IO thread已經(jīng)拉取了主庫全部的binlog內(nèi)容。

然后再對比從庫的Retrieved_Gtid_Set和Executed_Gtid_Set范圍值，保證從庫拉取的binlog全部應(yīng)用完成。

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

數(shù)據(jù)庫備份是數(shù)據(jù)安全的最重要屏障，當(dāng)出現(xiàn)極端情況下，集群所有節(jié)點的數(shù)據(jù)都不可用，就需要依賴備份保證數(shù)據(jù)的可靠性和安全性。我們對RDS-MySQL的備份、恢復(fù)流程做了一系列優(yōu)化，保證用戶系統(tǒng)在災(zāi)備時恢復(fù)時間盡量短，恢復(fù)數(shù)據(jù)盡可能最新。每日全量備份，實時binlog備份；

所有備份上傳到對象存儲，多備份保存，多區(qū)域存放；

定期做備份數(shù)據(jù)的有效性驗證；

高可用、擴(kuò)容、刪除等重要流程強(qiáng)制做數(shù)據(jù)庫的數(shù)據(jù)備份；

支持軟刪除功能，單庫表恢復(fù)功能。

京東智聯(lián)云RDS-MySQL的用戶在使用過程中，出現(xiàn)過很多數(shù)據(jù)可靠性相關(guān)的案例，下面舉一些典型案例來分享：

問題由于用戶并發(fā)較大，集群從庫出現(xiàn)延遲。

發(fā)現(xiàn)從庫對于用戶是不可見的，所以從庫延遲用戶是無需感知的。通過后臺的監(jiān)控系統(tǒng)，觸發(fā)從庫延遲報警，運維人員才發(fā)現(xiàn)這個問題。

解決后臺任務(wù)會掃描所有報警信息，當(dāng)掃描到延遲報警后，會結(jié)合該實例的其他信息定位故障原因，然后自動調(diào)整集群數(shù)據(jù)庫配置，達(dá)到降低延遲的目的。延遲報警解除后，恢復(fù)集群配置。

意義RDS-MySQL部分報警已經(jīng)實現(xiàn)了“負(fù)載異常檢測”、“自動診斷”、“線上配置優(yōu)化”、“優(yōu)化效果跟蹤”的閉環(huán)處理。可幫助用戶快速、安全、準(zhǔn)確地處理集群數(shù)據(jù)安全隱患。

問題由于用戶并發(fā)較大，集群從庫出現(xiàn)延遲。