Replica con standby caldo
Mantieni un sistema di database in standby in continuo aggiornamento in un'area separata utilizzando la replica PostgreSQL con standby caldo.
La replica con Warm Standby è uno strumento di disaster recovery che consente di mantenere un sistema di database in standby in continuo aggiornamento in un'area separata. Implementando questo metodo, puoi ridurre i tempi di ripristino, proteggere i tuoi dati e garantire la continuità aziendale quando si verificano interruzioni impreviste. La replica con Warm Standby supporta il disaster recovery con Recovery Point Objective (RPO) SLO sia nella stessa area che tra più aree che consente la protezione dei dati da eventi imprevisti. Lo standby caldo nella stessa area può abilitare un ulteriore ridimensionamento orizzontale in quanto un singolo sistema di database supporta solo 8 nodi.
La replica con Warm Standby migliora le seguenti funzionalità
- Disaster recovery e business continuity: replicando regolarmente i dati dall'area primaria a quella secondaria, puoi ricreare rapidamente le applicazioni in un'altra area se si verifica un errore irreversibile a livello di area.
- Migrazione ed espansione: puoi migrare ed espandere facilmente le tue applicazioni in un'altra area.
- Semplificare la compliance: le organizzazioni soggette ai requisiti normativi per l'alta disponibilità o la distribuzione geografica, come gli enti finanziari o governativi, possono soddisfare gli standard di compliance più facilmente.
Ruoli sistema di database
Se la replica con warm standby non è impostata, tutti i sistemi di database esistenti vengono considerati standalone, senza replica. Ogni sistema di database standalone funziona in modo indipendente e fornisce sia l'accesso in lettura che in scrittura (lettura/scrittura).
Quando imposti un database in standby caldo, tale database agisce nel ruolo warm standby. Il database standalone associato agisce nel ruolo sistema di database primario. Di seguito sono riportate ulteriori informazioni su questi ruoli.
- Ruolo sistema di database principale:
- Un sistema di database primario consente gli aggiornamenti dei dati tramite l'endpoint primario e la replica con l'impostazione del warm standby avrebbe un sistema di database in questo ruolo.
- Supporta operazioni di lettura e scrittura (accesso in lettura/scrittura).
- Esegue il flusso continuo dei log write-ahead (WAL) nel sistema di database in standby per la replica.
- Ruolo del sistema di database in standby caldo:
- Il sistema di database in standby caldo viene configurato nella replica tra più aree (CRR) come sistema di replica/DR.
- Viene eseguito in modalità di sola lettura per garantire la coerenza dei dati (accesso di sola lettura).
- Riceve continuamente aggiornamenti WAL dal database primario.
- Può essere promosso a sistema primario durante un evento disastroso, ma altrimenti è limitato alle query di lettura (come reporting, analytics o operazioni su scala di lettura).
Per informazioni sulla configurazione delle estensioni, vedere Configurazioni ed estensioni.
Requisiti indispensabili
Osserva e segui questi vincoli e best practice per impostare e configurare i sistemi di database primario e di standby a caldo.
Requisiti forma
È consentito selezionare qualsiasi forma eterogenea o operazione di input/output al secondo (IOPS) tra i database di standby primario e di standby caldo. Tuttavia, si consiglia di configurarle con la stessa forma e le stesse prestazioni per garantire un failover trasparente al sistema di database in standby con un profilo delle prestazioni paragonabile in caso di emergenza.
IAM
Per utilizzare i servizi Oracle Cloud Infrastructure, devi avere l'accesso di sicurezza appropriato tramite i criteri IAM. Se si ricevono errori di "autorizzazione negata" o "non autorizzata", assicurarsi di disporre dell'appartenenza al gruppo e dell'accesso al compartimento necessari.
Per accedere all'uso della replica con standby caldo, creare il criterio seguente:
Allow group <group_name> to manage { POSTGRES_DB_SYSTEM_REPLICATE } in [ tenancy | compartment <compartment_name> | compartment id <compartment_ocid> ]
Se si dispone già di un criterio che concede la gestione di postgres-db-systems a livello di database, questo criterio non è necessario, poiché POSTGRES_DB_SYSTEM_REPLICATE è già incluso nelle autorizzazioni postgres-db-systems più ampie.
Ecco un esempio del criterio più ampio:
Allow group <group_name> to manage postgres-db-systems in [ tenancy | compartment <compartment_name> | compartment id <compartment_ocid> ]
Credenziali amministratore
Gli utenti e i ruoli vengono replicati dal database primario al database di standby caldo. Il database di standby a caldo non può avere utenti o ruoli dedicati.
Il nome utente amministratore per il database di standby a caldo è uguale al nome utente amministratore definito durante la creazione del sistema di database primario.
Failover
Failover automatico non supportato. È necessario eseguire il failover manualmente promuovendo il sistema di database in standby caldo.
RPO (Recovery Point Objective)
Utilizza Recovery Point Objective (RPO) per limitare la potenziale perdita di dati quando utilizzi la replica con warm standby. Abilita o disabilita l'applicazione RPO a seconda dei requisiti del cliente, ad esempio le esigenze di disponibilità e protezione dei dati.
RPO è la quantità di dati, misurata nel tempo, che possono essere persi in caso di disastro. L'RPO viene calcolato come differenza di tempo dell'orologio a muro tra l'indicatore orario della scrittura più recente nel database e il record WAL meno recente che non è stato ancora replicato.
Di seguito sono riportate ulteriori informazioni su RPO.
-
I log write-ahead (WAL) nell'area primaria vengono replicati in modo asincrono nel warm standby nell'area secondaria.
-
RPO tiene traccia del ritardo di replica, che rappresenta la distanza dello standby rispetto al database primario.
- Valori supportati e predefiniti per la soglia di applicazione:
- Intervallo supportato: da 300 secondi (5 minuti) a 10.800 secondi (3 ore).
- Valore predefinito: 300 secondi (5 minuti).
- Quando l'applicazione RPO è abilitata:
- OCI Database con PostgreSQL valuta continuamente RPO durante il commit di una transazione.
-
Quando il ritardo della replica supera il valore RPO configurato:
-
Il sistema di database primario passa automaticamente alla modalità di sola lettura.
-
Questo switch impedisce ulteriori modifiche ai dati e un'eccessiva perdita di dati.
-
Il warm standby è consentito recuperare, dopo di che le normali operazioni riprendono.
-
-
Quando l'applicazione RPO è disabilitata:
-
Il sistema di database continua le normali operazioni anche se il ritardo di replica supera l'RPO configurato.
-
Il database primario non passa alla modalità di sola lettura.
-
Versioni del database supportate per il riscaldamento in standby
La funzione di standby caldo richiede che i sistemi di database primario e di standby caldo abbiano una versione di database uguale o superiore a 14.
Configurazioni ed estensioni
Le estensioni installate nel sistema di database primario devono essere sempre uguali o subset di quelle applicate nel sistema di database in standby caldo.
È possibile creare configurazioni per il sistema di database di standby a caldo nell'area di replica. Queste configurazioni non vengono replicate automaticamente dai sistemi di database primario ai sistemi di database in standby caldo come parte dell'impostazione Replication with Warm Standby.
Impostazione della replica con standby caldo
La replica con Warm Standby fornisce resilienza mantenendo un database di standby caldo in un'area OCI secondaria. Questo standby viene continuamente aggiornato dal database primario nell'area di origine e può essere promosso manualmente in caso di errore.
In questa sezione vengono descritte le attività necessarie per configurare questo ambiente.
Creazione del sistema di database primario
Creazione del sistema di database di standby a caldo
Verifica dell'assegnazione del ruolo
Elenca sistemi di database di replica
Nella console di Oracle Cloud, i sistemi di database di replica associati vengono visualizzati nella pagina dei dettagli del sistema di database primario, in cui gli utenti possono visualizzare la lista delle repliche collegate al sistema di database primario insieme alle aree e agli identificativi corrispondenti.
Conversione di un sistema di database in standby caldo in modalità standalone
Il sistema di database primario a esso associato viene convertito automaticamente in stato standalone in quanto non fa più parte di una configurazione Replica con standby caldo.
Conversione di un sistema di database standalone in standby caldo
Aprire la pagina dei dettagli del sistema di database in standby caldo convertito e confermare che il valore del ruolo di sistema DB sia Warm standby.
Aprire la pagina dei dettagli per il sistema di database specificato come primario e confermare che il valore del ruolo di sistema DB sia Principale. Selezionare Sistemi DB di replica per aprire il pannello Sistema DB di replica e assicurarsi che sia elencato il database di standby caldo associato convertito.
Cambio di ruoli tra i sistemi di database in standby primario e a caldo
Disaster Recovery
Questa sezione descrive le azioni da eseguire quando si verifica un'indisponibilità dell'area primaria e come ripristinare le normali operazioni dopo il recupero dell'area.
In questo scenario di disaster recovery, il sistema di database primario si trova in un'area di origine come PHX. Il sistema di database primario dispone di accesso in lettura/scrittura. Il sistema di database in standby caldo è un'area di replica come LHR. Il sistema di database di standby a caldo dispone di accesso di sola lettura ed è sempre sincronizzato con il sistema di database primario utilizzando la replica tra più aree.
Convertire il Warm Standby in Standalone
Per istruzioni, vedere Conversione di un sistema di database standalone in standby caldo.
Convertire il primario originale in standby caldo
Dopo il ripristino dell'area di origine, il database primario originale (PHX) rimane un sistema di database standalone.
Aggiornare il ruolo del sistema di database primario (PHX) originale a un sistema di database in standby caldo come descritto in Conversione di un sistema di database standalone in standby caldo. Specificare il database server LHR in standby caldo originale, ora convertito in standalone, come sistema di database primario.
Ora il sistema di database primario è LHR con accesso in lettura/scrittura e il database server in standby caldo è PHX con accesso in sola lettura.
Ripristinare l'impostazione del database originale
Utilizzare la funzione di switchover per riportare il sistema di database primario (LHR) corrente al sistema primario (PHX) originale, come descritto in Cambio di ruoli tra sistemi di database primario e in standby caldo. Dopo lo switchover, il primario aggiornato è PHX e il warm standby aggiornato è LHR. Puoi riprendere le normali operazioni del database con il database primario nell'area di origine e il warm standby nell'area di replica.
Applicazione RPO
È possibile abilitare RPO per un sistema di database primario e specificare il valore RPO desiderato nei modi seguenti.
- Durante l'impostazione della replica con standby caldo
L'applicazione dell'RPO all'impostazione garantisce che l'applicazione dell'RPO venga applicata dall'inizio e che qualsiasi potenziale perdita di dati rimanga entro la soglia configurata. Se l'RPO configurato viene superato, il sistema di database primario potrebbe passare temporaneamente alla modalità di sola lettura fino al recupero dello standby.
Per abilitare RPO al momento dell'impostazione, utilizzare il pannello Scegli sistema di database primario. Per ulteriori informazioni, vedere Creazione del sistema di database in standby caldo.
- Dopo aver impostato la replica con standby caldo
Per abilitare o disabilitare RPO dopo l'impostazione, procedere come segue.
- Aprire la pagina dei dettagli del database primario (come descritto in Ottenere i dettagli di un sistema di database).
- Selezionare Modifica criterio di gestione dal menu Azioni.
- Nel pannello Modifica criterio di gestione, abilitare o disabilitare l'applicazione RPO e configurare il valore RPO all'interno dell'intervallo supportato.
- Salvare le modifiche.
Le modifiche vengono applicate immediatamente.
Metriche
Utilizza le metriche per monitorare la replica e lo stato RPO per i sistemi di database primario e in standby caldo.
Nella pagina dei dettagli del sistema di database, selezionare Metriche per visualizzare la pagina Metriche. Di seguito sono riportate le metriche incluse.
Metriche database primario
- RPO corrente (secondi): RPO corrente del sistema di database primario. Visualizza il ritardo di replica corrente in secondi, indicando la distanza del database in standby rispetto al database primario.
- Modalità di transazione corrente: modalità di transazione corrente del sistema di database primario.
1: Lettura/scrittura0: di sola letturaIl valore
0indica che il sistema di database è stato trasformato in modalità di sola lettura a causa dell'applicazione RPO.
Metriche calde database in standby
- Epoca dell'ultima ripetizione della transazione: visualizza l'ora in cui il record di log dell'ultima ripetizione della transazione è stato generato sul record principale.
- Ritardo ultima ripetizione transazione: visualizza il ritardo in millisecondi tra l'epoca in cui l'ultima transazione è stata ripetuta in un sistema di database in standby caldo e l'epoca in cui è stato eseguito il commit della stessa transazione nel sistema di database primario.
Supporto CLI
È possibile utilizzare i comandi dell'interfaccia CLI per eseguire le attività di replica con Warm Standby.
Crea sistema di database primario
Passare all'area in cui si desidera che il sistema di database primario risieda e crei il database utilizzando l'interfaccia CLI, come descritto in Creazione di un sistema di database.
Crea sistema di database in standby a caldo
Passa all'area in cui desideri che risieda il sistema di database in standby caldo. Utilizzare il comando seguente per creare il warm standby.
Aggiornare i dettagli del sistema di database di origine, ad esempio sourceType e primaryDbSystemId, con i valori appropriati. Ad esempio:
oci raw-request --http-method POST --auth security_token --config-file ~/.oci/config --profile DEFAULT --target-uri 'https://postgresql.us-phoenix-1.oci.oraclecloud.com/20220915/dbSystems' \
--request-body '{
"displayName": "Warm Standby Database",
"description": "Test db",
"compartmentId": "ocid.compartment.oc1..exampleuniqueID",
"dbVersion": "14",
"storageDetails": {
"systemType": "OCI_OPTIMIZED_STORAGE",
"isRegionallyDurable": false,
"availabilityDomain": "gXfg:UK-LONDON-1-AD-2"
},
"shape": "PostgreSQL.VM.Standard.E5.Flex",
"instanceOcpuCount": 2,
"instanceCount": 1,
"instanceMemorySizeInGBs": 32,
"networkDetails": {
"subnetId": "ocid1.subnet..exampleuniqueID"
},
"source": {
"sourceType": "DB_SYSTEM",
"primaryDbSystemId": "ocid1.postgresqldbsystem..exampleuniqueID"
}
}'
Elenca sistemi di database di replica
Utilizzare il comando seguente per elencare i sistemi di database in standby a caldo associati al sistema di database primario.
oci raw-request --http-method GET --target-uri 'https://postgresql.us-phoenix-1.oci.oraclecloud.com/20220915/dbSystems/<dbSystemId>/replicas' --region us-phoenix-1 --profile DEFAULT --config-file ~/.oci/config --auth security_token
dove <dbSystemId> è l'OCID del sistema di database primario.
Conversione di un sistema di database in standby caldo in modalità standalone
Utilizzare il comando seguente per convertire un sistema di database in standby caldo in standalone.
oci raw-request --http-method POST --target-uri 'https://postgresql.us-phoenix-1.oci.oraclecloud.com/20220915/dbSystems/<warm_standby>/actions/changeRoleToStandalone' --region us-phoenix-1 --request-body '{"changeMode":"[immediately | "Replay Pending Updates"]"}' --profile DEFAULT --config-file ~/.oci/config --auth security_token
dove <warm_standby> è il sistema di database di standby caldo.
Conversione di un sistema di database standalone in standby caldo
Utilizzare il comando seguente per convertire un sistema di database standalone in warm standby.
oci raw-request --http-method POST --target-uri 'https://postgresql.us-phoenix-1.oci.oraclecloud.com/20220915/dbSystems/<warm_standby>/actions/changeRoleToReplica' --region us-phoenix-1 --request-body '{"primaryDbSystemId":"<primary>"}' --profile DEFAULT --config-file ~/.oci/config --auth security_token
dove <warm_standby> è il sistema di database in standby caldo e <primary> è il sistema di database primario.
Aggiornamento RPO
Utilizzare il comando seguente per aggiornare la configurazione di replica (impostazioni RPO) per un sistema di database.
oci raw-request --http-method PUT --target-uri 'https://postgresql.us-phoenix-1.oci.oraclecloud.com/20220915/dbSystems/<dbSystemId>' --region us-phoenix-1 --request-body '{"replicationConfig": {"isRpoEnforced": true, "rpoInSeconds": 300}}' --profile DEFAULT --config-file ~/.oci/config --auth security_token
dove <dbSystemId> è l'OCID del sistema di database.
-
isRpoEnforced: specifica se l'applicazione RPO è abilitata o disabilitata. -
rpoInSeconds: specifica il valore RPO (in secondi) da applicare quando abilitato. Il valore deve essere compreso tra 300 e 10.800 secondi.
Switchover
Utilizzare il comando seguente per eseguire uno switchover tra un sistema di database standalone e uno standby a caldo.
oci raw-request --http-method POST --target-uri 'https://postgresql.us-phoenix-1.oci.oraclecloud.com/20220915/dbSystems/<primary>/actions/switchover' --region us-phoenix-1 --request-body
'{"replicaDbSystemId":"<warm-standby>"}' --profile DEFAULT --config-file ~/.oci/config --auth security_token
dove <primary> è il sistema di database primario e <warm_standby> è il sistema di database warm standby.
Limitazioni
Ripristina sistemi di database
Il ripristino del sistema di database non è supportato per la replica con sistemi di database in standby caldo (standby primario e warm).