Indicazioni sul ripristino di emergenza - Database SQL di Azure

Si applica a: Database SQL di Azure

• Database SQL di Azure
• Istanza gestita di database SQL di Azure

Il database SQL di Azure offre una garanzia di disponibilità elevata leader del settore di almeno il 99,99% per supportare un'ampia gamma di applicazioni, tra cui quelle cruciali, che devono sempre essere disponibili. Il database SQL di Azure include anche le principali funzionalità di continuità aziendale che consentono di eseguire un ripristino di emergenza rapido in caso di interruzione a livello di area. Questo articolo contiene informazioni utili da consultare preventivamente sulla distribuzione dell'applicazione.

Nonostante il nostro continuo impegno a fornire una disponibilità elevata, in alcuni casi il servizio del database SQL di Azure subisce interruzioni che causano l'indisponibilità del database e influiscono pertanto sull'applicazione. Quando il nostro monitoraggio del servizio rileva problemi che causano errori di connettività, errori o problemi di prestazioni, il servizio dichiara automaticamente un'interruzione per mantenere l'utente informato.

Interruzione del servizio

In caso di interruzione del servizio del database SQL di Azure, è possibile trovare ulteriori dettagli relativi all'interruzione nelle posizioni seguenti:

• Banner del portale di Azure

  Se la sottoscrizione è identificata come interessata, viene visualizzato un avviso di interruzione del servizio nelle Notifiche del portale di Azure:

  

• Aiuto e supporto o Supporto e risoluzione dei problemi

  Quando si crea un ticket di supporto da Aiuto e supporto o da Supporto e risoluzione dei problemi, dove sono disponibili informazioni su eventuali problemi che influiscono sulle risorse. Selezionare Visualizza dettagli dell'interruzione per altre informazioni e un riepilogo dell'impatto. Nella pagina Nuova richiesta di supporto è presente anche un avviso.

  

• Integrità dei servizi

  La pagina Integrità dei servizi nel portale di Azure contiene informazioni sullo stato del data center di Azure a livello globale. Cercare "integrità dei servizi" nella barra di ricerca nel portale di Azure, 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. Di seguito è riportato uno screenshot di esempio della pagina Integrità dei servizi, con informazioni su un problema di servizio attivo in Asia sud-orientale:

  

• Notifica tramite email

  Se sono stati configurati avvisi, viene inviata una notifica tramite email da azure-noreply@microsoft.com quando un'interruzione del servizio influisce sulla sottoscrizione e sulla risorsa. Il corpo dell'email inizia in genere con "L'avviso del log attività ... è stato attivato da un problema di servizio per la sottoscrizione di Azure...". Per maggiori informazioni sugli avvisi di integrità dei servizi, vedere Ricevere avvisi del log attività sulle notifiche del servizio di Azure tramite portale di Azure.

• Metrica di disponibilità

  È possibile monitorare e configurare gli avvisi per la metrica di disponibilità del database SQL di Azure nel portale di Azure.

Quando avviare il ripristino di emergenza durante un'interruzione

In caso di interruzione del servizio che influisce sulle risorse dell'applicazione, considerare le seguenti linee d'azione:

• I team di Azure puntano a ripristinare la disponibilità del servizio quanto più rapidamente possibile, ma questo può richiedere ore in base alla causa radice. Se l'applicazione può tollerare tempi di inattività significativi, è possibile attendere semplicemente il completamento del ripristino. In tal caso, non è necessaria alcuna azione da parte dell'utente. Visualizzare l'integrità delle singole risorse nella pagina Integrità risorse di qualsiasi risorsa nel menu Aiuto. Fare riferimento alla pagina Integrità risorse per gli aggiornamenti e le informazioni più recenti relative a un'interruzione. Dopo il ripristino dell'area, la disponibilità dell'applicazione viene ripristinata.

• Il ripristino in un'altra area di Azure può richiedere la modifica delle stringhe di connessione dell'applicazione o l'uso del reindirizzamento DNS, e può causare una perdita di dati permanente. Pertanto, il ripristino di emergenza deve essere eseguito solo quando la durata dell'interruzione si avvicina all'obiettivo del tempo di ripristino dell'applicazione (RTO). Quando l'applicazione viene distribuita nell'ambiente di produzione, è consigliabile eseguire il monitoraggio regolare dell'integrità dell'applicazione e ricordare che il ripristino è garantito solo in caso di interruzione prolungata della connettività dal livello applicazione al database. A seconda della tolleranza dell'applicazione al tempo di inattività e alla possibile responsabilità aziendale, è possibile decidere se si vuole attendere il ripristino o avviare il ripristino di emergenza manualmente.

Indicazioni per il ripristino in seguito a interruzioni

Se l'interruzione del database SQL di Azure in un'area non è stata mitigata per un lungo periodo di tempo e influisce sul contratto di servizio dell'applicazione, considerare i passaggi seguenti:

Failover (nessuna perdita di dati) nel server secondario con replica geografica

Se la replica geografica attiva o i gruppi di failover sono abilitati, verificare se lo stato della risorsa del database primario e secondario è Online nel portale di Azure. In questo caso, il piano dati per il database primario e secondario è integro. Avviare un failover della replica geografica attiva o dei gruppi di failover nell'area secondaria usando il portale di Azure, T-SQL, PowerShell o l'interfaccia della riga di comando di Azure.

Nota

Un failover richiede la sincronizzazione completa dei dati prima di cambiare i ruoli e non comporta la perdita di dati. A seconda del tipo di interruzione del servizio non esiste alcuna garanzia che il failover senza perdita di dati avrà esito positivo, ma vale la pena provare come prima opzione di recupero.

