主从复制

序 号 日志名称 解释说明 01 general_log 表示查询日志（通用日志），默认日志状态处于关闭，可以进行在线调整配置 作用：记录了客户端从会话连接开始，执行过的所有SQL语句信息； 02 1 log_error 表示错误日志（运行日志），默认日志状态处于激活 作用：记录了数据库服务启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息； 03 1 log_bin 表示二进制日志（binlog日志），默认日志状态处于激活（8.0之后） 作用：记录了所有的DDL语句和DML语句，但是不包括数据库查询语句；语句以事件的形式保存，描述了数据的更改过程，此日志对于灾难时的数据恢复起着极其 重要的作用。 04 slow_quer y_log 表示慢查询日志，记录了所有执行时间超过参数long_quer y_time设置值并且扫描记录数小于min_examined_row_limit的所有SQL语句的日志。 基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.11 数据库服务日志管理 1.11.1 数据库服务日志概述介绍 任何一种数据库中，都会有各种各样的日志，记录这数据库工作的方方面面，以帮助数据库管理员追踪数据库曾经发生过的各种事件； 主要是针对数据库ser ver层产生的数据信息，主要用于记录和数据库服务运行本身有关的日志、以及SQL语句操作执行相关的日志； 1.11.2 数据库服务日志常用分类 在MySQL数据库服务中，有4种不同的日志是最常用的日志类型，这些日志记录这数据库在不同方面的踪迹； 日志信息查看方法： 常用日志信息介绍： 1.11.3 数据库服务日志信息配置 分类日志信息配置：通用日志（general_log） 01 日志信息基本配置： 1 2 3 4 5 6 7 8 9 10 11 12 13 mysql> show variables like '%log%'; +------------------------------------------------+---------------------------------------------+ | Variable_name | Value | +------------------------------------------------+---------------------------------------------+ | general_log | OFF | | general_log_file | /data/3306/data/xiaoQ-01.log | | log_error | ./xiaoQ-01.edu.err | | log_bin | ON | | log_bin_basename | /data/3306/data/binlog | | log_bin_index | /data/3306/data/binlog.index | | slow_quer y_log | OFF | | slow_quer y_log_file | /data/3306/data/xiaoQ-01-slow.log | +------------------------------------------------+---------------------------------------------+ 说明：企业真实环境，由于日志记录量比较大，所以不建议打开此日志记录功能，可以在有需要时打开，支持在线配置调整； ...

前言 主从延迟是 MySQL 高可用架构中最高频的问题之一。很多人对延迟的理解停留在"大事务导致延迟"这个层面，遇到问题时无从下手。本文从复制链路的两个阶段出发——IO 线程和 SQL 线程——分别梳理常见延迟原因，并结合真实案例深入分析原理。 一、主从复制链路简述 理解延迟，先要清楚复制的完整链路： 主库写入事务 ↓ 主库 Dump 线程：读取 binlog 发送给从库 ↓ （网络传输） 从库 IO 线程：接收 binlog，写入 relay log ↓ 从库 SQL 线程（或并行 Worker）：读取 relay log，回放事务 ↓ 从库数据与主库一致 延迟分两类： IO 延迟：从库 IO 线程落后于主库，relay log 还没接收完整 SQL 延迟：relay log 已收到，但 SQL 线程回放跟不上 用 SHOW SLAVE STATUS\G 区分： 1 2 3 4 5 6 7 8 SHOW SLAVE STATUS\G -- 判断是 IO 延迟还是 SQL 延迟： -- Master_Log_File / Read_Master_Log_Pos → IO 线程已读到的位置 -- Relay_Master_Log_File / Exec_Master_Log_Pos → SQL 线程已执行的位置 -- 如果 Read_Master_Log_Pos 远落后于主库最新位置 → IO 延迟 -- 如果 Read_Master_Log_Pos 接近主库，但 Exec_Master_Log_Pos 落后 → SQL 延迟 二、IO 线程延迟的常见原因 原因 1：网络带宽不足 原理： ...

