Mysql数据库主从集群从库Slave因为RelayLog过多过大引起服务器硬盘爆满生产事故实战解决

Mysql数据库主从集群从库slave因为RelayLog过多过大引起从库服务器硬盘爆满生产事故实战解决

一、MySQL数据库主从集群概念

MySQL数据库主从集群是一种高可用性和读写分离的数据库架构，它基于MySQL的复制（Replication）技术来同步数据。在主从集群中，至少包含一个主数据库（Master）和一个或多个从数据库（Slave）。
•主数据库：负责处理所有的写操作（INSERT、UPDATE、DELETE等），并将这些更改记录到其二进制日志（Binary Log）中。
•从数据库：通过连接主数据库并读取主库上的二进制日志，将其中的事务事件应用到自身的数据表中，这个过程称为“中继”（Relay）。
从数据库一般只用于处理读请求（SELECT），不接受直接的写入操作。主从集群的主要优势包括：1. 数据备份与恢复：从数据库提供了一种实时的数据备份方式，如果主数据库出现故障，可以从从数据库切换为新的主数据库以保证服务连续性。
2. 负载均衡：通过读写分离，可以将读密集型的查询分发到从数据库上执行，减轻主数据库的压力，提高系统整体性能。
3. 高可用性：多从数据库可以进一步提升系统的可用性，即使部分从库宕机，其他从库仍然可以提供读服务。
4. 扩展性：随着业务量的增长，可以通过增加从库的方式来扩展系统的读能力。在更复杂的场景下，还可以构建多层复制结构，例如级联复制（Cascade Replication）或者环形复制（Circular Replication），甚至实现互为主从的集群，从而达到更高的容错能力和灵活的部署架构。

在这里插入图片描述

二、RelayLog是什么？

MySQL中的中继日志（Relay Log）主要用于主从复制（Master-Slave Replication）场景下，它存储在从库（Slave）服务器上。当主库将二进制日志（Binary Log）中的事件传输给从库时，这些事件先被记录到从库上的中继日志文件中，然后由SQL线程读取中继日志并执行这些事件，从而实现主从数据同步。

三、生产实际问题描述

从库服务器MYSQL文件路径下情况如下：
在这里插入图片描述
从库产生特别多RelayLog的日志文件，导致硬盘爆满！

四、解决问题方法

解决方法（1）

（1）删除一些没有用的文件，腾出空间，让mysql服务至少正常启动！

（2）修改localhost-relay-bin配置

localhost-relay-bin 日志是MySQL数据库主从复制中备库上的中继日志文件，主要用于存储从主库接收到的binlog事件，以便备库在本地应用这些事件以保持数据同步。当主从之间存在延迟或者同步过程中出现问题时，中继日志可能会积累得很大。处理 localhost-relay-bin 日志过大的情况通常不建议直接手动删除，因为这可能导致数据一致性问题和主从复制中断。正确做法包括：总之，针对localhost-relay-bin日志过大问题，重点在于找到并解决复制延迟的原因，而不是简单粗暴地删除日志文件。如非必要，应当避免手动清理中继日志以防止破坏复制链路。

修改localhost-relay-bin为100G最大值

要在MySQL中配置relay-log-space-limit参数，使其最大值为100GB，你需要在MySQL服务器的配置文件（通常是my.cnf或my.ini）中添加或修改该参数。

 vi /etc/my.cnf

以下是在配置文件中设置的方法：[mysqld]下配置追加
设置中继日志使用的最大磁盘空间为100GB

relay-log-space-limit = 107374182400 # 这是100GB以字节为单位表示

请注意，上述数字是将100GB转换成字节（1GB = 1024 * 1024 * 1024 字节）。保存配置文件后，需要重启MySQL服务来应用新的配置。如果你正在运行的是MySQL 8.0版本，请确保这个选项仍然有效，并且适用于你的MySQL复制环境。在某些情况下，可能还需要根据具体的MySQL版本和配置进行调整。在执行任何配置更改之前，请查阅官方文档以获取最新的建议和最佳实践。

在MySQL中，你无法直接通过SQL查询来获取relay-log-space-limit的当前设置值。这个参数是一个服务器级别的系统变量，通常是在MySQL服务器启动时通过配置文件（如my.cnf或my.ini）进行设置的。要查看该参数的当前值，你需要登录到MySQL服务器，并执行如下命令：
SHOW VARIABLES LIKE ‘relay_log_space_limit’;
这条命令将显示所有与 relay_log_space_limit 相关的系统变量及其当前设置值。如果该值为0，则表示未设置上限或者默认不限制中继日志占用的空间大小。

SHOW VARIABLES LIKE 'relay_log_space_limit';

在这里插入图片描述
在MySQL中清理relay_log（中继日志）时，你需要确保主从复制没有延迟且数据同步正常。以下是几个步骤来安全地清理relay log：步骤1：检查复制状态首先，通过运行以下命令确认从库是否与主库保持同步：

SHOW SLAVE STATUS;

