Panoramica della continuità aziendale con Database di Azure per PostgreSQL - Server flessibile

Articolo
01/19/2024

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

La continuità aziendale in Database di Azure per PostgreSQL server flessibile si riferisce ai meccanismi, ai criteri e alle procedure che consentono all'azienda di continuare a funzionare in caso di interruzione, in particolare all'infrastruttura di elaborazione. Nella maggior parte dei casi, Database di Azure per PostgreSQL server flessibile gestisce eventi di interruzione che possono verificarsi nell'ambiente cloud e mantenere in esecuzione le applicazioni e i processi aziendali. Esistono tuttavia alcuni eventi che non possono essere gestiti automaticamente, ad esempio:

L'utente elimina o aggiorna accidentalmente una riga in una tabella.
Il terremoto causa un'interruzione dell'alimentazione e disabilita temporaneamente una zona di disponibilità o un'area.
L'applicazione di patch al database necessaria per risolvere un problema di sicurezza o di bug.

Database di Azure per PostgreSQL server flessibile offre funzionalità che proteggono i dati e riduce i tempi di inattività per i database cruciali durante gli eventi di tempo di inattività pianificati e non pianificati. Basato sull'infrastruttura di Azure che offre resilienza e disponibilità affidabili, Database di Azure per PostgreSQL server flessibile offre funzionalità di continuità aziendale che offrono un'altra protezione dagli errori, soddisfare i requisiti di tempo di ripristino e ridurre l'esposizione alla perdita di dati. Quando si progettano le applicazioni, è consigliabile considerare la tolleranza al tempo di inattività, ovvero l'obiettivo del tempo di ripristino (RTO) e l'esposizione alla perdita di dati, ovvero l'obiettivo del punto di ripristino (RPO). Ad esempio, il database business critical richiede tempi di attività più rigorosi rispetto a un database di test.

La tabella seguente illustra le funzionalità offerte Database di Azure per PostgreSQL server flessibile.

Funzionalità	Descrizione	Considerazioni
Backup automatici	Database di Azure per PostgreSQL server flessibile esegue automaticamente backup giornalieri dei file di database e esegue continuamente il backup dei log delle transazioni. I backup possono essere conservati da 7 fino a 35 giorni. È possibile ripristinare il server di database a qualsiasi punto nel tempo entro il periodo di conservazione dei backup. L'obiettivo RTO dipende dalle dimensioni dei dati da ripristinare e dal tempo necessario per eseguire il ripristino del log. Può essere di pochi minuti fino a 12 ore. Per altri dettagli, vedere Concetti - Backup e ripristino.	I dati di backup rimangono all'interno dell'area.
Disponibilità elevata di ridondanza della zona	Database di Azure per PostgreSQL server flessibile può essere distribuito con configurazione a disponibilità elevata con ridondanza della zona in cui i server primario e standby vengono distribuiti in due zone di disponibilità diverse all'interno di un'area. Questa configurazione a disponibilità elevata protegge i database da errori a livello di zona e consente anche di ridurre i tempi di inattività delle applicazioni durante gli eventi di tempo di inattività pianificati e non pianificati. I dati del server primario vengono replicati nella replica standby in modalità sincrona. In caso di interruzione del server primario, il server viene eseguito automaticamente il failover nella replica di standby. L'RTO nella maggior parte dei casi dovrebbe essere inferiore a 120 secondi. Il valore di RPO dovrà essere uguale a zero (nessuna perdita di dati). Per altre informazioni, vedere Concetti - Disponibilità elevata.	Supportato nei livelli di calcolo ottimizzati per utilizzo generico e memoria. Disponibile solo nelle aree in cui sono disponibili più zone.
Disponibilità elevata della stessa zona	Database di Azure per PostgreSQL server flessibile può essere distribuito con la stessa configurazione a disponibilità elevata della zona in cui i server primario e standby vengono distribuiti nella stessa zona di disponibilità in un'area. Questa configurazione a disponibilità elevata protegge i database da errori a livello di nodo e consente anche di ridurre i tempi di inattività delle applicazioni durante gli eventi di inattività pianificati e non pianificati. I dati del server primario vengono replicati nella replica standby in modalità sincrona. In caso di interruzione del server primario, il server viene eseguito automaticamente il failover nella replica di standby. L'RTO nella maggior parte dei casi dovrebbe essere inferiore a 120 secondi. Il valore di RPO dovrà essere uguale a zero (nessuna perdita di dati). Per altre informazioni, vedere Concetti - Disponibilità elevata.	Supportato nei livelli di calcolo ottimizzati per utilizzo generico e memoria.
Dischi gestiti Premium	I file di database vengono archiviati in una risorsa di archiviazione durevole gestita in modo affidabile. In questo modo si garantisce la ridondanza dei dati con tre copie di replica archiviate all'interno di una zona di disponibilità con funzionalità di ripristino automatico dei dati. Per altre informazioni, vedere la documentazione di Managed Disks.	Dati archiviati all'interno di una zona di disponibilità.
Backup con ridondanza della zona	Database di Azure per PostgreSQL backup flessibili del server vengono archiviati automaticamente e in modo sicuro in una risorsa di archiviazione con ridondanza della zona all'interno di un'area, se l'area supporta le zone di disponibilità. Durante un errore a livello di zona in cui viene effettuato il provisioning del server e se il server non è configurato con ridondanza della zona, è comunque possibile ripristinare il database usando il punto di ripristino più recente in una zona diversa. Per altre informazioni, vedere Concetti - Backup e ripristino.	Applicabile solo nelle aree in cui sono disponibili più zone.
Backup con ridondanza geografica	Database di Azure per PostgreSQL backup flessibili del server vengono copiati in un'area remota. che consente il ripristino di emergenza nel caso in cui l'area del server primario sia inattiva.	Questa funzionalità è attualmente abilitata nelle aree selezionate. Per eseguire il ripristino e la quantità di ripristino, sono necessari un RTO più lungo e un RPO superiore, a seconda delle dimensioni dei dati.
Replica in lettura	Le repliche in lettura tra aree possono essere distribuite per proteggere i database da errori a livello di area. Le repliche in lettura vengono aggiornate in modo asincrono usando la tecnologia di replica fisica di PostgreSQL e possono causare un ritardo nel database primario. Per altre informazioni, vedere Concetti - Repliche in lettura.	Supportato nei livelli di calcolo ottimizzati per utilizzo generico e memoria.

