ToB企服应用市场:ToB评测及商务社交产业平台

标题: 利用Docker部署的基于binlog实现Mysql8 [打印本页]

---

作者: 缠丝猫    时间: 2025-1-9 15:54
标题: 利用Docker部署的基于binlog实现Mysql8
概念

MySQL 基于 Binlog 的主从复制（Master-Slave Replication）是 MySQL 数据库中实现数据复制的一种机制。在这种复制模式下，主库（Master）记录所有对数据库的修改操作（如 INSERT、UPDATE、DELETE 等）到 二进制日记（Binlog），从库（Slave）则读取这些日记并执行相同的操作，从而保持与主库的数据一致性。
1. 基本概念：

• 主库（Master）：所有的数据修改操作都在主库上执行，主库会将这些修改记录到 Binlog 中。
  
• 从库（Slave）：从库通过连接到主库，读取主库的 Binlog 并将其中的操作应用到本身的数据上，达到与主库一致的目标。
  

2. Binlog（二进制日记）

Binlog 是 MySQL 用来记录所有修改数据库的事件的日记文件，包括：

• 数据修改事件：比方 INSERT、UPDATE、DELETE 等。
  
• DDL 事件：比方 CREATE、ALTER 等操作。
  
• 日记文件：Binlog 是一个文件序列，每个文件都有一个唯一的名称。它是记录所有数据库更改的核心。
  

Binlog 存储的是操作日记而非数据本身，因此从库必要根据这些操作来更新本身的数据。
3. 工作流程：

基于 Binlog 的复制模式大抵可以分为以下几个步骤：
1. 主库记录 Binlog

• 在主库中执行任何更改操作时，这些操作会被记录到主库的 Binlog 文件中。
  
• 这些操作是顺序记录的，并按时间顺序分列。
  

2. 从库连接主库

• 从库通过连接主库来获取 Binlog 数据。这个连接通过 IO 线程 来实现，从库会定期向主库哀求新的 Binlog 事件。
  
• 从库会记录主库当前的 Binlog 位置，并哀求从该位置开始同步数据。
  

3. 从库读取 Binlog

• 从库的 IO 线程从主库获取到最新的 Binlog 事件，并将这些事件存储到从库的本地 Binlog 文件中。
  

4. 从库执行 Binlog 事件

• 从库的 SQL 线程 会读取本地存储的 Binlog，并根据日记中的操作来执行相应的 SQL 语句。这样，从库就能够与主库的数据保持一致。
  

5. 保持同步

• 主库和从库通过 Binlog 的持续同步保持一致。每次主库有新的数据更新时，这些更新会通过 Binlog 被传播到从库。
  

4. 主从复制的关键组件：

• Binlog（Binary Log）：记录所有更改数据的操作，主库通过 Binlog 来传递更改的内容。
  
• I/O 线程：从库的 I/O 线程负责从主库读取 Binlog 事件，并将其写入到从库的本地 Binlog 中。
  
• SQL 线程：从库的 SQL 线程负责读取本地 Binlog，执行其中的操作，使从库的数据保持同步。
  

5. 复制模式的类型：

基于 Binlog 的主从复制可以分为不同的复制模式，主要有以下几种：

• 异步复制：
  
  
  
  • 在这种模式下，主库执行操作后，不等候从库确认即返回。主库不会等候从库是否已经同步完数据。
    
  • 优点：性能高，不会因为等候从库确认而增加延迟。
    
  • 缺点：假如主库故障，大概会丢失未同步的数据。
    
  
  
• 半同步复制（Semi-Synchronous Replication）：
  
  
  
  • 在这种模式下，主库在执行操作后，至少等候一个从库确认已接收数据并写入本地 Binlog 后才返回。这比完全异步复制稍微安全一些，但仍然存在延迟。
    
  • 优点：比异步复制更安全，至少一个从库能够确认同步。
    
  • 缺点：会增加一定的延迟，大概影响性能。
    
  
  
• 全同步复制（Synchronous Replication）：
  
  
  
  • 在这种模式下，主库在执行操作后，必须等候所有从库确认数据已经同步才会返回。
    
  • 优点：可以包管主库和所有从库的数据完全一致。
    
  • 缺点：性能开销大，延迟较高，且必要更多的资源。
    
  
  

6. 复制延迟与容错性：

• 复制延迟：由于主库和从库是异步同步的，因此在高并发的场景中，从库大概会出现延迟，导致主库和从库的数据不一致。这种延迟通常是由于从库处理速率较慢，或者网络问题等原因导致。
  
• 容错性：基于 Binlog 的主从复制，主库发生故障时，必要手动或自动切换到从库。虽然从库可以保持主库的副本，但在主库故障时大概会丢失一定的事件，因此对高可用性的需求必要联合其他技能（如 MHA、ProxySQL、Group Replication 等）来提高容错性。
  

7. 优缺点：

优点：

• 简洁性：基于 Binlog 的复制设置较为简单，容易理解和实现。
  
• 性能：相比于 GTID 复制模式，Binlog 复制模式的性能开销较小。
  
