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余个!紧急处理数据库生产事故上百起,挽回数据丢失所造成的灾难损失不计其数!并为某国家级大数据系统的技术方案(国家知识产权局颁布)专利权的第一专利发明人!