Usare i seguenti link per avviare un failover pianificato:

Tecnologia	Metodo	Passaggi
Replica geografica attiva	PowerShell	Failover in un database secondario con replica geografica tramite PowerShell
	T-SQL	Failover in un database secondario con replica geografica tramite T-SQL
Gruppi di failover	Interfaccia della riga di comando di Azure	Failover nel server secondario tramite l'interfaccia della riga di comando di Azure
	Azure portal	Failover nel server secondario tramite il portale di Azure
	PowerShell	Failover nel server secondario tramite PowerShell

Failover forzato (potenziale perdita di dati) nel server secondario con replica geografica

Se il failover non viene completato correttamente e si verificano errori o se lo stato del database primario non è online, prendere attentamente in considerazione il failover forzato con potenziale perdita di dati nell'area secondaria.

Per avviare un failover forzato, usare i collegamenti seguenti:

Tecnologia	Metodo	Passaggi
Replica geografica attiva	Interfaccia della riga di comando di Azure	Failover forzato nella replica geografica secondaria tramite l'interfaccia della riga di comando di Azure
	Azure portal	Failover forzato in un database secondario con replica geografica tramite il portale di Azure
	PowerShell	Failover forzato in un database secondario con replica geografica tramite PowerShell
	T-SQL	Failover forzato in un database secondario con replica geografica tramite T-SQL
Gruppi di failover	Azure portal	Failover forzato nel server secondario tramite il portale di Azure ma scegliere Failover forzato.
	Interfaccia della riga di comando di Azure	Failover forzato nel server secondario tramite l'interfaccia della riga di comando di Azure, ma usare --allow-data-loss
	PowerShell	Failover forzato nel server secondario tramite PowerShell, ma usare -AllowDataLoss

Ripristino geografico

Se non è stata abilitata la replica geografica attiva o i gruppi di failover, è possibile usare il ripristino geografico per eseguire il ripristino da un'interruzione. Il ripristino geografico usa come origine un backup con replica geografica. Puoi ripristinare un database presente su un server logico in qualsiasi area di Azure usando gli ultimi backup con replica geografica. È possibile richiedere un ripristino geografico anche se un'interruzione ha reso inaccessibile il database o l'intera area.

Per altre informazioni sui ripristini geografici tramite l'interfaccia della riga di comando di Azure, il portale di Azure, PowerShell o l'API REST, vedere Ripristino geografico del database SQL di Azure.

Configurare il database dopo il ripristino

Se si usa il failover geografico o il ripristino geografico per il ripristino dopo un'interruzione, è necessario assicurarsi che la connettività al nuovo database sia configurata correttamente per poter riprendere il normale funzionamento dell'applicazione. Di seguito è riportato un elenco di controllo di attività per fare in modo che il database ripristinato sia pronto per la produzione.

Importante

Si consiglia di condurre esercitazioni periodiche della strategia di ripristino di emergenza per verificare la tolleranza dell'applicazione, nonché tutti gli aspetti operativi della procedura di ripristino. Gli altri livelli dell'infrastruttura dell'applicazione possono richiedere una riconfigurazione. Per maggiori informazioni sui passaggi dell'architettura resiliente, vedere l'elenco di controllo per la disponibilità elevata e il ripristino di emergenza del database SQL di Azure.

Aggiornare le stringhe di connessione

• Se si usa la replica geografica attiva o il ripristino geografico, è necessario assicurarsi che la connettività ai nuovi database sia configurata correttamente per poter riprendere il normale funzionamento dell'applicazione. Poiché il database ripristinato si trova in un server diverso, è necessario aggiornare la stringa di connessione dell'applicazione in modo che punti a tale server. Per altre informazioni sulla modifica delle stringhe di connessione, vedere il linguaggio di sviluppo appropriato per le raccolte di connessioni.
• Se si usano gruppi di failover per il ripristino da un'interruzione e si usano listener di lettura-scrittura e di sola lettura nelle stringhe di connessione dell'applicazione, non sono necessarie altre azioni perché le connessioni vengono indirizzate automaticamente alla nuova istanza primaria.

Configurare le regole del firewall

Verificare che le regole firewall configurate nel server secondario e nel database corrispondano a quelle configurate nel server primario e nel database primario. Per altre informazioni, si veda Procedura: configurare le impostazioni del firewall.

Configurare gli account di accesso e gli utenti del database

Creare gli account di accesso che devono essere presenti nel database master nel nuovo server primario e verificare che questi account di accesso dispongano delle autorizzazioni appropriate nel database master, se necessarie. Per altre informazioni, si veda Come gestire la sicurezza dopo il ripristino di emergenza.

Avvisi di telemetria di configurazione

Assicurarsi che le impostazioni delle regole di avviso esistenti vengano aggiornate per mapparle al nuovo database primario e al nuovo server. Per altre informazioni sulle regole di avviso per il database, vedere Ricevere notifiche di avviso e Tracciare l’integrità del servizio.

Abilitare il controllo

Se il controllo è configurato nel server primario, renderlo identico nel server secondario. Per altre informazioni, vedere Controllo.

Contenuto correlato

Per altre informazioni, vedere:

• Scenari di continuità.
• Backup automatizzati
• Ripristinare un database dai backup avviati dal servizio.
• Per altre informazioni su opzioni di ripristino più veloci, consultare l'articolo sulla replica geografica attiva e i gruppi di failover.
• Si veda la guida per il ripristino di emergenza e l’elenco di controllo per la disponibilità elevata e il ripristino di emergenza.