Documentazione dell'infrastruttura Oracle Cloud

Informazioni sui database in standby

Fornisce informazioni sull'abilitazione e sull'uso di Autonomous Data Guard per il disaster recovery su Autonomous AI Database.

Quando utilizzi Autonomous Data Guard, il sistema crea un database di standby che viene aggiornato continuamente con le modifiche del database primario. Puoi utilizzare Autonomous Data Guard con un database in standby nella region corrente, un database in standby locale o con uno o più database in standby in region diverse, database in standby tra più region oppure puoi aggiungere sia un database in standby locale che uno o più database in standby remoto.

Puoi anche creare un standby Autonomous Data Guard, locale o remoto in una tenancy diversa.

Scegliendo tra le opzioni di disaster recovery offerte da Autonomous AI Database, puoi scegliere le funzioni e le opzioni che soddisfano i requisiti RTO (Recovery Time Objective) e RPO (Recovery Point Objective).

Per impostazione predefinita, ogni istanza di Autonomous AI Database fornisce un database peer di disaster recovery basato su backup locale.

Per aggiungere il failover automatico e ridurre l'obiettivo RTO (Recovery Time Objective), puoi utilizzare un database di standby Autonomous Data Guard locale.

Per utilizzare l'opzione di disaster recovery più resiliente offerta da Autonomous AI Database, puoi aggiungere un database di standby Autonomous Data Guard locale e uno o più database di standby Autonomous Data Guard tra più aree.

Inoltre, altre opzioni che utilizzano il disaster recovery basato su backup ti consentono di fornire opzioni di disaster recovery RTO (Recovery Time Objective) a costi inferiori e più elevati rispetto ad Autonomous Data Guard. Vedere Usa Disaster Recovery basato sul backup per i dettagli sul Disaster Recovery basato sul backup.

Argomenti

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

Autonomous Data Guard con standby locale

Quando utilizzi un database di standby Autonomous Data Guard nell'area corrente, Autonomous AI Database esegue il provisioning di un database di standby locale e monitora il database primario; se il database primario diventa inattivo, l'istanza di standby assume automaticamente il ruolo dell'istanza primaria.

I database peer Autonomous Data Guard locali comportano il costo aggiuntivo delle CPU di base e dello storage del database primario, incluso qualsiasi uso dello storage con scala automatica, fatturato sul database primario stesso. Le CPU con scala automatica del database primario non vengono fatturate in modo aggiuntivo nel database peer Autonomous Data Guard locale. Per ulteriori informazioni, consulta Oracle Autonomous Database Serverless Features Billing.

L'aggiunta di un database di standby locale fornisce un database di standby identico che consente, a seconda dello stato del database primario, di:

  • Se il database primario diventa inattivo, Autonomous Data Guard converte il database di standby in database primario con un'interruzione minima. Al termine del failover, Autonomous Data Guard crea automaticamente un nuovo database di standby.

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

Autonomous AI Database non fornisce l'accesso a un database di standby nell'area corrente. Si eseguono 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, e Autonomous Data Guard esegue quindi le stesse azioni nel database di standby locale. Allo stesso modo, si eseguono solo azioni quali l'arresto o il riavvio del database nel database primario.

Un database di standby locale viene creato nella stessa area del database primario (area corrente). Per una migliore resilienza, viene eseguito il provisioning del database in standby come indicato di seguito.

  • Nelle aree con più domini di disponibilità, il provisioning di un database in standby locale viene eseguito automaticamente in un dominio di disponibilità diverso da quello del database primario.

  • Nelle aree con un singolo dominio di disponibilità, il provisioning di un database in standby locale viene eseguito automaticamente in un dominio di errore diverso da quello del database primario, ovvero in una macchina fisica diversa.

Per ulteriori informazioni sui domini di disponibilità, vedere Visualizza informazioni di rete nella console OCI e Aree e domini di disponibilità.

