Instância do Amazon RDS perdendo lentamente espaço livre em disco

Question

Um tempo atrás, o servidor executando minha instância tinha 20 GB de armazenamento EBS. Em seguida, ele começou a receber erros de armazenamento em disco, então aumentamos para 40 GB. Então, novamente, falta de erros de armazenamento, então eu aumentei novamente para 60GB. (Então esta é uma Instância RDS de 60GB)

Você pode ver aqui o gráfico Espaço livre de armazenamento (MB) . Cada vez que aparece, adiciono mais espaço de armazenamento.

Seeuexecutaressaconsulta...

SELECTCONCAT(table_schema,'.',table_name),CONCAT(ROUND(table_rows/1000000,2),'M')rows,CONCAT(ROUND(data_length/(1024*1024*1024),2),'G')DATA,CONCAT(ROUND(index_length/(1024*1024*1024),2),'G')idx,CONCAT(ROUND((data_length+index_length)/(1024*1024*1024),2),'G')total_size,ROUND(index_length/data_length,2)idxfracFROMinformation_schema.TABLESORDERBYdata_length+index_lengthDESCLIMIT10;

Receboaseguinteresposta...

Nada se destaca por ocupar uma enorme quantidade de espaço.

Se eu, então, executar

select table_schema, CONCAT(ROUND( sum((data_length+index_length)/1024/1024)/1024, 2), 'G') AS MB from information_schema.tables group by 1;

Eu posso ver que a maior tabela tem cerca de 10 GB. (Isso inclui data_length e index_length)

Meupróximopensamentoéqueobaixoelentoarmazenamentoéoregistrogeral_logoulogslentosdeconsultagravadosnodisco...

SeeuverificarosgruposdeparâmetrosnaminhainstânciadoRDS,podereiverqueoregistroestádesabilitado.

Alguém sabe por que meu servidor RDS está vazando lentamente?

ATUALIZAÇÃO:

Eu recebi ajuda do tipo folk em #mysql

Depois de executar

show global variables like 'log_bin';

Ficou claro que os registros binários foram ativados.

Eu então corri

show binary logs e tinha 41674+ registros.

Rolando para baixo através de meus logs, eu pude ver que um tamanho de arquivo era 2064636

Eu,então,tenteiapagartodososregistrosbináriosatéoarquivochangelog.

purgebinarylogsto"mysql-bin-changelog.152193"

No entanto, o RDS não fornece File_priv ou Super_priv ao usuário principal.

Eu gostaria de pensar que este é o lugar onde o espaço em disco se foi .. no entanto, 2064636 é apenas cerca de 2Mb ... Então, voltando à prancheta?

    

Answer 1

Você pode verificar seu período de retenção do log binário pelo seguinte comando no MySQL:

mysql> call mysql.rds_show_configuration;

Para definir o período de retenção para 1 dia, use o comando:

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

O que significa que o servidor MySQL irá limpar o log binário todos os dias.

Além disso, o log binário, eu acho que você pode verificar a configuração de innodb_file_per_table , todos os dados serão armazenados no arquivo ibdata se ele for atribuído com "0".

Sugiro que você atribua a opção "1" para que sua tabela seja armazenada separadamente e você possa recuperar seu espaço usado por:

mysql> OPTIMIZE TABLE <table_name>

Verifique os links de referência abaixo para ver se eles refletem seu problema:

Por que o ibdata1 arquivo crescendo continuamente no MySQL?

Mais uma coisa, de acordo com o site, você terá um arquivo ibdata1 de rápido crescimento porque você tem uma transação longa. Tente enviá-los o mais rápido possível para evitar a execução da restauração do sistema para recuperar espaço.

    

Answer 2

Eu acho que o espaço livre perdido reside nos arquivos tablespace do mecanismo de armazenamento InnoDB. Depois de conversar com o suporte da AWS, eles sugeriram que eu os recriamos configurando uma nova instância despejando todos os dados e importando para essa nova instância e, em seguida, alternando. Criar uma réplica de leitura não funciona nesse caso, pois as réplicas de leitura usam o mesmo armazenamento com a instância do mestre ao serem criadas.

Nesse processo, tive que configurar a replicação manualmente. Eu segui o guia aqui ( link ) e criou um script para automatizar esse processo. Você pode encontrá-lo em:

link