Condividi tramite

Elenco di controllo per la disponibilità elevata e il ripristino di emergenza dell’istanza gestita di SQL di Azure

  • Articolo

Si applica a: Istanza gestita di SQL di Azure SQL

Il servizio Istanza gestita di 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 livelli di servizio di Istanza gestita di 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:

  • Abilitare la ridondanza della zona, se disponibile per l’istanza gestita di SQL, per garantire la resilienza per gli errori di zona.

Elenchi di controllo per il ripristino di emergenza

Anche se l’istanza gestita di 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 dell’istanza gestita di 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 l'istanza.
    • 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 istanza primaria.
    • Impostare i criteri di failover su gestito dal cliente.
  • Verificare che l'istanza geografica secondaria venga creata con lo stesso livello di servizio, la generazione hardware e le dimensioni di calcolo dell'istanza primaria.
  • 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, è consigliabile impostare l'opzione di ridondanza dell'archivio di backup su archivio di backup con ridondanza geografica per usare la funzionalità di ripristino geografico.
  • 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 i gruppi di failover o il ripristino geografico, è necessario preparare un’istanza gestita SQL di Azure secondaria in un'altra area. Se necessario, questa istanza secondaria può diventare la nuova istanza primaria. 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 l’istanza in un'altra area perché diventi la nuova istanza primaria. In genere si tratta di un’istanza nell'area abbinata a quella in cui si trova l’istanza primaria. L'uso di un’istanza nella stessa area abbinata elimina i costi di traffico aggiuntivi durante le operazioni di 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, facoltativamente, definire la configurazione del gruppo di sicurezza di rete e della tabella di route a cui gli utenti devono accedere nel 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.
  • Documentare la configurazione del controllo nell’istanza primaria corrente e renderla identica nell'istanza secondaria.

Contenuto correlato

Per altre informazioni, vedere: