Em nosso sistema produtivo, recentemente descartamos uma Tabela de 1TB. Após a conclusão da queda, a tabela desapareceu no mysql, mas o arquivo ainda estava presente na pasta / lib / mysql / dbname /. (Usamos a configuração de um arquivo por tabela) Eu deletei os arquivos associados à tabela.
Então eu verifiquei com
lsof | grep crawl_link | grep deleted
e descobriu que ainda existem identificadores abertos pelo processo mysql
mysqld 38115 mysql 11uW REG 8,3 1016938364928 182524780 /var/lib/mysql/seobility/_crawl_links_new.ibd (deleted)
mysqld 38115 2110 mysql 11uW REG 8,3 1016938364928 182524780 /var/lib/mysql/seobility/_crawl_links_new.ibd (deleted)
mysqld 38115 4530 mysql 11uW REG 8,3 1016938364928 182524780 /var/lib/mysql/seobility/_crawl_links_new.ibd (deleted)
mysqld 38115 8192 mysql 11uW REG 8,3 1016938364928 182524780 /var/lib/mysql/seobility/_crawl_links_new.ibd (deleted)
(Total 120 Lines)
Eu sei que o problema seria resolvido reiniciando o MySql, mas nosso banco de dados está rodando a 2 TB + e eu realmente gostaria de evitar o tempo de inatividade.
Existe uma maneira de soltar o identificador de arquivo e liberar o espaço em disco ocupado?
A solução óbvia é matar (ou reiniciar) o processo que está mantendo o descritor de arquivo (ID do processo 38115 como mostrado em lsof output).
Se você não quiser fazer isso, poderá truncar o arquivo (mesmo se ele for excluído) para liberar espaço em disco. Você pode tentar o seguinte:
$ :> /proc/38115/fd/11
Em que 38115 é o ID do processo e 11 é o descritor do arquivo. Não esqueça de executar como root quando necessário.