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服务至少正常启动！就是让服务器稍微有一点空间让MYSQL服务可以正常重启或者至少能正常操作，如果硬盘100%就算是调整MYSQL参数也不能成功，操作系统层面就运行不了！！
（2）修改localhost-relay-bin配置，relay_log_purge 配置，relay_log_recovery配置 需要重启mysql服务
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以字节为单位表示
relay_log_purge = 1 # relay_log_purge配置设置成1
relay_log_recovery=1
请注意，上述数字是将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，则表示未设置上限或者默认不限制中继日志占用的空间大小。 如果relay_log_purge为ON，MySQL会在应用完 relay log 中的数据后自动删除它们。
SHOW VARIABLES LIKE 'relay_log_space_limit';
SHOW VARIABLES LIKE 'relay_log_purge';
SHOW VARIABLES LIKE 'relay_log_recovery';
重启MYSQL服务，确定3个配置已经起效！ 在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_space_limit';
SHOW VARIABLES LIKE 'relay_log_purge';
SHOW VARIABLES LIKE 'relay_log_recovery';
如果relay_log_purge为ON，MySQL会在应用完 relay log 中的数据后自动删除它们。
（3）重置主从操作
上述3个配置打开之后，进行重置主从命令，MYSQL服务会自动清理relay_log，把硬盘释放！
stop slave; #停止主从服务
reset slave; #只是重置了与复制相关的一些内部状态信息
start slave; #启动就可以，之前的主从配置还在！
重置了主从，主从的配置还是存在的！
reset slave和RESET SLAVE ALL;的主要区别在于：
reset slave只是重置了与复制相关的一些内部状态信息。
RESET SLAVE ALL;除了重置复制相关的状态信息外，还会清除所有与复制相关的文件和设置，包括relay log等。 笔者实际操作发现relay_log_recovery的配置不是必须的，上述步骤relay_log_recovery不依赖！relay_log_purge是必须的！
如果你在操作数据库过程中，生产环境不能马上重启操作！此时要怎么操作？
步骤（一） 清理一下空间，能让MYSQL服务能正常工作！ 步骤（二） 动态配置参数，不用重启
SET GLOBAL relay_log_purge=1;
FLUSH LOGS;
步骤（三）
stop slave; #停止主从服务
reset slave; #只是重置了与复制相关的一些内部状态信息
start slave; #启动就可以，之前的主从配置还在！
步骤（四） 凌晨调整固化参数，重启服务！
解决方法（2）终极解决方法重置当前主从配置，抹平服务器，数据重新同步，重新配置！
手动清理（仅在必要时）尽管MySQL应该自动管理relay log，但在某些情况下可能需要手动干预。为了安全起见，在执行这些操作之前，请确保你了解可能的风险并备份相关数据。方法A： 停止slave服务以释放磁盘空间（这将清除当前的relay log）：
终极解决方法重置当前主从配置，抹平服务器，数据重新同步，重新配置！ 在从库上执行的操作
1. 停止从库的复制服务：
STOP SLAVE;
2. 重置从库的复制状态：
RESET SLAVE ALL; #这个命令相当于完全的清理从库的配置，相当于抹平！
此时可以人工清理所有relaylog文件了，如果relay_log_purge提前已经启用，那所有relaylog都是清空！ 如果没有启动，你也可以人工过去硬盘里面删除，因为此时你的主从配置以及完全的清空了，相当于全部重置！relaylog根本么有启用，就可以完全的清理干净！ 下面就是重新配置从库！
如果需要重新配置从库指向新的主库，或者重新开始同步，则需执行以下命令（假设新主库的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，但必须确保不会影响数据一致性及复制状态。
解决本次事故的主要核心教训就是提前把
SHOW VARIABLES LIKE 'relay_log_purge';
SHOW VARIABLES LIKE 'relay_log_space_limit';
参数配置好，因为MYSQL 主从集群从库默认是不自动清理relaylog文件的！这点大家注意！笔者也提醒大家，以后配置集群的时候提前把参数配置好，省的未来硬盘被挤满，还得按上述步骤调整！
笔者简介 国内某一线知名软件公司企业认证在职员工：任JAVA高级研发工程师,大数据领域专家,数据库领域专家兼任高级DBA!10年软件开发经验！现任国内某大型软件公司大数据研发工程师、MySQL数据库DBA，软件架构师。直接参与设计国家级亿级别大数据项目!并维护真实企业级生产数据库300余个!紧急处理数据库生产事故上百起，挽回数据丢失所造成的灾难损失不计其数!并为某国家级大数据系统的技术方案（国家知识产权局颁布）专利权的第一专利发明人！
精彩文章
发表评论