Questa pagina introduce le architetture di disponibilità di AlloyDB Omni che puoi utilizzare per assicurarti che il tuo database AlloyDB Omni sia ripristinabile in modo tempestivo con una perdita di dati minima o nulla.
Per garantire la continuità aziendale e ridurre al minimo la perdita di dati, l'alta disponibilità e il ripristino di emergenza sono strategie di protezione dei dati fondamentali per AlloyDB Omni. L'alta disponibilità si concentra sul mantenimento della disponibilità del database e sulla riduzione al minimo del Recovery Time Objective (RTO), mentre RE si occupa del ripristino da eventi catastrofici e della riduzione al minimo del Recovery Point Objective (RPO).
RTO e RPO sono allineati ai requisiti aziendali e sono definiti come segue:
- L'RTO è il tempo massimo in cui un database può essere inattivo o non disponibile prima che l'attività subisca conseguenze inaccettabili, come la perdita di entrate o di produttività.
- RPO è la quantità massima di perdita di dati che un'attività può subire prima che influisca sui requisiti aziendali. Ad esempio, i sistemi di inventario che richiedono un audit trail completo potrebbero richiedere una perdita di dati pari a zero.
AlloyDB Omni offre le seguenti architetture di riferimento per la disponibilità che forniscono livelli di disponibilità crescenti:
- Disponibilità standard: protegge i tuoi dati utilizzando i backup.
- Maggiore disponibilità: protegge i dati utilizzando la replica zonale in una regione (HA).
- Disponibilità Premium: protegge i dati utilizzando la replica a livello di zona e di regione (HA e RE).
Meccanismi di disponibilità
Di seguito sono riportati i principali meccanismi che garantiscono la disponibilità:
- Backup dei database
- Replica dei database
Backup dei database
I backup del database, un aspetto fondamentale della protezione dei dati, prevedono la creazione di copie fisiche dei file di dati del database. I diversi tipi di backup (completo, incrementale e differenziale) offrono diversi equilibri tra l'obiettivo del punto di ripristino (RPO), le dimensioni e la durata del backup e il tempo di ripristino.
Per garantire un ripristino efficiente e ridurre al minimo la perdita di dati in caso di guasti al sistema, una strategia di backup efficace deve includere backup sia del database sia del file di log write-ahead (WAL). I backup regolari (in genere giornalieri) dei file di dati sono fondamentali. Devi anche eseguire il backup dei file WAL, che registrano le modifiche al database e sono fondamentali per il recupero point-in-time e per mantenere l'integrità dei dati durante il ripristino.
Replica dei database
PostgreSQL offre server di replica per una maggiore affidabilità. Queste repliche sono classificate come standby caldi, che non accettano connessioni di applicazioni, o standby attivi, che operano in modalità di sola lettura. Le modifiche apportate al database primario vengono applicate continuamente alla replica per mantenere aggiornati i dati della replica. Se il database principale non funziona, la replica viene promossa a stato principale e assume le responsabilità del database principale.
Le repliche del database possono essere posizionate nella stessa zona o data center dell'istanza principale, in una zona diversa, in una regione diversa o in un mix di queste località. Più la replica si trova lontano dal database principale, maggiore è la latenza durante l'invio delle modifiche per mantenere aggiornate le repliche. Per i deployment in località distanti per mitigare errori su larga scala, come guasti regionali, la replica dei dati viene in genere eseguita in modo asincrono. Questo approccio evita il peggioramento delle prestazioni che può verificarsi in queste configurazioni.
Nelle implementazioni ad alta affidabilità, le repliche vengono in genere implementate in prossimità del database principale. Ad esempio, le repliche di cui viene eseguito il deployment in una zona diversa all'interno dello stesso data center offrono RTO bassi e RPO quasi pari a zero. D'altra parte, nelle configurazioni di ripristino di emergenza, le repliche vengono implementate in data center o regioni separati, a seconda del livello di protezione richiesto contro le interruzioni. Questo approccio comporta un RPO più elevato (poiché la replica potrebbe essere asincrona) e un RTO variabile.
La tabella seguente riassume i meccanismi utilizzati per le architetture di riferimento per l'alta disponibilità di AlloyDB Omni:
| Funzionalità | Standard | Avanzato | Premium |
|---|---|---|---|
| Backup | ✔ | ✔ | ✔ |
| Replica a livello di zona | ❌ | ✔ | ✔ |
| Replica tra zone | ❌ | ✔ | ✔ |
| Replica regionale | ❌ | ❌ | ✔ |
Tabella 1. Meccanismi di disponibilità di AlloyDB Omni supportati
Scenari di errori e recupero del database
L'errore del database può verificarsi ai seguenti livelli:
- Errore dell'istanza (nodo o server): il database stesso non funziona.
- Errore del server: il server che ospita il database non funziona.
- Errore di zona: l'intero data center che ospita il server non funziona.
- Errore della regione: l'intera regione contenente più data center (zone di disponibilità) non è disponibile, ad esempio a causa di un'inondazione o di un terremoto di forte magnitudo.
La probabilità e il rischio di un disastro diminuiscono quando si verificano meno eventi e il costo della prevenzione di questi eventi aumenta. Le aziende devono determinare la propria tolleranza al rischio e scegliere se accettare potenziali interruzioni o investire in architetture più resilienti per ridurre al minimo i rischi.
La seguente tabella riassume gli scenari di ripristino supportati dalle architetture di riferimento di AlloyDB Omni:
| Tipo di disastro | Standard | Avanzato | Premium |
|---|---|---|---|
| Errore VM/istanza | ✔ | ✔ | ✔ |
| Errore del nodo/server | ✔ | ✔ | ✔ |
| Errore zona | ❌ | ✔ | ✔ |
| Errore relativo alla regione | ❌ | ❌ | ✔ |
Tabella 2. Scenari di ripristino supportati
Considera gli obiettivi aziendali per il tuo database AlloyDB Omni, ad esempio la necessità critica di una disponibilità di diversi 9 (99,99%) e di una perdita di dati pari a zero al momento del ripristino per le applicazioni mission-critical. Lo scopo delle architetture di riferimento per la disponibilità è soddisfare i requisiti RTO e RPO.
AlloyDB Omni offre architetture di disponibilità standard, avanzata e premium per proteggere i database da interruzioni pianificate e non pianificate, in linea con le diverse esigenze aziendali. Ad esempio, gli ambienti di sviluppo potrebbero utilizzare una protezione di base con backup, mentre le applicazioni mission-critical potrebbero impiegare configurazioni di alta disponibilità e ripristino di emergenza.
Passaggi successivi
Scopri di più sulle architetture di riferimento per la disponibilità di AlloyDB Omni:
- Proteggi i tuoi dati utilizzando i backup (disponibilità standard).
- Proteggi i tuoi dati utilizzando la replica zonale in una regione (disponibilità avanzata).
- Proteggi i tuoi dati utilizzando la replica zonale e regionale (disponibilità Premium).