Guida al ripristino di emergenza - Istanza gestita di SQL di Azure
Si applica a: 
Istanza gestita di SQL di Azure SQL
L’istanza gestita di SQL 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. L’istanza gestita 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 dell’istanza gestita SQL di Azure subisce interruzioni che causano l'indisponibilità dell’istanza gestita 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 di istanza gestita 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.comquando 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.
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 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 dell’istanza gestita 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) nell’istanza secondaria con replica geografica
Se 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 l’istanza primaria e secondaria è integro.
Avviare un failover dei gruppi di failover nell'area secondaria usando:
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.
Failover forzato (potenziale perdita di dati) nell’istanza secondaria 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:
- Portale di Azure ma scegliere e Failover forzato.
- PowerShell ma usare
--allow-data-loss. - Interfaccia della riga di comando di Azure ma usare
-AllowDataLoss.
Ripristino geografico
Se non sono stati abilitati 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. È possibile ripristinare un database in qualsiasi istanza in qualsiasi area di Azure dai backup con replica geografica più recenti. Puoi richiedere un ripristino geografico anche se l’istanza o l’intera area è inaccessibile a causa di un'interruzione del servizio.
Per altre informazioni sui ripristini geografici tramite l'interfaccia della riga di comando di Azure, il portale di Azure, PowerShell o l'API REST, si veda Ripristino geografico.
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à alla nuova istanza 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, si veda l'elenco di controllo per la disponibilità elevata e il ripristino di emergenza.
Aggiornare le stringhe di connessione
- Se si utilizza il ripristino geografico, è necessario assicurarsi che la connettività alle nuove istanze sia configurata correttamente in modo da poter riprendere il normale funzionamento dell'applicazione. Poiché il database ripristinato si trova in un’istanza diversa, è 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
Assicurarsi che le regole del gruppo di sicurezza di rete e della tabella di route configurate per l'istanza secondaria corrispondano a quelle configurate nell'istanza primaria. Per maggiori informazioni, si veda configurazione della subnet supportata dal servizio.
Configurare gli account di accesso e gli utenti del database
Creare gli account di accesso che devono essere presenti nel database master nella nuova istanza primaria e verificare che questi account di accesso dispongano delle autorizzazioni appropriate nel database master, se necessarie.
Avvisi di telemetria di configurazione
Assicurarsi che le impostazioni delle regole di avviso esistenti vengano aggiornate per eseguire il mapping alla nuova istanza primaria. 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 è stato configurato il controllo nell'istanza primaria, renderlo identico nell'istanza secondaria. Per maggiori informazioni, vedere Controllo SQL di Azure per l’istanza gestita SQL di Azure.
Contenuto correlato
Per altre informazioni, vedere: