Gestire i database primari e di standby in una configurazione Autonomous Data Guard
Scopri come gestire i database primari e in standby in una configurazione di Data Guard autonoma.
Quando crei un Autonomous AI Database in un Autonomous Container Database con Autonomous Data Guard abilitato, vengono create due copie completamente separate del database: una in un container database primario e una (copia sincronizzata) in un container database standby. Quindi, se il container database primario non è più disponibile, Autonomous Data Guard converte automaticamente il container database di standby nel container database primario e, come tale, inizia a servire le connessioni delle applicazioni all'Autonomous AI Database.
Nota: poiché quando si utilizza Autonomous Data Guard vengono creati due database AI autonomi, viene utilizzato il doppio del numero di risorse di CPU e storage, metà per il database primario e metà per il database in standby.
Questi due database, spesso chiamati database peer l'uno dell'altro, sono identificati dalle etichette Primary e Standby nella lista dei database AI autonomi e nella pagina Dettagli per il database.
Per informazioni sul modo in cui gli amministratori della flotta creano e gestiscono Autonomous Container Database con Autonomous Data Guard abilitato, vedere Gestisci Autonomous Data Guard.
Operazioni di gestione sui database primari e in standby
Poiché i due database sono collegati e sincronizzati, alcune delle operazioni di gestione eseguite sui database AI autonomi funzionano in modo diverso sui database primari e in standby in una configurazione Autonomous Data Guard rispetto AI database standard. L'elenco seguente descrive queste differenze.
-
Esegui scale-up, scale-down e scalabilità automatica
I due database peer devono avere le stesse impostazioni di conteggio CPU, dimensione di storage e scala automatica. Pertanto, è possibile eseguire lo scale up, lo scale down e modificare le impostazioni di scala automatica solo dalla pagina Dettagli del database primario. Le modifiche apportate influiscono sia sui database primari che su quelli in standby.
-
Arresta, avvia e riavvia
Lo stato del ciclo di vita dei due database peer viene mantenuto sincronizzato. Pertanto, è possibile arrestare, avviare e riavviare il database solo dalla pagina Dettagli del database primario. L'operazione eseguita interessa sia i database primari che quelli in standby.
-
Esegui backup manualmente
Puoi eseguire manualmente il backup dei database primari e in standby separatamente e in modo indipendente, proprio come se fossero database standard.
-
Ripristina
È possibile ripristinare e recuperare il database solo dalla pagina Dettagli del database primario.
-
Duplica
È possibile duplicare il database solo dalla pagina Dettagli del database primario.
-
Ruotare la chiave di cifratura
Puoi ruotare le chiavi di cifratura dei database primari e in standby separatamente e in modo indipendente, come se fossero database standard.
-
Sposta in un altro compartimento
Puoi spostare i database primari e in standby in compartimenti diversi separatamente e in modo indipendente, proprio come se fossero database standard.
-
Termina
È possibile arrestare il database solo dalla pagina Dettagli del database primario.
Accesso ai database in standby dalle applicazioni client
Quando si utilizza Autonomous Data Guard, le applicazioni client in genere si connettono ed eseguono operazioni sul database primario.
Oltre a questa normale connettività, Autonomous Data Guard ti offre la possibilità di connettere le applicazioni client che eseguono solo operazioni di sola lettura al database di standby. Per usufruire di questa opzione, le applicazioni client si connettono al database utilizzando i nomi dei servizi di database che includono "_RO" (per "sola lettura"), come descritto in Nomi dei servizi di database predefiniti per i database AI autonomi.
Tempi di ritardo monitoraggio
Man mano che i database che utilizzano Autonomous Data Guard sono in esecuzione, puoi monitorare i ritardi di trasporto e applicare i tempi di ritardo dalla pagina Dettagli del database primario o in standby facendo clic su Autonomous Data Guard.
Dovresti aspettarti di vedere fluttuazioni minori nel tempo man mano che il carico di lavoro sul tuo database diminuisce e scorre. Tuttavia, se si nota una tendenza al rialzo continua nel tempo di ritardo, è possibile eseguire queste azioni per risolvere la situazione:
-
Andamento al rialzo in ritardo applicazione. Una tendenza al rialzo continua del ritardo di applicazione indica che il database di standby non dispone di capacità sufficiente per tenere il passo con i redo record provenienti dal database primario. Per risolvere questa situazione, eseguire lo scale up delle CPU del database, come descritto in Aggiungere risorse di CPU o storage a un database AI autonomo dedicato.
-
Andamento al rialzo in ritardo trasporto. Una continua tendenza al rialzo del ritardo dei trasporti indica un problema di prestazioni della rete. Il personale operativo di Oracle Cloud monitora costantemente le prestazioni della rete, quindi dovresti vedere la situazione risolversi da sola senza intraprendere alcuna azione. Tuttavia, se lo si desidera, è possibile portare la situazione al personale operativo inviando una richiesta di servizio.