1. 項(xiàng)目概述為什么我們需要主從復(fù)制與讀寫(xiě)分離如果你負(fù)責(zé)的線(xiàn)上應(yīng)用數(shù)據(jù)庫(kù)查詢(xún)突然變慢CPU和內(nèi)存使用率飆升甚至偶爾出現(xiàn)連接超時(shí)而業(yè)務(wù)還在持續(xù)增長(zhǎng)你會(huì)怎么辦單純地給數(shù)據(jù)庫(kù)服務(wù)器升級(jí)硬件成本高昂且總有上限。這時(shí)數(shù)據(jù)庫(kù)架構(gòu)的橫向擴(kuò)展能力就顯得至關(guān)重要。MySQL的主從復(fù)制與讀寫(xiě)分離正是解決這類(lèi)高并發(fā)、大數(shù)據(jù)量場(chǎng)景下數(shù)據(jù)庫(kù)性能與可靠性問(wèn)題的經(jīng)典架構(gòu)方案。簡(jiǎn)單來(lái)說(shuō)主從復(fù)制就是讓一臺(tái)主數(shù)據(jù)庫(kù)Master的數(shù)據(jù)自動(dòng)、異步地同步到一臺(tái)或多臺(tái)從數(shù)據(jù)庫(kù)Slave上。而讀寫(xiě)分離則是基于這個(gè)復(fù)制架構(gòu)讓?xiě)?yīng)用將寫(xiě)操作如INSERT、UPDATE、DELETE定向到主庫(kù)將讀操作如SELECT分散到各個(gè)從庫(kù)從而分?jǐn)傊鲙?kù)的壓力提升整個(gè)系統(tǒng)的吞吐量和并發(fā)處理能力。這不僅僅是“安裝配置”那么簡(jiǎn)單理解其背后的數(shù)據(jù)流轉(zhuǎn)原理、潛在的數(shù)據(jù)延遲風(fēng)險(xiǎn)以及如何根據(jù)業(yè)務(wù)特點(diǎn)設(shè)計(jì)架構(gòu)才是確保線(xiàn)上服務(wù)穩(wěn)定性的關(guān)鍵。接下來(lái)我將結(jié)合多年的運(yùn)維和開(kāi)發(fā)經(jīng)驗(yàn)從原理到落地為你拆解這套架構(gòu)的每一個(gè)核心環(huán)節(jié)。2. 核心原理深度拆解數(shù)據(jù)是如何“流動(dòng)”的在動(dòng)手搭建之前我們必須搞清楚MySQL是如何實(shí)現(xiàn)數(shù)據(jù)復(fù)制的。知其然更要知其所以然這樣在出現(xiàn)數(shù)據(jù)不一致、同步延遲等問(wèn)題時(shí)你才能快速定位根因而不是盲目重啟服務(wù)。2.1 二進(jìn)制日志復(fù)制的基石MySQL主從復(fù)制的核心依賴(lài)于主庫(kù)生成的二進(jìn)制日志。你可以把它理解為主庫(kù)所有數(shù)據(jù)變更操作的“流水賬”或“操作記錄片”。它不是記錄數(shù)據(jù)頁(yè)的物理變化而是記錄導(dǎo)致數(shù)據(jù)變化的邏輯SQL語(yǔ)句Statement-Based Replication, SBR或者行數(shù)據(jù)的變化前后鏡像Row-Based Replication, RBR。為什么是二進(jìn)制日志因?yàn)樗哂许樞蛐?、持久性和可重放性。主?kù)上任何一個(gè)成功提交的事務(wù)都會(huì)按照提交順序被記錄到二進(jìn)制日志文件中。從庫(kù)通過(guò)讀取和重放這個(gè)日志就能在本地重現(xiàn)主庫(kù)的數(shù)據(jù)變更過(guò)程最終達(dá)到數(shù)據(jù)一致的狀態(tài)。注意務(wù)必理解binlog_format這個(gè)關(guān)鍵參數(shù)。它決定了流水賬的記錄方式。在MySQL 5.7之后默認(rèn)是ROW模式。ROW模式的優(yōu)勢(shì)在于能精準(zhǔn)復(fù)制每一行的變化避免了STATEMENT模式下因使用不確定函數(shù)如NOW()RAND()或觸發(fā)器導(dǎo)致的主從數(shù)據(jù)不一致問(wèn)題但日志量會(huì)更大。生產(chǎn)環(huán)境通常推薦使用ROW模式或在MIXED模式下由MySQL自行判斷。2.2 復(fù)制線(xiàn)程與流程三步走的數(shù)據(jù)同步整個(gè)復(fù)制過(guò)程由三個(gè)線(xiàn)程協(xié)同完成理解它們的分工是排查同步問(wèn)題的關(guān)鍵。主庫(kù)Binlog Dump Thread當(dāng)有從庫(kù)連接上來(lái)時(shí)主庫(kù)會(huì)為每個(gè)連接的從庫(kù)創(chuàng)建一個(gè)“日志轉(zhuǎn)儲(chǔ)線(xiàn)程”。這個(gè)線(xiàn)程的唯一職責(zé)就是監(jiān)聽(tīng)從庫(kù)的請(qǐng)求讀取主庫(kù)本地的二進(jìn)制日志并將其發(fā)送給從庫(kù)的I/O線(xiàn)程。它不會(huì)主動(dòng)推送而是響應(yīng)從庫(kù)的拉取請(qǐng)求。從庫(kù)I/O Thread從庫(kù)上運(yùn)行的I/O線(xiàn)程負(fù)責(zé)與主庫(kù)建立客戶(hù)端連接并向主庫(kù)的Binlog Dump Thread發(fā)送請(qǐng)求索取二進(jìn)制日志內(nèi)容。獲取到日志內(nèi)容后它會(huì)將其寫(xiě)入到從庫(kù)本地的文件中這個(gè)文件叫做中繼日志。你可以把中繼日志看作是二進(jìn)制日志在從庫(kù)的一個(gè)“中轉(zhuǎn)站”或“緩沖區(qū)”。從庫(kù)SQL Thread從庫(kù)上運(yùn)行的SQL線(xiàn)程負(fù)責(zé)讀取本地的中繼日志解析出其中記錄的SQL語(yǔ)句或行變更信息并在從庫(kù)上順序執(zhí)行這些操作從而使得從庫(kù)的數(shù)據(jù)與主庫(kù)保持一致。流程總結(jié)主庫(kù)事務(wù)提交 - 寫(xiě)入Binlog- 從庫(kù)I/O線(xiàn)程請(qǐng)求并獲取Binlog- 寫(xiě)入從庫(kù)Relay Log- 從庫(kù)SQL線(xiàn)程讀取Relay Log并執(zhí)行 - 從庫(kù)數(shù)據(jù)更新。 這個(gè)過(guò)程是異步的意味著主庫(kù)提交事務(wù)后不會(huì)等待從庫(kù)應(yīng)用完成就向客戶(hù)端返回成功。這帶來(lái)了高性能但也引入了主從延遲的風(fēng)險(xiǎn)。2.3 讀寫(xiě)分離的核心訴求解耦壓力提升擴(kuò)展性在主從復(fù)制架構(gòu)就緒后讀寫(xiě)分離便是水到渠成的應(yīng)用層優(yōu)化。其核心思想是寫(xiě)操作所有對(duì)數(shù)據(jù)的增、刪、改操作必須發(fā)送到主庫(kù)。因?yàn)橹挥兄鲙?kù)的寫(xiě)操作才會(huì)產(chǎn)生二進(jìn)制日志從庫(kù)的數(shù)據(jù)變更依賴(lài)于主庫(kù)的日志。讀操作所有查詢(xún)操作可以分發(fā)到一個(gè)或多個(gè)從庫(kù)上執(zhí)行。由于讀請(qǐng)求通常占數(shù)據(jù)庫(kù)操作的80%甚至更高將其分散到多個(gè)從庫(kù)實(shí)例能極大減輕主庫(kù)的負(fù)載提升系統(tǒng)的整體查詢(xún)吞吐量。實(shí)現(xiàn)讀寫(xiě)分離通常不在MySQL本身而需要在應(yīng)用層或中間件層進(jìn)行路由。常見(jiàn)方案有應(yīng)用層封裝在代碼中手動(dòng)定義主數(shù)據(jù)源和從數(shù)據(jù)源在DAO層或ORM框架中根據(jù)SQL類(lèi)型選擇數(shù)據(jù)源。中間件代理使用獨(dú)立的中間件如MyCat、ShardingSphere-Proxy等對(duì)應(yīng)用透明地實(shí)現(xiàn)SQL解析和路由。驅(qū)動(dòng)層增強(qiáng)使用支持讀寫(xiě)分離的數(shù)據(jù)庫(kù)連接池如阿里的Druid結(jié)合Spring AOP進(jìn)行動(dòng)態(tài)數(shù)據(jù)源切換。選擇哪種方案取決于團(tuán)隊(duì)的運(yùn)維能力和業(yè)務(wù)復(fù)雜度。對(duì)于快速上手的項(xiàng)目從應(yīng)用層手動(dòng)分離開(kāi)始是成本最低的。3. 環(huán)境準(zhǔn)備與配置實(shí)戰(zhàn)理論清晰后我們進(jìn)入實(shí)戰(zhàn)環(huán)節(jié)。假設(shè)我們有兩臺(tái)服務(wù)器192.168.1.10主庫(kù)192.168.1.11從庫(kù)。操作系統(tǒng)均為CentOS 7MySQL版本為8.0。3.1 主庫(kù)配置詳解首先登錄主庫(kù)服務(wù)器編輯MySQL配置文件/etc/my.cnf路徑可能因安裝方式而異。[mysqld] # 服務(wù)器唯一ID這是必須的集群內(nèi)不能重復(fù) server-id 1 # 啟用二進(jìn)制日志并指定日志文件的前綴 log-bin mysql-bin # 設(shè)置二進(jìn)制日志格式推薦ROW binlog_format ROW # 可選指定需要復(fù)制的數(shù)據(jù)庫(kù)多個(gè)則寫(xiě)多行。不配置則默認(rèn)復(fù)制所有庫(kù)。 # binlog-do-db your_database_name # 可選指定不需要復(fù)制的數(shù)據(jù)庫(kù) # binlog-ignore-db mysql # 可選設(shè)置二進(jìn)制日志過(guò)期天數(shù)避免磁盤(pán)占滿(mǎn) expire_logs_days 7 # 從MySQL 8.0.3開(kāi)始默認(rèn)的認(rèn)證插件可能導(dǎo)致舊版從庫(kù)連接失敗可顯式設(shè)置 default_authentication_pluginmysql_native_password配置項(xiàng)解讀server-id1這是主從集群中識(shí)別該節(jié)點(diǎn)的唯一標(biāo)識(shí)必須設(shè)置且不能重復(fù)。log-binmysql-bin開(kāi)啟二進(jìn)制日志功能日志文件將以mysql-bin.000001、mysql-bin.000002這樣的序列命名。binlog_formatROW生產(chǎn)環(huán)境強(qiáng)烈建議使用行模式數(shù)據(jù)一致性最有保障。expire_logs_days7一個(gè)非常實(shí)用的參數(shù)自動(dòng)清理7天前的二進(jìn)制日志防止日志文件無(wú)限增長(zhǎng)吞噬磁盤(pán)空間。配置完成后重啟MySQL服務(wù)使配置生效systemctl restart mysqld。接下來(lái)我們需要在主庫(kù)上創(chuàng)建一個(gè)專(zhuān)門(mén)用于復(fù)制的用戶(hù)并授予相應(yīng)的權(quán)限。這個(gè)用戶(hù)僅用于從庫(kù)連接主庫(kù)拉取日志權(quán)限應(yīng)嚴(yán)格控制。-- 登錄MySQL后執(zhí)行 CREATE USER repl192.168.1.% IDENTIFIED BY YourStrongPassword123!; GRANT REPLICATION SLAVE ON *.* TO repl192.168.1.%; FLUSH PRIVILEGES;這里創(chuàng)建了用戶(hù)repl允許從192.168.1.0/24網(wǎng)段連接密碼需要設(shè)置得足夠復(fù)雜。REPLICATION SLAVE權(quán)限足以讓其讀取二進(jìn)制日志。最后我們需要獲取主庫(kù)當(dāng)前的一個(gè)關(guān)鍵狀態(tài)用于從庫(kù)初始化時(shí)定位從哪個(gè)時(shí)間點(diǎn)開(kāi)始同步。-- 在主庫(kù)執(zhí)行 FLUSH TABLES WITH READ LOCK; -- 鎖定所有表阻止新的寫(xiě)操作確保狀態(tài)一致性 SHOW MASTER STATUS;執(zhí)行SHOW MASTER STATUS;后你會(huì)看到類(lèi)似下面的輸出------------------------------------------------------------------------------- | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | ------------------------------------------------------------------------------- | mysql-bin.000003 | 785 | | | | -------------------------------------------------------------------------------請(qǐng)務(wù)必記錄下File和Position的值本例中是mysql-bin.000003和785。它們告訴從庫(kù)“請(qǐng)從mysql-bin.000003這個(gè)日志文件的第785個(gè)字節(jié)處開(kāi)始復(fù)制”。重要實(shí)操心得在生產(chǎn)環(huán)境執(zhí)行FLUSH TABLES WITH READ LOCK;會(huì)導(dǎo)致所有表被全局讀鎖鎖定寫(xiě)操作會(huì)阻塞。因此這個(gè)操作必須在業(yè)務(wù)低峰期進(jìn)行并且獲取狀態(tài)信息后應(yīng)立即解鎖UNLOCK TABLES;。對(duì)于已有大量數(shù)據(jù)的主庫(kù)更推薦使用物理備份工具如mysqldump --single-transaction --master-data或Percona XtraBackup來(lái)初始化從庫(kù)這些工具可以在不長(zhǎng)時(shí)間鎖表的情況下獲取一致的備份和準(zhǔn)確的二進(jìn)制日志坐標(biāo)。3.2 從庫(kù)配置與初始化現(xiàn)在切換到從庫(kù)服務(wù)器192.168.1.11編輯其MySQL配置文件。[mysqld] # 服務(wù)器唯一ID必須與主庫(kù)不同 server-id 2 # 可選啟用中繼日志 relay-log mysql-relay-bin # 可選防止從庫(kù)寫(xiě)操作被復(fù)制如果該從庫(kù)還有下級(jí)從庫(kù)則不需要 read_only 1server-id2確保與主庫(kù)不同。relay-log中繼日志的文件名前綴。read_only1這是一個(gè)非常重要的安全設(shè)置。它將從庫(kù)設(shè)置為只讀模式超級(jí)用戶(hù)除外可以防止人為誤操作在從庫(kù)寫(xiě)入數(shù)據(jù)導(dǎo)致主從數(shù)據(jù)不一致。但請(qǐng)注意復(fù)制線(xiàn)程SQL Thread具有超級(jí)權(quán)限不受此限制仍能正常應(yīng)用日志。重啟從庫(kù)MySQL服務(wù)systemctl restart mysqld。接下來(lái)是關(guān)鍵步驟告訴從庫(kù)它的“主人”是誰(shuí)以及從哪里開(kāi)始“跟隨”。我們使用之前在主庫(kù)獲取的File和Position信息。-- 在從庫(kù)的MySQL中執(zhí)行 CHANGE MASTER TO MASTER_HOST192.168.1.10, MASTER_USERrepl, MASTER_PASSWORDYourStrongPassword123!, MASTER_LOG_FILEmysql-bin.000003, MASTER_LOG_POS785;這條命令配置了主庫(kù)的連接信息和復(fù)制的起始點(diǎn)。參數(shù)含義一目了然主機(jī)地址、復(fù)制用戶(hù)、密碼、二進(jìn)制日志文件和位置。配置完成后啟動(dòng)從庫(kù)的復(fù)制線(xiàn)程START SLAVE; -- 在MySQL 8.0.22及以后推薦使用 START REPLICA;然后檢查從庫(kù)的復(fù)制狀態(tài)SHOW SLAVE STATUS\G; -- 使用\G讓結(jié)果垂直顯示更易讀在輸出的海量信息中你需要重點(diǎn)關(guān)注以下兩個(gè)字段Slave_IO_Running: Yes表示I/O線(xiàn)程是否正常運(yùn)行即是否成功連接到主庫(kù)并接收日志。Slave_SQL_Running: Yes表示SQL線(xiàn)程是否正常運(yùn)行即是否在正確重放中繼日志中的事件。如果兩者均為Yes恭喜你主從復(fù)制鏈路已經(jīng)成功建立此時(shí)你在主庫(kù)上創(chuàng)建數(shù)據(jù)庫(kù)、表、插入數(shù)據(jù)稍等片刻取決于網(wǎng)絡(luò)和負(fù)載在從庫(kù)上就能查詢(xún)到相同的數(shù)據(jù)。4. 讀寫(xiě)分離的代碼層實(shí)現(xiàn)策略架構(gòu)搭好了如何讓?xiě)?yīng)用程序用起來(lái)呢下面以經(jīng)典的Spring Boot MyBatis項(xiàng)目為例介紹兩種常見(jiàn)的實(shí)現(xiàn)方式。4.1 方案一基于Spring AOP的注解式動(dòng)態(tài)數(shù)據(jù)源這是一種在應(yīng)用層實(shí)現(xiàn)、靈活性很高的方式。其核心是創(chuàng)建一個(gè)DynamicDataSource類(lèi)繼承AbstractRoutingDataSource并讓它能根據(jù)當(dāng)前上下文動(dòng)態(tài)決定使用主庫(kù)還是從庫(kù)。首先定義數(shù)據(jù)源配置和枚舉。# application.yml spring: datasource: master: jdbc-url: jdbc:mysql://192.168.1.10:3306/your_db?useSSLfalseserverTimezoneUTC username: master_user password: MasterPass123! driver-class-name: com.mysql.cj.jdbc.Driver slave: jdbc-url: jdbc:mysql://192.168.1.11:3306/your_db?useSSLfalseserverTimezoneUTC username: slave_user password: SlavePass123! driver-class-name: com.mysql.cj.jdbc.Driver// 數(shù)據(jù)源類(lèi)型枚舉 public enum DataSourceType { MASTER, SLAVE } // 用于持有當(dāng)前線(xiàn)程數(shù)據(jù)源類(lèi)型的上下文 public class DynamicDataSourceContextHolder { private static final ThreadLocalDataSourceType CONTEXT_HOLDER new ThreadLocal(); public static void setDataSourceType(DataSourceType type) { CONTEXT_HOLDER.set(type); } public static DataSourceType getDataSourceType() { return CONTEXT_HOLDER.get() null ? DataSourceType.MASTER : CONTEXT_HOLDER.get(); // 默認(rèn)主庫(kù) } public static void clearDataSourceType() { CONTEXT_HOLDER.remove(); } } // 動(dòng)態(tài)數(shù)據(jù)源路由器 public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { return DynamicDataSourceContextHolder.getDataSourceType(); } }然后編寫(xiě)一個(gè)自定義注解和AOP切面在Service方法執(zhí)行前根據(jù)方法名或自定義注解來(lái)切換數(shù)據(jù)源。// 自定義注解標(biāo)注在方法或類(lèi)上用于指定使用從庫(kù) Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) Documented public interface SlaveDataSource { } // AOP切面 Aspect Component Order(-1) // 確保在事務(wù)切面之前執(zhí)行 public class DataSourceAspect { // 攔截所有Service注解的類(lèi) Pointcut(within(org.springframework.stereotype.Service *)) public void servicePointcut() {} Before(servicePointcut()) public void beforeServiceMethod(JoinPoint joinPoint) { MethodSignature signature (MethodSignature) joinPoint.getSignature(); Method method signature.getMethod(); // 優(yōu)先級(jí)方法注解 類(lèi)注解 默認(rèn)規(guī)則 if (method.isAnnotationPresent(SlaveDataSource.class) || joinPoint.getTarget().getClass().isAnnotationPresent(SlaveDataSource.class)) { // 如果標(biāo)記了SlaveDataSource則使用從庫(kù) DynamicDataSourceContextHolder.setDataSourceType(DataSourceType.SLAVE); } else { // 默認(rèn)規(guī)則根據(jù)方法名判斷查詢(xún)方法走從庫(kù) String methodName method.getName().toLowerCase(); if (methodName.startsWith(select) || methodName.startsWith(get) || methodName.startsWith(find) || methodName.startsWith(query) || methodName.startsWith(list) || methodName.startsWith(count)) { DynamicDataSourceContextHolder.setDataSourceType(DataSourceType.SLAVE); } else { // 寫(xiě)操作或其他操作走主庫(kù) DynamicDataSourceContextHolder.setDataSourceType(DataSourceType.MASTER); } } } After(servicePointcut()) public void afterServiceMethod() { // 清理線(xiàn)程變量防止內(nèi)存泄漏和上下文污染 DynamicDataSourceContextHolder.clearDataSourceType(); } }最后在Spring配置中將主從數(shù)據(jù)源注入到DynamicDataSource中。這種方案的優(yōu)點(diǎn)是靈活、侵入性低可以精細(xì)控制每個(gè)方法的數(shù)據(jù)源。缺點(diǎn)是需要自己維護(hù)AOP邏輯和線(xiàn)程上下文且在復(fù)雜事務(wù)場(chǎng)景下需要特別注意下文會(huì)講。4.2 方案二使用成熟中間件如ShardingSphere-JDBC如果你覺(jué)得手寫(xiě)AOP太麻煩或者需要更強(qiáng)大的分庫(kù)分表功能那么集成ShardingSphere-JDBC是一個(gè)更專(zhuān)業(yè)的選擇。它作為一個(gè)增強(qiáng)版的JDBC驅(qū)動(dòng)對(duì)應(yīng)用幾乎透明。首先引入依賴(lài)以Spring Boot為例dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.3.2/version !-- 請(qǐng)使用最新穩(wěn)定版 -- /dependency然后在配置文件中定義讀寫(xiě)分離規(guī)則spring: shardingsphere: datasource: names: master,slave master: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://192.168.1.10:3306/your_db username: master_user password: MasterPass123! slave: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://192.168.1.11:3306/your_db username: slave_user password: SlavePass123! rules: readwrite-splitting: >Transactional public void businessMethod() { // 1. 寫(xiě)入主庫(kù) orderMapper.insert(order); // 2. 立刻查詢(xún)剛寫(xiě)入的訂單期望走從庫(kù) Order latestOrder orderMapper.selectById(order.getId()); }在默認(rèn)的讀寫(xiě)分離規(guī)則下第2步的查詢(xún)可能會(huì)被路由到從庫(kù)。由于主從延遲的存在從庫(kù)可能還沒(méi)有這條訂單記錄導(dǎo)致latestOrder為null業(yè)務(wù)邏輯出錯(cuò)。解決方案強(qiáng)制走主庫(kù)在事務(wù)方法內(nèi)所有查詢(xún)都強(qiáng)制使用主庫(kù)。在AOP方案中可以通過(guò)不標(biāo)記SlaveDataSource或修改切面邏輯讓帶有Transactional注解的方法內(nèi)的所有數(shù)據(jù)庫(kù)操作都默認(rèn)走主庫(kù)。在ShardingSphere中可以使用Hint強(qiáng)制路由HintManager.getInstance().setWriteRouteOnly();?；贕TID的讀寫(xiě)分離高級(jí)一些中間件支持“同一個(gè)線(xiàn)程內(nèi)寫(xiě)操作后的讀操作強(qiáng)制走主庫(kù)”的語(yǔ)義。這需要中間件能夠跟蹤上下文。業(yè)務(wù)妥協(xié)對(duì)于不要求強(qiáng)一致性的讀操作如查詢(xún)歷史訂單列表可以走從庫(kù)。對(duì)于要求實(shí)時(shí)性的讀操作如支付成功后跳轉(zhuǎn)的結(jié)果頁(yè)則直接走主庫(kù)或采用方案1。實(shí)操心得在項(xiàng)目初期最穩(wěn)妥的做法是所有在事務(wù)內(nèi)部進(jìn)行的查詢(xún)默認(rèn)都走主庫(kù)。在事務(wù)外部的查詢(xún)?cè)俑鶕?jù)業(yè)務(wù)對(duì)一致性的要求決定是否走從庫(kù)。這能避免絕大多數(shù)因延遲導(dǎo)致的詭異Bug。5.3 復(fù)制中斷與數(shù)據(jù)不一致修復(fù)復(fù)制鏈路可能會(huì)因?yàn)楦鞣N原因中斷常見(jiàn)錯(cuò)誤如Last_IO_Error/Last_SQL_Error在SHOW SLAVE STATUS輸出中會(huì)顯示具體錯(cuò)誤信息。常見(jiàn)錯(cuò)誤主鍵沖突、從庫(kù)上表不存在、網(wǎng)絡(luò)中斷等。通用排查與修復(fù)步驟查看錯(cuò)誤信息首先仔細(xì)閱讀Last_SQL_Error字段它通常直接指明了問(wèn)題所在例如“Duplicate entry 123 for key PRIMARY”。跳過(guò)特定錯(cuò)誤謹(jǐn)慎使用如果確認(rèn)錯(cuò)誤數(shù)據(jù)可以忽略例如從庫(kù)上已經(jīng)存在一條重復(fù)數(shù)據(jù)且可以接受可以臨時(shí)跳過(guò)這個(gè)錯(cuò)誤事件讓復(fù)制繼續(xù)。STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER 1; -- 跳過(guò)1個(gè)事件 START SLAVE;警告這可能導(dǎo)致數(shù)據(jù)不一致需確保跳過(guò)的操作不會(huì)影響業(yè)務(wù)邏輯。重新同步如果數(shù)據(jù)不一致范圍較大最徹底的方法是重建從庫(kù)。在主庫(kù)使用mysqldump --single-transaction --master-data做全量備份。在從庫(kù)停止復(fù)制恢復(fù)備份。使用備份文件中的CHANGE MASTER TO信息--master-data會(huì)自動(dòng)記錄重新指向主庫(kù)的最新位置啟動(dòng)復(fù)制。使用工具修復(fù)對(duì)于少量表的數(shù)據(jù)不一致可以使用pt-table-checksum和pt-table-sync工具。前者檢查主從數(shù)據(jù)差異后者生成修復(fù)差異的SQL語(yǔ)句。務(wù)必在測(cè)試環(huán)境充分驗(yàn)證后再在生產(chǎn)環(huán)境使用。6. 高可用與架構(gòu)演進(jìn)思考基礎(chǔ)的“一主一從”架構(gòu)能滿(mǎn)足大多數(shù)初創(chuàng)場(chǎng)景但隨著業(yè)務(wù)發(fā)展架構(gòu)需要演進(jìn)。6.1 一主多從與負(fù)載均衡當(dāng)讀壓力進(jìn)一步增大時(shí)可以增加多個(gè)從庫(kù)。這時(shí)應(yīng)用端的讀寫(xiě)分離中間件或連接池的負(fù)載均衡能力就很重要?？梢圆捎幂喸?xún)、隨機(jī)、或基于從庫(kù)負(fù)載權(quán)重的策略來(lái)分發(fā)讀請(qǐng)求。需要注意的是從庫(kù)越多主庫(kù)復(fù)制數(shù)據(jù)的網(wǎng)絡(luò)和IO壓力也越大。6.2 級(jí)聯(lián)復(fù)制架構(gòu)如果從庫(kù)數(shù)量很多比如超過(guò)5個(gè)全部從主庫(kù)拉取日志會(huì)給主庫(kù)帶來(lái)巨大壓力。此時(shí)可以采用級(jí)聯(lián)復(fù)制Master - SlaveA - (SlaveB1, SlaveB2, ...)。SlaveA作為一個(gè)“中繼從庫(kù)”既接收主庫(kù)的數(shù)據(jù)又作為其他下游從庫(kù)的主庫(kù)。這樣可以減輕主庫(kù)的負(fù)擔(dān)但代價(jià)是數(shù)據(jù)到達(dá)下游從庫(kù)的延遲會(huì)疊加。6.3 高可用方案主庫(kù)故障切換主從復(fù)制本身不解決主庫(kù)的高可用問(wèn)題。如果主庫(kù)宕機(jī)需要手動(dòng)或自動(dòng)將一個(gè)從庫(kù)提升為新的主庫(kù)并讓其他從庫(kù)和應(yīng)用程序指向新的主庫(kù)這個(gè)過(guò)程稱(chēng)為“故障切換”。手動(dòng)切換DBA介入在從庫(kù)執(zhí)行STOP SLAVE; RESET SLAVE ALL;清除其從屬身份然后將其配置為新的主庫(kù)并讓其他從庫(kù)和應(yīng)用程序修改配置。這個(gè)過(guò)程耗時(shí)較長(zhǎng)期間服務(wù)不可用。自動(dòng)切換推薦使用高可用框架如MHA、Orchestrator或云廠(chǎng)商提供的RDS高可用服務(wù)。這些工具能自動(dòng)檢測(cè)主庫(kù)故障選舉新的主庫(kù)并完成拓?fù)渲貥?gòu)和虛擬IP切換將停機(jī)時(shí)間縮短到幾十秒內(nèi)。6.4 半同步復(fù)制與數(shù)據(jù)強(qiáng)一致性默認(rèn)的異步復(fù)制可能丟失數(shù)據(jù)如果主庫(kù)在將事務(wù)寫(xiě)入二進(jìn)制日志后、但尚未將日志發(fā)送給任何從庫(kù)時(shí)就崩潰了這個(gè)已提交的事務(wù)可能會(huì)丟失。半同步復(fù)制提供了折衷方案主庫(kù)提交事務(wù)時(shí)會(huì)阻塞等待至少一個(gè)從庫(kù)接收并寫(xiě)入中繼日志不要求執(zhí)行完成后才向客戶(hù)端返回成功。這保證了數(shù)據(jù)至少存在于兩個(gè)節(jié)點(diǎn)上增強(qiáng)了數(shù)據(jù)安全性但會(huì)稍微增加寫(xiě)操作的延遲。在MySQL中可以通過(guò)安裝半同步插件并設(shè)置相關(guān)參數(shù)來(lái)啟用-- 在主庫(kù)和從庫(kù)上安裝插件 INSTALL PLUGIN rpl_semi_sync_master SONAME semisync_master.so; INSTALL PLUGIN rpl_semi_sync_slave SONAME semisync_slave.so; -- 啟用 SET GLOBAL rpl_semi_sync_master_enabled 1; SET GLOBAL rpl_semi_sync_slave_enabled 1;架構(gòu)設(shè)計(jì)沒(méi)有銀彈。選擇異步、半同步還是基于Group Replication的完全同步取決于業(yè)務(wù)對(duì)數(shù)據(jù)一致性、可用性和性能之間的權(quán)衡。對(duì)于絕大多數(shù)互聯(lián)網(wǎng)應(yīng)用基于異步復(fù)制的主從架構(gòu)配合高可用方案已經(jīng)能提供非常可靠的數(shù)據(jù)庫(kù)服務(wù)支撐。理解每一層原理明確每一個(gè)配置項(xiàng)的含義才能在出現(xiàn)問(wèn)題時(shí)胸有成竹在架構(gòu)演進(jìn)時(shí)做出合理的選擇。