I produttori di server e i fornitori di servizi cloud offrono diversi tipi di soluzioni di archiviazione per soddisfare le tue esigenze di database. Quando acquistiamo un nuovo server o scegliamo un'istanza cloud per eseguire il nostro database, spesso ci chiediamo:quanto spazio su disco dovremmo allocare? Come scopriremo, la risposta non è banale in quanto ci sono una serie di aspetti da considerare. Lo spazio su disco è qualcosa che deve essere pensato in anticipo, perché la riduzione e l'espansione dello spazio su disco possono essere un'operazione rischiosa per un database basato su disco.
In questo post del blog, esamineremo come dimensionare inizialmente lo spazio di archiviazione e quindi pianificare la capacità per supportare la crescita del tuo database MySQL o MariaDB.
Come MySQL utilizza lo spazio su disco
MySQL memorizza i dati in file sul disco rigido in una directory specifica che ha la variabile di sistema "datadir". Il contenuto della dir dati dipenderà dalla versione del server MySQL e dai parametri di configurazione caricati e dalle variabili del server (ad es. general_log, slow_query_log, binary log).
Le informazioni di archiviazione e recupero effettive dipendono dai motori di archiviazione. Per il motore MyISAM, gli indici di una tabella sono archiviati nel file .MYI, nella directory dei dati, insieme ai file .MYD e .frm per la tabella. Per il motore InnoDB, gli indici sono archiviati nel tablespace, insieme alla tabella. Se innodb_file_per_table è impostata, gli indici saranno nel file .ibd della tabella insieme al file .frm. Per il motore di memoria, i dati vengono archiviati nella memoria (heap) mentre la struttura viene archiviata nel file .frm su disco. Nel prossimo MySQL 8.0, i file di metadati (.frm, .par, dp.opt) vengono rimossi con l'introduzione del nuovo schema del dizionario dei dati.
È importante notare che se si utilizza lo spazio tabella condiviso di InnoDB per la memorizzazione dei dati della tabella (innodb_file_per_table=OFF ), si prevede che le dimensioni dei dati fisici di MySQL crescano continuamente anche dopo aver troncato o eliminato enormi file di dati. L'unico modo per recuperare lo spazio libero in questa configurazione è esportare, eliminare i database correnti e reimportarli tramite mysqldump. Pertanto, è importante impostare innodb_file_per_table=ON se sei preoccupato per lo spazio su disco, quindi quando tronchi una tabella, lo spazio può essere recuperato. Inoltre, con questa configurazione, un'enorme operazione DELETE non libererà spazio su disco a meno che non venga eseguito OPTIMIZE TABLE in seguito.
MySQL memorizza ogni database nella propria directory nel percorso "datadir". Inoltre, i file di registro e altri file MySQL correlati come file socket e PID, per impostazione predefinita, verranno creati anche in datadir. Per motivi di prestazioni e affidabilità, si consiglia di archiviare i file di registro MySQL su un disco o una partizione separata, in particolare il registro degli errori MySQL e i registri binari.
Stima delle dimensioni del database
Il modo di base per stimare le dimensioni consiste nel trovare il rapporto di crescita tra due diversi momenti e quindi moltiplicarlo per le dimensioni del database corrente. La misurazione del traffico del database nelle ore di punta per questo scopo non è la procedura ottimale e non rappresenta l'utilizzo del database nel suo insieme. Pensa a un'operazione batch o a una stored procedure che viene eseguita a mezzanotte o una volta alla settimana. Il tuo database potrebbe potenzialmente crescere in modo significativo al mattino, prima di essere eventualmente ridotto da un'operazione di pulizia a mezzanotte.
Un modo possibile è utilizzare i nostri backup come elemento di base per questa misurazione. Il backup fisico come Percona Xtrabackup, MariaDB Backup e lo snapshot del filesystem produrrebbero una rappresentazione più accurata delle dimensioni del database rispetto al backup logico, poiché contiene la copia binaria del database e degli indici. Il backup logico come mysqldump memorizza solo istruzioni SQL che possono essere eseguite per riprodurre le definizioni degli oggetti del database e i dati delle tabelle originali. Tuttavia, puoi comunque ottenere un buon rapporto di crescita confrontando i backup di mysqldump.
Possiamo utilizzare la seguente formula per stimare la dimensione del database:
Dove,
- B - Dimensioni del backup completo della settimana corrente,
- B - Dimensioni del backup completo della settimana precedente,
- Dbdati - Dimensione totale dei dati del database,
- Dbindice - Dimensione totale dell'indice del database,
- 52 - Numero di settimane in un anno,
- S - Anno.
La dimensione totale del database (dati e indici) in MB può essere calcolata utilizzando le seguenti istruzioni:
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+L'equazione di cui sopra può essere modificata se si desidera utilizzare invece i backup mensili. Cambia il valore costante da 52 a 12 (12 mesi in un anno) e sei a posto.
Inoltre, non dimenticare di tenere conto di innodb_log_file_size x 2, innodb_data_file_path e per Galera Cluster, aggiungi gcache.size valore.
Stima dimensione log binari
I log binari vengono generati dal master MySQL per scopi di replica e ripristino point-in-time. È un insieme di file di registro che contengono informazioni sulle modifiche ai dati effettuate sul server MySQL. La dimensione dei log binari dipende dal numero di operazioni di scrittura e dal formato del log binario:STATEMENT, ROW o MIXED. Il log binario basato su istruzioni è generalmente molto più piccolo rispetto al log binario basato su riga, perché consiste solo nelle istruzioni di scrittura mentre quello basato su riga è costituito da informazioni sulle righe modificate.
Il modo migliore per stimare l'utilizzo massimo del disco dei log binari è misurare la dimensione del log binario per un giorno e moltiplicarla per expire_logs_days valore (il valore predefinito è 0 - nessuna rimozione automatica). È importante impostare expire_logs_days così puoi stimare la taglia correttamente. Per impostazione predefinita, ogni registro binario ha un limite di circa 1 GB prima che MySQL ruoti il file di registro binario. Possiamo usare un evento MySQL per svuotare semplicemente il log binario ai fini di questa stima.
Innanzitutto, assicurati che la variabile event_scheduler sia abilitata:
mysql> SET GLOBAL event_scheduler = ON;Quindi, come utente privilegiato (con privilegi EVENT e RELOAD), crea il seguente evento:
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;Per un carico di lavoro ad alta intensità di scrittura, probabilmente è necessario ridurre l'intervallo a 30 minuti o 10 minuti prima che il registro binario raggiunga la dimensione massima di 1 GB, quindi arrotondare l'output a un'ora. Quindi verifica lo stato dell'evento utilizzando la seguente istruzione e osserva la colonna LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Quindi, dai un'occhiata ai log binari che abbiamo ora:
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+Possiamo quindi calcolare la media della crescita dei nostri log binari che è di circa ~562 MB all'ora durante le ore di punta. Moltiplica questo valore per 24 ore e expire_logs_days valore:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Otterremo 94416 MB, ovvero circa ~95 GB di spazio su disco per i nostri log binari. I registri dei relè dello slave sono fondamentalmente gli stessi dei registri binari del master, tranne per il fatto che sono memorizzati sul lato slave. Pertanto, questo calcolo si applica anche ai registri dei relè slave.
Disco mandrino o stato solido?
Esistono due tipi di operazioni di I/O sui file MySQL:
- File orientati all'I/O sequenziale:
- Spazio tabella di sistema InnoDB (ibdata)
- File di registro MySQL:
- Registri binari (binlog.xxxx)
- Registri REDO (ib_logfile*)
- Registri generali
- Registri delle query lenti
- Registro errori
- File casuali orientati all'I/O:
- File di dati file per tabella InnoDB (*.ibd) con innodb_file_per_table=ON (predefinito).
Prendi in considerazione l'idea di inserire file casuali orientati all'I/O in un sottosistema di dischi a velocità effettiva elevata per ottenere le migliori prestazioni. Potrebbe trattarsi di un'unità flash:SSD o scheda NVRAM o dischi mandrino ad alto numero di giri come SAS 15K o 10K, con controller RAID hardware e unità con batteria tampone. Per i file sequenziali orientati all'I/O, l'archiviazione su HDD con cache di scrittura con batteria tampone dovrebbe essere sufficiente per MySQL. Tieni presente che se la batteria è scarica è probabile che il degrado delle prestazioni.
Tratteremo quest'area (stima della velocità effettiva del disco e dell'allocazione dei file) in un post separato.
Pianificazione e dimensionamento della capacità
La pianificazione della capacità può aiutarci a creare un server di database di produzione con risorse sufficienti per sopravvivere alle operazioni quotidiane. Dobbiamo anche provvedere a esigenze impreviste, tenere conto delle future esigenze di archiviazione e velocità effettiva del disco. Pertanto, la pianificazione della capacità è importante per garantire che il database disponga di spazio sufficiente per respirare fino al successivo ciclo di aggiornamento dell'hardware.
È meglio illustrarlo con un esempio. Considerando il seguente scenario:
- Prossimo ciclo hardware:3 anni
- Dimensione attuale del database:2013 MB
- Dimensione attuale del backup completo (settimana N):1177 MB
- Dimensione del backup completo precedente (settimana N-1):936 MB
- Dimensione delta:241 MB a settimana
- Rapporto delta:incremento del 25,7% a settimana
- Settimane totali in 3 anni:156 settimane
- Stima della dimensione totale del database:((1177 - 936) x 2013 x 156)/936 =80856 MB ~ 81 GB dopo 3 anni
Se stai usando log binari, sommalo dal valore che abbiamo ottenuto nella sezione precedente:
- 81 + 95 =176 GB di spazio di archiviazione per database e log binari.
Aggiungi almeno il 100% di spazio in più per le attività operative e di manutenzione (backup locale, gestione temporanea dei dati, registro degli errori, file del sistema operativo, ecc.):
- 176 + 176 =352 GB di spazio su disco totale.
Sulla base di questa stima, possiamo concludere che avremmo bisogno di almeno 352 GB di spazio su disco per il nostro database per 3 anni. Puoi utilizzare questo valore per giustificare l'acquisto di un nuovo hardware. Ad esempio, se desideri acquistare un nuovo server dedicato, puoi optare per 6 x 128 SSD RAID 10 con controller RAID con batteria tampone che ti darà circa 384 GB di spazio su disco totale. Oppure, se preferisci il cloud, puoi ottenere 100 GB di spazio di archiviazione a blocchi con IOPS fornito per l'utilizzo del nostro database da 81 GB e utilizzare lo spazio di archiviazione a blocchi persistente standard per i nostri registri binari da 95 GB e altri utilizzi operativi.
Buon dimensionamento!