La tabella seguente confronta RTO e RPO in uno scenario tipico del carico di lavoro :

Funzionalità	Burstable	Utilizzo generico	Ottimizzato per la memoria
Ripristino temporizzato dal backup	Qualsiasi punto di ripristino entro il periodo di conservazione RTO - Varia RPO < 15 min	Qualsiasi punto di ripristino entro il periodo di conservazione RTO - Varia RPO < 15 min	Qualsiasi punto di ripristino entro il periodo di conservazione RTO - Varia RPO < 15 min
Ripristino geografico dai backup con replica geografica	RTO - Varia RPO < 1 h	RTO - Varia RPO < 1 h	RTO - Varia RPO < 1 h
Repliche in lettura	RTO - Minuti* RPO < 5 min*	RTO - Minuti* RPO < 5 min*	RTO - Minuti* RPO < 5 min*

* RTO e RPO possono essere molto più elevati in alcuni casi a seconda di vari fattori, tra cui la latenza tra siti, la quantità di dati da trasmettere e soprattutto il carico di lavoro di scrittura del database primario.

Eventi di inattività pianificati

Di seguito sono riportati alcuni scenari di manutenzione pianificata. Questi eventi in genere comportano fino a pochi minuti di tempo di inattività e senza perdita di dati.

Scenario	Processo
Ridimensionamento del calcolo (avviato dall'utente)	Durante l'operazione di ridimensionamento del calcolo, i checkpoint attivi sono autorizzati a completare, le connessioni client vengono svuotate, tutte le transazioni non sottoposte a commit vengono annullate, l'archiviazione viene scollegata e quindi viene arrestata. Viene effettuato il provisioning di una nuova istanza del server flessibile Database di Azure per PostgreSQL con lo stesso nome del server di database con la configurazione di calcolo con scalabilità orizzontale. Lo spazio di archiviazione viene quindi collegato al nuovo server e il database viene avviato che esegue il ripristino, se necessario, prima di accettare le connessioni client.
Aumento dell'archiviazione (avviata dall'utente)	Quando viene avviata un'operazione di aumento delle risorse di archiviazione, i checkpoint attivi sono autorizzati a completare, le connessioni client vengono svuotate e tutte le transazioni di cui non è stato eseguito il commit vengono annullate. Dopo l'arresto del server. Lo spazio di archiviazione viene ridimensionato in base alle dimensioni desiderate e quindi collegato al nuovo server. Se necessario, viene eseguito un ripristino prima di accettare le connessioni client. Si noti che il ridimensionamento delle dimensioni di archiviazione non è supportato.
Nuova distribuzione software (avviata da Azure)	Le nuove funzionalità di implementazione o correzioni di bug vengono eseguite automaticamente come parte della manutenzione pianificata del servizio ed è possibile pianificare quando si verificano tali attività. Per altre informazioni, vedere il portale.
Aggiornamenti delle versioni secondarie (avviato da Azure)	Database di Azure per PostgreSQL applica automaticamente patch ai server di database alla versione secondaria determinata da Azure. Si verifica come parte della manutenzione pianificata del servizio. Il server di database viene riavviato automaticamente con la nuova versione secondaria. Per altre informazioni, vedere la documentazione. È anche possibile controllare il portale.

