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