利用Docker部署的基于binlog实现Mysql8

打印 上一主题 下一主题

主题 886|帖子 886|积分 2658

概念

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 的主从复制,主库发生故障时,必要手动或自动切换到从库。虽然从库可以保持主库的副本,但在主库故障时大概会丢失一定的事件,因此对高可用性的需求必要联合其他技能(如 MHAProxySQLGroup 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}}
  3. # 修改权限
  4. chmod -R 777 /opt/mysql-compose/{master1/{data,logs},slave1/{data,logs},slave2/{data,logs}}
  5. # 临时测试-删除持久化的数据
  6. rm -rf /opt/mysql-compose/{master1/{data/*,logs/*},slave1/{data/*,logs/*},slave2/{data/*,logs/*}}
  7. #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
  3. # 运行docker compose 容器服务
  4. docker compose up -d
  5. #停止docker compose 容器服务
  6. docker compose down
  7. #查看docker compose 容器服务状态
  8. 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;
  6. #2.配置从服务器连接到指定的主服务器(192.168.137.2),并设置复制的起始点。
  7. #功能: 设置从服务器的主服务器连接信息及复制位置。
  8. #作用: 配置从服务器如何连接到主服务器,以及从哪个二进制日志文件和位置开始复制。
  9. CHANGE MASTER TO
  10. MASTER_HOST='192.168.137.2',   # 指定主服务器的 IP 地址或主机名,表示从服务器将连接到这个主机
  11. MASTER_PORT=13306,             # 指定主服务器的端口号,通常 MySQL 的默认端口是 3306,根据实际情况修改
  12. MASTER_USER='root',            # 指定主服务器上用于连接的用户名,通常是具备复制权限的用户
  13. MASTER_PASSWORD='123456',      # 指定上述用户的密码,用于认证连接
  14. MASTER_LOG_FILE='binlog.000005',# 指定主服务器的二进制日志文件名,从该文件的指定位置开始复制数据。
  15. MASTER_LOG_POS=157; #指定从主服务器的二进制日志文件中从哪个位置开始复制。位置是一个数字,表示从该位置开始的日志条目
  16. #3.启动从服务器的复制进程。
  17. #功能: 启动从服务器的复制进程
  18. #作用: 在执行完 CHANGE MASTER TO 后,启动从服务器的复制任务,使得从服务器开始连接主服务器,并从指定的二进制日志文件位置开始复制数据。
  19. START SLAVE;
  20. #4.查看从服务器的复制状态。
  21. #功能: 显示从服务器的复制状态
  22. #作用: 查看从服务器的当前复制状态,包括是否成功连接到主服务器,复制是否正常进行,以及任何可能出现的错误。
  23. 该命令会返回一个包含多个字段的结果,常用的字段有 Slave_IO_Running 和 Slave_SQL_Running,这两者的值为yes,分别表示 I/O 线程和 SQL 线程是否正在运行,Last_Error 显示最后一个错误信息等。
  24. SHOW SLAVE STATUS;
复制代码
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

缠丝猫

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表