Tutte le funzioni di Autonomous AI Database del database primario sono disponibili quando l'istanza di standby locale diventa primaria, dopo il guasto del sistema o dopo l'esecuzione di un'operazione di switchover, tra cui:

  • Opzioni del database: le opzioni di licenza Conteggio ECPU (Conteggio OCIPU se il database utilizza OCPU), Storage, Nome visualizzato, Nome database, Ridimensionamento automatico, Tag e BYOL hanno gli stessi valori dopo un failover al database in standby o dopo aver eseguito uno switchover.

  • Notebook OML: i notebook e gli utenti creati nel database primario sono disponibili in standby.

  • Dati e metadati APEX: le informazioni APEX create nel database primario vengono copiate in standby.

  • ACL: la lista di controllo dell'accesso (ACL) del database primario è duplicata per lo standby.

  • Endpoint privato: l'endpoint privato del database primario si applica allo standby.

    Oracle consiglia di utilizzare l'opzione subnet regionale per garantire disponibilità e latenza ottimali per i database in un endpoint privato quando si crea la subnet. Per ulteriori informazioni, vedere Creazione di una subnet.

  • API o script: qualsiasi API o script utilizzato per gestire Autonomous AI Database continua a funzionare senza alcuna modifica dopo un'operazione di failover o dopo aver eseguito uno switchover.

  • Connessioni alle applicazioni client: le applicazioni client non devono modificare le stringhe di connessione per connettersi al database dopo un failover al database in standby o dopo aver eseguito uno switchover.

  • Connessioni basate su wallet: è possibile continuare a utilizzare i wallet esistenti per connettersi al database dopo un failover al database in standby o dopo aver eseguito uno switchover.

Autonomous Data Guard con cross-region o cross-tenancy in standby

Puoi aggiungere un database di standby Autonomous Data Guard 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.

Per ulteriori informazioni, vedere Informazioni su Autonomous Data Guard con standby tra più aree.

Obiettivo RTO (Autonomous Data Guard Recovery Time Objective) e RPO (Recovery Point Objective)

Autonomous Data Guard monitora il database primario e, se l'istanza diventa inattiva, l'istanza di standby locale assume il ruolo dell'istanza primaria, in base al Recovery Time Objective (RTO) e al Recovery Point Objective (RPO).

Se un'istanza di standby Autonomous Data Guard locale non è disponibile e hai abilitato il disaster recovery tra più aree, puoi eseguire manualmente il failover allo standby tra più aree.

Se non aggiungi uno standby Autonomous Data Guard tra più aree, hai la possibilità di aggiungere un peer Disaster Recovery basato su backup tra più aree. Vedere RTO (Backup-Based Disaster Recovery Time Objective) e RPO (Recovery Point Objective) per dettagli su RTO e RPO con Disaster Recovery basato su backup.

L'RTO è il tempo massimo necessario per ripristinare la connettività del database a un database in standby dopo l'avvio di un failover manuale o automatico. L'RPO è la durata massima della potenziale perdita di dati nel database primario.

Standby Autonomous Data Guard locale

Quando si aggiunge un database di standby locale, Autonomous Data Guard fornisce le opzioni riportate di seguito per il failover o lo switchover.

  • Failover o switchover automatici:

    Quando abiliti Autonomous Data Guard, puoi selezionare un limite di perdita di dati. Il limite di perdita di dati predefinito per il failover automatico è 0 (i valori validi sono compresi tra 0 e 3600 secondi). Ad esempio, un limite di perdita di dati pari a 0 significa che Autonomous Data Guard esegue il failover automatico solo quando non si verifica alcuna perdita di dati. Ciò significa che se Autonomous Data Guard è in grado di verificare che non vi sia alcuna perdita di dati, non riesce automaticamente in caso di problema. Quando si verifica un problema e Autonomous Data Guard determina che la possibile perdita di dati è maggiore del limite di perdita di dati, il failover automatico non si verifica e hai la possibilità di eseguire un failover manuale.

  • Failover manuale: l'RTO è di due (2) minuti e l'RPO di 10 secondi

