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