Documentazione dell'infrastruttura Oracle Cloud

Informazioni su Autonomous Data Guard con standby tra più aree

Fornisce informazioni sulle funzioni e sul funzionamento di Autonomous Data Guard con un database di standby tra più aree o tra più tenancy.

Quando aggiungi un database di standby in un'altra area, se l'istanza primaria diventa inattiva, Autonomous Data Guard fornisce un database di standby fisicamente separato in un'area remota. Il database di standby è disponibile per assumere il ruolo dell'istanza primaria non disponibile. Quando aggiungi un database di standby in una tenancy diversa, Autonomous Data Guard fornisce un database di standby che si trova in una tenancy diversa. Il database di standby è disponibile per assumere il ruolo dell'istanza primaria non disponibile.

Un database di standby tra più aree è una replica del database primario e può essere utilizzato per il recupero in caso di errore o quando il database primario non è disponibile. L'abilitazione di Autonomous Data Guard con uno standby tra più aree fornisce una soluzione RTO bassa per il disaster recovery nel caso in cui un'intera area non sia disponibile o quando il database primario è inattivo per qualsiasi motivo.

I database di standby tra più aree di Autonomous Data Guard comportano il costo aggiuntivo delle CPU di base e il doppio dello storage del database primario, incluso qualsiasi uso dello storage con scala automatica, fatturato sul database peer remoto. Le CPU con scala automatica del database primario non vengono fatturate in modo aggiuntivo nel database peer remoto. Il numero di CPU di base viene specificato dal numero di ECPU (OCPU se il database utilizza OCPU) come mostrato nel campo Conteggio ECPU (Conteggio OCPU) della console di Oracle Cloud Infrastructure.

Autonomous AI Database ti consente di creare uno o più database peer di disaster recovery remoti, a seconda del tuo modello di computazione:

  • Modello di computazione OCPU: puoi aggiungere un database in standby remoto in un'area abbinata. Le aree abbinate sono aree remote in cui è possibile creare un peer tra più aree.

  • Modello di computazione ECPU: puoi aggiungere più peer di disaster recovery remoti, con un massimo di un peer in ogni area remota accoppiata. Ad esempio, se il database primario si trova nell'area IAD, è possibile aggiungere un database in standby in PHX e un database in standby in SJC, ma non è possibile aggiungere due peer di disaster recovery remoti in PHX.

Le region abbinate sono region remote in cui puoi creare un database di standby tra più aree. Per ulteriori informazioni sulle region abbinate, consulta la sezione relativa alle aree abbinate ad Autonomous AI Database Cross-Region.

È possibile eseguire quasi tutte le operazioni, ad esempio lo scale-up del conteggio ECPU (conteggio OCIPU se il database utilizza le OCPU) e l'abilitazione della scala automatica di computazione nel database primario. Autonomous Data Guard esegue quindi le stesse azioni sul database di standby tra più aree.

Dopo aver aggiunto un database in standby remoto, Autonomous AI Database fornisce l'accesso al database in standby remoto dalla console di Oracle Cloud Infrastructure. Autonomous AI Database fornisce l'accesso al database di standby remoto in modo da poter eseguire alcune operazioni in modo indipendente sul database di standby remoto, come la configurazione di reti e VCN per gli endpoint privati e l'aggiunta di tag per definire chiavi e valori non replicati tra il database primario e il database di standby remoto.

Nota

Autonomous Data Guard non esegue il failover automatico per uno standby tra più aree. Se il database primario non è disponibile e uno standby locale non è disponibile, è possibile eseguire un failover manuale per fare in modo che un database di standby tra più aree assuma il ruolo primario.

Non è possibile connettersi a uno standby tra più aree mentre opera come database di standby e non è disponibile per le operazioni di sola lettura. È possibile connettersi al database nei seguenti casi:

Le seguenti aree presentano differenze per il failover o lo switchover dal database primario a un database in standby remoto, se confrontate con il failover o lo switchover a uno standby locale:

  • Nome visualizzato: il nome visualizzato ha un'estensione "_region". Dove regione è il nome dell'area, ad esempio IAD o BOM.

    Se il peer tra più aree è stato creato prima dell'introduzione del supporto per più pari livello tra più aree, il nome visualizzato del peer tra più aree ha un'estensione "_Remote".

  • Notebook OML: dopo uno switchover o un failover tra più aree, i notebook OML del database primario di cui è stato eseguito lo switchover o il failover non sono presenti nel database primario (il database primario corrente dopo la modifica del ruolo). È possibile creare nuovi notebook OML.

  • Endpoint privato: è possibile configurare e aggiornare in modo indipendente gli endpoint privati su un database di standby prima del failover o prima di eseguire uno switchover. Ciò consente di disporre di un endpoint privato configurato in modo diverso, dopo il failover o dopo l'esecuzione dello switchover. Autonomous AI Database non mantiene sincronizzata la configurazione di rete dal database primario a quello remoto.

    Il peering VCN e l'inoltro del dominio sono necessari affinché i wallet funzionino in tutte le region, con database AI autonomi con un endpoint privato con standby Autonomous Data Guard, in cui il database primario e in standby si trovano in VCN diverse. See Remote VCN Peering using an RPC and DNS in Your Virtual Cloud Network for information on VCN peering and domain forwarding.

  • Elenco di controllo dell'accesso di rete: per impostazione predefinita, un database primario di disaster recovery e i database peer remoti utilizzano le stesse liste di controllo dell'accesso di rete (ACL, Network Access Control List). Se si desidera, è possibile modificare in modo indipendente le ACL di rete su un database peer remoto. Ciò consente di utilizzare ACL diverse in un database peer remoto.

    Per ulteriori informazioni, vedere Gestire le ACL di rete peer remoto.

  • Tag: le tag vengono gestite in modo indipendente su un database primario di disaster recovery e su un database peer remoto. Ciò significa che:

    • Quando si aggiunge, rimuove o aggiorna una tag su un peer remoto, la modifica si applica solo al database peer remoto.

    • Quando si aggiunge, aggiorna o rimuove una tag nel database primario, la tag non viene aggiunta, aggiornata o rimossa nei database peer remoti.

  • API o script: qualsiasi API o script utilizzato per gestire Autonomous AI Database potrebbe dover essere aggiornato per chiamare le API nel database primario.

    Puoi anche utilizzare variabili di sostituzione predefinite negli URL Oracle Cloud Infrastructure (OCI) per il failover tra più aree per Autonomous AI Database quando utilizzi le API REST OCI. Per ulteriori informazioni, vedere Variabili di sostituzione negli URL di Oracle Cloud Infrastructure (OCI).

    Per le connessioni mTLS, è necessario scaricare un wallet dal database primario, dal database primario corrente, dopo un failover o dopo aver eseguito uno switchover. Per ulteriori informazioni, vedere Stringhe e wallet di connessione di disaster recovery tra più aree.

  • Applicazioni client: le applicazioni client devono connettersi utilizzando le stringhe di connessione e il wallet scaricato dal database primario, dal database primario corrente, dopo un failover o dopo l'esecuzione di uno switchover. Per ulteriori informazioni, vedere Stringhe e wallet di connessione di disaster recovery tra più aree.

  • Connessioni basate su wallet: è necessario scaricare un wallet e connettersi utilizzando le stringhe di connessione del database primario, il database primario corrente, per connettersi al database dopo un failover o dopo l'esecuzione di uno switchover. Per ulteriori informazioni, vedere Stringhe e wallet di connessione di disaster recovery tra più aree.

  • Autonomous AI Database Strumenti: gli strumenti hanno URL diversi nel database primario, nel database primario corrente, dopo un failover o dopo l'esecuzione di uno switchover (gli URL degli strumenti non cambiano per uno switchover o un failover in uno standby locale):

    • Azioni database

    • Oracle APEX

    • Oracle REST Data Services (ORDS)

    • Graph Studio

    • Oracle Machine Learning Notebooks

    • Trasformazioni dei dati

    • API MongoDB

  • Uso di Oracle Cloud Infrastructure Object Storage: dopo aver eseguito il failover o lo switchover dal database primario a un database in standby, nel database primario (il database primario corrente) le credenziali e gli URL che forniscono l'accesso allo storage degli oggetti continuano a funzionare come prima del failover o dello switchover, fornendo l'accesso a quanto segue:

    • Tabelle esterne

    • Tabelle partizionate esterne

    • Tabelle partizionate ibride esterne

    Nota

    Ciò si applica quando lo storage degli oggetti è disponibile. Per scenari rari in cui lo storage degli oggetti non è disponibile, Oracle consiglia di disporre di backup o repliche dello storage degli oggetti in un'area diversa. Se lo storage degli oggetti non è disponibile, ovvero la risorsa di storage degli oggetti utilizzata con il primario prima di uno switchover o di un failover, è possibile aggiornare le credenziali utente e i parametri che impostano gli URL per lo storage degli oggetti in modo che i parametri specifichino i valori per accedere allo storage degli oggetti di un'area disponibile. Per ulteriori informazioni, vedere Utilizzo della replica.

Autonomous Data Guard tra tenancy con standby tra più aree

Puoi abilitare Autonomous Data Guard tra tenancy con uno standby tra più aree. Quando aggiungi un database di standby Autonomous Data Guard tra tenancy in un'altra area, Autonomous AI Database esegue il provisioning di un database di standby tra più aree nella tenancy di destinazione. Con uno standby Autonomous Data Guard tra tenancy, puoi eseguire il failover, eseguire lo switchover o creare uno standby snapshot con uno standby tra più aree in una tenancy diversa. Questa funzione consente di utilizzare Autonomous Data Guard per eseguire la migrazione di un database in una tenancy diversa.

Per ulteriori informazioni, vedere Usa un database di standby Autonomous Data Guard cross-tenancy.

OCI Full Stack Disaster Recovery con un Autonomous Data Guard Cross-Region Standby

Quando Full Stack Disaster Recovery è abilitato, la pagina dei dettagli di Autonomous AI Database, in Disaster recovery, mostra il campo Full Stack DR come Abilitato.


Segue la descrizione di adb_full_stack_dr_enabled.png
Descrizione dell'immagine adb_full_stack_dr_enabled.png

Per ulteriori informazioni, consulta Usa OCI Full Stack Disaster Recovery con Autonomous AI Database.

Argomenti

Argomento padre: Utilizzare i database in standby con Autonomous Data Guard per il disaster recovery

Ruolo di Autonomous Data Guard Database

Dopo aver aggiunto un database di standby tra più aree, ogni database ha un ruolo designato: standby primario, standby o standby snapshot.

Il ruolo specifica lo stato corrente di un database, un database primario, uno standby o uno standby snapshot e questo valore cambia dopo aver eseguito uno switchover o un failover o dopo aver convertito un database di standby in uno standby snapshot. È possibile visualizzare il ruolo di Autonomous AI Database nell'icona che mostra accanto al nome visualizzato nella pagina Informazioni su Autonomous AI Database. Ad esempio:

Segue la descrizione di adb_adg_primary.png
Descrizione dell'immagine adb_adg_primary.png

Segue la descrizione di adb_adg_standby.png
Descrizione dell'immagine adb_adg_standby.png

Dopo aver aggiunto un database di standby tra più aree, è possibile visualizzare il ruolo nell'area Disaster recovery nella pagina dei dettagli. Il ruolo è uno dei seguenti:

  • In Ruolo viene visualizzato Principale nel database primario.

  • Dopo uno switchover o un failover, nello stesso database il ruolo mostra Standby.

  • Dopo aver convertito un peer tra più aree in uno standby snapshot, il ruolo viene visualizzato come Standby snapshot.

Per visualizzare i dettagli di un peer, nella pagina dei dettagli di Autonomous AI Database selezionare la scheda Disaster recovery. La lista mostra le informazioni sul database peer e la colonna Ruolo peer mostra il ruolo peer:

  • In standby (locale): la colonna ruolo peer mostra In standby e il database ha lo stesso nome visualizzato nella colonna Autonomous Database peer. La colonna Area mostra il nome dell'area corrente.

  • In standby (tra più aree) la colonna Ruolo peer mostra In standby per un database in standby remoto e il database ha lo stesso nome con un'estensione "_regione" nella colonna Peer Autonomous Database. È possibile fare clic sul collegamento per accedere al database remoto. La colonna Area mostra il nome dell'area remota.

    Se il peer tra più aree è stato creato prima dell'introduzione del supporto per più pari livello tra più aree, il nome visualizzato del peer tra più aree ha un'estensione "_Remote".

  • Standard snapshot: la colonna Ruolo peer mostra Standard snapshot. La colonna Area mostra il nome dell'area remota.

