使用Docker部署的基于binlog實現(xiàn)Mysql8的操作方法
概念
MySQL 基于 Binlog 的主從復制(Master-Slave Replication)是 MySQL 數(shù)據(jù)庫中實現(xiàn)數(shù)據(jù)復制的一種機制。在這種復制模式下,主庫(Master)記錄所有對數(shù)據(jù)庫的修改操作(如 INSERT、UPDATE、DELETE 等)到 二進制日志(Binlog),從庫(Slave)則讀取這些日志并執(zhí)行相同的操作,從而保持與主庫的數(shù)據(jù)一致性。
1. 基本概念:
- 主庫(Master):所有的數(shù)據(jù)修改操作都在主庫上執(zhí)行,主庫會將這些修改記錄到 Binlog 中。
- 從庫(Slave):從庫通過連接到主庫,讀取主庫的 Binlog 并將其中的操作應用到自己的數(shù)據(jù)上,達到與主庫一致的目的。
2. Binlog(二進制日志)
Binlog 是 MySQL 用來記錄所有修改數(shù)據(jù)庫的事件的日志文件,包括:
- 數(shù)據(jù)修改事件:例如 INSERT、UPDATE、DELETE 等。
- DDL 事件:例如 CREATE、ALTER 等操作。
- 日志文件:Binlog 是一個文件序列,每個文件都有一個唯一的名稱。它是記錄所有數(shù)據(jù)庫更改的核心。
Binlog 存儲的是操作日志而非數(shù)據(jù)本身,因此從庫需要根據(jù)這些操作來更新自己的數(shù)據(jù)。
3. 工作流程:
基于 Binlog 的復制模式大致可以分為以下幾個步驟:
1. 主庫記錄 Binlog
- 在主庫中執(zhí)行任何更改操作時,這些操作會被記錄到主庫的 Binlog 文件中。
- 這些操作是順序記錄的,并按時間順序排列。
2. 從庫連接主庫
- 從庫通過連接主庫來獲取 Binlog 數(shù)據(jù)。這個連接通過 IO 線程 來實現(xiàn),從庫會定期向主庫請求新的 Binlog 事件。
- 從庫會記錄主庫當前的 Binlog 位置,并請求從該位置開始同步數(shù)據(jù)。
3. 從庫讀取 Binlog
- 從庫的 IO 線程從主庫獲取到最新的 Binlog 事件,并將這些事件存儲到從庫的本地 Binlog 文件中。
4. 從庫執(zhí)行 Binlog 事件
- 從庫的 SQL 線程 會讀取本地存儲的 Binlog,并根據(jù)日志中的操作來執(zhí)行相應的 SQL 語句。這樣,從庫就能夠與主庫的數(shù)據(jù)保持一致。
5. 保持同步
- 主庫和從庫通過 Binlog 的持續(xù)同步保持一致。每次主庫有新的數(shù)據(jù)更新時,這些更新會通過 Binlog 被傳播到從庫。
4. 主從復制的關鍵組件:
- Binlog(Binary Log):記錄所有更改數(shù)據(jù)的操作,主庫通過 Binlog 來傳遞更改的內(nèi)容。
- I/O 線程:從庫的 I/O 線程負責從主庫讀取 Binlog 事件,并將其寫入到從庫的本地 Binlog 中。
- SQL 線程:從庫的 SQL 線程負責讀取本地 Binlog,執(zhí)行其中的操作,使從庫的數(shù)據(jù)保持同步。
5. 復制模式的類型:
基于 Binlog 的主從復制可以分為不同的復制模式,主要有以下幾種:
異步復制:
- 在這種模式下,主庫執(zhí)行操作后,不等待從庫確認即返回。主庫不會等待從庫是否已經(jīng)同步完數(shù)據(jù)。
- 優(yōu)點:性能高,不會因為等待從庫確認而增加延遲。
- 缺點:如果主庫故障,可能會丟失未同步的數(shù)據(jù)。
半同步復制(Semi-Synchronous Replication):
- 在這種模式下,主庫在執(zhí)行操作后,至少等待一個從庫確認已接收數(shù)據(jù)并寫入本地 Binlog 后才返回。這比完全異步復制稍微安全一些,但仍然存在延遲。
- 優(yōu)點:比異步復制更安全,至少一個從庫能夠確認同步。
- 缺點:會增加一定的延遲,可能影響性能。
全同步復制(Synchronous Replication):
- 在這種模式下,主庫在執(zhí)行操作后,必須等待所有從庫確認數(shù)據(jù)已經(jīng)同步才會返回。
- 優(yōu)點:可以保證主庫和所有從庫的數(shù)據(jù)完全一致。
- 缺點:性能開銷大,延遲較高,且需要更多的資源。
6. 復制延遲與容錯性:
復制延遲:由于主庫和從庫是異步同步的,因此在高并發(fā)的場景中,從庫可能會出現(xiàn)延遲,導致主庫和從庫的數(shù)據(jù)不一致。這種延遲通常是由于從庫處理速度較慢,或者網(wǎng)絡問題等原因?qū)е隆?/p>
容錯性:基于 Binlog 的主從復制,主庫發(fā)生故障時,需要手動或自動切換到從庫。雖然從庫可以保持主庫的副本,但在主庫故障時可能會丟失一定的事務,因此對高可用性的需求需要結合其他技術(如 MHA、ProxySQL、Group Replication 等)來提高容錯性。
7. 優(yōu)缺點:
優(yōu)點:
- 簡潔性:基于 Binlog 的復制設置較為簡單,容易理解和實現(xiàn)。
- 性能:相比于 GTID 復制模式,Binlog 復制模式的性能開銷較小。
- 兼容性強:Binlog 復制是 MySQL 的標準復制方式,幾乎所有版本都支持。
- 適用廣泛:適用于大多數(shù)需要主從同步的場景,特別是讀寫分離和負載均衡。
缺點:
- 故障恢復較慢:如果主庫發(fā)生故障,可能需要人工干預來恢復主從復制關系,且在切換過程中可能會丟失未同步的數(shù)據(jù)。
- 可能出現(xiàn)數(shù)據(jù)不一致:在網(wǎng)絡延遲或復制延遲較大的情況下,主從數(shù)據(jù)可能暫時不一致。
- 復制延遲:高負載時,主從復制可能存在延遲,導致從庫的數(shù)據(jù)滯后于主庫。
總結:
基于 Binlog 的主從復制是 MySQL 中實現(xiàn)數(shù)據(jù)復制的常見方式,它通過記錄主庫的二進制日志,并將日志同步到從庫,從而保持數(shù)據(jù)一致性。這種方式在大多數(shù)應用中運行穩(wěn)定、性能良好,但需要注意故障恢復、復制延遲等問題,適用于高可用架構中進行讀寫分離、負載均衡等場景。
binlog二進制日志文件記錄了主服務器上所有數(shù)據(jù)庫的更改操作
實操,一個主庫兩個從庫之間進行主從復制
參考:https://blog.csdn.net/2401_85648342/article/details/139765433
數(shù)據(jù)持久化管理-路徑規(guī)劃
. ├── docker-compose.yml ├── master1 │ ├── conf │ ├── data │ └── logs ├── slave1 │ ├── conf │ ├── data │ └── logs └── slave2 ├── conf ├── data └── logs
創(chuàng)建相關文件夾
# 創(chuàng)建持久化目錄 mkdir -p /opt/mysql-compose/{master1/{data,logs,conf},slave1/{data,logs,conf},slave2/{data,logs,conf}} # 修改權限 chmod -R 777 /opt/mysql-compose/{master1/{data,logs},slave1/{data,logs},slave2/{data,logs}} # 臨時測試-刪除持久化的數(shù)據(jù) rm -rf /opt/mysql-compose/{master1/{data/*,logs/*},slave1/{data/*,logs/*},slave2/{data/*,logs/*}} #rm -rf /opt/mysql-compose/{master1/data/*,slave1/data/*,slave2/data/*}
分別上傳配置文件(my.cnf)至 conf 目錄下
master1配置文件my.cnf如下
[mysqld] # 服務器唯一id,默認值1 server-id=11 # 設置日志格式,默認值ROW binlog_format=STATEMENT # 二進制日志名,默認binlog # log-bin=binlog # 設置需要復制的數(shù)據(jù)庫,默認復制全部數(shù)據(jù)庫 binlog-do-db=testdb # 設置不需要復制的數(shù)據(jù)庫 #binlog-ignore-db=mysql #binlog-ignore-db=infomation_schema #binlog-ignore-db=sys #binlog-ignore-db=performance_schema
slave1配置文件my.cnf如下
# 服務器唯一id,每臺服務器的id必須不同,如果配置其他從機,注意修改id server-id=12 # 中繼日志名,默認xxxxxxxxxxxx-relay-bin #relay-log=relay-bin
slave2配置文件my.cnf如下
# 服務器唯一id,每臺服務器的id必須不同,如果配置其他從機,注意修改id server-id=13 # 中繼日志名,默認xxxxxxxxxxxx-relay-bin #relay-log=relay-bin
docker-compose.yml內(nèi)容如下
#version: "3.5" services: #mysql: # image: registry.cn-shenzhen.aliyuncs.com/multiway/mysql:8.0.29 # container_name: mysql8 # ports: # - "13306:3306" # restart: always # environment: # - MYSQL_ROOT_PASSWORD=123456 # - TZ=Asia/Shanghai # volumes: # - /opt/mysql-compose/master1/conf:/etc/mysql/conf.d # - /opt/mysql-compose/master1/logs:/var/log/mysql # - /opt/mysql-compose/master1/data:/var/lib/mysql mysql_master1: image: registry.cn-shenzhen.aliyuncs.com/multiway/mysql:8.0.29 container_name: mysql_master1 ports: - "13306:3306" restart: always environment: - MYSQL_ROOT_PASSWORD=123456 - TZ=Asia/Shanghai volumes: - ./master1/mysql:/etc/mysql - ./master1/logs:/var/log/mysql - ./master1/data:/var/lib/mysql mysql_slave1: image: registry.cn-shenzhen.aliyuncs.com/multiway/mysql:8.0.29 container_name: mysql_slave1 ports: - "13307:3306" restart: always environment: - MYSQL_ROOT_PASSWORD=123456 - TZ=Asia/Shanghai volumes: - ./slave1/mysql:/etc/mysql - ./slave1/logs:/var/log/mysql - ./slave1/data:/var/lib/mysql mysql_slave2: image: registry.cn-shenzhen.aliyuncs.com/multiway/mysql:8.0.29 container_name: mysql_slave2 ports: - "13308:3306" restart: always environment: - MYSQL_ROOT_PASSWORD=123456 - TZ=Asia/Shanghai volumes: - ./slave2/mysql:/etc/mysql - ./slave2/logs:/var/log/mysql - ./slave2/data:/var/lib/mysql
注意:/var/lib/mysql/auto.cnf文件中的server-uuid是 MySQL 數(shù)據(jù)庫服務器的唯一標識符(UUID)。這個標識符用于標識 MySQL 實例,尤其在復制(Replication)設置中,它可以幫助區(qū)分不同的數(shù)據(jù)庫實例。在 MySQL 中,/var/lib/mysql/auto.cnf 是一個自動生成的配置文件,通常包含 MySQL 實例的 UUID 信息。你可以通過這個文件來查看 MySQL 服務器的 UUID。它是在 MySQL 啟動時自動生成的,并且通常不需要手動修改。如果docker-compose掛載本地目錄已有掛載數(shù)據(jù)請檢查,如果有重復的修改server-uuid或者刪除這個auto.cnf文件之后重啟mysql服務
[auto] server-uuid=bc8c658e-ce63-11ef-89ae-0242ac130004
運行docker-compose命令啟動服務
# 進入docker-compose.yml的所在層級文件夾 cd /opt/mysql-compose # 運行docker compose 容器服務 docker compose up -d #停止docker compose 容器服務 docker compose down #查看docker compose 容器服務狀態(tài) docker compose ps
使用數(shù)據(jù)庫管理工具連接主庫和從庫數(shù)據(jù)庫
查看主庫狀態(tài),連接master1數(shù)據(jù)庫執(zhí)行下面sql語句
SHOW MASTER STATUS;
查看結果
File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
---|---|---|---|---|
binlog.000005 | 157 | testdb |
注意:如果是指定的數(shù)據(jù)庫比如testdb的話,先在主數(shù)據(jù)庫master1創(chuàng)建數(shù)據(jù)庫,并創(chuàng)建表添加數(shù)據(jù)后,導出腳本,然后從庫slave1和slave2也要創(chuàng)建數(shù)據(jù)庫testdb導入執(zhí)行sql腳本,使主從庫數(shù)據(jù)一致,執(zhí)行主從復制操作之前停止其他服務對主庫的讀寫操作,不然會造成數(shù)據(jù)丟失等問題;簡單來說在主從復制操作開始之前保證主從數(shù)據(jù)庫數(shù)據(jù)一致
分別連接slave1和slave2數(shù)據(jù)庫執(zhí)行下面sql語句,設置或修復 MySQL 的主從復制關系
#1.重置從服務器的復制設置。 #功能: 清除當前從服務器的所有復制設置 #作用: 重置從服務器的復制狀態(tài),包括清除 MASTER_* 配置、復制相關的文件、狀態(tài)標記等。如果之前從服務器已經(jīng)在運行復制任務,執(zhí)行這個命令會停止復制進程并清除復制的所有狀態(tài)信息。 #使用場景: 這通常在配置新的復制關系,或者需要重新設置復制時使用。 RESET SLAVE; #2.配置從服務器連接到指定的主服務器(192.168.137.2),并設置復制的起始點。 #功能: 設置從服務器的主服務器連接信息及復制位置。 #作用: 配置從服務器如何連接到主服務器,以及從哪個二進制日志文件和位置開始復制。 CHANGE MASTER TO MASTER_HOST='192.168.137.2', # 指定主服務器的 IP 地址或主機名,表示從服務器將連接到這個主機 MASTER_PORT=13306, # 指定主服務器的端口號,通常 MySQL 的默認端口是 3306,根據(jù)實際情況修改 MASTER_USER='root', # 指定主服務器上用于連接的用戶名,通常是具備復制權限的用戶 MASTER_PASSWORD='123456', # 指定上述用戶的密碼,用于認證連接 MASTER_LOG_FILE='binlog.000005',# 指定主服務器的二進制日志文件名,從該文件的指定位置開始復制數(shù)據(jù)。 MASTER_LOG_POS=157; #指定從主服務器的二進制日志文件中從哪個位置開始復制。位置是一個數(shù)字,表示從該位置開始的日志條目 #3.啟動從服務器的復制進程。 #功能: 啟動從服務器的復制進程 #作用: 在執(zhí)行完 CHANGE MASTER TO 后,啟動從服務器的復制任務,使得從服務器開始連接主服務器,并從指定的二進制日志文件位置開始復制數(shù)據(jù)。 START SLAVE; #4.查看從服務器的復制狀態(tài)。 #功能: 顯示從服務器的復制狀態(tài) #作用: 查看從服務器的當前復制狀態(tài),包括是否成功連接到主服務器,復制是否正常進行,以及任何可能出現(xiàn)的錯誤。 該命令會返回一個包含多個字段的結果,常用的字段有 Slave_IO_Running 和 Slave_SQL_Running,這兩者的值為yes,分別表示 I/O 線程和 SQL 線程是否正在運行,Last_Error 顯示最后一個錯誤信息等。 SHOW SLAVE STATUS;
到此這篇關于使用Docker部署的基于binlog實現(xiàn)Mysql8的文章就介紹到這了,更多相關使用Docker部署的基于binlog實現(xiàn)Mysql8內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
利用Dockerfile制作java運行環(huán)境的鏡像的方法步驟
這篇文章主要介紹了利用Dockerfile制作java運行環(huán)境的鏡像的方法步驟,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2018-11-11docker-compose部署coredns如何實現(xiàn)自建DNS服務
本文介紹了如何在內(nèi)網(wǎng)中使用自建的CoreDNS服務進行域名解析,通過配置Corefile和hosts文件,實現(xiàn)內(nèi)部域名解析,無需在互聯(lián)網(wǎng)上注冊域名,使用docker-compose運行CoreDNS,并通過修改resolv.conf文件配置DNS服務2025-01-01