Condividi tramite

Elenco di controllo per la disponibilità elevata e il ripristino di emergenza - database SQL di Azure

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

Elenco di controllo per la disponibilità elevata

Segue la configurazione consigliata per ottenere una disponibilità elevata:

  • Abilita la ridondanza zonale dove disponibile per il database o il pool elastico, per garantire la resilienza ai guasti zonali.

Elenco di controllo per il ripristino di emergenza

Anche se il database SQL di Azure mantiene automaticamente la disponibilità, esistono istanze in cui anche la 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.
    • Utilizzare gli endpoint listener di lettura/scrittura e di sola lettura nella stringa di connessione dell'applicazione affinché le applicazioni si connettano automaticamente al server e al 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.
  • Assicurati che il database geografico secondario venga creato con lo stesso livello di servizio, livello di calcolo (con provisioning o serverless) e con 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 che effettua la chiamata fino a quando l'ultima transazione sottoposta a commit non viene trasmessa e registrata in modo definitivo 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 espresso in secondi tra le transazioni di cui è stato eseguito il commit nel database primario e quelle registrate nel log delle transazioni del database secondario. Si supponga, ad esempio, che il ritardo sia un secondo in un momento specifico, se il database primario è interessato da un'interruzione e un failover geografico viene avviato in quel momento, le transazioni di cui è stato eseguito il commit nell'ultimo secondo andranno perse.
  • Se l'abilitazione dei gruppi di failover o della replica geografica attiva non è possibile, è consigliabile impostare l'opzione di ridondanza dell'archiviazione di backup su archiviazione di backup con ridondanza geografica per usare ripristino geografico per il database SQL di Azure.
  • Pianificare frequentemente ed eseguire esercitazioni sul ripristino di emergenza in modo da essere più preparati in caso di interruzione reale.

Preparare il sistema secondario per 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 il ripristino geografico, identificare un server in un'altra area che diventerà 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 hai configurato gruppi di failover e usi il listener di lettura-scrittura e di sola lettura nelle stringhe di connessione dell'applicazione, non sono necessarie altre azioni: le connessioni vengono automaticamente indirizzate al nuovo 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 Configurare e gestire la sicurezza del database SQL di Azure per il ripristino geografico o il failover.
  • Identificare le regole di avviso che devono essere aggiornate per il collegamento al nuovo primario.
  • Documentare la configurazione di controllo nel server primario corrente e renderla identica nel server secondario.

Contenuto correlato