Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Emula Oracle DR utilizzando un database globale Aurora compatibile con PostgreSQL
*HariKrishna Boorgadda, Amazon Web Services*
## Riepilogo
Le migliori pratiche per il disaster recovery (DR) aziendale consistono fondamentalmente nella progettazione e implementazione di sistemi hardware e software con tolleranza ai guasti in grado di sopravvivere a un disastro (*continuità aziendale*) e riprendere le normali operazioni (ripresa *aziendale), con un intervento minimo e, idealmente, senza* perdita di dati. La creazione di ambienti con tolleranza ai guasti per soddisfare gli obiettivi aziendali di disaster recovery può essere costosa e dispendiosa in termini di tempo e richiede un forte impegno da parte dell'azienda.
Oracle Database offre tre diversi approcci al DR che offrono il massimo livello di protezione e disponibilità dei dati rispetto a qualsiasi altro approccio per la protezione dei dati Oracle.
+ Dispositivo di ripristino Oracle Zero Data Loss
+ Oracle Active Data Guard
+ Oracle GoldenGate
Questo modello fornisce un modo per emulare Oracle GoldenGate DR utilizzando un database globale Amazon Aurora. L'architettura di riferimento utilizza Oracle GoldenGate for DR in tre regioni AWS. Lo schema illustra la ripiattaforma dell'architettura di origine nel database globale Aurora nativo per il cloud basato su Amazon Aurora PostgreSQL — Compatible Edition.
I database globali Aurora sono progettati per applicazioni con un'impronta globale. Un singolo database Aurora si estende su più regioni AWS con un massimo di cinque regioni secondarie. I database globali Aurora offrono le seguenti funzionalità:
+ Replica fisica a livello di storage
+ Letture globali a bassa latenza
+ Ripristino di emergenza rapido in caso di interruzioni a livello regionale
+ Migrazioni rapide tra regioni
+ Basso ritardo di replica tra le regioni
+ Little-to-no impatto sulle prestazioni del database
Per ulteriori informazioni sulle caratteristiche e i vantaggi dei database globali di Aurora, consulta [Utilizzo dei database globali di Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database-overview). Per ulteriori informazioni sui failover non pianificati e gestiti, consulta [Uso del failover in un database globale Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-failover).
## Prerequisiti e limitazioni
**Prerequisiti**
+ Un account AWS attivo
+ Un driver PostgreSQL Java Database Connectivity (JDBC) per la connettività delle applicazioni
+ Un database globale Aurora basato su Amazon Aurora PostgreSQL Compatible Edition
+ Un database Oracle Real Application Clusters (RAC) migrato al database globale Aurora basato sulla compatibilità con Aurora PostgreSQL
**Limitazioni dei database globali Aurora**
+ I database globali Aurora non sono disponibili in tutte le regioni AWS. Per un elenco delle regioni supportate, consulta [Database globali Aurora con Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.html#Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.apg).
+ Per informazioni sulle funzionalità non supportate e altre limitazioni dei database globali di Aurora, consulta le [Limitazioni dei database globali di Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database.limitations).
**Versioni del prodotto**
+ Amazon Aurora PostgreSQL — Compatible Edition versione 10.14 o successiva
## Architecture
**Stack tecnologico di origine******
+ Database Oracle RAC a quattro nodi
+ Oracle GoldenGate
**Architettura di origine******
Il diagramma seguente mostra tre cluster con Oracle RAC a quattro nodi in diverse regioni AWS replicati utilizzando Oracle. GoldenGate
**Stack tecnologico Target**
+ Un database globale Amazon Aurora a tre cluster basato su Aurora PostgreSQL, compatibile con un cluster nella regione principale, due cluster in diverse regioni secondarie
**Architettura Target**
## Tools (Strumenti)
**Servizi AWS**
+ [Amazon Aurora PostgreSQL Compatible Edition è un motore](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html) di database relazionale completamente gestito e conforme ad ACID che ti aiuta a configurare, gestire e scalare le distribuzioni PostgreSQL.
+ I [database globali di Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) si estendono su più regioni AWS, fornendo letture globali a bassa latenza e ripristino rapido da rare interruzioni che potrebbero interessare un'intera regione AWS.
## Epiche
### Aggiungi regioni con istanze DB Reader
| Operazione | Description | Competenze richieste |
| --- | --- | --- |
| Collega uno o più cluster Aurora secondari. | Nella Console di gestione AWS, scegli Amazon Aurora. Seleziona il cluster primario, scegli **Azioni** e scegli **Aggiungi regione** dall'elenco a discesa. | DBA |
| Seleziona la classe dell'istanza. | È possibile modificare la classe di istanza del cluster secondario. Tuttavia, si consiglia di mantenerla uguale alla classe di istanza del cluster principale. | DBA |
| Aggiungi la terza regione. | Ripeti i passaggi di questa epopea per aggiungere un cluster nella terza regione. | DBA |
### Esegui il failover del database globale Aurora
| Operazione | Description | Competenze richieste |
| --- | --- | --- |
| Rimuovi il cluster primario dal database globale Aurora. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/emulate-oracle-dr-by-using-a-postgresql-compatible-aurora-global-database.html) | DBA |
| Riconfigurare l'applicazione per deviare il traffico di scrittura nel nuovo cluster promosso. | Modifica l'endpoint nell'applicazione con quello del cluster appena promosso. | DBA |
| Interrompi l'esecuzione di operazioni di scrittura sul cluster non disponibile. | Interrompi l'applicazione e qualsiasi attività DML (Data Manipulation Language) sul cluster che hai rimosso. | DBA |
| Crea un nuovo database globale Aurora. | Ora puoi creare un database globale Aurora con il cluster appena promosso come cluster primario. | DBA |
### Avvia il cluster primario
| Operazione | Description | Competenze richieste |
| --- | --- | --- |
| Seleziona il cluster primario da avviare dal database globale. | Nella console Amazon Aurora, nella configurazione di Global Database, scegli il cluster primario. | DBA |
| Avvia il cluster. | Nell'elenco a discesa **Azioni**, scegli **Avvia**. Questo processo potrebbe richiedere del tempo. Aggiorna la schermata per visualizzare lo stato oppure controlla la colonna **Status** per lo stato corrente del cluster una volta completata l'operazione. | DBA |
### Pulisci le risorse
| Operazione | Description | Competenze richieste |
| --- | --- | --- |
| Eliminare i cluster secondari rimanenti. | Una volta completato il programma pilota di failover, rimuovete i cluster secondari dal database globale. | DBA |
| Eliminare il cluster primario. | Rimuovi il cluster. | DBA |
## Risorse correlate
+ [Using Amazon Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database-detaching)
+ [Soluzioni di disaster recovery Aurora PostgreSQL che utilizzano Amazon Aurora](https://aws.amazon.com/blogs/database/aurora-postgresql-disaster-recovery-solutions-using-amazon-aurora-global-database/) Global Database (post sul blog)