Backup diviso

Una strategia di backup suddiviso consiste nella migrazione di un server di database di grandi dimensioni dividendo il backup in più parti. È possibile utilizzare approcci diversi per migrare ogni parte del backup. Questa può essere l'opzione migliore per i seguenti casi d'uso:

• Server di database di grandi dimensioni ma database singoli di piccole dimensioni: questo è un buon approccio quando la dimensione del server di database totale è di più TB ma la dimensione di ogni singolo database utente indipendente è inferiore a 1 TB. Per ridurre il periodo di migrazione complessivo, è possibile migrare i singoli database separatamente e in parallelo.

  Usiamo un esempio di un server di database locale da 2 TB. Questo server è composto da quattro database da 0,5 TB ciascuno. È possibile eseguire i backup di ogni singolo database separatamente. Quando si ripristina il backup, è possibile ripristinare tutti i database su un'istanza in parallelo oppure, se i database sono indipendenti, è possibile ripristinare ogni backup su un'istanza separata. È consigliabile ripristinare database indipendenti su istanze separate, anziché ripristinarli sulla stessa istanza. Per ulteriori informazioni, consulta le procedure consigliate in questa guida.

• Server di database di grandi dimensioni ma piccole tabelle di database individuali: questo è un buon approccio quando la dimensione del server di database totale è di più TB ma la dimensione di ogni tabella di database indipendente è inferiore a 1 TB. Per ridurre il periodo di migrazione complessivo, è possibile migrare le tabelle indipendenti singolarmente.

  Usiamo un esempio di database per utente singolo di 1 TB, l'unico database in un server di database locale. Il database contiene 10 tabelle, ognuna delle quali è di 100 GB. È possibile eseguire i backup di ogni singola tabella separatamente. Quando si ripristina il backup, è possibile ripristinare tutte le tabelle su un'istanza in parallelo.

• Un database contiene tabelle di carichi di lavoro transazionali e non transazionali: analogamente al caso d'uso precedente, è possibile utilizzare un approccio di backup suddiviso quando nello stesso database sono presenti tabelle di carichi di lavoro transazionali e non transazionali.

  Prendiamo un esempio di database da 2 TB composto da 0,5 TB di tabelle di carichi di lavoro critiche utilizzate per l'elaborazione delle transazioni online (OLTP) e una singola tabella da 1,5 TB utilizzata per l'archiviazione di vecchi dati. È possibile eseguire il backup di tutti gli oggetti del database ad eccezione della tabella di archiviazione come backup coerente e a transazione singola. Quindi, si esegue solo un altro backup separato della tabella di archiviazione. Per il backup della tabella di archiviazione, puoi anche prendere in considerazione l'idea di eseguire più backup paralleli utilizzando condizioni per dividere il numero di righe nel file di backup. Di seguito è riportato un esempio:

  mysqldump -p your_db1 --tables your_table1 --where=“column1 between 1 and 1000000 " > your_table1_part1.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql

  Quando si ripristinano i file di backup, è possibile ripristinare il backup del carico di lavoro transazionale e il backup della tabella di archiviazione in parallelo.

• Limitazioni delle risorse di elaborazione: se nel server locale sono disponibili risorse di elaborazione limitate, ad esempio CPU, memoria o I/O del disco, ciò può influire sulla stabilità e sulle prestazioni durante l'esecuzione del backup. Invece di eseguire un backup completo, puoi dividerlo in parti.

  Ad esempio, un server di produzione locale potrebbe essere sovraccarico di carichi di lavoro e disporre di risorse CPU limitate. Se si esegue un backup in un'unica esecuzione di un database di più terabyte su questo server, può consumare risorse CPU aggiuntive e influire negativamente sul server di produzione. Invece di eseguire il backup completo del database, suddividetelo in più parti, ad esempio 2-3 tabelle ciascuna.