Indicazioni sul ripristino di emergenza - Database SQL di Azure

  • Articolo

Si applica a: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:

    A screenshot from the Azure portal of a notification of an Azure SQL Database service issue.

  • 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.

    A screenshot of the Help+Support page showing a notification of an active service health issue..

  • 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:

    A screenshot of the Azure portal Service Health page during a service issue in Southeast Asia, showing the Issue and a map of affected resources.

  • 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.

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 i backup con replica geografica. È possibile ripristinare un database su qualsiasi server logico in qualsiasi area di Azure dai backup con replica geografica più recenti. È 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 al nuovo database primario.

Configurare le regole del firewall

Verificare che le regole firewall configurate nel server e nel database corrispondano a quelle configurate nel server primario e nel database primario. Per altre informazioni, vedere Procedura: Configurare le impostazioni del firewall (Database SQL di Azure).

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, vedere come gestire la sicurezza del database SQL di Azure 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 è necessario il controllo di accesso al database, occorre attivare il controllo dopo il ripristino del database. Per maggiori informazioni, vedere Controllo SQL di Azure per il database SQL di Azure.

Passaggi successivi