本文主要是介绍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，但必须确保不会影响数据一致性及复制状态。
这篇关于Mysql数据库主从集群从库Slave因为RelayLog过多过大引起服务器硬盘爆满生产事故实战解决的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
