当前位置: 首页 > news >正文

数据库主从复制

Binlog(Binary Log)

Binlog(Binary Log)是 MySQL 数据库的核心日志之一,用于记录数据库的逻辑操作。简单来说,它像一台摄像机,忠实记录所有对数据库进行修改的 SQL 语句(如 INSERT/UPDATE/DELETE)或表结构变更(如 CREATE/ALTER)等操作。

核心特性

逻辑日志 

记录的是 SQL 语句的原始逻辑(例如:UPDATE users SET age=20 WHERE id=1;),而非底层数据页的物理修改细节(这是 redo log 的特性)。

持久化存储 

Binlog 以文件形式存储在磁盘中,不会随数据库重启而丢失,生命周期由配置决定(可长期保存)。

可追溯性 

通过解析 binlog 文件,可以精确还原数据库的历史变更过程。

核心用途

主从复制(Replication) 

主库将 binlog 发送给从库,从库重放这些日志以实现数据同步,是 MySQL 高可用架构的基础。

数据恢复 

当误删数据或数据库故障时,可通过 binlog + 定期备份实现时间点恢复(Point-in-Time Recovery)。

Binlog 格式(3种类型)

格式

特点

示例

STATEMENT

记录原始 SQL 语句

UPDATE orders SET create_time = NOW() WHERE status = 'unpaid';

ROW

记录每行数据的变化细节(如修改前后的整行数据

记录每行数据修改前后的完整值(例如:id=1 的用户 balance 从 500 → 400)

MIXED

混合模式,根据 SQL 语句自动选择 STATEMENT 或 ROW 格式

对于 INSERT INTO payments VALUES (UUID(), 100); MIXED 模式会自动切到 ROW 格式,避免主键冲突。

二、主从复制

是数据库系统中实现数据高可用、读写分离、负载均衡的核心技术。其核心思想是通过将主库(Master)的数据变更异步/同步复制到从库(Slave),使从库与主库保持数据一致。

核心原理
主库(Master)
  • 记录所有数据变更到 Binlog(二进制日志)
  • 通过 Binlog Dump 线程 向从库发送日志事件
从库(Slave)
  • I/O 线程:连接主库,接收 Binlog 并写入本地 Relay Log(中继日志)
  • SQL 线程:读取 Relay Log,重放 SQL 事件,实现数据同步

配置步骤(以 MySQL 为例)
1. 主库配置

# my.cnf
[mysqld]
server_id = 1               # 唯一ID
log_bin = mysql-bin         # 开启Binlog
binlog_format = ROW         # 推荐ROW模式
2. 创建复制账号
CREATE USER 'repl'@'%' IDENTIFIED BY 'your_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
3. 从库配置
# my.cnf
[mysqld]
server_id = 2               # 唯一ID,不能与主库冲突
relay_log = mysql-relay-bin # 开启Relay Log
read_only = ON              # 从库设为只读(防误操作)
4. 启动复制
-- 从库执行
CHANGE MASTER TOMASTER_HOST = '主库IP',MASTER_USER = 'repl',MASTER_PASSWORD = 'your_password',MASTER_LOG_FILE = 'mysql-bin.000001', -- 主库当前Binlog文件名MASTER_LOG_POS = 154;                 -- 主库当前Binlog位置START SLAVE;  -- 启动复制

三、GTID

GTID(全局事务标识符)是 MySQL 主从复制中用于唯一标识事务的机制,它解决了传统复制依赖 binlog 文件名和位置的痛点。

GTID 核心组成

每个 GTID 格式为: GTID = source_id:transaction_id

    • source_id:产生事务的服务器唯一标识(通常是 server_uuid)
    • transaction_id:事务序列号,单调递增(如 1-100 表示第1到第100个事务)

示例: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5 表示该事务来自 server_uuid 为 3E11FA47... 的服务器,事务序列号为1到5。

GTID 核心优势

传统复制痛点

GTID 解决方案

主从切换需手动指定 binlog 位置

自动追踪事务,无需关心文件位置

难以确定事务是否在所有从库执行

通过 GTID 集合全局唯一标识事务状态

级联复制拓扑管理复杂

事务路径清晰,支持任意拓扑结构

GTID 启用配置
修改 my.cnf
   [mysqld]gtid_mode = ON                 # 启用 GTIDenforce_gtid_consistency = ON  # 强制 GTID 一致性log_bin = mysql-bin            # 必须开启 binlogserver_id = 1                  # 服务器唯一 ID
重启 MySQL 生效
   systemctl restart mysqld

相关文章:

  • 解决Ubuntu终端命令不能补全的问题
  • Linux:解决 yum 官方源无法使用(CentOS 7)
  • postman使用技巧
  • Postman做自动化测试
  • opencv函数展示
  • 【数字图像处理】数字图像空间域增强(3)
  • WIFI扫描记录
  • Spark-SQL核心编程(二)(三)
  • LIB-ZC, 一个跨平台(Linux)平台通用C/C++扩展库, IO操作
  • 管理与维护samba服务器
  • 信创服务器-大国崛起,信创当道!
  • SpringBoot异常处理之自定义统一的错误处理页面
  • 大模型全景解析:从技术突破到行业变革
  • 专为路由器和嵌入式设备设计的OpenWrt是什么?
  • RabbitMQ架构原理及消息分发机制
  • STM32江科大----------PID算法
  • SpringBoot整合Redis限流
  • 数据中台进化史:从概念萌芽到价值变现的蜕变之路
  • 理解最左前缀原则:联合索引命中规则全解析(含流程图)
  • Flutter PIP 插件 ---- iOS Video Call 自定义PIP WINDOW渲染内容
  • 建设资格注册管理中心网站/百度搜索引擎优化怎么做
  • 网站建设最新技术/八戒
  • java程序员自己做网站/国内销售平台有哪些
  • node怎么做网站/百度客服人工服务电话
  • 宁波网站制作 收费标准/最近发生的新闻
  • 2023年文职招聘岗位表/浙江seo博客