首页 > 数据库 >MySQL数据库笔记——主从复制

MySQL数据库笔记——主从复制

时间：2025-01-19 16:02:27浏览次数：3  
标签：主库 主从复制 Log 数据库 复制 线程 MySQL 日志 从库

大家好，这里是Good Note，关注 公主号：Goodnote，本文详细介绍 MySQL的主从复制，从原理到配置再到同步过程。

在这里插入图片描述

文章目录

简介

MySQL 主从复制（Replication）是一种数据分布和同步的技术，通过将主库（Master）的数据和操作复制到一个或多个从库（Slave），实现数据的同步和备份。它常用于读写分离、数据容灾、数据分布等场景。

核心组件

  1. 主库（Master）：

    • 负责记录所有数据变更操作到 Binary Log 中。
    • 通过网络将 Binary Log 提供给从库。

  2. 从库（Slave）：

    • 负责从主库获取 Binary Log，并通过中继日志（Relay Log）将其重放在本地，最终实现与主库的数据同步。

  3. 二进制日志（Binary Log）：

    • 主库记录所有数据变更的日志文件。
    • 包含数据变更的具体操作（语句或行数据）。

  4. 中继日志（Relay Log）：

    • 从库将主库发送的 Binary Log 存储为中继日志。
    • 从库 SQL 线程根据中继日志执行对应的操作。

主从复制的原理

  1. 基于二进制日志（Binary Log）：

    • MySQL 主从复制依赖主库的二进制日志（Binary Log）。主库将所有数据变更操作（如 INSERT、UPDATE、DELETE）记录到 Binary Log 中。

  2. 复制过程：

    • 日志同步：从库向主库请求二进制日志，从主库读取日志文件中最近的更新操作。
    • 日志重放：从库接收到二进制日志后，存储到自己的中继日志（Relay Log），并重放这些操作以保持与主库数据一致。

  3. 主从独立运行：

    • 主库和从库的操作相互独立，从库的备份操作不会干扰主库，主库可以继续处理写操作。

作用

  1. 数据冗余，宕机保护：

    • 数据冗余：在从库上保存主库的数据副本，防止数据丢失。
    • 宕机保护：主库宕机时，可以快速启用从库，保障业务连续性。

  2. 读写分离，性能提升：

    • 支持读写分离：主库处理写操作，从库处理读操作。
    • 流量分担：多台从库分担主库的查询压力，提升系统性能。

  3. 扩展性：

    • 易于扩展：通过增加从库节点应对流量增长。
    • 平滑升级：可以优先升级从库，验证新版本的稳定性后再升级主库。

  4. 负载均衡：

    • 多从库分担读流量，实现负载均衡，提升并发能力。

主从复制的线程模型

主从复制主要涉及以下线程：

  1. 主库线程：

    • Binlog Dump 线程：主库为每个从库分配一个 Binlog Dump 线程，将 Binary Log 发送到从库。

  2. 从库线程：

    • I/O 线程：从库从主库拉取 Binary Log 并保存为 Relay Log。
    • SQL 线程：从库读取 Relay Log，并将日志中的操作在从库中重放。

主从复制的模式

  1. 异步复制（Asynchronous Replication）：

    • 主库提交事务后立即返回客户端，从库异步同步数据。延迟低，但存在数据丢失风险。
    • 默认复制模式。
    • 主库不等待从库的确认即完成事务提交。
    • 延迟低，但如果主库崩溃，可能会导致从库数据不一致。

  2. 半同步复制（Semi-Synchronous Replication）：

    • 主库在事务提交后会等待至少一个从库确认接收 Binary Log。，才返回客户端。
    • 特点：
      • 提高数据安全性。
      • 延迟较低，但仍比异步复制稍高。
      • 从 MySQL 5.5 开始支持（需要插件）。

  3. 全同步复制（Synchronous Replication）：

    • 主库必须等待从库同步完成后，才向客户端返回写入成功。延迟较高，但数据一致性强。
    • 所有从库都确认接收到 Binary Log 后，主库才提交事务。
    • 数据一致性最高，但性能损耗较大。

