Confronto tra i backup di prima e seconda generazione
Gen 2
I backup con istanze di prima generazione e quelli (snapshot) con istanze di seconda generazione differiscono sia per ambito che per meccanismo. I backup tradizionali (Gen 1) operano a livello di file, acquisendo i file di database e i log di scrittura anticipata (WAL). Questo metodo si basa su una profonda integrazione con il motore di database per garantire la coerenza transazionale e l'integrità dei dati. Al contrario, Gen 2 utilizza snapshot a livello di infrastruttura, sfruttando le funzionalità di archiviazione a blocchi e condivisione di file della VPC di IBM. Queste istantanee creano copie a livello di volume quasi istantanee, veloci, scalabili e con un impatto minimo sulle prestazioni, anche in presenza di set di dati di grandi dimensioni. Analogamente ai backup della Gen 1, ogni istanza dispone di backup pianificati che vengono eseguiti automaticamente ogni giorno durante le finestre di backup. È possibile visualizzare un elenco dei backup delle proprie istanze, avviare backup su richiesta ed eseguire il ripristino dei backup su nuove istanze.
Gen 2 offre due tipi di backup: backup accoppiati (per la maggior parte dei servizi) e backup indipendenti. I backup indipendenti sono istanze di servizio separate che permangono anche dopo la cancellazione del database, mentre i backup associati sono legati al ciclo di vita dell'istanza del database.
I backup indipendenti sono attualmente disponibili solo per Databases for MySQL. Tutti gli altri servizi di seconda generazione utilizzano backup accoppiati.
Le istanze di Gen 2 non possono essere utilizzate per ripristinare un'istanza di Gen 1, poiché il processo di ripristino dello snapshot del volume richiede immagini complete a livello di blocco anziché singoli file di database.
Principali differenze nelle caratteristiche tra la Gen 1 e la Gen 2
| Differenziatore | Gen 1 | Gen 2 |
|---|---|---|
| Meccanismo | Backup a livello di file: si tratta di backup a livello di file eseguiti copiando i singoli file del database e i segmenti WAL; per ogni file incluso nel backup vengono calcolati i checksum, che vengono ricontrollati durante le operazioni di ripristino o verifica. Il meccanismo di backup opera a livello dell'applicazione del prodotto e richiede una profonda integrazione con il motore di database per garantire la coerenza transazionale e l'integrità dei dati. | Backup a livello di infrastruttura: i backup si avvalgono di snapshot dei volumi a livello di infrastruttura che acquisiscono l'intero stato dello storage a livello di blocco, riducendo in modo significativo le finestre di backup da ore a minuti, anche per database di diverse terabyte. Questo approccio consente di creare backup quasi istantanei, indipendentemente dalle dimensioni del database. |
| Prestazioni | Influisce sulle prestazioni dei processi del database, consumando risorse di CPU e memoria. | I backup funzionano in modo indipendente dal processo del database, senza quindi influire sul consumo di CPU e RAM dei database. |
| Accesso ai ripristini | Accesso ritardato alle operazioni di ripristino. I backup richiedono il ripristino completo dei file prima dell'avvio del database. Accesso non consentito durante il periodo di ripristino. | Accesso immediato ai ripristini con prestazioni di I/O ridotte fino al completamento dell'idratazione. Ripristino di un volume da uno snapshot. |
| Recovery Time Objective (RTO) | RTO più lento. Il ripristino dell'accesso ai dati richiede un tempo che cresce in modo quasi lineare con l'aumentare del volume dei dati e, nel caso di database di grandi dimensioni, può richiedere ore. | RTO rapido: il ripristino dell'accesso ai dati richiede solo pochi minuti ed è indipendente dal volume dei dati. Tuttavia, le prestazioni di I/O potrebbero subire un temporaneo calo durante il processo di ripristino, con un impatto che varia in base alla dimensione dei dati. |
| Recovery Point Objective (RPO) | Pianificato a intervalli fissi, il che crea potenziali finestre di perdita di dati. | Può essere utilizzato frequentemente con un impatto minimo sulle prestazioni. |
| Ripristino a un punto nel tempo (PITR) | Sì | Prossima uscita. |
Funzionalità di backup indipendenti
La versione 2 introduce backup indipendenti per Databases for MySQL. Questi backup offrono funzionalità che vanno oltre quelle dei tradizionali backup accoppiati:
| Funzione | Gen 1 | Gen 2 (accoppiato) | Gen 2 (Indipendente) |
|---|---|---|---|
| Ciclo di vita | Associato all'istanza | Associato all'istanza | Indipendente dall'istanza |
| Viste a livello di account | Non supportato | Non supportato | Hub del database con vista centralizzata |
| Eliminazione dei backup | Solo automatico | Solo automatico | Manuale e automatico |
| Località di backup | Fisso | Con blocco regionale | Blocco regionale; la versione futura supporterà la copia di backup |
| Persistenza | Eliminato con l'istanza | Eliminato con l'istanza | Può essere conservato anche dopo l'eliminazione dell'istanza |
| Gestione | API per database | Solo interfaccia utente | Hub del database, Elenco delle risorse, Interfaccia utente dell'istanza |
I backup indipendenti sono attualmente disponibili solo per Databases for MySQL. Tutti gli altri servizi di seconda generazione utilizzano backup accoppiati.
Per ulteriori informazioni sui backup indipendenti, consultare la sezione " Gestione dei backup indipendenti ".
Gestione dei backup di Gen 2
Per scoprire come gestire i backup di Gen 2:
- Per " Databases for MySQL ", consultare la sezione " Gestione dei backup indipendenti ".
- Per tutti gli altri servizi di seconda generazione, consultare la sezione " Gestione dei backup ".