Perché i miei "byte di volume utilizzati" aumentano sempre sul mio cluster Amazon Aurora?


11

Ho un cluster Aurora DB Amazon (AWS) e ogni giorno [Billed] Volume Bytes Usedè in aumento.

VolumeBytesUsata metrica CloudWatch nel tempo

Ho controllato la dimensione di tutte le mie tabelle (in tutti i miei database su quel cluster) usando la INFORMATION_SCHEMA.TABLEStabella:

SELECT ROUND(SUM(data_length)/1024/1024/1024) AS data_in_gb, ROUND(SUM(index_length)/1024/1024/1024) AS index_in_gb, ROUND(SUM(data_free)/1024/1024/1024) AS free_in_gb FROM INFORMATION_SCHEMA.TABLES;
+------------+-------------+------------+
| data_in_gb | index_in_gb | free_in_gb |
+------------+-------------+------------+
| 30         | 4           | 19         |
+------------+-------------+------------+

Totale: 53 GB

Quindi perché un fatturazione di quasi 75 GB in questo momento?

Capisco che lo spazio fornito non può mai essere liberato, allo stesso modo in cui i file ibdata su un normale server MySQL non possono mai ridursi; Sono d'accordo con quello. Questo è documentato e accettabile.

Il mio problema è che ogni giorno aumenta lo spazio che mi viene addebitato. E sono sicuro che NON sto usando temporaneamente 75 GB di spazio. Se dovessi fare qualcosa del genere, capirei. È come se lo spazio di archiviazione che sto liberando, eliminando le righe dalle mie tabelle, o rilasciando le tabelle, o persino eliminando i database, non venisse mai riutilizzato.

Ho contattato il supporto AWS (premium) più volte e non sono mai stato in grado di ottenere una buona spiegazione del perché.
Ho ricevuto suggerimenti per l'esecuzione OPTIMIZE TABLEsulle tabelle in cui è presente free_space(per INFORMATION_SCHEMA.TABLEStabella) o per verificare la lunghezza della cronologia di InnoDB, per assicurarmi che i dati eliminati non siano ancora conservati nel segmento di rollback (rif: MVCC ) e riavviare le istanze per assicurarsi che il segmento di rollback sia svuotato.
Nessuno di questi ha aiutato.

Risposte:


19

Ci sono più cose in gioco qui ...

  1. Ogni tabella è memorizzata nel proprio tablespace

    Per impostazione predefinita, default.aurora5.6definisce il gruppo di parametri per i cluster Aurora (denominati ) innodb_file_per_table = ON. Ciò significa che ogni tabella è archiviata in un file separato, nel cluster di archiviazione Aurora. Puoi vedere quale tablespace viene utilizzato per ciascuna delle tue tabelle usando questa query:

    SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

    Nota: non ho provato a passare innodb_file_per_tablea OFF. Forse sarebbe d'aiuto ..?

  2. Lo spazio di archiviazione liberato eliminando i tablespace NON viene riutilizzato

    Citando il supporto premium AWS:

    A causa del design unico del motore Aurora Storage per aumentare le prestazioni e la tolleranza agli errori, Aurora non ha una funzionalità per deframmentare i tablespace file per tabella allo stesso modo di MySQL standard.

    Attualmente Aurora purtroppo non ha modo di ridurre i tablespace come fa MySQL standard e tutto lo spazio frammentato viene caricato perché è incluso in VolumeBytesUsed.
    La ragione per cui Aurora non può recuperare lo spazio di una tabella rilasciata allo stesso modo di MySQL standard è che i dati per la tabella sono archiviati in un modo completamente diverso da un database MySQL standard con un singolo volume di archiviazione.

    Se si rilascia una tabella o una riga in Aurora, lo spazio non viene recuperato sul volume del cluster Auroras a causa di questo complicato design.
    Questa incapacità di recuperare piccole quantità di spazio di archiviazione è un sacrificio fatto per ottenere ulteriori guadagni in termini di prestazioni del volume di archiviazione del cluster Auroras e la tolleranza agli errori notevolmente migliorata di Aurora.

    Ma c'è un modo oscuro per riutilizzare parte di quello spazio sprecato ...
    Ancora una volta, cita il supporto premium di AWS:

    Quando il set di dati totali supera una determinata dimensione (circa 160 GB), è possibile iniziare a recuperare spazio in blocchi da 160 GB per il riutilizzo, ad esempio se si dispone di 400 GB nel volume del cluster Aurora e DROP 160 GB o più delle tabelle che Aurora può quindi riutilizzare automaticamente 160 GB di dati. Tuttavia, può essere lento recuperare questo spazio.
    La ragione della grande quantità di dati che devono essere liberati in una sola volta è dovuta al design unico di Auroras come motore DB su scala aziendale a differenza dello standard MySQL che non può essere utilizzato su questa scala.

  3. OTTIMIZZARE TABELLA è male!

    Poiché Aurora si basa su MySQL 5.6, OPTIMIZE TABLEviene mappato ALTER TABLE ... FORCE, il che ricostruisce la tabella per aggiornare le statistiche dell'indice e liberare spazio inutilizzato nell'indice cluster. In effetti, insieme a ciò innodb_file_per_table = ON, significa che eseguire un OPTIMIZE TABLEcrea un nuovo file tablespace ed elimina quello vecchio. Poiché l'eliminazione di un file tablespace non libera lo spazio di archiviazione che stava utilizzando, ciò significa che OPTIMIZE TABLEverrà sempre eseguito il provisioning di più spazio di archiviazione. Ahia!

    Rif: https://dev.mysql.com/doc/refman/5.6/en/optimize-table.html#optimize-table-innodb-details

  4. Utilizzo di tabelle temporanee

    Per impostazione predefinita, default.aurora5.6definisce il gruppo di parametri per le istanze Aurora (denominate ) default_tmp_storage_engine = InnoDB. Ciò significa che ogni volta che creo una TEMPORARYtabella, questa viene archiviata, insieme a tutte le mie tabelle normali , nel cluster di archiviazione Aurora. Ciò significa che viene fornito nuovo spazio per contenere quelle tabelle, aumentando così il VolumeBytesUsed totale.
    La soluzione è abbastanza semplice: modificare il default_tmp_storage_enginevalore del parametro in MyISAM. Ciò costringerà Aurora a creare le TEMPORARYtabelle nella memoria locale dell'istanza.
    Da notare: l'archiviazione locale delle istanze è limitata; guarda la Free Local Storagemetrica su CloudWatch per vedere quanto spazio di archiviazione hanno le tue istanze. Le istanze più grandi (più costose) hanno più spazio di archiviazione locale.

    Rif: nessuno ancora; l'attuale documentazione di Amazon Aurora non menziona questo. Ho chiesto al team di supporto AWS di aggiornare la documentazione e aggiornerò la mia risposta se / una volta fatto.


1
Questa è un'ottima risposta e, come se non bastasse , quelli sono alcuni avvertimenti importanti. Sono contento di averlo visto.
Ceejayoz,

Idem. Ho notato che un server DB era fino a 300 GB, per un database con dimensioni riportate da MySQL di 54 GB ... se lo spazio non viene mai recuperato, questo è un buon esempio di ciò che accade quando si hanno molte tabelle scritte di frequente ( ad es. tabelle di registro, tabelle di indice, ecc.).
geerlingguy,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.