形式

  1. 一主一从：

    • 简单高效的主从架构，适用于小型系统或简单业务场景。
    • 特点：
      • 支持基本的高可用性。
      • 从库可用于查询、备份等，主库专注写操作。

  2. 一主多从：

    • 主库将数据同步到多个从库，适合读多写少的场景。
    • 特点：
      • 提升并发能力，实现负载均衡。
      • 每个从库可以分配特定任务，如查询或备份。

  3. 多主一从：

    • 多个主库的数据同步到一台从库。
    • 特点：
      • 用于整合不同业务线的数据到一个中心数据库。
      • 对从库的存储性能要求较高。
    • 补充：由于主库间没有自动同步，需确保主库之间的写操作不会冲突。

  4. 双主复制：

    • 两台服务器互为主从，支持双机热备。
    • 特点：
      • 任一主库宕机后，另一主库可继续提供服务。
      • 双向同步，数据一致性需谨慎处理，防止循环复制或冲突。
    • 适用场景：
      • 高可用场景，如业务不允许服务中断。

  5. 级联复制：

    • 一些从库直接从主库同步数据，其他从库通过这些从库同步。
    • 特点：
      • 缓解主库压力。
      • 降低主库对网络带宽的依赖。
    • 适用场景：
      • 大规模分布式系统。

一主一从和一主多从是我们现在见的最多的主从架构，使用起来简单有效，不仅可以实现高可用，而且还能读写分离，进而提升集群的并发能力。

复制的方式

  1. 基于语句的逻辑复制（Statement-Based Replication, SBR）：

    • 特点：
      • 二进制日志记录 SQL 语句，操作逻辑在从库重放。
      • 日志体积小，传输效率高。
    • 缺点：
      • 语句重放依赖于上下文环境，可能导致主从数据不一致（如 NOW() 或 UUID() 生成的值不同）。基于语句更新依赖于其它因素，比如插入数据时利用了时间戳。因此在开发当中，我们应该尽量将业务逻辑逻辑放在代码层（创建时间，不应该是mysql的创建时间），而不应该放在 MySQL 中，不易拓展。
      • 多表操作或复杂查询时，性能可能不理想。
    • 适用场景：
      • 操作简单且可预测的业务场景。
      • 设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅需要发送一条sql，而基于行的复制需要发送一百万条更新记录

  2. 基于行的物理复制（Row-Based Replication, RBR）：

    • 特点：
      • 二进制日志记录每一行的数据变更，直接同步数据。
      • 精确可靠，不受上下文影响。
    • 缺点：
      • 日志体积大，占用更多存储和带宽。
    • 适用场景：
      • 数据更新频繁，且对数据一致性要求较高的场景。
      • 例如一条更新用户总积分的语句，需要统计用户的所有积分再写入用户表。如果是基于语句复制的话，从库需要再一次统计用户的积分，而基于行复制就直接更新记录，无需再统计用户积分。

  3. 混合复制（Mixed Replication, MIXED）：

    • 特点：
      • 默认使用语句复制，当遇到复杂场景（如函数、触发器）时切换为行复制。
      • 动态选择复制方式，兼具两种方式的优点。
    • 缺点：
      • 复杂度较高，需要额外的资源判断何时切换。
    • 适用场景：
      • 通用场景，特别是既有简单语句，又有复杂操作的业务。

设计复制机制

在这里插入图片描述

以下是主从复制的详细执行流程：

  1. 主库写入 Binary Log：

    • 任何修改数据的操作（如 INSERT、UPDATE、DELETE）都会记录到主库的 Binary Log。

  2. 从库 I/O 线程拉取 Binary Log：

    • 从库的 I/O 线程向主库请求 Binary Log。
    • 主库会生成一个 log dump 线程，将 Binary Log 发送给从库。

  3. 从库存储中继日志：

    • 从库将主库的 Binary Log 存储为中继日志（Relay Log）。

  4. 从库 SQL 线程执行 Relay Log：

    • 从库的 SQL 线程读取 Relay Log，将日志中的操作在从库重放，完成数据同步。

  5. 后续新数据到达主库：

    • 主库执行写操作后，事务提交时会将修改记录写入 Binary Log。主库的 Log Dump 线程实时检测 Binary Log 更新，并通过长连接主动推送到从库。

