One day, the user table in the production environment suddenly locked the table for no reason. I thought it was just an occasional bug. So the first solution that came to my mind was simple and rude: restart the database (service mysqld restart). The problem is solved.
After 10 minutes, the table is locked again. Finally realized that the problem is not that simple.
After checking the information in many ways, various attempts. For example, methods such as the kill process are invalid.
I finally saw one. It might be due to lack of disk space. I felt that it was it in an instant.
df -h check the server disk occupancy, and it turns out that used has been 100% (the disk space occupancy warning is not made ^-^!!).
Only large files can be deleted. Generally, the catalina.out file in tomcat’s logs directory is very large.
A check, it turns out that there are as many as 15 Gs. rm -f catalina.out delete files.
Use df -h to check the disk usage. Nothing has changed.
After multiple verifications, it was found that: When deleting a file in use, the system will not immediately release the space occupied by the file.
At this time, you can pass:
1. Restart (the production environment is restarted, and it will never come. Moreover, it is still working overtime at home at night, and you have to deal with it overnight if you can’t get up. Pass directly)
2. Kill the process of deleting the file
lsof |grep deleted Find the process of deleting the file (the second column is the process id, and the last column is the path to the deleted file)
kill -9 process id (delete Corresponding process)
Check the disk occupancy by df -h again, and the disk space has been released.
In addition, the problem of locking the table also caused the master-slave synchronization to stop.
Reset master-slave synchronization, refer to another article link