Quando l'istanza del server flessibile Database di Azure per PostgreSQL è configurata con disponibilità elevata, il servizio esegue prima il ridimensionamento e le operazioni di manutenzione sul server di standby. Per altre informazioni, vedere Concetti - Disponibilità elevata.

Mitigazione dei tempi di inattività non pianificati

I tempi di inattività non pianificati possono verificarsi a causa di interruzioni impreviste, ad esempio errori hardware sottostanti, problemi di rete e bug software. Se il server di database configurato con disponibilità elevata diventa inattivo in modo imprevisto, la replica di standby viene attivata e i client possono riprendere le operazioni. Se non è configurato con disponibilità elevata, se il tentativo di riavvio non riesce, viene eseguito automaticamente il provisioning di un nuovo server di database. Anche se non è possibile evitare tempi di inattività non pianificati, Database di Azure per PostgreSQL server flessibile consente di ridurre il tempo di inattività eseguendo automaticamente operazioni di ripristino senza richiedere l'intervento umano.

Anche se ci impegniamo continuamente a fornire disponibilità elevata, ci sono momenti in cui Database di Azure per PostgreSQL server flessibile causa interruzioni che causano l'indisponibilità dei database e quindi influiscono sull'applicazione. Quando il monitoraggio del servizio rileva problemi che causano errori di connettività, errori o problemi di prestazioni diffusi, il servizio dichiara automaticamente un'interruzione per mantenere l'utente informato.

Interruzione del servizio

In caso di interruzione del server flessibile Database di Azure per PostgreSQL, è possibile visualizzare altri dettagli relativi all'interruzione nelle posizioni seguenti:In the event of Database di Azure per PostgreSQL flexible server outage, you can see more details related to the outage in the following place:

portale di Azure banner: se la sottoscrizione è identificata come interessata, verrà visualizzato un avviso di interruzione del servizio nelle notifiche portale di Azure.

Screenshot showing notifications in Azure portal.

Guida e supporto o supporto e risoluzione dei problemi: quando si crea un ticket di supporto da Guida e supporto o supporto e risoluzione dei problemi, verranno fornite informazioni su eventuali problemi che influisce sulle risorse. Selezionare Visualizza dettagli interruzione per altre informazioni e un riepilogo dell'impatto. Nella pagina Nuova richiesta di supporto verrà visualizzato anche un avviso.

Screenshot showing Help Support notifications in Azure portal.

Guida del servizio: la pagina Integrità dei servizi nella portale di Azure contiene informazioni sullo stato del data center di Azure a livello globale. Cercare "integrità dei servizi" nella barra di ricerca nella portale di Azure, quindi visualizzare i problemi del servizio nella categoria Eventi attivi. È anche possibile visualizzare l'integrità delle singole risorse nella pagina Integrità risorse di qualsiasi risorsa nel menu ? Di seguito è riportata una schermata di esempio della pagina Integrità dei servizi con informazioni su un problema di servizio attivo in Asia sud-orientale.

Screenshot showing service outage in Service Health portal.

Notifica tramite posta elettronica: se sono stati configurati avvisi, verrà visualizzata una notifica tramite posta elettronica quando un'interruzione del servizio influisce sulla sottoscrizione e sulla risorsa. I messaggi di posta elettronica arrivano da "azure-noreply@microsoft.com". Il corpo del messaggio di posta elettronica inizia con "L'avviso del log attività ... è stato attivato da un problema di servizio per la sottoscrizione di Azure...". Per altre informazioni sugli avvisi di integrità dei servizi, vedere Ricevere avvisi del log attività sulle notifiche del servizio di Azure tramite portale di Azure.

Importante

Come suggerisce il nome, gli spazi di tabella temporanei in PostgreSQL vengono usati per gli oggetti temporanei, nonché per altre operazioni di database interne, ad esempio l'ordinamento. Non è pertanto consigliabile creare oggetti schema utente nello spazio tabelle temporaneo, perché non si garantisce la durabilità di tali oggetti dopo il riavvio del server, i failover a disponibilità elevata e così via.

Tempi di inattività non pianificati: scenari di errore e ripristino del servizio

Di seguito sono riportati alcuni scenari di errore non pianificati e il processo di ripristino.