注意：

  • 同步过程是实时推送日志。

  • 第一次连接：从库的 I/O 线程主动向主库发起请求，同步历史数据。

  • 后续新数据到达主库：主库主动推送新数据实时同步到从库。

  • 长连接保持：从库的 I/O 线程与主库的 Log Dump 线程建立长连接。从库无需反复发起请求去检查主库是否有新数据，而是等待主库通过长连接推送新的日志。

    • 长连接保持的关键在于：
      1. TCP 持久连接：从库的 I/O 线程与主库的 Log Dump 线程通过 TCP 连接持续通信。
      2. 复制心跳机制：即使主库没有新数据生成，也会定期发送心跳包，保持连接活动。
      3. 自动重连机制：当连接意外中断时，从库的 I/O 线程会自动尝试重新连接主库。
    • MySQL 设计了完整的断点续传和自动重连机制，确保长连接断开后可以尽快恢复。
      • 从库记录了上次成功同步的日志位置（MASTER_LOG_FILE 和 MASTER_LOG_POS）。
      • 重新连接后，从库会从上次中断的位置继续同步，避免重复同步或数据丢失。

主从复制的配置步骤

  1. 配置主库（Master）：

    • 启用 Binary Log：
      [mysqld]
log-bin=mysql-bin
server-id=1
    • 重启 MySQL 服务。

  2. 配置从库（Slave）：

    • 设置从库的 server-id：
      [mysqld]
server-id=2
    • 连接主库：
      CHANGE MASTER TO
MASTER_HOST='主库IP',
MASTER_USER='复制用户',
MASTER_PASSWORD='密码',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=120;
    • 启动从库复制：
      START SLAVE;

  3. 验证主从复制状态：

    • 在从库执行：
      SHOW SLAVE STATUS\G;

优化和改进

  1. 使用半同步复制：

    • 提高数据一致性，降低数据丢失风险。

  2. 多线程复制：

    • MySQL 5.6 开始支持多线程复制（Parallel Replication），从库的 SQL 线程可以并行处理不同表的数据，提升同步效率。

  3. 监控和告警：

    • 定期检查主从同步状态（SHOW SLAVE STATUS）。
    • 设置告警系统监控复制延迟、复制状态。

  4. 主从自动切换：

    • 使用高可用工具（如 MHA、Keepalived、Orchestrator）实现主从自动切换，避免主库故障时人工干预。

总结

MySQL 主从复制是实现高可用性和负载均衡的重要机制。通过合理的复制模式配置（如半同步、并行复制）以及结合监控和自动化工具，可以显著提高数据库系统的性能和可靠性。同时，了解主从复制的缺点（如数据延迟和单点故障）并采取适当的优化措施，可以进一步提升系统的稳定性。

历史文章

  1. MySQL数据库笔记——数据库三范式
  2. MySQL数据库笔记——存储引擎（InnoDB、MyISAM、MEMORY、ARCHIVE）
  3. MySQL数据库笔记——常见的几种锁分类
  4. MySQL数据库笔记——索引介绍
  5. MySQL数据库笔记——事务介绍
  6. MySQL数据库笔记——索引结构之B+树
  7. MySQL数据库笔记——索引潜规则（回表查询、索引覆盖、索引下推）
  8. MySQL数据库笔记——索引潜规则（最左前缀原则）
  9. MySQL数据库笔记——常见慢查询优化方式
  10. MySQL数据库笔记——日志介绍
  11. MySQL数据库笔记——多版本并发控制MVCC

标签：主库,主从复制,Log,数据库,复制,线程,MySQL,日志,从库
From： https://blog.csdn.net/haopingbiji/article/details/145238406