• 兼容性强：Binlog 复制是 MySQL 的标准复制方式，几乎所有版本都支持。
  
• 适用广泛：适用于大多数必要主从同步的场景，特别是读写分离和负载均衡。
  

缺点：

• 故障规复较慢：假如主库发生故障，大概必要人工干预来规复主从复制关系，且在切换过程中大概会丢失未同步的数据。
  
• 大概出现数据不一致：在网络延迟或复制延迟较大的情况下，主从数据大概临时不一致。
  
• 复制延迟：高负载时，主从复制大概存在延迟，导致从库的数据滞后于主库。
  

总结：

基于 Binlog 的主从复制是 MySQL 中实现数据复制的常见方式，它通过记录主库的二进制日记，并将日记同步到从库，从而保持数据一致性。这种方式在大多数应用中运行稳定、性能良好，但必要留意故障规复、复制延迟等问题，适用于高可用架构中举行读写分离、负载均衡等场景。
binlog二进制日记文件记录了主服务器上所有数据库的更改操作
实操，一个主库两个从库之间举行主从复制

参考：https://blog.csdn.net/2401_85648342/article/details/139765433
数据长期化管理-路径规划

1. .
2. ├── docker-compose.yml
3. ├── master1
4. │   ├── conf
5. │   ├── data
6. │   └── logs
7. ├── slave1
8. │   ├── conf
9. │   ├── data
10. │   └── logs
11. └── slave2
12.     ├── conf
13.     ├── data
14.     └── logs

复制代码

创建相关文件夹