Failover e switchover tra più aree di Autonomous Data Guard

Puoi avere un peer di disaster recovery locale e, facoltativamente, puoi aggiungere uno o più peer tra più aree (più peer tra più aree sono consentiti con il modello di computazione ECPU). In entrambi i casi locali e tra più aree, il peer può essere una copia di Disaster Recovery basata su backup o uno standby Autonomous Data Guard.

Con un'area corrente e uno o più database peer Autonomous Data Guard tra più aree, a seconda dello stato del database primario, hai le seguenti opzioni:

  • Se il database primario diventa inattivo e il database di standby locale è disponibile, Autonomous Data Guard esegue automaticamente il failover per convertire il database di standby locale nel database primario, con un'interruzione minima. Al termine del failover, Autonomous Data Guard crea automaticamente un nuovo database di standby locale. Se il failover automatico non è possibile, è possibile eseguire un failover manuale.

    Autonomous Data Guard continua a utilizzare gli stessi database peer tra più aree.

  • Se il database primario diventa inattivo e il database in standby locale non è disponibile, è possibile eseguire un failover manuale in un database peer tra più aree e il database peer tra più aree di cui si esegue il failover diventa il database primario.

    In questo caso, una volta completato il failover, Autonomous Data Guard non crea un nuovo database di standby locale (per impostazione predefinita, si dispone di un peer di copia di backup).

  • È possibile eseguire un'operazione di switchover, in cui il database primario diventa il database di standby locale e il database di standby locale diventa il database primario.

    Autonomous Data Guard continua a utilizzare gli stessi database peer tra più aree.

  • È possibile eseguire un'operazione di switchover, in cui un database peer tra più aree diventa il database primario e il database che era il database primario viene ricreato come nuovo database di standby in modo che diventi un database peer.

    Uno switchover modifica i ruoli del database primario e di un database peer. Se si esegue uno switchover due volte tra le stesse due aree remote, il database primario torna a essere di nuovo il database primario.

Backup e ripristino tra più aree di Autonomous Data Guard Database

Dopo aver aggiunto un database di standby tra più aree Autonomous Data Guard, il backup e il ripristino dal backup vengono gestiti come indicato di seguito.

  • Se il database primario viene ripristinato da un backup, viene creato un nuovo standby remoto dal database primario ripristinato.

  • I backup automatici vengono eseguiti solo sul database primario (il database che mostra il ruolo: principale). Ad esempio, dopo uno switchover o un failover, il database con il ruolo Primary inizia a eseguire i backup automatici. Un database con il ruolo In standby non esegue più i backup. Se si esegue di nuovo lo switchover, il database che diventa il database dei ruoli Principale inizia a eseguire di nuovo i backup.

  • Non è possibile eseguire il ripristino o la copia da un backup quando un database peer si trova nel ruolo In standby. I backup vengono eseguiti solo sul database nel ruolo Principale e l'operazione di ripristino non è disponibile nella console di Oracle Cloud Infrastructure in un database Standby.

Stringhe e wallet di connessione Disaster Recovery tra più aree

Quando si aggiunge un database di standby tra più aree (remote) di Autonomous Data Guard o si utilizza un peer di Disaster Recovery basato su backup tra più aree, il wallet e la stringa di connessione del database primario contengono solo il nome host del database primario.

Inoltre, il wallet e la stringa di connessione da un database peer remoto contengono solo il nome host del database remoto. Ciò vale sia per i wallet delle istanze che per quelli regionali.