前言 在 MySQL 备份实践中，mysqldump --single-transaction --master-data=2 是最常见的组合。但很多 DBA 只知道"这样用不锁表"，却不清楚底层原理。今天我们深入剖析这两个参数的工作机制，以及为什么它们必须配合使用。 一、MVCC 可见性规则（理论基础） 在理解 --single-transaction 之前，必须先掌握 InnoDB 的 MVCC 机制。 1.1 Read View 结构 当事务执行 START TRANSACTION WITH CONSISTENT SNAPSHOT 时，InnoDB 会创建一个 Read View： 1 2 3 4 5 6 7 struct read_view_t { trx_id_t m_low_limit_id; // 系统中尚未分配的最小事务ID（当前最大事务ID + 1） trx_id_t m_up_limit_id; // 活跃事务列表中的最小事务ID trx_id_t m_creator_trx_id; // 创建此 Read View 的事务ID trx_id_t *m_ids; // 创建 Read View 时的活跃事务ID数组（降序） ulint m_n_trx_ids; // 活跃事务数量 }; 注意：InnoDB 的命名反直觉 m_low_limit_id 虽然叫 “low limit”，但实际是最大值（下一个要分配的事务ID） m_up_limit_id 虽然叫 “up limit”，但实际是最小值（最小活跃事务ID） 1.2 可见性判断规则 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 def is_visible(row_trx_id, read_view): # 规则1：如果是当前事务自己修改的，可见 if row_trx_id == read_view.m_creator_trx_id: return True # 规则2：如果行的事务ID < m_up_limit_id（最小活跃事务ID），说明在 Read View 创建前已提交，可见 if row_trx_id < read_view.m_up_limit_id: return True # 规则3：如果行的事务ID >= m_low_limit_id（下一个要分配的ID），说明在 Read View 创建后才开始，不可见 if row_trx_id >= read_view.m_low_limit_id: return False # 规则4：如果在 [m_up_limit_id, m_low_limit_id) 区间内 # 需要检查是否在活跃事务列表 m_ids 中 if row_trx_id in read_view.m_ids: return False # 在活跃列表中，说明创建 Read View 时未提交，不可见 else: return True # 不在活跃列表中，说明已提交，可见 可见性判断示例： ...

一、如何评估并行复制能力是否需要调整？ 1.1 核心思路 MySQL 并行复制（MTS，Multi-Threaded Slave）的并行粒度由 last_committed 决定： last_committed 相同的事务，可以并行回放 sequence_number 是事务的全局递增序号 1.2 解析 binlog 查看并行度 1 2 # 解析 binlog，查看 last_committed 和 sequence_number mysqlbinlog --no-defaults -v /var/lib/mysql/binlog.000052 | grep -E "last_committed|sequence_number" | head -40 输出示例： #250101 10:00:01 server id 1 end_log_pos 256 GTID last_committed=10 sequence_number=11 #250101 10:00:01 server id 1 end_log_pos 512 GTID last_committed=10 sequence_number=12 #250101 10:00:01 server id 1 end_log_pos 768 GTID last_committed=10 sequence_number=13 #250101 10:00:01 server id 1 end_log_pos 1024 GTID last_committed=10 sequence_number=14 上面 4 个事务 last_committed 都是 10，说明这 4 个事务可以并行回放。 ...

前言 relay_log_recovery=ON 是 MySQL 主从复制中常见的安全配置，官方文档描述它的作用是：从库重启时，丢弃未执行的 relay log，从主库重新拉取。听起来很安全，但在特定条件下，它不仅救不了你，反而会导致 数据静默丢失 — 复制显示正常，实际上数据已经少了。 本文通过一个完整的实验，从环境确认、故障触发、原因分析到最终修复，逐步展示这个陷阱的全貌。 一、实验环境 角色 实例 服务器 主库 3308 120.48.119.118 从库 3309 101.34.248.57 MySQL 版本：8.0.35，GTID 模式，半同步复制。 从库关键参数 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 mysql> SHOW VARIABLES LIKE 'relay_log_recovery'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | relay_log_recovery | ON | +--------------------+-------+ mysql> SHOW VARIABLES LIKE 'relay_log_info_repository'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | relay_log_info_repository| TABLE | +--------------------------+-------+ mysql> SHOW VARIABLES LIKE 'slave_parallel_workers'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | slave_parallel_workers| 4 | +-----------------------+-------+ -- ↑ 多线程复制，这是出问题的关键！ mysql> SHOW VARIABLES LIKE 'slave_parallel_type'; +--------------------+---------------+ | Variable_name | Value | +--------------------+---------------+ | slave_parallel_type| LOGICAL_CLOCK | +--------------------+---------------+ mysql> SHOW VARIABLES LIKE 'gtid_mode'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | gtid_mode | ON | +---------------+-------+ 配置总结：GTID + AUTO_POSITION + relay_log_recovery + MTS(4 worker) ...