检查Seconds_Behind_Master字段，如果值为0或者很小，并且没有任何未解决的错误，说明从库是同步的。步骤2：自动清理MySQL从5.6版本开始，通常会自动清理不再需要的relay log文件。确认服务器配置参数relay_log_purge和relay_log_recovery已设置为启用状态：

SHOW VARIABLES LIKE 'relay_log_purge';
SHOW VARIABLES LIKE 'relay_log_recovery';

如果relay_log_purge为ON，MySQL会在应用完 relay log 中的数据后自动删除它们。

在这里插入图片描述

解决方法（2）手动清理

手动清理（仅在必要时）尽管MySQL应该自动管理relay log，但在某些情况下可能需要手动干预。为了安全起见，在执行这些操作之前，请确保你了解可能的风险并备份相关数据。方法A：停止slave服务以释放磁盘空间（这将清除当前的relay log）：

STOP SLAVE;
PURGE MASTER LOGS TO 'mysql-relay-bin.000001'; # 替换为你想保留的第一个relay log文件名
START SLAVE;

这个命令会删除所有旧于指定名称的relay log文件，并重新创建新的relay log。
方法B：如果你想要只移除一部分relay log而不是全部，可以尝试更细致的方法：

PURGE RELAY LOGS BEFORE 'YYYY-MM-DD HH:MM:SS'; # 替换为想要保留的最早时间点

这将会清理在指定时间点之前的relay log。请注意，无论采用哪种方法，都应在清理之后再次检查复制状态以确保其继续正常工作。

SHOW SLAVE STATUS;

预防措施最后，始终建议根据官方文档指导以及实际环境进行操作，并在进行任何清理操作前，充分理解风险和影响。

笔者尝试上述的方法遇到了另个报错

mysql Replica failed to initialize applier metadata structure from the repository

（3）终极解决方法重置当前主从，数据重新同步！

在从库上执行的操作

1. 停止从库的复制服务：

STOP SLAVE;

2. 重置从库的复制状态：

RESET SLAVE ALL;

如果需要重新配置从库指向新的主库，或者重新开始同步，则需执行以下命令（假设新主库的IP为new_master_ip，端口为new_master_port，用户名为replication_user，密码为password）：

CHANGE MASTER TO 
MASTER_HOST='new_master_ip', 
MASTER_USER='replication_user', 
MASTER_PASSWORD='password',
MASTER_PORT=new_master_port,
MASTER_LOG_FILE='mysql-bin.00000X',  -- 替换为从主库SHOW MASTER STATUS得到的实际日志文件名
MASTER_LOG_POS=X;                     -- 替换为主库SHOW MASTER STATUS得到的日志位置

4. 启动从库复制：

START SLAVE;

5.确定rely-log最大值的配置是否真正启用

SHOW VARIABLES LIKE 'relay_log_purge';
SHOW VARIABLES LIKE 'relay_log_space_limit';

从而最终解决问题！

总结

MySQL主从集群中Relay Log日志过多过大的可能原因有以下几点：

（1）主库写入操作频繁：

如果主数据库有大量的INSERT、UPDATE和DELETE等写操作，这些操作会被记录到二进制日志（Binary Log）中，并传输给从库。从库会将这些事件记录在自己的Relay Log中，然后执行这些事件以保持与主库的数据同步。

（2）主从延迟：

在主从复制过程中，如果从库由于性能问题或其他原因无法及时处理并删除Relay Log中的事务，则可能导致Relay Log堆积。例如，SQL线程在从库上运行较慢，或者网络延迟导致数据传输速度低于主库产生新事务的速度。

（3）relay_log_purge设置不当：

MySQL的relay_log_purge参数默认为ON，这意味着一旦SQL线程已经应用了Relay Log中的事务，系统就会自动清理这些已使用的Relay Log文件。但如果该参数被错误地设置为OFF，或者由于某些异常情况导致自动清理机制失效，Relay Log就可能持续增长而不被清理。
从库长时间未重启或主从断开连接后未正确恢复：
当主从之间出现故障导致复制暂停时，如果未及时发现并恢复正常复制，Relay Log将持续接收但不处理新的事务，进而积累大量未执行的日志。

（4）MHA等高可用解决方案禁用自动清理：

在一些高级的MySQL高可用性解决方案如MHA（MySQL Master High Availability）中，为了保证滞后从库能够通过其他节点的Relay Log进行补救性恢复，有时会选择暂时禁用Relay Log的自动清理功能，待所有从库都追赶上主库之后再进行清理。

（5）relay_log_space_limit配置不足：

如果relay_log_space_limit参数设置得过小，而实际产生的Relay Log超过了这个限制值，理论上MySQL应该会自动删除旧的Relay Log来释放空间，但如果这个参数设置不合理，可能会导致Relay Log清理不及时。要解决Relay Log过大过多的问题，通常需要根据实际情况调整上述配置参数，优化复制性能，确保SQL线程能跟上主库的更新速率，并定期检查和合理清理Relay Log。同时，也可以考虑增加从库资源以提高其处理能力。在必要时，可以手动清理Relay Log，但必须确保不会影响数据一致性及复制状态。