Oracle consiglia di configurare le applicazioni in esecuzione nel database dei ruoli primari in modo che utilizzino il wallet o la stringa di connessione scaricati dal database primario. Per le applicazioni eseguite su un database remoto, utilizzare il wallet o la stringa di connessione scaricata dal database remoto (dove il database remoto è il database primario corrente dopo un failover o dopo l'esecuzione di uno switchover). È possibile ottenere queste stringhe di connessione o il wallet facendo clic su Connessione al database nella console di Oracle Cloud Infrastructure.

Ad esempio, se Autonomous Data Guard tra più aree è impostato con il database primario in Ashburn (IAD) e un database di standby tra più aree in Phoenix (PHX), Oracle consiglia di utilizzare le applicazioni di livello intermedio in esecuzione in IADstringa di connessione o wallet dal database primario in IAD e dalle applicazioni corrispondenti che vengono eseguite in PHX dopo un failover o dopo aver eseguito uno switchover, utilizzare la stringa di connessione o il wallet dal database di standby in PHX. Durante il failover o lo switchover regionale, Oracle consiglia di eseguire il failover del database e delle applicazioni di livello intermedio sul nuovo database dei ruoli primario per ottenere prestazioni ottimali e ridurre al minimo qualsiasi latenza tra più aree.

Per ulteriori informazioni, vedere Scarica credenziali client (wallet).

Se richiesto dall'applicazione, è possibile creare manualmente stringhe di connessione contenenti nomi host del database primario e remoto, per supportare la connessione a un'istanza disponibile e aperta per le connessioni automaticamente, al database primario o remoto.

Per i dettagli sui passi per creare manualmente queste stringhe di connessione, vedere:

Autonomous Data Guard tra più aree con chiavi di cifratura gestite dal cliente

Quando aggiungi un standby tra più aree di Autonomous Data Guard, sono presenti considerazioni speciali quando il database primario utilizza chiavi di cifratura gestite dal cliente o se si desidera passare all'uso di chiavi di cifratura gestite dal cliente nel database primario.

Nota

Autonomous AI Database supporta più provider di chiavi gestite dal cliente. Solo Oracle Cloud Infrastructure Vault è supportato per l'uso con Autonomous Data Guard. Altri vault non sono supportati per le chiavi gestite dal cliente.

Affinché uno standby remoto possa utilizzare la stessa chiave di cifratura master del database primario, è necessario replicare la chiave di cifratura master nell'area remota. Le chiavi di cifratura gestite dal cliente sono supportate solo con un singolo standby Autonomous Data Guard tra più aree. Più standby tra più aree non sono supportati perché Oracle Cloud Infrastructure Vault supporta solo la replica in un'area remota.

Considerare i seguenti casi:

  • L'aggiunta di un standby remoto Autonomous Data Guard è consentita se Autonomous AI Database utilizza chiavi gestite dal cliente. Quando il database utilizza una chiave gestita dal cliente e si aggiunge un standby tra più aree di Autonomous Data Guard, la lista Area nella finestra di dialogo Aggiungi database peer mostra solo le aree che contengono il vault e le chiavi replicati. Se non viene visualizzata un'area remota elencata, devi replicare il vault e le chiavi nell'area in cui desideri il database in standby (questa deve essere un'area abbinata).

  • Il passaggio alle chiavi gestite dal cliente è consentito sul database primario quando si dispone di un standby tra più aree di Autonomous Data Guard. Nel caso in cui il database utilizzi chiavi gestite da Oracle e passi a chiavi gestite dal cliente sul database primario, vengono visualizzate solo le chiavi replicate sia nell'area primaria che in quella in standby. Le liste Gestisci chiave di cifratura Vault e Chiave di cifratura primaria mostrano solo vault e chiavi replicati nelle region primarie e in standby. Se non viene visualizzata una chiave elencata, replicare il vault e le chiavi in un'area associata.

Per ulteriori informazioni, vedere gli argomenti riportati di seguito.

Cross Tenancy Autonomous Data Guard con chiavi di cifratura gestite dal cliente

Quando aggiungi un standby tra tenancy Autonomous Data Guard, sono presenti considerazioni speciali quando il database primario utilizza chiavi di cifratura gestite dal cliente o se si desidera passare all'uso di chiavi di cifratura nel database primario.

Quando aggiungi uno standby cross-tenancy Autonomous Data Guard per una maggiore sicurezza, ad esempio per proteggerti dal ransomware, se il primario utilizza una chiave gestita dal cliente, puoi replicare la chiave di cifratura e utilizzarla in standby. È necessario utilizzare la stessa chiave di cifratura, sia essa una chiave gestita da Oracle o una chiave gestita dal cliente, sia nella tenancy primaria che in quella in standby. Poiché ogni tenancy dispone di una copia indipendente della chiave, la disabilitazione o l'eliminazione della chiave in una tenancy non ha effetto sull'altra.

Nota