Standby Autonomous Data Guard tra più aree

Quando aggiungi un database di standby tra più aree, i numeri RTO e RPO per il failover al database di standby tra più aree di Autonomous Data Guard sono i seguenti:

  • Switchover: l'RTO è inferiore a dieci (10) minuti e l'RPO è zero (0).

  • Failover automatico: non disponibile

  • Failover manuale: l'RTO è inferiore a dieci (10) minuti e l'RPO è fino a un (1) minuto.

Per ulteriori informazioni, vedere gli argomenti riportati di seguito.

Operazioni di Autonomous Data Guard

Autonomous Data Guard fornisce un set di operazioni per gestire un database in standby, tra cui: abilitare, eseguire lo switchover, disconnettere o arrestare un database in standby.

Operation Descrizione
Converti in standby istantanea

La conversione di un peer di disaster recovery in uno standby snapshot apre il database in modalità di lettura-scrittura e il peer di disaster recovery tra più aree interrompe temporaneamente l'aggiornamento dei dati dal database di origine.

Per ulteriori informazioni, vedere Converti peer tra più aree in standby snapshot.

Disabilita Autonomous Data Guard

Se disponi di un database in standby locale o di un database in standby tra più aree, puoi modificare il tipo di disaster recovery in Backup-Based Disaster Recovery per lo standby locale o puoi interrompere uno standby tra più aree. In entrambi i casi, la disabilitazione di Autonomous Data Guard termina il database di standby.

Per i dettagli, vedere Aggiorna standby per utilizzare un peer di copia di backup o Disabilita un database in standby tra più aree.

Disconnetti in standby

Quando si disconnette un database in standby tra più aree, l'associazione del database in standby viene annullata dal database primario. In questo modo il database viene convertito da un database peer a un database standalone. Dopo l'operazione di disconnessione non è consentito riconnettersi al primario.

Per ulteriori informazioni, vedere Disconnetti database peer e Disconnetti database snapshot in standby.

Abilita Autonomous Data Guard

Se stai utilizzando il disaster recovery basato su backup, puoi aggiornare il tuo tipo di disaster recovery in Autonomous Data Guard locale (area corrente) oppure puoi aggiungere uno standby tra più aree di Autonomous Data Guard.

Per i dettagli, vedere Abilita Autonomous Data Guard e Aggiungi un database in standby tra più aree.

Failover - Automatico

Dopo aver aggiunto un database di standby Autonomous Data Guard locale, il sistema monitora l'istanza primaria e esegue automaticamente il failover in un database di standby locale in determinati scenari.

Per ulteriori informazioni, vedere Failover automatico con un database in standby.

Failover - Manuale

