一、確保mysql數(shù)據(jù)庫主從數(shù)據(jù)一定是一樣的方法

　　1、確保同步狀態(tài)正常

　　主從數(shù)據(jù)庫的同步狀態(tài)正常是保證主從數(shù)據(jù)一致性的前提，需要定期監(jiān)控主從同步狀態(tài)，并及時(shí)處理同步異常情況。

　　2、配置和參數(shù)設(shè)置保持一致

　　主從數(shù)據(jù)庫的配置和參數(shù)設(shè)置必須一致，否則可能導(dǎo)致主從數(shù)據(jù)不一致問題。可以通過檢查my.cnf文件、SHOW VARIABLES命令等方式來確認(rèn)配置和參數(shù)是否一致。

　　3、定期備份和比對數(shù)據(jù)

　　定期備份主從數(shù)據(jù)庫數(shù)據(jù)，并進(jìn)行比對，查看是否有差異。可以使用mysqldump工具或者其他自動化備份工具進(jìn)行備份，并使用比對工具進(jìn)行數(shù)據(jù)檢查。

　　4、選擇合適的數(shù)據(jù)同步方式

　　使用適當(dāng)?shù)臄?shù)據(jù)同步方式能夠更好地保證主從數(shù)據(jù)的一致性。例如，使用基于GTID或binlog格式的數(shù)據(jù)同步方式，可確保主從數(shù)據(jù)的同步流程更為精確和可靠。

　　二、MySQL主從

　　1、數(shù)據(jù)庫主從概念

　　主從數(shù)據(jù)庫是什么意思呢，主是主庫的意思，從是從庫的意思。數(shù)據(jù)庫主庫對外提供讀寫的操作，從庫對外提供讀的操作。

　　數(shù)據(jù)庫需要主從架構(gòu)的原因：

　　高可用，實(shí)時(shí)災(zāi)備，用于故障切換。比如主庫掛了，可以切從庫。讀寫分離，提供查詢服務(wù)，減少主庫壓力，提升性能備份數(shù)據(jù)，避免影響業(yè)務(wù)。

　　2、數(shù)據(jù)庫主從復(fù)制原理

　　主從復(fù)制原理，簡言之，分三步曲進(jìn)行：

　　主數(shù)據(jù)庫有個(gè)bin log二進(jìn)制文件，紀(jì)錄了所有增刪改SQL語句。(binlog線程)從數(shù)據(jù)庫把主數(shù)據(jù)庫的bin log文件的SQL 語句復(fù)制到自己的中繼日志 relay log(io線程)從數(shù)據(jù)庫的relay log重做日志文件，再執(zhí)行一次這些sql語句。(Sql執(zhí)行線程)

　　詳細(xì)的主從復(fù)制過程如圖：

　　上圖主從復(fù)制過程分了五個(gè)步驟進(jìn)行：

　　主庫的更新SQL(update、insert、delete)被寫到binlog從庫發(fā)起連接，連接到主庫。此時(shí)主庫創(chuàng)建一個(gè)binlog dump thread，把bin log的內(nèi)容發(fā)送到從庫。從庫啟動之后，創(chuàng)建一個(gè)I/O線程，讀取主庫傳過來的bin log內(nèi)容并寫入到relay log從庫還會創(chuàng)建一個(gè)SQL線程，從relay log里面讀取內(nèi)容，從ExecMasterLog_Pos位置開始執(zhí)行讀取到的更新事件，將更新內(nèi)容寫入到slave的db

　　3、主主、主從、主備的區(qū)別

　　數(shù)據(jù)庫主主：兩臺都是主數(shù)據(jù)庫，同時(shí)對外提供讀寫操作。客戶端訪問任意一臺。數(shù)據(jù)存在雙向同步。數(shù)據(jù)庫主從：一臺是主數(shù)據(jù)庫，同時(shí)對外提供讀寫操作。一臺是從數(shù)據(jù)庫，對外提供讀的操作。數(shù)據(jù)從主庫同步到從庫。數(shù)據(jù)庫主從：一臺是主數(shù)據(jù)庫，同時(shí)對外提供讀寫操作。一臺是從數(shù)據(jù)庫，對外提供讀的操作。數(shù)據(jù)從主庫同步到從庫。

　　4、MySQL是怎么保證主從一致的

　　我們學(xué)習(xí)數(shù)據(jù)庫的主從復(fù)制原理后，了解到從庫拿到并執(zhí)行主庫的binlog日志，就可以保持?jǐn)?shù)據(jù)與主庫一致了。這是為什么呢?哪些情況會導(dǎo)致不一致呢?

　　長鏈接：

　　主庫和從庫在同步數(shù)據(jù)的過程中斷怎么辦呢，數(shù)據(jù)不就會丟失了嘛。因此主庫與從庫之間維持了一個(gè)長鏈接，主庫內(nèi)部有一個(gè)線程，專門服務(wù)于從庫的這個(gè)長鏈接的。

　　binlog格式：

　　binlog日志有三種格式，分別是statement，row和mixed。如果是statement格式，binlog記錄的是SQL的原文，如果主庫和從庫選的索引不一致，可能會導(dǎo)致主庫不一致。我們來分析一下。假設(shè)主庫執(zhí)行刪除這個(gè)SQL(其中a和create_time都有索引)如下：

　　delete from t where a > '666' and create_time<'2022-03-01' limit 1;

　　我們知道，數(shù)據(jù)選擇了a索引和選擇create_time索引，最后limit 1出來的數(shù)據(jù)一般是不一樣的。所以就會存在這種情況：在binlog = statement格式時(shí)，主庫在執(zhí)行這條SQL時(shí)，使用的是索引a，而從庫在執(zhí)行這條SQL時(shí)，使用了索引create_time。最后主從數(shù)據(jù)不一致了。

　　解決這個(gè)問題的方法：可以把binlog格式修改為row。row格式的binlog日志，記錄的不是SQL原文，而是兩個(gè)event:Table_map 和 Delete_rows。Table_map event說明要操作的表，Delete_rows event用于定義要刪除的行為，記錄刪除的具體行數(shù)。row格式的binlog記錄的就是要刪除的主鍵ID信息，因此不會出現(xiàn)主從不一致的問題。

　　但是如果SQL刪除10萬行數(shù)據(jù)，使用row格式就會很占空間的，10萬條數(shù)據(jù)都在binlog里面，寫binlog的時(shí)候也很耗IO。但是statement格式的binlog可能會導(dǎo)致數(shù)據(jù)不一致，因此設(shè)計(jì)MySQL的大叔想了一個(gè)折中的方案，mixed格式的binlog。所謂的mixed格式其實(shí)就是row和statement格式混合使用，當(dāng)MySQL判斷可能數(shù)據(jù)不一致時(shí)，就用row格式，否則使用就用statement格式。

　　延伸閱讀1：MySQL的特點(diǎn)

　　性能卓越服務(wù)穩(wěn)定，很少出現(xiàn)異常宕機(jī)開放源代碼且無版權(quán)制約，自主性強(qiáng)、使用成本低。歷史悠久、社區(qū)及用戶非常活躍，遇到問題，可以很快獲取到幫助。軟件體積小，安裝使用簡單，并且易于維護(hù)，安裝及維護(hù)成本低。支持多種操作系統(tǒng)，提供多種api幾口，支持多種開發(fā)語言。