Autonomous AI Database supporta più provider di chiavi gestite dal cliente. Solo Oracle Cloud Infrastructure Vault è supportato per l'uso con Autonomous Data Guard. Altri vault non sono supportati per le chiavi gestite dal cliente sul database primario o in standby con Autonomous Data Guard.

Per ulteriori informazioni, consulta le note per le chiavi di cifratura gestite dal cliente con un standby Autonomous Data Guard cross-tenancy.

Replica dei backup in un database di standby Autonomous Data Guard tra più aree

Quando aggiungi un database di standby Autonomous Data Guard tra più aree, puoi abilitare la replica di backup tra più aree in modo che i backup automatici dal database primario siano disponibili anche in un'area remota.

Per impostazione predefinita, i backup eseguiti sul database primario non vengono replicati in un database di standby tra più aree. Quando abiliti la replica di backup tra più aree, fino a 7 giorni di backup automatici per il database primario vengono replicati in un database di standby tra più aree. Quando questa funzione è abilitata, i backup automatici sono disponibili nell'area remota come indicato di seguito.

  • Dopo uno switchover o un failover, è possibile ripristinare o duplicare qualsiasi indicatore orario negli ultimi sette (7) giorni o qualsiasi indicatore orario nel periodo di conservazione specificato quando il periodo di conservazione è impostato su meno di sette giorni.

  • Tutti i backup per il primario replicati nell'area remota vengono eliminati nel peer dell'area remota dopo sette giorni o dopo il numero di giorni del periodo di conservazione quando il periodo di conservazione è impostato su meno di sette giorni.

  • Non puoi modificare il periodo di conservazione dei backup per i backup replicati, tranne se modifichi il periodo di conservazione dei backup nel database primario per specificare un valore inferiore a sette giorni. In questo caso, il periodo retention per i backup replicati nell'area remota corrisponde al periodo retention backup automatico impostato nel database primario.

La replica del backup tra più aree comporta un costo aggiuntivo. Per ulteriori informazioni, consulta Oracle Autonomous Database Serverless Features Billing.

Per ulteriori informazioni, vedere Aggiungere un database in standby tra più aree e Abilitare o disabilitare la replica di backup per un database in standby tra più aree esistente.

Tenere presente quanto riportato di seguito per la replica di backup automatico tra più aree.

  • Dopo uno switchover o un failover, mentre il database tra più aree si trova nel ruolo primario, i backup vengono eseguiti sul database primario corrente e vengono replicati nel database di standby (remoto) corrente.

  • In un'area remota è possibile creare una copia da un backup replicato mentre il database si trova nel ruolo In standby.

Licenza BYOL per Autonomous Data Guard tra più aree

Il limite ECPU BYOL impostato su un database primario Autonomous Data Guard non si applica a un database in standby Autonomous Data Guard tra più aree o tra più tenancy.

In uno standby tra più aree o cross-tenancy puoi impostare in modo indipendente il limite ECPU BYOL, a seconda delle esigenze. L'impostazione di un valore per il limite di licenze BYOL limita il numero di ECPU coperte dalle licenze BYOL.

Ad esempio, prendi in considerazione un database primario Autonomous Data Guard da 8 ECPU che utilizza la licenza BYOL. Quando aggiungi un database in standby tra più aree o tenancy, il database in standby acquisisce la relativa licenza dal database primario (utilizzando la licenza BYOL).

In questo esempio, se si imposta il limite di licenza BYOL su 4 (ECPU) nel database primario, 4 delle 8 ECPU utilizzano la licenza BYOL. Tuttavia, il limite di licenza BYOL impostato sul database primario non si applica in standby tra più aree o tra tenancy. La licenza Bring Your Own License (BYOL) (senza un limite di licenza BYOL). Se si imposta separatamente un limite di licenza BYOL per lo standby, ad esempio se si imposta il valore Limite di licenza BYOL su 2 (ECPU), 2 ECPU nello standby vengono fatturate utilizzando la licenza BYOL e 6 ECPU. Analogamente, il limite ECPU BYOL impostato in Standby non ha effetto sul limite ECPU BYOL del database primario.

Per ulteriori informazioni, consulta la sezione Scegli l'opzione Bring Your Own License durante il provisioning o la clonazione e Scegliere Bring Your Own License su Autonomous AI Database (ECPU Compute Model).