1. # 创建持久化目录
2. mkdir -p /opt/mysql-compose/{master1/{data,logs,conf},slave1/{data,logs,conf},slave2/{data,logs,conf}}
4. # 修改权限
5. chmod -R 777 /opt/mysql-compose/{master1/{data,logs},slave1/{data,logs},slave2/{data,logs}}
7. # 临时测试-删除持久化的数据
8. rm -rf /opt/mysql-compose/{master1/{data/*,logs/*},slave1/{data/*,logs/*},slave2/{data/*,logs/*}}
10. #rm -rf /opt/mysql-compose/{master1/data/*,slave1/data/*,slave2/data/*}

复制代码

分别上传配置文件(my.cnf)至 conf 目录下

master1配置文件my.cnf如下

1. [mysqld]
2. # 服务器唯一id，默认值1
3. server-id=11
4. # 设置日志格式，默认值ROW
5. binlog_format=STATEMENT
6. # 二进制日志名，默认binlog
7. # log-bin=binlog
8. # 设置需要复制的数据库，默认复制全部数据库
9. binlog-do-db=testdb
10. # 设置不需要复制的数据库
11. #binlog-ignore-db=mysql
12. #binlog-ignore-db=infomation_schema
13. #binlog-ignore-db=sys
14. #binlog-ignore-db=performance_schema

复制代码

slave1配置文件my.cnf如下

1. # 服务器唯一id，每台服务器的id必须不同，如果配置其他从机，注意修改id
2. server-id=12
3. # 中继日志名，默认xxxxxxxxxxxx-relay-bin
4. #relay-log=relay-bin

复制代码

slave2配置文件my.cnf如下

1. # 服务器唯一id，每台服务器的id必须不同，如果配置其他从机，注意修改id
2. server-id=13
3. # 中继日志名，默认xxxxxxxxxxxx-relay-bin
4. #relay-log=relay-bin

复制代码

docker-compose.yml内容如下

1. #version: "3.5"
2. services:
3.     #mysql:
4.     #    image: registry.cn-shenzhen.aliyuncs.com/multiway/mysql:8.0.29
5.     #    container_name: mysql8
6.     #    ports:
7.     #      - "13306:3306"
8.     #    restart: always
9.     #    environment:
10.     #      - MYSQL_ROOT_PASSWORD=123456
11.     #      - TZ=Asia/Shanghai
12.     #    volumes:
13.     #      - /opt/mysql-compose/master1/conf:/etc/mysql/conf.d
14.     #      - /opt/mysql-compose/master1/logs:/var/log/mysql
15.     #      - /opt/mysql-compose/master1/data:/var/lib/mysql
16.     mysql_master1:
17.         image: registry.cn-shenzhen.aliyuncs.com/multiway/mysql:8.0.29
18.         container_name: mysql_master1
19.         ports:
20.           - "13306:3306"
21.         restart: always
22.         environment:
23.           - MYSQL_ROOT_PASSWORD=123456
24.           - TZ=Asia/Shanghai
25.         volumes:
26.           - ./master1/mysql:/etc/mysql
27.           - ./master1/logs:/var/log/mysql
28.           - ./master1/data:/var/lib/mysql
29.     mysql_slave1:
30.         image: registry.cn-shenzhen.aliyuncs.com/multiway/mysql:8.0.29
31.         container_name: mysql_slave1
32.         ports:
33.           - "13307:3306"
34.         restart: always
35.         environment:
36.           - MYSQL_ROOT_PASSWORD=123456
37.           - TZ=Asia/Shanghai
38.         volumes:
39.           - ./slave1/mysql:/etc/mysql
40.           - ./slave1/logs:/var/log/mysql
41.           - ./slave1/data:/var/lib/mysql
42.     mysql_slave2:
43.         image: registry.cn-shenzhen.aliyuncs.com/multiway/mysql:8.0.29
44.         container_name: mysql_slave2
45.         ports:
46.           - "13308:3306"
47.         restart: always
48.         environment:
49.           - MYSQL_ROOT_PASSWORD=123456
50.           - TZ=Asia/Shanghai
51.         volumes:
52.           - ./slave2/mysql:/etc/mysql
53.           - ./slave2/logs:/var/log/mysql
54.           - ./slave2/data:/var/lib/mysql
55.    
56.    

复制代码

留意：/var/lib/mysql/auto.cnf文件中的server-uuid是 MySQL 数据库服务器的唯一标识符（UUID）。这个标识符用于标识 MySQL 实例，尤其在复制（Replication）设置中，它可以帮助区分不同的数据库实例。在 MySQL 中，/var/lib/mysql/auto.cnf 是一个自动生成的配置文件，通常包含 MySQL 实例的 UUID 信息。你可以通过这个文件来查看 MySQL 服务器的 UUID。它是在 MySQL 启动时自动生成的，并且通常不必要手动修改。假如docker-compose挂载本地目录已有挂载数据请查抄，假如有重复的修改server-uuid或者删除这个auto.cnf文件之后重启mysql服务

1. [auto]
2. server-uuid=bc8c658e-ce63-11ef-89ae-0242ac130004

复制代码

运行docker-compose命令启动服务

1. # 进入docker-compose.yml的所在层级文件夹
2. cd /opt/mysql-compose
4. # 运行docker compose 容器服务
5. docker compose up -d
7. #停止docker compose 容器服务
8. docker compose down
10. #查看docker compose 容器服务状态
11. docker compose ps

复制代码

利用数据库管理工具连接主库和从库数据库

查看主库状态，连接master1数据库执行下面sql语句

1. SHOW MASTER STATUS;

复制代码

查看结果

FilePositionBinlog_Do_DBBinlog_Ignore_DBExecuted_Gtid_Setbinlog.000005157testdb

留意：假如是指定的数据库比如testdb的话，先在主数据库master1创建数据库，并创建表添加数据后，导出脚本，然后从库slave1和slave2也要创建数据库testdb导入执行sql脚本,使主从库数据一致，执行主从复制操作之前停止其他服务对主库的读写操作，否则会造成数据丢失等问题；简单来说在主从复制操作开始之前包管主从数据库数据一致

分别连接slave1和slave2数据库执行下面sql语句,设置或修复 MySQL 的主从复制关系

1. #1.重置从服务器的复制设置。
2. #功能: 清除当前从服务器的所有复制设置
3. #作用: 重置从服务器的复制状态，包括清除 MASTER_* 配置、复制相关的文件、状态标记等。如果之前从服务器已经在运行复制任务，执行这个命令会停止复制进程并清除复制的所有状态信息。
4. #使用场景: 这通常在配置新的复制关系，或者需要重新设置复制时使用。
5. RESET SLAVE;
7. #2.配置从服务器连接到指定的主服务器（192.168.137.2），并设置复制的起始点。
8. #功能: 设置从服务器的主服务器连接信息及复制位置。
9. #作用: 配置从服务器如何连接到主服务器，以及从哪个二进制日志文件和位置开始复制。
11. CHANGE MASTER TO
12. MASTER_HOST='192.168.137.2',   # 指定主服务器的 IP 地址或主机名，表示从服务器将连接到这个主机
13. MASTER_PORT=13306,             # 指定主服务器的端口号，通常 MySQL 的默认端口是 3306，根据实际情况修改
14. MASTER_USER='root',            # 指定主服务器上用于连接的用户名，通常是具备复制权限的用户
15. MASTER_PASSWORD='123456',      # 指定上述用户的密码，用于认证连接
16. MASTER_LOG_FILE='binlog.000005',# 指定主服务器的二进制日志文件名，从该文件的指定位置开始复制数据。
17. MASTER_LOG_POS=157; #指定从主服务器的二进制日志文件中从哪个位置开始复制。位置是一个数字，表示从该位置开始的日志条目
19. #3.启动从服务器的复制进程。
20. #功能: 启动从服务器的复制进程
21. #作用: 在执行完 CHANGE MASTER TO 后，启动从服务器的复制任务，使得从服务器开始连接主服务器，并从指定的二进制日志文件位置开始复制数据。
23. START SLAVE;
25. #4.查看从服务器的复制状态。
26. #功能: 显示从服务器的复制状态
27. #作用: 查看从服务器的当前复制状态，包括是否成功连接到主服务器，复制是否正常进行，以及任何可能出现的错误。
28. 该命令会返回一个包含多个字段的结果，常用的字段有 Slave_IO_Running 和 Slave_SQL_Running，这两者的值为yes，分别表示 I/O 线程和 SQL 线程是否正在运行，Last_Error 显示最后一个错误信息等。
30. SHOW SLAVE STATUS;

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4