Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La continuità aziendale in Database di Azure per PostgreSQL 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 gestisce eventi di interruzione che possono verificarsi nell'ambiente cloud e mantiene in esecuzione le applicazioni e i processi aziendali. Tuttavia, alcuni eventi non possono essere gestiti automaticamente, ad esempio:
- Un utente elimina o aggiorna accidentalmente una riga in una tabella.
- Un terremoto causa un'interruzione dell'alimentazione e disabilita temporaneamente una zona di disponibilità o un'area.
- Applicazione di patch al database necessaria per risolvere un problema di sicurezza o di bug.
Database di Azure per PostgreSQL offre funzionalità che proteggono i dati e attenuano 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 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. Durante la progettazione delle applicazioni, prendere in considerazione 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.
Nella tabella seguente vengono illustrate le funzionalità offerte da Database di Azure per PostgreSQL.
| Feature | Descrizione | Considerazioni |
|---|---|---|
| Backup automatici | Un'istanza del server flessibile di Database di Azure per PostgreSQL esegue automaticamente backup giornalieri dei file di database e esegue continuamente il backup dei log delle transazioni. È possibile conservare i backup da 7 giorni fino a 35 giorni. È possibile ripristinare il server di database in qualsiasi momento entro il periodo di conservazione dei backup. L'RTO dipende dalle dimensioni dei dati da ripristinare, a cui si aggiunge il tempo necessario per eseguire il recupero del log. Possono essere da pochi minuti fino a 12 ore. Per altre informazioni, vedere Concetti - Backup e ripristino. | I dati di backup rimangono all'interno dell'area. |
| Disponibilità elevata di ridondanza della zona | È possibile distribuire un'istanza del server flessibile Database di Azure per PostgreSQL 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 inattività pianificati e non pianificati. I dati del server primario vengono replicati in modo sincrono nella replica di standby. In caso di interruzione del server primario, il server viene sottoposto automaticamente a failover nella replica di standby. Nella maggior parte dei casi, si prevede che l'RTO sia 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 per utilizzo generico e ottimizzato per la memoria. Disponibile solo nelle aree in cui sono disponibili più zone. |
| Disponibilità elevata nella stessa zona | È possibile distribuire un'istanza di Database di Azure per PostgreSQL - Server flessibile con una configurazione di disponibilità elevata (HA) nella stessa zona, in cui i server primario e standby vengono distribuiti nella stessa zona di disponibilità della regione. 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 in modo sincrono nella replica di standby. In caso di interruzione del server primario, il server viene sottoposto automaticamente a failover nella replica di standby. Nella maggior parte dei casi, l'RTO 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]/azure/reliability/reliability-postgresql-flexible-server. | Supportato nei livelli di calcolo per utilizzo generico e ottimizzato per la memoria. |
| Dischi gestiti Premium | I file di database vengono archiviati in una risorsa di archiviazione durevole gestita in modo affidabile. Questa risorsa di archiviazione offre la ridondanza dei dati con tre copie della replica archiviata 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 | I backup delle istanze del server flessibile di Azure Database per PostgreSQL vengono archiviati automaticamente e in modo sicuro in un'archiviazione ridondante a livello di zona all'interno di una regione, se la regione supporta le aree 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 un'area diversa. Per altre informazioni, vedere Concetti - Backup e ripristino. | Applicabile solo nelle aree in cui sono disponibili più zone. |
| Backup con ridondanza geografica | I backup dell'istanza del server flessibile di Database di Azure per PostgreSQL vengono copiati in un'area remota. Questa funzionalità consente di risolvere la situazione di ripristino di emergenza nel caso in cui l'area del server primaria sia inattiva. | Questa funzionalità è attualmente abilitata nelle aree selezionate. Sono necessari un RTO più lungo e un RPO superiore, a seconda delle dimensioni dei dati da ripristinare e dalla quantità di ripristino da effettuare. |
| Replica in lettura | È possibile distribuire repliche in lettura tra aree 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 potrebbero causare un ritardo nel database primario. Per altre informazioni, vedere Concetti - Repliche di lettura. | Supportato nei livelli di calcolo per utilizzo generico e ottimizzato per la memoria. |
La tabella seguente confronta RTO e RPO in uno scenario con carico di lavoro tipico:
| Funzionalità | Possibilità di burst | SKU di produzione (utilizzo generico/ottimizzato per la memoria) |
|---|---|---|
| Ripristino temporizzato dal backup | Qualsiasi punto di ripristino compreso nel periodo di conservazione RTO - Varie RPO < 5 minuti |
Qualsiasi punto di ripristino compreso nel periodo di conservazione RTO - Varie RPO < 5 minuti |
| Ripristino geografico dai backup con replica geografica | RTO - Varie RPO < 1 h |
RTO - Varie RPO < 1 h |
| Repliche in lettura | Non applicabile | RTO - Minuti* RPO - In genere compreso tra 30 sec e 5 minuti* |
| Disponibilità elevata | Non applicabile | RTO < 120 sec RPO = 0 |
Eventi di inattività pianificati
La tabella seguente descrive alcuni scenari comuni di manutenzione pianificata. Questi eventi causano in genere alcuni minuti di inattività, ma non causano la perdita di dati.
| Scenario | Processo |
|---|---|
| Ridimensionamento dell'ambiente di calcolo (avviato dall'utente) | Durante l'operazione di ridimensionamento delle risorse di calcolo, il processo consente il completamento dei checkpoint attivi, chiude gradualmente le connessioni client, annulla tutte le transazioni non sottoposte a commit, scollega l'archiviazione e quindi si arresta. Il processo effettua il provisioning di una nuova istanza del server flessibile Database di Azure per PostgreSQL con lo stesso nome del server di database, ma con la configurazione di calcolo ridimensionata. Il processo collega l'archiviazione al nuovo server e avvia il database, che esegue il ripristino, se necessario, prima di accettare le connessioni client. |
| Aumento dell'archiviazione (avviato dall'utente) | Quando si avvia un'operazione di aumento delle risorse di archiviazione, il processo consente il completamento dei checkpoint attivi, svuota le connessioni client e annulla tutte le transazioni di cui non è stato eseguito il commit. Dopodiché, il processo arresta il server. Il processo ridimensiona lo spazio di archiviazione alle dimensioni desiderate e quindi lo collega al nuovo server. Il processo esegue il ripristino, se necessario, prima di accettare le connessioni client. Tenere presente che la riduzione delle dimensioni di archiviazione non è supportata. |
| Nuova distribuzione software (avviata da Azure) | Il servizio implementa automaticamente nuove funzionalità o correzioni di bug come parte della manutenzione pianificata. È possibile pianificare quando si verificano tali attività. Per altre informazioni, vedere il portale. |
| Aggiornamenti della versione secondaria (avviati da Azure) | Database di Azure per PostgreSQL applica automaticamente patch del server di database alla versione secondaria determinata da Azure. Questa applicazione di patch viene eseguita come parte della manutenzione pianificata del servizio. Il processo riavvia automaticamente il server del database con la nuova versione minore. Per altre informazioni, vedere la documentazione. È anche possibile controllare il portale. |
Quando si configura l'istanza del server flessibile Database di Azure per PostgreSQL con disponibilità elevata, il servizio esegue prima le operazioni di ridimensionamento e manutenzione nel server di standby. Per altre informazioni, vedere [Concetti - Disponibilità elevata]/azure/reliability/reliability-postgresql-flexible-server.
Mitigazione dei tempi di inattività non pianificati
Possono verificarsi tempi di inattività non pianificati a causa di interruzioni impreviste, ad esempio errori hardware sottostanti, problemi di rete e bug del software. Se il server di database configurato con disponibilità elevata risulta inattivo in modo imprevisto, il servizio attiva la replica di standby e i client possono riprendere le operazioni. Se non si configura il server con disponibilità elevata, il servizio effettua automaticamente il provisioning di un nuovo server di database se il tentativo di riavvio non riesce. Anche se non è possibile evitare tempi di inattività non pianificati, Database di Azure per PostgreSQL consente di ridurre i tempi di inattività eseguendo automaticamente operazioni di ripristino senza richiedere l'intervento umano.
Anche se il team di progettazione si impegna costantemente a fornire disponibilità elevata, ci sono momenti in cui Database di Azure per PostgreSQL causa un'interruzione che causa l'indisponibilità dei database e quindi influisce 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 aggiornato l'utente.
Interruzione del servizio
Se un'istanza del server flessibile Database di Azure per PostgreSQL è inattiva, è possibile trovare altri dettagli sull'interruzione nelle posizioni seguenti:
- Banner del portale di Azure: se la sottoscrizione è interessata, nel portale di Azure Notifiche visualizza un avviso di interruzione relativo a un problema del servizio.
- Guida + supporto o supporto + risoluzione dei problemi: quando si crea un ticket di supporto da Guida e supporto o supporto e risoluzione dei problemi, il portale include informazioni su eventuali problemi che influisce sulle risorse. Selezionare Visualizza dettagli dell'interruzione per altre informazioni e un riepilogo dell'impatto. La pagina Nuova richiesta di supporto include anche un avviso.
- Integrità dei servizi: la pagina Integrità dei servizi nel portale di Azure contiene informazioni sullo stato del data center Azure a livello globale. Cercare "integrità dei servizi" nella barra di ricerca nel portale di Azure e quindi visualizzare i problemi del servizio nella categoria Eventi attivi. È anche possibile visualizzare l'integrità delle singole risorse nella pagina Integrità delle risorse di qualsiasi risorsa nel menu Aiuto. La schermata seguente della pagina Integrità dei servizi mostra informazioni su un problema di servizio attivo in Asia sud-orientale.
- Notifica tramite posta elettronica: se si configurano avvisi, si riceve una notifica tramite posta elettronica quando un'interruzione del servizio influisce sulla sottoscrizione e sulla risorsa. I messaggi di posta elettronica provengono da "azure-noreply@microsoft.com". Il corpo dell'e-mail inizia con "L'avviso del log attività ... è stato attivato da un problema di servizio per la sottoscrizione di Azure...". Per altre informazioni sugli avvisi sull'integrità dei servizi, vedere Ricevere avvisi del log attività sulle notifiche del servizio Azure tramite il portale di Azure.
Importante
Come suggerisce il nome, gli spazi tabella temporanei in PostgreSQL vengono usati per oggetti temporanei, nonché per altre operazioni di database interne, ad esempio l'ordinamento. Pertanto, non creare oggetti dello schema utente nella tablespace temporanea, poiché la persistenza di questi oggetti dopo i riavvii del server, i failover HA e altri eventi simili non è garantita.
Tempi di inattività non pianificati: scenari di errore e ripristino del servizio
La tabella seguente descrive gli scenari comuni di errore non pianificato 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 e ridondanza della zona] |
|---|---|---|
| Errore del server di database | Se il server di database è inattivo, Azure tenta di riavviare il server di database. Se il tentativo ha esito negativo, Azure riavvia il server di database in un altro nodo fisico. Il tempo di ripristino (RTO) dipende da vari fattori, tra cui l'attività al momento dell'errore, ad esempio una transazione 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 rilevare e ripetere le connessioni eliminate e le transazioni non riuscite. |
Se viene rilevato un errore del server di database, il server esegue il failover nel server di standby, riducendo così il tempo di inattività. Per altre informazioni, vedere [pagina Concetti della disponibilità elevata]/azure/reliability/reliability-postgresql-flexible-server. L'obiettivo RTO dovrebbe essere di 60-120 secondi, con una perdita di dati pari a zero. |
| Errore di archiviazione | Le applicazioni non vedono alcun impatto su eventuali 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 risorsa di archiviazione sopravvissuta serve la copia dei dati. 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 quando l'intera risorsa di archiviazione non è accessibile, l'istanza del server flessibile Database di Azure per PostgreSQL esegue il failover nella replica di standby per ridurre il tempo di inattività. Per altre informazioni, vedere [pagina Concetti della disponibilità elevata]/azure/reliability/reliability-postgresql-flexible-server. |
| Errori logici o utente | Per ripristinare il sistema dopo errori dell'utente, ad esempio tabelle eliminate accidentalmente o dati aggiornati in modo errato, eseguire un ripristino point-in-time (PITR). Durante l'esecuzione dell'operazione di ripristino, 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 dalla disponibilità elevata perché tutte le modifiche vengono replicate nella replica standby in modo sincrono. È necessario eseguire un ripristino a un momento preciso per recuperare da tali errori. |
| Errore nella zona di disponibilità | Per eseguire il ripristino da un errore a livello di zona, eseguire il ripristino temporizzato usando il backup e scegliere un punto di ripristino personalizzato con l'ora più recente per ripristinare i dati più recenti. Distribuisci una nuova istanza di server flessibile di Database di Azure per PostgreSQL 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. | Un'istanza del server flessibile Database di Azure per PostgreSQL esegue automaticamente il failover nel server di standby entro 60-120 secondi senza perdita di dati. Per altre informazioni, vedere [pagina Concetti della disponibilità elevata]/azure/reliability/reliability-postgresql-flexible-server. |
| Errore dell'area | Se il server è configurato con il backup con ridondanza geografica, è possibile eseguire il ripristino geografico nell'area abbinata. Azure esegue il provisioning e ripristina un nuovo server usando l'ultima copia dei dati disponibile in questa area geografica. È anche possibile usare repliche in lettura tra aree. In caso di guasto di un'area geografica, è possibile eseguire un'operazione di disaster recovery promuovendo la replica di lettura a server autonomo di lettura e scrittura. Si prevede che l'RPO non superi i cinque minuti (con possibile perdita di dati), tranne nel caso di un grave guasto a livello di area geografica, quando l'RPO può avvicinarsi alla latenza di replica al momento del guasto. |
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, assicurarsi che la connettività al nuovo server sia configurata correttamente in modo che la normale funzione dell'applicazione possa riprendere. Seguire le attività 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.
- Per configurare gli avvisi di telemetria, 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.
Importante
È possibile ripristinare i server eliminati. Se si elimina il server, seguire le indicazioni riportate in Ripristinare un server eliminato per il ripristino. Usare il blocco delle risorse di Azure per impedire l'eliminazione accidentale del server.