背景:公司生产环境服务器空间报警,超过80%,紧急检查发现是Mysql备份服务器,有一个记录明细的大表,占用空间150G左右。找到了问题,就要解决他。计划将此表移走,重新建一个空新表,继续记录。在操作过程中
背景:公司生产环境服务器空间报警,超过80%,紧急检查发现是Mysql备份服务器,有一个记录明细的大表,占用空间150G左右。找到了问题,就要解决他。计划将此表移走,重新建一个空新表,继续记录。在操作过程中因为失误,导致多饶了好多流程,现在记录下来。
原计划:
1、备份这个表,使用xtrabackup
2、对表空间进行硬链接(ln命令),目的是不删除文件本身,而只删除其指针,从而达到快速删除,不影响使用,不占用资源的目的。(依赖原理:OS HARD LINK 当多个文件名同时指向同一个Inode时,这个INODE的引用数N>1, 删除其中任何一个文件名只是删除了一个指针而已,不会删除数据文件。当INODE的引用数N=1时, 删除文件需要去把这个文件相关的所有数据块清除,所以会比较耗时)。
3、使用drop删除表,最后删除表文件。
问题:然而理想很丰满现实很骨干,打我登陆服务器之后,发现服务器剩余的空间不足以让我进行硬链接。这就尴尬了,没办法,只能另找其他方法。
实际操作:
1、备份完数据
2、思索怎么把大表删除或者移走。最后决定将表空间重命名(mv),然后再操作,但是在mv重命名过程中,因为失误将ibd文件覆盖了,导致的问题是此大文件瞬间消失了,但是查看服务器空间发现其所占空间大小依然存在。按照道理来说,如果mv导致文件覆盖,文件相当于是被删除了,空间也应该释放了,然而没有。考虑到文件为mysql表空间文件,可能存在链接问题,重启mysql后,发现硬盘空间释放。
3、解决了硬盘空间问题,迎来了新的问题。在原数据库中建立同名表的时候,数据库一直提示表已存在,这就是直接删除表空间遗留下的问题。因为要新建一个空表,继续使用,所以也要解决这个问题。当然如果条件允许的话,可以另见一个结构一样表名称不一样的新表使用。我认为既然遇到了,就解决这个问题。
4、登陆数据库进行drop表测试,发现提示找不到这张表t1。考虑到表空间不存在,手动建一个空的表空间。首先是建了一张结构一样但是表名称不一样的表t2,复制t2的表空间并重命名为t1的表空间。重启数据库,然后再进入数据库,先分离表空间,再drop表,发现可以成功。然后新建t1表,也可以成功。最后将t2表删除。
5、此操作虽然没有问题,但是t1表中原始数据会丢失,所以在操作数据库之前一定要备份数据。
总结:虽然这是一个不大不小的问题,特别记录下来,有需要的朋友可以看一下。当然也有一个意外收获,那就是这样删除比drop速度要快得多,而且还不占用资源。
--结束END--
本文标题: 清理服务器空间遇到的mysql问题
本文链接: https://lsjlt.com/news/39007.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0