Scenario	Processo di ripristino [Server configurati senza disponibilità elevata con ridondanza della zona]	Processo di ripristino [Server configurati con disponibilità elevata con ridondanza della zona]
Errore del server di database	Se il server di database è inattivo, Azure tenterà di riavviare il server di database. In caso di errore, il server di database verrà riavviato in un altro nodo fisico. Il tempo di ripristino (RTO) dipende da vari fattori, tra cui l'attività al momento dell'errore, ad esempio transazioni di grandi dimensioni e il volume di ripristino da eseguire durante il processo di avvio del server di database. Le applicazioni che usano i database PostgreSQL devono essere compilate in modo da rilevare e ripetere le connessioni eliminate e le transazioni non riuscite.	Se viene rilevato un errore del server di database, il server viene sottoposto a failover nel server di standby, riducendo così il tempo di inattività. Per altre informazioni, vedere la pagina relativa ai concetti relativi alla disponibilità elevata. L'obiettivo RTO dovrebbe essere di 60-120s, con una perdita di dati pari a zero.
errore di Archiviazione	Le applicazioni non riscontrano alcun impatto sui problemi correlati all'archiviazione, ad esempio un errore del disco o un danneggiamento di blocchi fisici. Poiché i dati vengono archiviati in tre copie, la copia dei dati viene servita dall'archiviazione sopravvissuta. Il blocco di dati danneggiato viene ripristinato automaticamente e viene creata automaticamente una nuova copia dei dati.	Per eventuali errori rari e non ripristinabili, ad esempio l'intera risorsa di archiviazione, l'istanza del server flessibile Database di Azure per PostgreSQL viene eseguito il failover nella replica di standby per ridurre il tempo di inattività. Per altre informazioni, vedere la pagina relativa ai concetti relativi alla disponibilità elevata.
Errori logici/utente	Per eseguire il ripristino da errori utente, ad esempio tabelle eliminate accidentalmente o dati aggiornati in modo non corretto, è necessario eseguire un ripristino temporizzato.To recover from user errors, such as accidentally dropped tables or in incorrect data, you have to perform a point-in-time recovery (PITR). Durante l'esecuzione dell'operazione di ripristino, è necessario specificare il punto di ripristino personalizzato, ovvero l'ora prima dell'errore. Se si desidera ripristinare solo un subset di database o tabelle specifiche anziché tutti i database nel server di database, è possibile ripristinare il server di database in una nuova istanza, esportare le tabelle tramite pg_dump e quindi utilizzare pg_restore per ripristinare tali tabelle nel database.	Questi errori utente non sono protetti con disponibilità elevata perché tutte le modifiche vengono replicate in modo sincrono nella replica di standby. È necessario eseguire il ripristino temporizzato per eseguire il ripristino da tali errori.
Errore nella zona di disponibilità	Per eseguire il ripristino da un errore a livello di zona, è possibile eseguire il ripristino temporizzato usando il backup e scegliendo un punto di ripristino personalizzato con l'ora più recente per ripristinare i dati più recenti. Una nuova istanza del server flessibile Database di Azure per PostgreSQL viene distribuita in un'altra zona non interessata. Il tempo necessario per il ripristino dipende dal backup precedente e dal volume dei log delle transazioni da ripristinare.	Database di Azure per PostgreSQL server flessibile viene eseguito automaticamente il failover nel server standby entro 60-120s con perdita di dati zero. Per altre informazioni, vedere la pagina relativa ai concetti relativi alla disponibilità elevata.
Errore dell'area	Se il server è configurato con il backup con ridondanza geografica, è possibile eseguire il ripristino geografico nell'area abbinata. Verrà eseguito il provisioning e il ripristino di un nuovo server negli ultimi dati disponibili copiati in questa area. È anche possibile usare repliche in lettura tra aree. In caso di errore dell'area, è possibile eseguire un'operazione di ripristino di emergenza promuovendo la replica in lettura come server scrivibile in lettura autonomo. È previsto che l'RPO sia fino a 5 minuti (possibile perdita di dati) tranne nel caso di un errore a livello di area grave quando l'RPO può essere vicino al ritardo della replica al momento dell'errore.	Stesso processo.

Configurare il database dopo il ripristino da un errore a livello di area

Se si usa il ripristino geografico o la replica geografica per il ripristino da un'interruzione, è necessario assicurarsi che la connettività al nuovo server sia configurata correttamente in modo che la normale funzione dell'applicazione possa essere ripresa. È possibile seguire le attività di post-ripristino.
Se in precedenza è stata configurata un'impostazione di diagnostica nel server originale, assicurarsi di eseguire la stessa operazione nel server di destinazione, se necessario, come illustrato in Configurare e accedere ai log in Database di Azure per PostgreSQL - Server flessibile.
Configurare gli avvisi di telemetria, è necessario assicurarsi che le impostazioni delle regole di avviso esistenti vengano aggiornate per eseguire il mapping al nuovo server. Per altre informazioni sulle regole di avviso, vedere Usare il portale di Azure per configurare gli avvisi sulle metriche per Database di Azure per PostgreSQL - Server flessibile.