Elenco di controllo per la disponibilità elevata e il 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 servizio database SQL di Azure assicura automaticamente che tutti i database siano online e integri e si sforza costantemente di ottenere il contratto di servizio pubblicato.

Questa guida fornisce una revisione dettagliata dei passaggi proattivi che è possibile eseguire per ottimizzare la disponibilità, garantire il ripristino e prepararsi alle interruzioni di Azure. Queste linee guida si applicano a tutti i modelli di acquisto e i livelli di servizio di database SQL di Azure.

Elenco di controllo della disponibilità

Seguono le configurazioni consigliate per ottimizzare la disponibilità:

• Incorporare la logica di ripetizione dei tentativi nell'applicazione per gestire gli errori temporanei.
• Usare finestre di manutenzione per rendere prevedibili e meno problematici gli eventi di manutenzione.
• Testare la resilienza degli errori dell'applicazione attivando manualmente un failover per visualizzare la resilienza in azione.

Elenco di controllo per la disponibilità elevata

Segue la configurazione consigliata per ottenere una disponibilità elevata:

• Abilitare la ridondanza della zona, se disponibile per il database o il pool elastico, per garantire la resilienza per gli errori di zona.

Elenco di controllo per il ripristino di emergenza

Anche se database SQL di Azure mantiene automaticamente la disponibilità, esistono istanze in cui anche una disponibilità elevata (ridondanza della zona) potrebbe non garantire la resilienza perché l'interruzione che influisce si estende su un'intera area. Un'interruzione di database SQL di Azure a livello di area potrebbe richiedere l'avvio del ripristino di emergenza.

Per prepararsi al meglio per il ripristino di emergenza, attenersi alle seguenti raccomandazioni:

• Abilitare i gruppi di failover per un gruppo di database.
  • Usare gli endpoint listener in lettura/scrittura e di sola lettura nella stringa di connessione dell'applicazione, in modo che le applicazioni si connettano automaticamente a qualsiasi server e database attualmente primario.
  • Impostare i criteri di failover su gestito dal cliente.
• In alternativa ai gruppi di failover, è possibile abilitare la replica geografica attiva per avere un database secondario leggibile in un'area di Azure diversa.
• Assicurarsi che il database geografico secondario venga creato con lo stesso livello di servizio, livello di calcolo (con provisioning o serverless) e le stesse dimensioni di calcolo (DTU o vCore) del database primario.
• Quando si aumentano le prestazioni, è consigliabile aumentare prima quelle del database secondario geografico e successivamente quelle del database primario.
• In caso di riduzione delle prestazioni, invertire l'ordine: ridurre prima le prestazioni del database primario e successivamente ridurre le prestazioni di quello secondario.
• Il ripristino di emergenza, per natura, è progettato per usare la replica asincrona dei dati tra l'area primaria e l'area secondaria. Per classificare in ordine di priorità la disponibilità dei dati rispetto a una latenza di commit superiore, è consigliabile chiamare la stored procedure sp_wait_for_database_copy_sync immediatamente dopo aver eseguito il commit di una transazione. La chiamata sp_wait_for_database_copy_sync blocca il thread chiamante fino a quando l'ultima transazione sottoposta a commit non viene trasmessa e sottoposta a protezione avanzata nel log delle transazioni del database secondario.
• Monitorare il ritardo rispetto all'obiettivo del punto di ripristino (RPO) usando la colonna replication_lag_sec della vista a gestione dinamica (DMV) sys.dm_geo_replication_link_status nel database primario. Il DMV mostra il ritardo in secondi tra le transazioni di cui è stato eseguito il commit nel database primario e quelle sottoposte a protezione avanzata nel log delle transazioni nel database secondario. Ad esempio, supponendo che il ritardo sia di un secondo in un dato momento, se il database primario è interessato da un'interruzione in quel momento e viene avviato un failover geografico, le transazioni di cui è stato eseguito il commit nell'ultimo secondo andranno perse.
• Se non è possibile abilitare i gruppi di failover o della replica geografica attiva, è consigliabile impostare l'opzione di ridondanza dell'archivio di backup su archivio di backup con ridondanza geografica per usare la funzionalità di ripristino geografico.
  • Questa opzione non è disponibile nelle aree senza coppia di aree.
• Pianificare frequentemente ed eseguire esercitazioni sul ripristino di emergenza in modo da essere più preparati in caso di interruzione reale.

Preparare la replica secondaria a un'interruzione

Per un corretto ripristino in un'altra area dati usando la replica geografica attiva, i gruppi di failover o il ripristino geografico, è necessario preparare un server logico database SQL di Azure secondario in un'altra area. Se necessario, questo server secondario può diventare il nuovo server primario. Occorre inoltre disporre di passaggi ben definiti documentati e testati per garantire un ripristino senza interruzioni. La procedura di preparazione comprende:

• Per procedere al ripristino geografico, identificare un server logico in un'altra area perché diventi il nuovo server primario. Se l'area primaria ha un'area abbinata, è comune usare l'area abbinata come area secondaria. In questo modo, in genere si riduce la latenza per le operazioni di replica e ripristino geografico.
• Stabilire come reindirizzare gli utenti al nuovo server primario. Il reindirizzamento degli utenti può essere effettuato modificando manualmente le stringa di connessione dell'applicazione o le voci DNS. Se sono stati configurati gruppi di failover e si usa il listener in lettura/scrittura e di sola lettura nelle stringhe di connessione dell'applicazione, non sono necessarie altre azioni. Le connessioni vengono indirizzate automaticamente al nuovo server primario dopo il failover.
• Identificare e definire, facoltativamente, le regole del firewall di cui gli utenti necessitano per accedere al nuovo database primario.
• Identificare e, facoltativamente, creare gli account di accesso 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.
• Identificare le regole di avviso che devono essere aggiornate per il mapping sul nuovo database primario.
• Documentare la configurazione di controllo nel server primario corrente e renderla identica nel server secondario.

Contenuto correlato

• Esaminare la Guida al ripristino di emergenza per il database SQL di Azure.
• Esaminare il Contratto di servizio per database SQL di Azure.
• Per informazioni sui backup automatici del database SQL di Azure, vedere Backup automatici del database SQL.
• Per informazioni sugli scenari di progettazione e ripristino della continuità aziendale, leggere l'articolo relativo agli Scenari di continuità aziendale.
• Per altre informazioni sull'uso dei backup automatici per il ripristino, vedere l'articolo relativo al Ripristino di un database dai backup avviati dal servizio.
• Maggiori informazioni sulla replica geografica attiva.
• Maggiori informazioni sui gruppi di failover.
• Maggiori informazioni sul ripristino geografico.
• Maggiori informazioni sui database con ridondanza della zona.