Por que meus “bytes de volume usados” sempre aumentam em meu cluster do Amazon Aurora?

Question

Eu tenho um cluster do Aurora (AWS) Aurora do banco de dados e, todos os dias, seu [Billed] Volume Bytes Used está aumentando.

Euverifiqueiotamanhodetodasasminhastabelas(emtodososmeusbancosdedadosnessecluster)usandoatabelaINFORMATION_SCHEMA.TABLES:

SELECTROUND(SUM(data_length)/1024/1024/1024)ASdata_in_gb,ROUND(SUM(index_length)/1024/1024/1024)ASindex_in_gb,ROUND(SUM(data_free)/1024/1024/1024)ASfree_in_gbFROMINFORMATION_SCHEMA.TABLES;+------------+-------------+------------+|data_in_gb|index_in_gb|free_in_gb|+------------+-------------+------------+|30|4|19|+------------+-------------+------------+

Total:53GB

Entãoporqueeuestousendofaturadoquase75GBnestemomento?

Euentendoqueoespaçoprovisionadonuncapodeserliberado,damesmaformaqueosarquivosibdataemumservidorMySQLregularnuncapodemencolher;Euestoubemcomisso.Issoédocumentadoeaceitável.

Meuproblemaéquetododia,oespaçoqueeureceboaumenta.Etenhocertezadequenãoestouusando75GBdeespaçotemporariamente.Seeufossefazeralgoassim,euentenderia.Écomoseoespaçodearmazenamentoqueestouliberando,excluindolinhasdeminhastabelas,descartandotabelasoumesmodescartandobancosdedados,nuncasejareutilizado.

EntreiemcontatocomosuportedaAWSváriasvezesenuncaconseguiumaboaexplicaçãosobreomotivo.RecebisugestõesparaexecutarOPTIMIZETABLEnastabelasnasquaishámuitofree_space(porINFORMATION_SCHEMA.TABLEStable)ouparaverificaraduraçãodohistóricodoInnoDB,paragarantirqueosdadosexcluídosaindanãosejammantidosnosegmentoderollback(ref: MVCC ) e reinicie a instância (s) para garantir que o segmento de rollback seja esvaziado.
Nenhum desses ajudou.

    

Answer 1

Há várias coisas em jogo aqui ...

1. Cada tabela é armazenada em seu próprio espaço de tabela

   Por padrão, o grupo de parâmetros para os clusters Aurora (denominado default.aurora5.6 ) define innodb_file_per_table = ON . Isso significa que cada tabela é armazenada em um arquivo separado, no cluster de armazenamento do Aurora. Você pode ver qual tablespace é usado para cada uma de suas tabelas usando esta consulta:

   SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

   Nota: Eu não tentei alterar innodb_file_per_table para OFF . Talvez isso ajudasse ..?

2. O espaço de armazenamento liberado pela exclusão de tablespaces NÃO é reutilizado

   Como citar o suporte premium da AWS:

   Due to the unique design of the Aurora Storage engine to increase its performance and fault tolerance Aurora does not have a functionality to defragment file-per-table tablespaces in the same way as standard MySQL.

   Currently Aurora unfortunately does not have a way to shrink tablespaces as standard MySQL does and all fragmented space are charged because it is included in VolumeBytesUsed.
   The reason that Aurora cannot reclaim the space of a dropped table in the same way as standard MySQL is that the data for the table is stored in a completely different way to a standard MySQL database with a single storage volume.

   If you drop a table or row in Aurora the space is not then reclaimed on Auroras cluster volume due to this complicated design.
   This inability to reclaim small amounts of storage space is a sacrifice made to get the additional performance gains of Auroras cluster storage volume and the greatly improved fault tolerance of Aurora.

   Mas há uma maneira obscura de reutilizar parte desse espaço perdido ...
   Novamente, cite o suporte premium da AWS:

   Once your total data set exceeds a certain size (approximately 160 GB) you can begin to reclaim space in 160 GB blocks for re-use e.g. if you have 400 GB in your Aurora cluster volume and DROP 160 GB or more of tables Aurora can then automatically re-use 160 GB of data. However it can be slow to reclaim this space.
   The reason for the large amount of data required to be freed at once is due to Auroras unique design as an enterprise scale DB engine unlike standard MySQL which cannot be used on this scale.

3. O OPTIMIZE TABLE é malvado!

   Como o Aurora é baseado no MySQL 5.6, OPTIMIZE TABLE é mapeado para ALTER TABLE ... FORCE , que reconstrói a tabela para atualizar estatísticas de índice e liberar espaço não utilizado no índice clusterizado. Efetivamente, junto com innodb_file_per_table = ON , isso significa executar um OPTIMIZE TABLE cria um novo arquivo de espaço de tabela e exclui o antigo. Como a exclusão de um arquivo de espaço de tabela não libera o armazenamento que estava sendo usado, isso significa que OPTIMIZE TABLE sempre resultará em mais armazenamento sendo provisionado. Ai!

   Ref: link

4. Usando tabelas temporárias

   Por padrão, o grupo de parâmetros para instâncias Aurora (denominado default.aurora5.6 ) define default_tmp_storage_engine = InnoDB . Isso significa que toda vez que eu estou criando uma tabela TEMPORARY , ela é armazenada, junto com todas as minhas tabelas regulares , no cluster de armazenamento Aurora. Isso significa que um novo espaço é provisionado para conter essas tabelas, aumentando assim o volume totalBytesUsed.
   A solução para isso é bastante simples: altere o valor do parâmetro default_tmp_storage_engine para MyISAM . Isso forçará o Aurora a criar as tabelas TEMPORARY no armazenamento local da instância.
   Nota: o armazenamento local das instâncias é limitado; Veja a Free Local Storage métrica no CloudWatch para ver quanto armazenamento suas instâncias têm. Instâncias maiores (mais caras) têm mais armazenamento local.

   Ref: nenhum ainda; a documentação atual do Amazon Aurora não menciona isso. Pedi à equipe de suporte da AWS para atualizar a documentação e atualizarei a minha resposta se / uma vez o fizerem.