Se il database primario non è disponibile, è possibile eseguire un failover manuale per modificare i ruoli in modo da rendere un database di standby il database primario:

  • Se è disponibile uno standby locale, è possibile eseguire manualmente il failover allo standby locale (non si dispone dell'opzione per eseguire il failover a uno standby remoto se è disponibile uno standby locale).
  • Se uno standby locale non è disponibile, hai la possibilità di eseguire manualmente il failover in uno standby remoto.

Per informazioni dettagliate, vedere Eseguire un failover manuale.

Switchover

Quando Autonomous Data Guard è abilitato, lo switchover modifica i ruoli del database primario e dello standby, il database di standby diventa il database primario e il database primario diventa lo standby. Se hai sia un database di standby locale (current region) che un database di standby tra più aree (remote), puoi scegliere di eseguire lo switchover allo standby locale o allo standby remoto.

Per informazioni dettagliate, vedere Eseguire uno switchover.

Termina

Se si desidera arrestare l'istanza primaria, selezionare Altre azioni e Termina. L'arresto dell'istanza primaria termina anche un database di standby locale.

Se disponi sia di un database di standby locale (area corrente) che di un database di standby tra più aree, devi arrestare il database di standby tra più aree prima di arrestare il database primario.

Per informazioni dettagliate, vedere Terminare un database in standby tra più aree.

Stato disaster recovery di Autonomous AI Database

Autonomous AI Database fornisce informazioni sullo stato di disaster recovery nella pagina Dettagli di Autonomous AI Database.

Nell'area Disaster recovery:

Il campo Ruolo mostra il ruolo del database corrente, come indicato di seguito.

  • Quando si dispone di un peer di copia di backup locale o di uno standby Autonomous Data Guard locale, nella console di Oracle Cloud Infrastructure viene visualizzato il valore del campo Ruolo Principale. Autonomous AI Database non fornisce l'accesso a un database di standby locale (o a un peer di copia di backup locale).

  • Quando si utilizza un peer di copia di backup tra più aree o uno standby Autonomous Data Guard tra più aree, la console di Oracle Cloud Infrastructure mostra il valore del campo Ruolo Principale se si sta visualizzando il database primario e mostra In standby se si stanno visualizzando i dettagli per un database in standby.

  • Switchover: fornisce un collegamento che consente di eseguire un'operazione di switchover.

  • Failover: quando il database primario non è disponibile e si dispone di uno standby locale e di un failover automatico non riusciti, il collegamento di failover consente di avviare un failover manuale.

    Quando il database primario non è disponibile e non è possibile eseguire il failover in standby tra più aree e in standby locale, il collegamento di failover consente di avviare un failover manuale nel database di standby remoto.

Per visualizzare le informazioni su Autonomous AI Database peer, nella pagina dei dettagli di Autonomous AI Database selezionare la scheda Disaster recovery. Mostra le informazioni su Autonomous AI Database peer. La colonna Stato mostra lo stato di un database in standby, come indicato di seguito.

  • Provisioning

    • Questo stato mostra quando si abilita Autonomous Data Guard e indica che viene eseguito il provisioning di un database di standby (fino a quando lo stato del database di standby non viene modificato in Standby).

    • Questo stato viene visualizzato dopo un failover in standby locale durante la ricreazione di un database di standby locale.

    • Questo stato mostra se viene eseguita un'operazione di ripristino dal backup nel database primario, lo standby locale viene ricreato e la colonna Stato mostra il provisioning.

  • Standby: indica che un database in standby è disponibile e pronto per un'operazione di switchover o di failover.

    Nota

    Quando un database in standby viene arrestato, lo stato in standby mostra In standby. Un database in standby non mostra mai lo stato Arrestato.

  • Modifica del ruolo in corso: indica che è stata avviata un'operazione di failover o switchover.

Eventi Autonomous Data Guard

Puoi utilizzare gli eventi di Oracle Cloud Infrastructure per rispondere quando Autonomous AI Database modifica il proprio stato a causa di un evento correlato ad Autonomous Data Guard, ad esempio un'operazione di failover o switchover.

Gli eventi di Autonomous AI Database includono quanto segue:

  • Avvia failover automatico
  • Termina failover automatico
  • Inizia a disabilitare Autonomous Data Guard
  • Avvia abilitazione di Autonomous Data Guard
  • Avvia failover
  • Avvia switchover
  • Termina disabilitazione di Autonomous Data Guard
  • Termina abilitazione di Autonomous Data Guard
  • Terminare il failover con il risultato del failover di operazione riuscita o non riuscita.
  • Terminare lo switchover con il risultato dello switchover di operazione riuscita o non riuscita.

In base agli eventi è possibile eseguire azioni o inviare notifiche. Per ulteriori informazioni sull'uso degli eventi e sulla produzione delle notifiche, vedere Eventi e notifiche per un database in standby.

Metriche di Autonomous Data Guard

Puoi utilizzare le metriche di Oracle Cloud Infrastructure per monitorare Autonomous Data Guard.

Le metriche di Autonomous AI Database includono quanto segue:

  • Ritardo peer: il tempo totale in secondi durante il quale il peer di disaster recovery è in ritardo rispetto al database primario.

Per ulteriori informazioni, vedere Metriche disponibili: oci_autonomous_database.