相关文章

  • MySQL 创建数据库问题：You have an error in your SQL syntax（MySQL 数据库命名规则问题
    问题描述与处理策略1、问题描述CREATEDATABASEmy-shop-db;执行上述SQL语句，报如下错误CREATEDATABASEmy-shop-db>1064-YouhaveanerrorinyourSQLsyntax;checkthemanualthatcorrespondstoyourMySQLserverversionfortherightsyntaxtouse......
  • 安全认证框架【springSecurity】进行数据库效验开箱即用。
    流程：注册---加密密码---保存数据库---登录---授权---认证---效验数据库账号密码---生成token存redis---返回前端第一步子模块引入依赖；版本号由父统一管理，这里有不理解的可以看我maven篇巩固一下。<?xmlversion="1.0"encoding="UTF-8"?><projectxmlns="http://maven.apac......
  • ingress-nginx代理tcp使其能外部访问mysql
    一、helm部署mysql主从复制helmrepoaddbitnamihttps://charts.bitnami.com/bitnamihelmrepoupdate helmpullbitnami/mysql 解压后编辑values.yaml文件，修改如下（storageclass已设置默认类）117##@paramarchitectureMySQLarchitecture(`standalone`or`re......
  • MySQL数据库基本操作命令
    数据库基本操作数据库可以看作是一个专门存储数据对象的容器，每一个数据库都有唯一的名称，并且数据库名称都是有实际意义的，这样就可以清晰的看出每一个数据库用来存放什么数据。在MySQL数据库中存在系统数据库和自定义数据库，系统数据库是安装在MySQL后系统自带的数据库，自定义......
  • MySQL——DQL基本查询 聚合函数 分组查询 排序查询 分页查询
    1.3DQL语法DQL：数据查询语言，用来查询数据库表中的记录。DQL基本查询1.查询多个字段select字段1，字段2，字段3...from表名；案例查询指定字段nameworknoageselectname,workno,agefromemp;2.查询所有字段select*from表名；select*fromemp;3.设置别名select字段1a......
  • SpringBoot体育场馆在线预约系统ig5br（程序+源码+数据库+调试部署+开发环境）
    本系统（程序+源码+数据库+调试部署+开发环境）带论文文档1万字以上，文末可获取，系统界面在最后面。系统程序文件列表用户,场地类别,场地信息,场地预约,取消预约,统计数据开题报告内容一、研究背景与意义随着人们健康意识的增强，体育锻炼已成为现代人日常生活的重要组成部分。体......
  • Golang结合MySQL和DuckDB提高查询性能
    要在Golang中组合MySQL和DuckDB以提高查询性能，请考虑使用混合查询执行方法。这种方法利用了MySQL强大的事务管理和DuckDB闪电般的分析处理能力。本文介绍如何充分利用两者的方法。各取所长用MySQL处理事务，用DuckDB处理分析MySQL应该处理常规的INSERT、UPDATE和DELETE操......
  • 免费送源码：Java+ssm+MySQL SSM宁夏地区自助旅游管理系统 计算机毕业设计原创定制
     摘 要本论文主要论述了如何使用SSM框架开发一个自助旅游管理系统，严格按照软件开发流程进行各个阶段的工作，采用B/S架构JAVA技术，面向对象编程思想进行项目开发。在引言中，作者将论述自助旅游管理系统的当前背景以及系统开发的目的，后续章节将严格按照软件开发流程，对系统进行各......
  • 宿舍管理信息系统【控制台+MySQL】（Java课设）
      客官进来看一眼呗，有惊喜！【帮你解决烦恼】：Java课设和计Java毕设太难不会做怎么办？系统类型控制台类型+Mysql数据库存储数据使用范围适合作为Java课设！！！部署环境jdk1.8+Mysql8.0+Idea或eclipse+jdbc运行效果本系统源码地址：宿舍管理信息系统【控制台+MySQL】（Java课设）资......
  • 关系型数据库与非关系型数据库（NoSQL）的主要区别是什么？
    关系型数据库（RDBMS）与非关系型数据库（NoSQL）之间存在多个显著的区别，这些区别主要体现在数据模型、事务处理、扩展性、性能和适用场景等方面。数据模型：关系型数据库采用基于表格的二维数据模型，数据以行和列的形式存储，通过表之间的关系（如外键）来维护数据的一致性和完整性。这种结......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99