1. 先搞清楚我們要搭的東西到底是什么先說結(jié)論這個(gè)標(biāo)題一點(diǎn)也不夸張但“1分鐘”是有前提的鏡像提前拉好、腳本寫好了剩下的啟動(dòng)和驗(yàn)證就是幾十秒的事。我用一套基于 Docker Compose 封裝的批量部署腳本在一臺(tái) 8 核 16G 的機(jī)器上同時(shí)拉起 10 套 MySQL 主從集群從執(zhí)行命令到SHOW SLAVE STATUS全部顯示W(wǎng)aiting for source to send event整個(gè)流程不超過 1 分鐘。這套方案我不是第一次用了前前后后踩了不少坑今天把這套東西拆開講清楚。1.1 主從復(fù)制到底在復(fù)制什么MySQL 主從復(fù)制嚴(yán)格說復(fù)制的是 binlog二進(jìn)制日志里的邏輯事件流。主庫把數(shù)據(jù)變更按順序?qū)戇M(jìn) binlog從庫通過 IO 線程把主庫 binlog 拉到本地 relay log中繼日志再由 SQL 線程回放 relay log最終讓從庫的數(shù)據(jù)追上主庫。整個(gè)鏈路看似簡(jiǎn)單但涉及三張關(guān)鍵的角色表主庫的 dump 線程負(fù)責(zé)把 binlog 事件推送給從庫的 IO 線程。從庫的 IO 線程負(fù)責(zé)連接主庫請(qǐng)求 binlog 并寫入 relay log。從庫的 SQL 線程負(fù)責(zé)讀取 relay log 并逐個(gè)執(zhí)行事件。記住這個(gè)模型后面所有排查都是圍繞這三條線展開的。我搭 10 套集群時(shí)最依賴的一個(gè)狀態(tài)字段就是Slave_IO_Running和Slave_SQL_Running這兩個(gè)字段同時(shí)為Yes基本說明復(fù)制鏈路是通的。如果 IO 線程卡住大概率是網(wǎng)絡(luò)、賬號(hào)權(quán)限或者 server-id 沖突如果 SQL 線程卡住大概率是主從數(shù)據(jù)不一致或者 relay log 損壞。復(fù)制模式上8.0 和 5.7 我選的是 GTID 模式也就是全局事務(wù)標(biāo)識(shí)符。GTID 是server_uuid:transaction_id的組合每個(gè)事務(wù)在主庫上產(chǎn)生唯一編號(hào)從庫可以通過 GTID 自動(dòng)定位復(fù)制位點(diǎn)不需要再關(guān)心binlog file和binlog position這兩個(gè)老參數(shù)。對(duì)于批量部署 10 套集群的場(chǎng)景GTID 最大的意義是讓初始化更加自動(dòng)化腳本里可以少處理很多“主庫位點(diǎn)變化”的邊界問題。如果你還在用老的MASTER_LOG_FILEMASTER_LOG_POS方式搭建少量實(shí)例沒問題但批量搞的時(shí)候就容易翻車因?yàn)橹鲙煲坏┯蓄~外寫入位點(diǎn)就會(huì)漂移。1.2 主從集群能解決什么解決不了什么用主從不是為了“看著專業(yè)”它的核心價(jià)值有三塊讀寫分離、容災(zāi)冗余、分析隔離。讀寫分離的場(chǎng)景最直觀主庫承接寫流量從庫承接讀流量應(yīng)用層按需切換數(shù)據(jù)源能明顯降低主庫負(fù)載。容災(zāi)冗余是指主庫出現(xiàn)硬件故障后可以手動(dòng)或通過高可用組件把從庫提升為新主庫減少不可用時(shí)間。分析隔離則是在從庫上跑公司里那些重量級(jí)查詢、報(bào)表任務(wù)、備份操作避免它們擠占主庫的 CPU 和 IO。但它不是萬能的有幾個(gè)誤區(qū)必須說清楚。第一主從復(fù)制不是同步復(fù)制默認(rèn)是異步的主庫提交事務(wù)后不等從庫確認(rèn)就返回成功所以從庫數(shù)據(jù)天然存在延遲。延遲高的時(shí)候你讀從庫會(huì)讀到舊數(shù)據(jù)這個(gè)必須靠業(yè)務(wù)層容忍或者中間件做分片策略。第二主從不能解決數(shù)據(jù)一致性問題如果主從數(shù)據(jù)已經(jīng)不一致復(fù)制鏈路直接報(bào)錯(cuò)停擺不是自動(dòng)修復(fù)。第三GTID 雖然自動(dòng)化程度高但反向切換從庫提升為主庫后再恢復(fù)原主庫時(shí)要注意事務(wù)沖突不能簡(jiǎn)單重連了事。1.3 為什么我選 Docker Compose 而不是裸機(jī)安裝很多人一看“10 套主從集群”第一反應(yīng)是一臺(tái)物理機(jī)裝 20 個(gè) MySQL 實(shí)例路徑、端口、配置要改到懷疑人生。確實(shí)如果用傳統(tǒng)方式在 Linux 上通過二進(jìn)制包部署 10 套主從光是規(guī)劃目錄、編譯參數(shù)、啟動(dòng)腳本就能折騰一天這個(gè)過程沒必要重復(fù)驗(yàn)證。用 Docker Compose 的好處在于每個(gè)容器就是一個(gè)隔離的 MySQL 實(shí)例端口映射、數(shù)據(jù)目錄、配置文件都可以通過編排文件聲明環(huán)境一致性極高。不管底層是 CentOS、Ubuntu 還是 Rocky只要 Docker 環(huán)境正常容器里的行為是一致的。這對(duì)批量復(fù)現(xiàn)主從場(chǎng)景極其重要尤其適合我這種經(jīng)常要測(cè)運(yùn)維工具、中間件、面試題里各種“主從切換”邏輯的人。不過我如實(shí)說一句Compose 不是萬金油。生產(chǎn)環(huán)境的主從集群往往要結(jié)合 Orchestrator、MHA、ProxySQL 等組件Docker Compose 更多是開發(fā)環(huán)境、測(cè)試環(huán)境、壓測(cè)環(huán)境的利器。但如果你想把“主從原理”驗(yàn)證透、把日常巡檢腳本跑通、把面試?yán)锬切┲鲝墓收蠄?chǎng)景復(fù)現(xiàn)出來這套方案是最快路徑。2. 環(huán)境準(zhǔn)備與資源評(píng)估別上來就盲目拉二十個(gè)容器2.1 資源規(guī)劃和端口設(shè)計(jì)是第一步10 套主從集群意味著 20 個(gè) MySQL 容器實(shí)例。分配資源之前先想清楚每套集群是“真跑業(yè)務(wù)”還是“模擬場(chǎng)景”。如果只是模擬主從復(fù)制、驗(yàn)證配置、測(cè)試讀寫分離每個(gè)容器內(nèi)存限制在 256M~512M 即可CPU 限制在 0.5~1 核即可。如果是壓測(cè)那就不能這么摳建議單實(shí)例至少 1G 內(nèi)存和 1.5 核起步。我用的機(jī)器是 8 核 16G給 20 個(gè)容器每實(shí)例分配了 512M 內(nèi)存限制CPU 不加硬限制磁盤用 SSD。啟動(dòng)后整體內(nèi)存占用在 10G 左右留了余量給宿主機(jī)和 docker daemon。這里有個(gè)很關(guān)鍵的思路資源限制一定要在 Compose 里聲明。不限制的話20 個(gè) MySQL 會(huì)按照 innodb_buffer_pool_size 默認(rèn)值瘋狂搶內(nèi)存我的默認(rèn)配置是 128M沒有顯式調(diào)大但容器本身沒有 cgroup 限制時(shí)宿主機(jī)很容易被吃滿。端口規(guī)劃上傳統(tǒng)做法是給不同實(shí)例分配不同的宿主機(jī)端口。10 套主從我劃分為集群編號(hào)主庫宿主機(jī)端口從庫宿主機(jī)端口容器內(nèi)部端口固定為1133061330733062134061340733063135061350733064136061360733065137061370733066138061380733067139061390733068140061400733069141061410733061014206142073306端口選擇從 13306 起步是為了避開常規(guī)的 3306、3307也不跟宿主機(jī)已有服務(wù)沖突。這里唯一要牢記的是容器內(nèi)部和外部端口不能混淆。連接主庫或從庫時(shí)用的是宿主機(jī) IP 加映射端口而 MySQL 配置文件里的 server 相關(guān)參數(shù)和數(shù)據(jù)目錄都在容器內(nèi)部視角。2.2 Docker 與 Compose 插件裝錯(cuò)版本會(huì)吃大虧先說宿主機(jī)系統(tǒng)。我在 Rocky Linux 9 和 Ubuntu 22.04 上都驗(yàn)證過這套流程核心要求是 Docker Engine 版本不低于 20.10Compose 插件正?？捎谩０惭b Docker 的步驟不再贅述重點(diǎn)提醒幾個(gè)容易出問題的地方。第一docker compose命令和老的docker-compose是兩套東西。新版 Docker Engine 推薦用docker compose帶空格作為子命令它是一個(gè) Go 編寫的獨(dú)立二進(jìn)制插件。老項(xiàng)目里常見的docker-compose由 Python 寫成新版本 Docker 環(huán)境下經(jīng)常出現(xiàn)兼容性問題尤其是version字段廢棄后老命令會(huì)給你報(bào)奇怪的格式錯(cuò)誤。我要不是為了兼容舊腳本絕不用docker-compose。實(shí)際操作中我用的是docker compose version檢查版本確保輸出里有Docker Compose version v2.x。第二運(yùn)行 Docker 服務(wù)的用戶要加入 docker 用戶組否則每次都要 sudo。批量操作 20 個(gè)容器時(shí)命令數(shù)量非常多如果每次都要 sudo 超時(shí)重新輸入密碼那 1 分鐘搭建就是個(gè)笑話。建議直接sudo usermod -aG docker $USER newgrp docker第三磁盤空間問題。MySQL 官方鏡像本身不算大但容器一旦初始化數(shù)據(jù)目錄很容易膨脹。10 套集群即使每套只有幾十 MB 的初始化數(shù)據(jù)加上 binlog、redo log、undo log總量也是可觀的。我建議宿主機(jī)的/var/lib/docker分區(qū)至少預(yù)留 30G 可用空間否則 MySQL 8.0 啟動(dòng)后會(huì)因?yàn)榇疟P空間不足報(bào)各種神鬼莫測(cè)的錯(cuò)比如InnoDB: Operating system error number 28。2.3 鏡像選型鎖定版本不要用 latest鏡像標(biāo)簽是這次實(shí)操里最容易陰溝翻船的地方。很多人圖省事直接用mysql:latest這是大忌。latest標(biāo)簽會(huì)跟隨官方更新飄移今天拉下來是 8.0.36明天變 8.0.38行為可能發(fā)生變化尤其在認(rèn)證插件、默認(rèn)字符集、參數(shù)默認(rèn)值上不同小版本的差異真的能坑到你懷疑人生。我選的是mysql:8.0.36官方鏡像鎖死在 Dockerfile 層面。為什么不選 5.7因?yàn)?MySQL 5.7 已經(jīng)停止更新8.0 在性能、安全性、GTID 支持方面都更主流。8.0 的默認(rèn)認(rèn)證插件是caching_sha2_password這一點(diǎn)在配置從庫連接主庫時(shí)要特別注意后面我會(huì)詳解。如果你有歷史包袱必須用 5.7那也請(qǐng)鎖死m(xù)ysql:5.7.44不要用5.7標(biāo)簽。鏡像最好提前手動(dòng)拉好這一步對(duì)“1分鐘”貢獻(xiàn)最大docker pull mysql:8.0.36不要以為隨便找臺(tái)機(jī)器現(xiàn)拉也能 1 分鐘搞定國內(nèi)鏡像源高峰期一個(gè)接近 100MB 的鏡像拉取時(shí)間能讓你直接破防。提前備好鏡像后面的操作才真正是讀秒級(jí)別的。3. 一分鐘搭建的關(guān)鍵批量生成 Compose 配置3.1 設(shè)計(jì)思路寫一份模板用一個(gè)變量驅(qū)動(dòng) 10 套純手工寫 20 個(gè) service 段是愚蠢且低效的。我的做法是準(zhǔn)備一個(gè)小的 shell 腳本gen_cluster.sh通過一個(gè)循環(huán)變量生成完整的docker-compose.yml。腳本不復(fù)雜但對(duì)格式極其敏感尤其是 YAML 縮進(jìn)少一個(gè)空格容器編排階段就會(huì)報(bào)錯(cuò)。腳本核心邏輯是定義一個(gè)要生成的集群數(shù)量比如CLUSTER_NUM10。定義一個(gè)基礎(chǔ)端口比如BASE_PORT13306。循環(huán)生成每個(gè)集群的主從兩個(gè) service 段。拼接生成docker-compose.yml文件。這里的核心點(diǎn)是每個(gè)主庫的server_id必須全局唯一。MySQL 復(fù)制協(xié)議中從庫連接主庫時(shí)會(huì)以 server-id 標(biāo)識(shí)自己如果兩個(gè)從庫用了相同的 server-id主庫會(huì)踢掉舊連接導(dǎo)致其中一個(gè)從庫頻繁斷連。我在批量生成時(shí)把 server_id 設(shè)計(jì)為“集群編號(hào)2-1”是主庫“集群編號(hào)2”是從庫這樣 10 套集群的 server_id 分別為 1 到 20兩兩集群之間完全不沖突。3.2 批量生成 docker-compose.yml 的代碼實(shí)現(xiàn)下面是實(shí)際跑通過的腳本我簡(jiǎn)化了部分注釋保留了核心邏輯。腳本內(nèi)容本身可以直接抄但請(qǐng)你先理解每一步再運(yùn)行#!/bin/bash CLUSTER_NUM10 BASE_PORT13306 MYSQL_ROOT_PASSWORDRoot123456 REPL_USERrepl_user REPL_PASSWORDRepl123456 OUT_FILEdocker-compose.yml cat $OUT_FILE EOF services: EOF for ((i1; iCLUSTER_NUM; i)); do MASTER_PORT$((BASE_PORT (i-1)*2)) SLAVE_PORT$((MASTER_PORT 1)) MASTER_ID$((i*2 - 1)) SLAVE_ID$((i*2)) cat $OUT_FILE EOF mysql-master-${i}: image: mysql:8.0.36 container_name: mysql-master-${i} restart: unless-stopped ports: - ${MASTER_PORT}:3306 environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} command: - --server-id${MASTER_ID} - --log-binmysql-bin - --gtid_modeON - --enforce_gtid_consistencyON - --binlog_formatROW - --default_authentication_pluginmysql_native_password volumes: - mysql-master-${i}-data:/var/lib/mysql networks: mysql-cluster-net: ipv4_address: 172.28.${i}.10 mysql-slave-${i}: image: mysql:8.0.36 container_name: mysql-slave-${i} restart: unless-stopped depends_on: - mysql-master-${i} ports: - ${SLAVE_PORT}:3306 environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} command: - --server-id${SLAVE_ID} - --gtid_modeON - --enforce_gtid_consistencyON - --read_onlyON - --super_read_onlyON volumes: - mysql-slave-${i}-data:/var/lib/mysql networks: mysql-cluster-net: ipv4_address: 172.28.${i}.20 EOF done cat $OUT_FILE EOF volumes: EOF for ((i1; iCLUSTER_NUM; i)); do cat $OUT_FILE EOF mysql-master-${i}-data: name: mysql-master-${i}-data mysql-slave-${i}-data: name: mysql-slave-${i}-data EOF done cat $OUT_FILE EOF networks: mysql-cluster-net: driver: bridge ipam: config: - subnet: 172.28.0.0/16 EOF echo Generated $OUT_FILE with $CLUSTER_NUM clusters這里有一個(gè)必須注意的細(xì)節(jié)MySQL 8.0 官方鏡像中默認(rèn)認(rèn)證插件是 caching_sha2_password我在主庫命令中顯式指定了--default_authentication_pluginmysql_native_password。原因是復(fù)制賬號(hào)在老認(rèn)證插件下更容易被兼容適配雖然 8.0 本身支持 caching_sha2_password但客戶端驅(qū)動(dòng)和中間件五花八門一不小心就報(bào)Authentication plugin caching_sha2_password cannot be loaded。如果目標(biāo)是生產(chǎn)環(huán)境且客戶端版本明確支持可以不用這個(gè)參數(shù)但批量測(cè)試場(chǎng)景我建議加上省掉一大片兼容性麻煩。網(wǎng)絡(luò)方面我給每套集群分配了獨(dú)立網(wǎng)段172.28.${i}.0/24主庫固定172.28.${i}.10從庫固定172.28.${i}.20。這樣主從之間的通訊地址不需要依賴 DNS 解析也不容易因?yàn)槿萜髦亟▽?dǎo)致 IP 變化。這種規(guī)劃對(duì)于批量管理非常友好后期寫巡檢腳本時(shí)直接按 IP 遍歷即可。3.3 啟動(dòng)容器的一個(gè)坑IPv4 子網(wǎng)不能鋪太大執(zhí)行docker compose up -d前我特意把 network 子網(wǎng)限制在172.28.0.0/16而不是默認(rèn)的橋接網(wǎng)絡(luò)。很多人直接省略 network 配置讓 Compose 自己創(chuàng)建默認(rèn)網(wǎng)絡(luò)也能跑但默認(rèn)網(wǎng)絡(luò)不支持指定靜態(tài) IP而且不同項(xiàng)目之間的網(wǎng)絡(luò)隔離不夠徹底。當(dāng)你有 10 套集群同時(shí)起時(shí)默認(rèn)網(wǎng)絡(luò)會(huì)把它們?nèi)糠旁谕粋€(gè)網(wǎng)段將來做網(wǎng)絡(luò)策略限制時(shí)你根本沒法區(qū)分。子網(wǎng)不能鋪太大還有另一個(gè)原因預(yù)留子網(wǎng)沖突。172.28.0.0/16這個(gè)網(wǎng)段如果和公司局域網(wǎng)沖突容器通信就會(huì)異常。我在一個(gè)客戶的服務(wù)器上就遇到過他們的內(nèi)網(wǎng)恰好占了 172.28.0.0/16Docker 自動(dòng)分配的網(wǎng)段一啟動(dòng)就把公司網(wǎng)絡(luò)搞懵了。所以部署前先查一下當(dāng)前機(jī)器上已有的 docker 網(wǎng)絡(luò)docker network ls如果有其他項(xiàng)目已經(jīng)占了類似網(wǎng)段就換一個(gè)不沖突的比如172.29.0.0/16或 10.88.0.0/16。3.4 啟動(dòng)命令與快速驗(yàn)證鏡像準(zhǔn)備好、配置文件生成好后啟動(dòng)命令只有一行docker compose up -d在 10 套集群規(guī)模下第一次啟動(dòng)需要初始化數(shù)據(jù)目錄通常會(huì)等一會(huì)兒。但如果你的數(shù)據(jù)卷是全新的、鏡像已緩存、磁盤是 SSD實(shí)測(cè)從執(zhí)行命令到 20 個(gè)容器全部顯示Up大約 40 秒到 1 分鐘。這也是標(biāo)題“1分鐘搭建10套MySQL主從集群”這句話的真正來源——它指的是容器全部正常啟動(dòng)而不是把復(fù)制鏈路也初始化完。容器啟動(dòng)后先用一個(gè)命令檢查全局狀態(tài)docker compose ps --format table {{.Name}}\t{{.Status}}\t{{.Ports}}這個(gè)輸出會(huì)顯示每個(gè)容器的狀態(tài)。如果你看到某個(gè)容器反復(fù) restart大概率是 MySQL 初始化失敗。此時(shí)去看對(duì)應(yīng)容器日志docker logs mysql-master-1 --tail 50最常見的失敗原因有兩個(gè)一是掛載的 volume 權(quán)限問題容器內(nèi) mysql 用戶無法寫入數(shù)據(jù)目錄二是配置文件或其他參數(shù)沖突導(dǎo)致 MySQL 無法完成初始化。前者在官方鏡像中相對(duì)少見后者通常和 my.cnf 里配了 Compose 命令行中重復(fù)的參數(shù)有關(guān)。還有一點(diǎn)要提醒不要看到 20 個(gè)容器都 Up 就以為萬事大吉。MySQL 容器對(duì)外表現(xiàn)為 Up內(nèi)部可能還在進(jìn)行初始化。需要在容器內(nèi)實(shí)際執(zhí)行mysqladmin ping確認(rèn)。批量檢查時(shí)可以用一行循環(huán)for i in $(seq 1 10); do docker exec mysql-master-$i mysqladmin ping -h127.0.0.1 -uroot -pRoot123456 2/dev/null docker exec mysql-slave-$i mysqladmin ping -h127.0.0.1 -uroot -pRoot123456 2/dev/null done全部返回mysqld is alive后容器層才算就緒。4. 復(fù)制鏈路的初始化與驗(yàn)證十套集群一起搞定4.1 在主庫創(chuàng)建復(fù)制賬號(hào)并授權(quán)容器全部啟動(dòng)后剩下就是配置復(fù)制鏈路。自動(dòng)化的思路是寫一個(gè)初始化腳本依次對(duì) 10 套集群執(zhí)行。但在此之前我先手動(dòng)對(duì)第一套集群做一遍完整流程確保每一步命令正確然后再批量執(zhí)行。這個(gè)習(xí)慣能幫你少踩很多雷尤其是 SQL 寫錯(cuò)時(shí)你只需要改一次腳本而不是在 20 個(gè)容器里逐個(gè)補(bǔ)救。先在主庫創(chuàng)建復(fù)制專用賬號(hào)。這個(gè)賬號(hào)在從庫連接主庫時(shí)使用必須具備REPLICATION SLAVE權(quán)限8.0 里對(duì)應(yīng)REPLICATION SLAVE。在主庫執(zhí)行CREATE USER repl_user% IDENTIFIED WITH mysql_native_password BY Repl123456; GRANT REPLICATION SLAVE ON *.* TO repl_user%; FLUSH PRIVILEGES;賬號(hào)權(quán)限最小化是鐵律。不要圖省事直接給repl_user授予 ALL PRIVILEGES 或者 SUPER 權(quán)限復(fù)制鏈路只需要 REPLICATION 相關(guān)權(quán)限多余的權(quán)限只會(huì)增加安全事故風(fēng)險(xiǎn)。順便提一句如果你的業(yè)務(wù)要配置級(jí)聯(lián)復(fù)制那才需要給中繼主庫額外權(quán)限而普通主從場(chǎng)景不必。接著確認(rèn)主庫當(dāng)前的 GTID 狀態(tài)。GTID 模式下不再需要獲取 File 和 Position但需要確保gtid_mode已開啟并且enforce_gtid_consistency生效?？梢詧?zhí)行SHOW VARIABLES LIKE gtid_mode; SHOW MASTER STATUS\G;在 GTID 模式下SHOW MASTER STATUS返回的File和Position字段已經(jīng)不再用于啟動(dòng)復(fù)制而是看Executed_Gtid_Set。這個(gè)值會(huì)記錄已經(jīng)執(zhí)行過的 GTID 集合從庫啟動(dòng)復(fù)制時(shí)只需要知道從哪個(gè) GTID 開始即可。4.2 從庫執(zhí)行 CHANGE MASTER TO 并啟動(dòng)復(fù)制從庫上執(zhí)行的語句如下我以集群 1 的從庫連接集群 1 的主庫為例CHANGE MASTER TO MASTER_HOST172.28.1.10, MASTER_PORT3306, MASTER_USERrepl_user, MASTER_PASSWORDRepl123456, MASTER_AUTO_POSITION1; START SLAVE;注意MASTER_AUTO_POSITION1這一行是 GTID 模式的核心。它告訴從庫不要再監(jiān)聽 File 和 Position改用 GTID 自動(dòng)定位到主庫的 binlog 位置。如果不加這個(gè)參數(shù)MySQL 默認(rèn)會(huì)認(rèn)為你要用老協(xié)議直接報(bào)錯(cuò)或者無法正確同步。從庫的MASTER_HOST用的是容器內(nèi)部網(wǎng)絡(luò)地址不是宿主機(jī)的映射端口地址。這一點(diǎn)很重要它體現(xiàn)的是“容器間通信”與“宿主機(jī)訪問”兩個(gè)視角。如果你在宿主機(jī)上用mysql -h127.0.0.1 -P13307去連從庫那意味著你在走宿主機(jī)端口映射但從庫內(nèi)部連接主庫時(shí)它處于容器網(wǎng)絡(luò)里必須用容器 IP 或容器服務(wù)名。第二套到第十套集群的復(fù)制鏈路原理完全一樣只是 IP 變化。對(duì)于批量操作我寫了一個(gè)init_replication.sh核心是在每套集群的主庫創(chuàng)建賬號(hào)然后到從庫執(zhí)行 CHANGE MASTER TO 和 START SLAVE。注意腳本里要捕獲每個(gè)步驟的返回值任何一個(gè)從庫啟動(dòng)失敗都不能靜默忽略。4.3 驗(yàn)證復(fù)制狀態(tài)三個(gè)字段決定成敗配置完復(fù)制后驗(yàn)證是必不可少的一步。在每套集群的從庫上執(zhí)行SHOW SLAVE STATUS\G;最需要關(guān)注的字段如下表字段正常值異常含義Slave_IO_RunningYesIO 線程未運(yùn)行連接主庫失敗Slave_SQL_RunningYesSQL 線程未運(yùn)行回放 relay log 出錯(cuò)Seconds_Behind_Master0 或接近 0數(shù)值持續(xù)增大代表從庫延遲嚴(yán)重Last_IO_Error空有內(nèi)容則代表網(wǎng)絡(luò)或認(rèn)證問題Last_SQL_Error空有內(nèi)容則代表回放出錯(cuò)Retrieved_Gtid_Set非空從庫尚未拉到任何 GTID 時(shí)為空第一次搭建時(shí)我遇到過Slave_IO_Running一直是Connecting的情況最開始以為是網(wǎng)絡(luò)問題后來才發(fā)現(xiàn)是復(fù)制賬號(hào)密碼寫錯(cuò)了Last_IO_Error里明確提示Access denied for user repl_user。所以只要看到 IO 線程不是 Yes第一件事就看Last_IO_Error不要瞎猜。驗(yàn)證全部通過后還可以做一次實(shí)際的寫入測(cè)試。在集群 1 主庫建一張表插入數(shù)據(jù)然后從庫查詢-- 主庫執(zhí)行 CREATE DATABASE test_db; USE test_db; CREATE TABLE t1 (id INT PRIMARY KEY, name VARCHAR(20)); INSERT INTO t1 VALUES (1, hello); -- 從庫查詢 USE test_db; SELECT * FROM t1;如果從庫能查到1|hello說明 binlog 事件通過 dump - IO - SQL 全鏈路回放成功這套主從就是活的。這一步最有說服力比任何狀態(tài)字段都真實(shí)。4.4 批量驗(yàn)證腳本的思路手動(dòng)查 10 套集群的狀態(tài)太浪費(fèi)時(shí)間我封裝了一個(gè)驗(yàn)證腳本邏輯很簡(jiǎn)單對(duì)每個(gè)從庫循環(huán)執(zhí)行SHOW SLAVE STATUS用 grep 或 awk 抓關(guān)鍵字段把所有異常實(shí)例匯總輸出。for i in $(seq 1 10); do docker exec mysql-slave-$i mysql -uroot -pRoot123456 -e SHOW SLAVE STATUS\G 2/dev/null | grep -E Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master | tr \n echo - cluster $i slave done沒驗(yàn)證之前你可能不知道批量腳本最大的價(jià)值是什么。當(dāng)你手動(dòng)執(zhí)行了二十遍 CHANGE MASTER TO 后你會(huì)發(fā)現(xiàn)任何可以“重復(fù)做”的操作都值得寫成腳本。5. 常見問題與排查策略這四十個(gè)容器讓我踩遍了坑說實(shí)話我第一次寫這套腳本時(shí)并沒有一次通過前后折騰到凌晨。如果你照著上文操作大概率會(huì)踩到如下幾個(gè)問題我把它們按出現(xiàn)頻率從高到低排個(gè)序。5.1 Container 反復(fù)重啟數(shù)據(jù)卷權(quán)限出問題現(xiàn)象docker compose ps看到某些容器 STATUS 為Restarting日志里有Permission denied或Cant open the mysql.plugin table。原因數(shù)據(jù)卷目錄上的權(quán)限不對(duì)。官方鏡像在容器內(nèi)是以mysql用戶運(yùn)行的如果宿主機(jī)掛載的目錄是 root 所有容器內(nèi)的 mysql 用戶沒有寫權(quán)限初始化直接失敗。解決辦法掛載卷時(shí)可以顯式指定:ZSELinux 環(huán)境或檢查目錄權(quán)限最穩(wěn)妥的是不掛宿主機(jī)目錄到/var/lib/mysql而是用 Docker named volume也就是上文腳本里做的volumes: mysql-master-${i}-data:/var/lib/mysql。Named volume 由 Docker 接管權(quán)限天然避開這個(gè)問題。5.2 從庫 IO 線程連接不上主庫總是在 Connecting這種問題我在新環(huán)境里遇到過好幾次。排查順序應(yīng)當(dāng)固定為檢查從庫與主庫的容器網(wǎng)絡(luò)連通性。進(jìn)入從庫容器ping 主庫容器 IP。檢查主庫的復(fù)制賬號(hào)是否存在、密碼是否正確、host 是否允許遠(yuǎn)程。賬號(hào) host 必須覆蓋從庫來源 IP 對(duì)應(yīng)的范圍比如%。檢查主庫和從庫的 server_id 是否重復(fù)。如果從庫 1 的 server_id 和從庫 2 相同主庫會(huì)認(rèn)為連接沖突。檢查防火墻。這里說的是宿主機(jī)防火墻不是 Docker 內(nèi)防火墻。雖然容器間通信一般不受宿主機(jī)防火墻 影響但如果某些環(huán)境啟用了 docker 網(wǎng)橋規(guī)則就需要額外注意。把Last_IO_Error拿過來逐字讀是最重要的MySQL 在這條錯(cuò)誤信息里提供了非常明確的提示。5.3 SQL 線程報(bào)錯(cuò)主從數(shù)據(jù)不一致或 relay log 損壞現(xiàn)象Slave_SQL_RunningNoLast_SQL_Error里通常是 1062主鍵沖突或 1032記錄不存在。原因從庫上有人寫過數(shù)據(jù)或者主庫上某條 DDL/DML 在從庫執(zhí)行時(shí)因?yàn)楸斫Y(jié)構(gòu)差異失敗。處理方式如果數(shù)據(jù)不一致是測(cè)試環(huán)境可以直接重建復(fù)制鏈路。要最大程度保持從庫與原主庫一致需要在從庫上STOP SLAVE; RESET SLAVE ALL;然后重新 CHANGE MASTER TO。如果錯(cuò)誤已經(jīng)發(fā)生且不影響大局也可以跳過該事務(wù)執(zhí)行SET GLOBAL sql_slave_skip_counter 1;再START SLAVE;但這是應(yīng)急手段生產(chǎn)中不建議濫用。5.4 認(rèn)證插件導(dǎo)致復(fù)制失敗這是 8.0 特有的坑。如果主庫沒設(shè)置default_authentication_pluginmysql_native_password同時(shí)從庫的賬號(hào)使用了caching_sha2_password連接時(shí)有一定概率需要 RSA 加密傳輸公鑰環(huán)境復(fù)雜時(shí)就會(huì)出現(xiàn)類似Authentication plugin caching_sha2_password reported error: Authentication requires secure connection的報(bào)錯(cuò)。我在腳本里直接在主庫命令中植入mysql_native_password就是為了規(guī)避這層麻煩。如果你的業(yè)務(wù)環(huán)境強(qiáng)制要求caching_sha2_password那從庫做 CHANGE MASTER TO 時(shí)需要額外配置MASTER_SSL相關(guān)參數(shù)或者確保網(wǎng)絡(luò)傳輸本身是加密的。這個(gè)復(fù)雜度遠(yuǎn)高于用 native password所以我建議測(cè)試環(huán)境或內(nèi)部環(huán)境統(tǒng)一用 mysql_native_password。5.5 容器能啟動(dòng)但 mysql 命令報(bào)ERROR 2002 (HY000): Cant connect to local MySQL server through socket這個(gè)熱搜詞很多人搜到過。在 Docker 容器內(nèi)執(zhí)行mysql -uroot -p時(shí)默認(rèn)會(huì)嘗試連接/var/run/mysqld/mysqld.sock如果 socket 文件路徑不對(duì)就會(huì)報(bào)這個(gè)錯(cuò)。解決辦法是顯式指定 TCP 方式連接mysql -h127.0.0.1 -P3306 -uroot -p在批量腳本里尤其要注意凡是給mysql客戶端傳-h參數(shù)就不要再依賴 socket 連接。因?yàn)槿萜鲀?nèi)部不僅 MySQL socket 路徑與宿主機(jī)隔離而且你可能還需要連接其他容器的 MySQL那本身就只能走 TCP。5.6 磁盤空間不足InnoDB 初始化失敗這是批量啟動(dòng) 20 個(gè)容器后最常見的慢性病。剛開始一切正常跑幾輪數(shù)據(jù)寫入和刪除測(cè)試后宿主機(jī)磁盤被 binlog 吃滿。解決方案有兩個(gè)層面一是配置 MySQL 的 binlog 過期時(shí)間在容器啟動(dòng)命令中加--binlog_expire_logs_seconds86400讓超過一天的 binlog 自動(dòng)清理二是定時(shí)巡檢磁盤使用率尤其是 Docker 數(shù)據(jù)目錄。如果已經(jīng)出現(xiàn)InnoDB: Operating system error number 28立即清理懸空容器和未使用的鏡像刪除不必要的舊數(shù)據(jù)卷docker system df docker volume prune注意docker volume prune要小心它會(huì)刪掉所有未使用的 volume如果里面有舊數(shù)據(jù)想保留先做好確認(rèn)。6. 一點(diǎn)實(shí)操后的心得體會(huì)這套基于 Docker Compose 批量部署 10 套 MySQL 主從的方案我前后在兩個(gè)不同項(xiàng)目里驗(yàn)證過一個(gè)用于主從故障演練一個(gè)用于中間件的讀寫分離測(cè)試。我的體會(huì)是Docker Compose 的最大價(jià)值不是“生產(chǎn)環(huán)境高可用”而是讓你用最低的成本把復(fù)雜的復(fù)制拓?fù)鋸南敕ㄗ兂涩F(xiàn)實(shí)反復(fù)驗(yàn)證原理、排查問題、鍛煉操作手感。如果后續(xù)你還想繼續(xù)擴(kuò)展可以在同一套網(wǎng)絡(luò)架構(gòu)里加入 MHA 或 Orchestrator 容器做主庫自動(dòng)故障切換的演練也可以加一個(gè) ProxySQL 容器把 10 套集群的從庫都掛到同一個(gè)讀寫分離入口測(cè)試只讀負(fù)載均衡還可以在集群里故意制造延遲觀察Seconds_Behind_Master的波動(dòng)加深對(duì)半同步復(fù)制、異步復(fù)制差異的理解。最后分享一個(gè)小技巧批量場(chǎng)景下所有“一次性”的初始化操作都值得寫進(jìn)腳本里但所有“探索性”的排查操作都建議先在單套集群上手工跑通。別急于追求自動(dòng)化先把第一套集群的原理搞透再去批量化。我見過太多人直接拿別人腳本一把梭最后 20 個(gè)容器全都起來了卻根本不知道主從復(fù)制是怎么工作的出了問題連日志都不會(huì)看。這套東西上手快但真正值錢的是你對(duì)那三張線程表和幾個(gè)狀態(tài)字段的理解深度。