MySQL主从复制和高可用

flytalei

已于 2024-09-23 22:34:29 修改

阅读量968

点赞数 9

分类专栏： mysql删库到跑路文章标签： mysql 数据库 linux

于 2024-09-03 18:15:51 首次发布

本文链接：https://blog.csdn.net/flytalei/article/details/141819398

版权

mysql删库到跑路专栏收录该内容

10 篇文章 0 订阅

订阅专栏

主从复制原理

MySQL主从复制的逻辑是基于二进制日志来实现的，简单来说就是把主节点Master上的二进制日志拷贝到从节点Slave上。前提是主从节点都得开启二进制日志。
在这里插入图片描述

主从相关线程

主从复制时，有三个关键线程参与工作。主节点的dump线程、从节点的IO线程和SQL线程

主从复制相关线程
  主节点:
    dump Thread: 为每个Slave的I/O线程启动一个dump线程，用于向其发送binary log events

  从节点:  (从节点需要有连接master的授权和账号)
    I/O Thread: 向Master请求二进制日志事件，并保存于中继日志中
    SQL Thread: 从中继日志中读取日志事件，在本地完成数据重放

复制基本流程

MySQL 主从复制（Master-Slave Replication）是指在 MySQL 数据库环境中，主节点（Master）将数据变更操作复制到从节点（Slave），以实现数据的冗余和容错。通过这种机制，从节点可以实时或准实时地保持与主节点相同的数据副本。

MySQL主从复制的整个过程可以分为以下几个步骤：
  1.主节点（Master）记录二进制日志（Binary Log）
    主库上发生的所有数据更改操作（如 INSERT、UPDATE、DELETE）会被记录到一个称为二进制日志（binlog）的文件中。
    这些日志记录了每一个数据修改语句，以及在执行这些语句时的状态。
    也就是说，二进制日志包含了所有可以重放的 SQL 语句，以便在从库上重新执行。

  2.从节点（Slave）读取主库的二进制日志
    从库上有一个 I/O 线程，它负责与主库建立连接，并读取主库的二进制日志。
    I/O 线程将读取到的日志传输到从节点，并将这些日志写入到从节点的一个称为中继日志（relay log）的文件中。
    
  3.从节点执行中继日志
    从节点上有一个 SQL 线程，它负责读取中继日志中的内容，并按照日志中的顺序执行所有数据修改操作。
    这些操作实际上是重新在从库上执行主库上已经执行过的 SQL 语句，从而使从节点的数据与主节点保持一致。

主从复制过程
  1.当master节点接收到写操作后，数据更新被写入到二进制BinLog文件中，
    此时Master会开启一个dump线程向从节点同步二进制文件Binlog；
    
  2.Slave从节点开启IO线程接收master同步过来的Binlog,Binlog被放进中继日志(也是二进制日志)中，
    由Slave的sql线程读取；
    
  3.Slave会在开启一个SQL线程读取中继日志之后，使Slave中的数据发生变更，确保和master数据的一致。

复制相关文件

master.info:      用于保存slave连接至master时的相关信息，例如账号、密码、服务器地址等
relay-log.info:   保存在当前slave节点上已经复制的当前二进制日志和本地relay log日志的对应关系
mysql-relay-bin.00000num:  中继日志,保存从主节点复制过来的二进制日志,本质就是二进制日志

说明: MySQL8.0取消master.info和relay-log.info文件,8.0的复制过程可参考官方文档。

主从复制的类型

MySQL主从复制根据不同的需求，可以实现多种类型的复制模式：
  2.1 异步复制（Asynchronous Replication）
      主库只将数据变更记录到二进制日志中，并不等待从库确认日志是否被读取或执行。
      这种模式下，如果主库出现故障，可能会导致从库的数据丢失。
      
  2.2 半同步复制（Semi-Synchronous Replication）
      主库在提交事务后，会等待至少一个从库确认已经收到并写入中继日志，再返回成功给客户端。
      这种模式下，从库至少有一个可以保证数据一致性，但仍有一定的延迟。
      
  2.3 全同步复制（Synchronous Replication）
      主库在提交事务后，需要等待所有从库都确认已经接收到数据后，才会返回成功给客户端。
      这种模式下，数据一致性最强，但性能较差，因为主库需要等待所有从库的响应。

主从复制的优势和劣势

主从复制的优势和劣势
  优势
     高可用性：从库作为主库的备份，可以在主库出现故障时接替主库的工作。
     负载均衡：读操作可以分布到多个从库，从而减轻主库的压力。
     数据备份：从库可以用于数据备份操作，而不影响主库的性能。
     
  劣势
     数据延迟：从库的数据更新存在延迟，尤其是在网络环境不佳或从库执行速度较慢的情况下。
     单点故障：如果主库出现故障，虽然从库可以接管，但仍然需要手动切换或依赖自动化工具来完成。

主从复制的配置

参考手册：https://dev.mysql.com/doc/refman/8.0/en/replication.html

配置MySQL主从复制通常包括以下几个步骤：
  1.在主库上启用二进制日志：通过在 my.cnf 文件中配置 log_bin 参数。
  2.创建复制用户：在主库上创建一个专门用于复制的用户，并授予该用户足够的权限。
  3.初始化从库：在从库上导入主库的数据快照，确保从库初始状态与主库一致。
  4.配置从库连接：在从库上配置连接到主库的参数，包括主库的 IP、端口、用户和密码。
  5.启动复制：在从库上启动复制线程，使其开始从主库获取二进制日志并执行。

复制的维护
  监控复制状态：使用 SHOW SLAVE STATUS 命令来监控从库的复制状态，检查是否有任何延迟或错误。
  处理复制延迟：通过优化网络、提高从库性能或调整复制配置来减少复制延迟。

主节点配置

1.启动二进制日志

启动二进制日志,mysql8.0默认开启

[mysqld]
log_bin

2.设置全局唯一ID

为当前节点设置一个全局惟一的ID号

[mysqld]
server-id=NUM
log-basename=master    可选项，设置datadir中日志名称，确保不依赖主机名

server-id的取值范围
1 to 4294967295 (>= MariaDB 10.2.2)，默认值为1，MysQL8.0默认值为1
0 to 4294967295 (<= MariaDB 10.2.1)，默认值为O，如果从节点为0，所有master都将拒绝此sLave的连接

3.查看从二进制日志的文件和位置开始进行复制

SHOW MASTER STATUS;

4.创建有复制权限的用户账号

GRANT REPLICATION SLAVE ON *.* To 'repluser '@'HOST' IDENTIFIED BY 'replpass';

MySQL8.0分成两步实现
mysql> create user repluser@'10.0.0.%' identified by '123456';
mysql> grant replication slave on *.* to repluser@'10.0.0.%';

从节点配置

1.启动中继日志

[mysqld]
server_id=num                      为当前节点设置一个全局惟的ID号
log-bin
read_only=ON                       设置数据库只读，针对supper user无效
relay_log=relay-log                relay log的文件路径，默认值hostname-relay-bin
relay_log_index=relay-log.index    默认值hostname-relay-bin.index

2.创建有复制权限的账户

使用有复制权限的用户账号连接至主服务器，并启动复制线程

官方说明：https://dev.mysql.com/doc/refman/8.0/en/change-master-to.html

范例

1.master节点配置

配置 /etc/my.cnf
vim /etc/my.cnf

[mysqld]
server-id=8
log-bin=/data/logbin/mysql-bin

在这里插入图片描述
创建binlog目录，修改所有者并重启服务。

mkdir /data/logbin
chown mysql.mysql /data/logbin
systemctl restart mysqld

在这里插入图片描述
创建授权账号

mysql> create user repluser@'10.0.0.%' identified by '123456';
Query OK, 0 rows affected (0.00 sec)

mysql> grant replication slave on *.* to repluser@'10.0.0.%';
Query OK, 0 rows affected (0.00 sec)

开始备份数据

mysqldump -A -F --single-transaction --master-data > /backup/full-`date +%F`.sql

将备份出来的full-2024-09-02.sql拷贝到slave节点上

2.slave节点配置

拷贝过来的full-2024-09-02.sql不要直接还原在slave节点上，需要做以下配置，需要配置master节点ip和授权账号。

查看配置帮助

mysql> help CHANGE MASTER TO

 CHANGE MASTER TO
  MASTER_HOST='10.0.0.8',
  MASTER_USER='repluser',
  MASTER_PASSWORD='123456',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mysql-bin.000002', 
  MASTER_LOG_POS=30489887,
  MASTER_CONNECT_RETRY=5;

做完以上配置就可以备份还原数据到slave上了，不过还是得先关掉slave上的二进制日志(还原的过程需要记录)

mysql> set sql_log_bin=0;

开始还原

source /backup/full-2024-09-02.sql

source之后再开启二进制日志

mysql> set sql_log_bin=1;

此时slave已经和master同步上数据了，但之后master有新增数据是不会同步到slave上的，因为slave上还没有开启IO和sql两个线程

可以使用命令查看主从节点信息

mysql> show slave status\G

在这里插入图片描述
查看slave上的线程

show processlist;

在这里插入图片描述

开启IO/SQL两个线程

开启slave线程

mysql> start slave;

在这里插入图片描述

开启slave的这俩个线程之后，master节点上再有什么数据跟新就会实时同步到slave节点上。

MHA集群架构

MySQL MHA（Master High Availability Manager）是一种用于MySQL主从架构的高可用性解决方案，能够在主库发生故障时自动进行故障转移，保证系统的高可用性。MHA的主要工作原理包括主从复制、故障检测、自动故障转移和数据一致性管理。

MHA通过监控MySQL主库的状态并在故障发生时快速执行自动化的故障转移，确保MySQL集群的高可用性。其核心在于选举新主库、保持数据一致性以及将其他从库重新指向新主库，这些步骤共同确保了系统的可靠性和数据完整性。

MHA 还支持多种高可用性策略，如半同步复制和异步复制组合使用，以减少主库故障导致的数据丢失风险。此外，MHA 能与其他高可用性工具（如 Keepalived、Heartbeat）集成，以进一步增强系统的稳定性。

架构概述

MHA 的架构通常由以下几个组件组成：
  MHA Manager: 
    部署在一个独立的管理节点，负责监控 MySQL 主库的状态，并在主库发生故障时进行故障转移。
    
  MHA Node: 
    部署在 MySQL 主库和从库所在的服务器上，用于执行故障转移过程中涉及的各种操作，如日志保存、复制位置检查等。

自动故障转移

当主库发生故障时，MHA会自动执行故障转移流程。该流程通常包括以下几个步骤：

  第1步: 保存二进制日志
    在主库故障后，MHA Node会在主库的服务器上尝试保存最新的二进制日志（如果主库服务器还存活但MySQL服务已停止）。保存这些日志对于数据一致性非常重要。

  第2步: 选举新主库
    MHA Manager会从现有的从库中选择一个合适的节点作为新的主库。选择依据通常是复制延迟最小的从库，因为它与主库的数据最接近。

  第3步: 应用中继日志
    选中的从库在被提升为新主库之前，需要应用其本地的中继日志（relay log），以确保自身数据与原主库一致。

  第4步: 将其他从库指向新主库
    一旦新主库确定，MHA Manager 会将其他所有从库的复制源从旧主库切换到新主库，并重启复制过程。