Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server)

 

QUESTO ARGOMENTO SI APPLICA A:sìSQL Server (a partire dalla versione 2016)noDatabase SQL di AzurenoAzure SQL Data WarehousenoParallel Data Warehouse

In questo argomento si illustrano le considerazioni sulla distribuzione di Gruppi di disponibilità AlwaysOn, inclusi prerequisiti, restrizioni e indicazioni su computer host, cluster WSCF (Windows Server Failover Clustering), istanze del server e gruppi di disponibilità. Per ognuno di questi componenti sono indicate le eventuali considerazioni sulla sicurezza e le autorizzazioni richieste.

System_CAPS_ICON_important.jpg Importante


Prima di distribuire Gruppi di disponibilità AlwaysOn, si consiglia di leggere tutte le sezioni presenti in questo argomento.

A seconda dei componenti e delle funzionalità di SQL Server 2016 che verranno utilizzati con Gruppi di disponibilità AlwaysOn, potrebbe essere necessario aggiungere hotfix di .Net aggiuntivi identificati nella seguente tabella. Gli hotfix possono essere installati in qualsiasi ordine.

Funzionalità dipendenteHotfixCollegamento
CheckboxReporting ServicesL'hotfix per .Net 3.5 SP1 aggiunge il supporto a SQL Client per le funzionalità AlwaysOn di Read-intent, readonly e multisubnetfailover. L'hotfix deve essere installato in ogni server di report di Reporting Services.KB 2654347: articolo relativo all'hotfix per .Net 3.5 SP1 per aggiungere supporto alle funzionalità AlwaysOn

Contenuto della sezione

Elenco di controllo: requisiti (sistema Windows)

Per supportare la funzionalità Gruppi di disponibilità AlwaysOn, assicurarsi che ogni computer che fa parte di uno o più gruppi di disponibilità soddisfi i requisiti essenziali seguenti:

RequisitoCollegamento
CheckboxAssicurarsi che il sistema non sia un controller di dominio.I gruppi di disponibilità non sono supportati nei controller di dominio.
CheckboxAssicurarsi che in ogni computer sia eseguita la versione di Windows Server 2012 o successive.Requisiti hardware e software per l'installazione di SQL Server 2016
CheckboxAssicurarsi che ogni computer sia un nodo in un cluster WSCF (Windows Server Failover Clustering).Windows Server Failover Clustering (WSFC) con SQL Server
CheckboxAssicurarsi che nel cluster WSFC siano contenuti nodi sufficienti per supportare le configurazioni dei gruppi di disponibilità.Un nodo WSFC può ospitare solo una replica di disponibilità per un gruppo di disponibilità specifico. In un nodo WSFC specificato possono essere ospitate repliche di disponibilità per numerosi gruppi di disponibilità da parte di una o più istanze di SQL Server .

Chiedere agli amministratori del database il numero di nodi WSFC necessario per supportare le repliche di disponibilità dei gruppi di disponibilità pianificati.

 Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server).
System_CAPS_ICON_important.jpg Importante


Inoltre, assicurarsi che l'ambiente sia configurato correttamente per la connessione a un gruppo di disponibilità. Per altre informazioni, vedere Connettività client AlwaysOn (SQL Server).

Indicazioni per computer in cui sono ospitate repliche di disponibilità (sistema Windows)

  • Sistemi simili: per un gruppo di disponibilità specificato, tutte le repliche di disponibilità devono essere eseguite in sistemi simili in grado di gestire carichi di lavoro identici.

  • Schede di rete dedicate: per ottimizzare le prestazioni, usare una scheda di rete dedicata (scheda di interfaccia di rete) per Gruppi di disponibilità AlwaysOn.

  • Spazio su disco sufficiente: in ogni computer in cui una replica di disponibilità è ospitata da un'istanza del server deve essere disponibile spazio su disco sufficiente per tutti i database nel gruppo di disponibilità. Tenere presente che, con l'aumentare delle dimensioni dei database primari, i database secondari corrispondenti aumentano di conseguenza.

Autorizzazioni (sistema Windows)

Per amministrare un cluster WSFC, l'utente deve essere un amministratore di sistema in ogni nodo del cluster.

Per altre informazioni sull'account per l'amministrazione del cluster, vedere Appendice A: Requisiti di un cluster di failover.

Attività correlate (sistema Windows)

AttivitàCollegamento
Impostare il valore HostRecordTTL.Modificare HostRecordTTL (tramite Windows PowerShell)

Modificare HostRecordTTL (tramite Windows PowerShell)

  1. Aprire la finestra di PowerShell con Esegui come amministratore.

  2. Importare il modulo FailoverClusters.

  3. Usare il cmdlet Get-ClusterResource per cercare la risorsa nome di rete, quindi usare il cmdlet Set-ClusterParameter per impostare il valore HostRecordTTL, come segue:

    Get-ClusterResource “<NetworkResourceName>” | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

    Nell'esempio di PowerShell seguente impostare HostRecordTTL su 300 secondi per una risorsa nome di rete denominata "SQL Network Name (SQL35)".

    Import-Module FailoverClusters  
    
    $nameResource = "SQL Network Name (SQL35)"  
    Get-ClusterResource $nameResource | Set-ClusterParameter ClusterParameter HostRecordTTL 300  
    
    
    System_CAPS_ICON_tip.jpg Suggerimento


    Ogni volta che viene aperta una nuova finestra di PowerShell, è necessario importare il modulo FailoverClusters.

Contenuto correlato (PowerShell)

Contenuto correlato (sistema Windows)

Per ogni gruppo di disponibilità è richiesto un set di partner di failover, noti come repliche di disponibilità, ospitati da istanze di SQL Server. Un'istanza del server specifica può essere un'istanza autonoma o un'istanza del cluster di failover (FCI) di SQL Server.

Contenuto della sezione

Elenco di controllo: prerequisiti (istanza del server)

PrerequisitiCollegamenti
CheckboxIl computer host deve essere un nodo WSFC (Windows Server Failover Clustering). Le istanze di SQL Server in cui sono ospitate le repliche di disponibilità di uno specifico gruppo di disponibilità risiedono in nodi diversi di un singolo cluster WSFC. Quando viene eseguita la migrazione a un altro cluster WSFC, un gruppo di disponibilità può risiedere temporaneamente in due cluster. SQL Server 2016 introduce i gruppi di disponibilità distribuita. In un gruppo di disponibilità distribuita due gruppi di disponibilità gruppo risiedono in cluster WSFC diversi.Windows Server Failover Clustering (WSFC) con SQL Server

 Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server)
 
 Gruppi di disponibilità distribuiti (gruppi di disponibilità AlwaysOn)
CheckboxSe si desidera che in un gruppo di disponibilità venga utilizzato Kerberos:

In tutte le istanze del server in cui è ospitata una replica di disponibilità per il gruppo di disponibilità deve essere utilizzato lo stesso account del servizio SQL Server.

L'amministratore di dominio deve registrare manualmente un nome dell'entità servizio (SPN, Service Principal Name) con Active Directory nell'account del servizio SQL Server per il nome di rete virtuale del listener del gruppo di disponibilità. Se il nome SPN è registrato in un account diverso da quello del servizio SQL Server, l'autenticazione non verrà completata.

 

 **Importante** Se si modifica l'account del servizio SQL Server, l'amministratore di dominio dovrà registrare di nuovo manualmente il nome SPN.
Registrazione di un nome dell'entità servizio per le connessioni Kerberos

 Breve spiegazione:

A Kerberos e ai nomi SPN viene applicata l'autenticazione reciproca. Tramite il nome SPN viene eseguito il mapping all'account di Windows mediante il quale vengono avviati i servizi SQL Server. Se la registrazione del nome SPN non viene eseguita correttamente o presenta un errore, tramite il livello di sicurezza di Windows non è possibile determinare l'account associato al nome SPN e l'autenticazione Kerberos non può essere utilizzata.

 

Nota: NTLM non presenta questo requisito.
CheckboxSe si intende utilizzare un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, assicurarsi di aver compreso le restrizioni su questo tipo di istanza e che vengano soddisfatti i relativi requisiti.Prerequisiti e requisiti sull'utilizzo di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, più avanti in questo argomento.
CheckboxIn ogni istanza del server deve essere in esecuzione la versione Enterprise Edition di SQL Server 2016.Funzionalità supportate dalle edizioni di SQL Server 2016
CheckboxIn tutte le istanze del server in cui sono ospitate repliche di disponibilità per un gruppo di disponibilità devono essere utilizzate le stesse regole di confronto di SQL Server.Impostazione o modifica di regole di confronto del server
CheckboxAbilitare la funzionalità Gruppi di disponibilità AlwaysOn in ogni istanza del server in cui sarà ospitata una replica di disponibilità per qualsiasi gruppo di disponibilità. In un computer specificato è possibile abilitare tante istanze del server per Gruppi di disponibilità AlwaysOn quante sono quelle supportate dall'installazione di SQL Server.Abilitare e disabilitare la funzionalità Gruppi di disponibilità AlwaysOn (SQL Server)

 

 **Importante** Se si elimina e si ricrea un cluster WSFC, è necessario disabilitare e riabilitare la funzionalità Gruppi di disponibilità AlwaysOn in ogni istanza del server abilitata per Gruppi di disponibilità AlwaysOn nel cluster WSFC originale.
CheckboxPer ogni istanza del server è necessario un endpoint del mirroring del database. Si noti che questo endpoint è condiviso da tutte le repliche di disponibilità, dai partner di mirroring di database, nonché dai server di controllo nell'istanza del server.

Se un'istanza del server selezionata come host per una replica di disponibilità è in esecuzione in un account utente di dominio e non dispone ancora di un endpoint del mirroring del database, tramite la Creazione guidata Gruppo di disponibilità (o Procedura guidata Aggiungi replica a gruppo di disponibilità) è possibile creare l'endpoint e concedere l'autorizzazione CONNECT all'account del servizio dell'istanza del server. Se, tuttavia, il servizio SQL Server viene eseguito come account predefinito, ad esempio Sistema locale, Servizio locale o Servizio di rete, oppure come account non di dominio, è necessario usare certificati per l'autenticazione dell'endpoint e non sarà possibile creare un endpoint del mirroring del database nell'istanza del server tramite la procedura guidata. In tal caso, è consigliabile creare manualmente gli endpoint del mirroring del database prima di avviare la procedura guidata.

 

 ** Nota di sicurezza ** La sicurezza del trasporto per Gruppi di disponibilità AlwaysOn corrisponde a quella per il mirroring del database.
Endpoint del mirroring del database (SQL Server)

 Sicurezza trasporto per il mirroring del database e i gruppi di disponibilità AlwaysOn (SQL Server)
CheckboxSe tutti i database in cui è utilizzato FILESTREAM saranno aggiunti a un gruppo di disponibilità, verificare che FILESTREAM sia abilitato in ogni istanza del server in cui sarà ospitata una replica di disponibilità per il gruppo di disponibilità.Abilitare e configurare FILESTREAM
CheckboxSe tutti i database indipendenti saranno aggiunti a un gruppo di disponibilità, verificare che l'opzione del server contained database authentication sia impostata su 1 in ogni istanza del server in cui sarà ospitata una replica di disponibilità per il gruppo di disponibilità.Opzione di configurazione del server contained database authentication

 Opzioni di configurazione del server (SQL Server)

Utilizzo del thread da parte dei gruppi di disponibilità

Gruppi di disponibilità AlwaysOn devono essere soddisfatti i requisiti seguenti:

  • In caso di istanza inattiva di SQL Server, in Gruppi di disponibilità AlwaysOn non viene utilizzato alcun thread.

  • Il numero massimo di thread usato dai gruppi di disponibilità è dato dall'impostazione configurata per il numero massimo di thread del server ('max worker threads') meno 40.

  • Nelle repliche di disponibilità ospitate in un'istanza del server specificata viene condiviso un singolo pool di thread.

    I thread vengono condivisi su richiesta, come riportato di seguito:

    • In genere, sono presenti 3-10 thread condivisi, tuttavia questo numero può aumentare a seconda del carico di lavoro della replica primaria.

    • Se un thread specificato è inattivo per un certo periodo di tempo, viene rilasciato nuovamente nel pool di thread generale di SQL Server . In genere, un thread inattivo viene rilasciato dopo ~15 secondi di inattività. Tuttavia, a seconda dell'ultima attività, un thread inattivo potrebbe essere mantenuto più a lungo.

    • Un'istanza di SQL Server usa fino a 100 thread per la fase di rollforward parallelo per le repliche secondarie. Ogni database usa fino a metà del numero totale di core CPU, ma non più di 16 thread per ogni database. Se il numero totale di thread necessari per una singola istanza supera 100, SQL Server usa un unico thread di fase di rollforward per tutti i database rimanenti. I thread della fase di rollforward vengono rilasciati dopo ~15 secondi di inattività.

  • Inoltre, nei gruppi di disponibilità vengono utilizzati thread non condivisi, come riportato di seguito:

    • In ogni replica primaria viene utilizzato 1 thread di acquisizione del log per ogni database primario. Inoltre, viene utilizzato 1 thread di invio del log per ogni database secondario. I thread di invio del log vengono rilasciati dopo ~15 secondi di inattività.

    • Tramite un backup di una replica secondaria un thread viene mantenuto nella replica primaria per la durata dell'operazione di backup.

Per altre informazioni, vedere la pagina relativa alla serie di informazioni su HADRON riguardanti l'uso del pool di lavoro per database abilitati HADRON in AlwaysOn (blog del Servizio Supporto Tecnico Clienti per gli ingegneri di SQL Server).

Autorizzazioni (istanza del server)

AttivitàAutorizzazioni necessarie
Creazione dell'endpoint del mirroring del databaseÈ richiesta l'autorizzazione CREATE ENDPOINT o l'appartenenza al ruolo predefinito del server sysadmin . È richiesta inoltre l'autorizzazione CONTROL ON ENDPOINT. Per altre informazioni, vedere GRANT - autorizzazioni per endpoint (Transact-SQL).
Abilitazione di Gruppi di disponibilità AlwaysOnÈ richiesta l'appartenenza al gruppo degli amministratori nel computer locale, nonché il controllo totale nel cluster WSCF.

Attività correlate (istanza del server)

AttivitàArgomento
Determinazione della presenza di un endpoint del mirroring del databasesys.database_mirroring_endpoints (Transact-SQL)
Creazione dell'endpoint del mirroring del database (se non ancora disponibile)Creare un endpoint del mirroring del database per l'autenticazione Windows (Transact-SQL)

 Utilizzare certificati per un endpoint del mirroring del database (Transact-SQL)

 Creare un endpoint del mirroring del database per i gruppi di disponibilità AlwaysOn (SQL Server PowerShell)
Abilitazione dei gruppi disponibilitàAbilitare e disabilitare la funzionalità Gruppi di disponibilità AlwaysOn (SQL Server)

Contenuto correlato (istanza del server)

Si consiglia di utilizzare gli stessi collegamenti di rete per le comunicazioni tra membri del cluster WSFC e le comunicazioni tra repliche di disponibilità. L'utilizzo di collegamenti di rete separati può provocare comportamenti imprevisti in caso di errore di alcuni collegamenti (anche in modo intermittente).

Ad esempio, affinché un gruppo di disponibilità supporti il failover automatico, lo stato della replica secondaria che è partner di failover automatico deve essere SYNCHRONIZED. In caso di errore di collegamento di rete a questa replica secondaria (anche in modo intermittente), lo stato della replica diventa UNSYNCHRONIZED e non sarà possibile cominciare la risincronizzazione fino a quando non viene ripristinato il collegamento. Se per il cluster WSFC è richiesto un failover automatico mentre la replica secondaria non è sincronizzata, il failover automatico non si verificherà.

Per informazioni sul supporto di Gruppi di disponibilità AlwaysOn per la connettività client, vedere Connettività client AlwaysOn (SQL Server).

Contenuto della sezione

Restrizioni (istanze del cluster di failover)

System_CAPS_ICON_note.jpg Nota


Le istanze del cluster di failover supportano i volumi condivisi cluster. Per ulteriori informazioni sui volumi condivisi cluster, vedere Informazioni sui volumi condivisi del cluster in un cluster di failover.

  • I nodi del cluster di un'istanza del cluster di failover possono ospitare solo una replica per un gruppo di disponibilità specificato: se si aggiunge una replica di disponibilità in un'istanza del cluster di failover, i nodi del cluster WSFC che sono i possibili proprietari dell'istanza del cluster di failover non possono ospitare un'altra replica per lo stesso gruppo di disponibilità.

    Inoltre, tutte le altre repliche devono essere ospitate da un'istanza di SQL Server 2016 che risiede in un nodo WSFC diverso nello stesso cluster WSFC. L'unica eccezione è che quando viene eseguita la migrazione a un altro cluster WSFC, un gruppo di disponibilità può risiedere temporaneamente in due cluster.

  • Le istanze del cluster di failover non supportano il failover automatico da gruppi di disponibilità: le istanze del cluster di failover non supportano il failover automatico da gruppi di disponibilità, pertanto qualsiasi replica di disponibilità ospitata da un'istanza del cluster di failover può essere configurata solo per il failover manuale.

  • Modifica del nome di rete di un'istanza del cluster di failover: se è necessario modificare il nome di rete di un'istanza del cluster di failover che ospita una replica di disponibilità, è necessario rimuovere la replica dal relativo gruppo di disponibilità e riaggiungerla successivamente a questo gruppo. Non è possibile rimuovere la replica primaria, pertanto se si rinomina un'istanza del cluster di failover in cui è ospitata la replica primaria, è consigliabile eseguire il failover in una replica secondaria e successivamente rimuovere e poi riaggiungere la prima replica primaria. Si noti che la ridenominazione di un'istanza del cluster di failover può comportare la modifica dell'URL del relativo endpoint del mirroring del database. Quando si aggiunge la replica assicurarsi di specificare l'URL dell'endpoint corrente.

Elenco di controllo: prerequisiti (istanze del cluster di failover)

PrerequisitiCollegamento
CheckboxAssicurarsi che in ogni istanza del cluster di failover di SQL Server sia disponibile l'archiviazione condivisa necessaria in base all'installazione dell'istanza del cluster di failover di SQL Server standard.

Attività correlate (istanze del cluster di failover)

AttivitàArgomento
Installazione di un cluster di failover di SQL ServerCreare un nuovo cluster di failover di SQL Server (programma di installazione)
Aggiornamento sul posto del cluster di failover di SQL Server esistenteEseguire l'aggiornamento di un'istanza del cluster di failover di SQL Server (installazione)
Gestione del cluster di failover di SQL Server esistenteAggiungere o rimuovere nodi in un cluster di failover di SQL Server (programma di installazione)

Contenuto correlato (istanze del cluster di failover)

Contenuto della sezione

Restrizioni (gruppi di disponibilità)

  • Le repliche di disponibilità devono essere ospitate da nodi diversi di un cluster WSFC: per un gruppo di disponibilità specificato, le repliche di disponibilità devono essere ospitate da istanze del server in esecuzione in nodi diversi dello stesso cluster WSFC. L'unica eccezione è che quando viene eseguita la migrazione a un altro cluster WSFC, un gruppo di disponibilità può risiedere temporaneamente in due cluster.

    System_CAPS_ICON_note.jpg Nota


    In ogni macchina virtuale presente nello stesso computer fisico può essere ospitata una replica di disponibilità per lo stesso gruppo di disponibilità, in quanto ogni macchina virtuale costituisce un computer distinto.

  • Nome univoco del gruppo di disponibilità: ogni nome di gruppo di disponibilità deve essere univoco nel cluster WSFC. La lunghezza massima consentita per il nome del gruppo di disponibilità è 128 caratteri.

  • Repliche di disponibilità: ogni gruppo di disponibilità supporta una replica primaria e fino a otto repliche secondarie. È possibile eseguire tutte le repliche in modalità con commit asincrono oppure fino a un massimo di tre in modalità con commit sincrono (una replica primaria con due repliche secondarie sincrone).

  • Numero massimo di gruppi di disponibilità e database di disponibilità per computer: il numero effettivo di database e gruppi di disponibilità che è possibile creare in un computer fisico o in una VM dipende dall'hardware e dal carico di lavoro, tuttavia non esiste un limite imposto. Microsoft ha eseguito test estensivi con 10 gruppi di disponibilità e 100 database per computer fisico. I segnali di sistemi di overload possono includere, a titolo esemplificativo, l'esaurimento del thread di lavoro, tempi di risposta lenti per visualizzazioni di sistema del gruppo di disponibilità e DMV e/o dump del sistema dispatcher bloccati. Assicurarsi di testare completamente l'ambiente con un carico di lavoro simile a quello di produzione per assicurare che possa gestire capacità di carico di lavoro di picco all'interno del contratto sul livello di servizio dell'applicazione. Per i contratti sul livello di servizio occorre considerare il carico in condizioni di errore e i tempi di risposta previsti.

  • Non utilizzare Gestione cluster di failover per modificare i gruppi di disponibilità:

    Esempio:

    • Non modificare le proprietà del gruppo di disponibilità, ad esempio i possibili proprietari.

    • Non utilizzare Gestione cluster di failover per eseguire il failover dei gruppi di disponibilità. È necessario utilizzare Transact-SQL o SQL Server Management Studio.

Prerequisiti (gruppi di disponibilità)

Quando si crea o riconfigura una configurazione del gruppo di disponibilità, assicurarsi che si soddisfino i requisiti seguenti.

PrerequisitiDescrizione
CheckboxSe si intende utilizzare un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, assicurarsi di aver compreso le restrizioni su questo tipo di istanza e che vengano soddisfatti i relativi requisiti.Prerequisiti e restrizioni per l'uso di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, precedentemente in questo argomento.

Sicurezza (gruppi di disponibilità)

  • La sicurezza viene ereditata dal cluster WSCF (Windows Server Failover Clustering). WSFC fornisce due livelli di sicurezza utente con granularità di API del cluster WSFC intere:

    • Accesso di sola lettura

    • Controllo completo

      Gruppi di disponibilità AlwaysOn necessita di un controllo completo. Se si abilita Gruppi di disponibilità AlwaysOn in un'istanza di SQL Server viene fornito a quest'ultima il controllo completo del cluster WSFC, tramite il SID del servizio.

      Non è possibile aggiungere o rimuovere direttamente la sicurezza per un'istanza del server in Gestione cluster di failover di WSFC. Per gestire sessioni di sicurezza di WSFC, utilizzare Gestione configurazione SQL Server o l'equivalente WMI da SQL Server.

  • Ogni istanza di SQL Server deve disporre delle autorizzazioni per l'accesso al Registro di sistema, al cluster e così via.

  • È consigliabile utilizzare la crittografia per le connessioni tra istanze del server in cui si ospitano repliche di disponibilità di Gruppi di disponibilità AlwaysOn.

Autorizzazioni (gruppi di disponibilità)

AttivitàAutorizzazioni necessarie
Creazione di un gruppo di disponibilitàSono necessarie l'appartenenza al ruolo predefinito del server sysadmin e l'autorizzazione server CREATE AVAILABILITY GROUP oppure l'autorizzazione ALTER ANY AVAILABILITY GROUP o CONTROL SERVER.
Modifica di un gruppo di disponibilitàÈ necessaria l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP o l'autorizzazione CONTROL SERVER.

Inoltre, per la creazione di un join di un database a un gruppo di disponibilità è richiesta l'appartenenza al ruolo predefinito del database db_owner.
Rimozione/eliminazione di un gruppo di disponibilitàÈ necessaria l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP o l'autorizzazione CONTROL SERVER. Per rimuovere un gruppo di disponibilità non ospitato nel percorso della replica locale, è necessaria l'autorizzazione CONTROL SERVER o CONTROL per questo gruppo di disponibilità.

Attività correlate (gruppi di disponibilità)

AttivitàArgomento
Creazione di un gruppo di disponibilitàUtilizzare il gruppo di disponibilità (Creazione guidata Gruppo di disponibilità)

 Creare un gruppo di disponibilità (Transact-SQL)

 Creare un gruppo di disponibilità (SQL Server PowerShell)

 Specifica dell'URL dell'endpoint quando si aggiunge o si modifica una replica di disponibilità (SQL Server)
Modifica del numero di repliche di disponibilitàAggiungere una replica secondaria a un gruppo di disponibilità (SQL Server)

 Creare un join di una replica secondaria a un gruppo di disponibilità (SQL Server)

 Rimuovere una replica secondaria da un gruppo di disponibilità (SQL Server)
Creazione di un listener del gruppo di disponibilitàCreare o configurare un listener del gruppo di disponibilità (SQL Server)
Rimozione di un gruppo di disponibilitàRimuovere un gruppo di disponibilità (SQL Server)

Per essere idoneo a essere aggiunto a un gruppo di disponibilità, un database deve soddisfare i prerequisiti e le restrizioni riportate di seguito.

Contenuto della sezione

Elenco di controllo: requisiti (database di disponibilità)

Per essere idoneo a essere aggiunto a un gruppo di disponibilità, un database deve soddisfare i requisiti seguenti:

RequisitiCollegamento
CheckboxDeve trattarsi di un database utente. I database di sistema non possono appartenere a un gruppo di disponibilità.
CheckboxDeve trovarsi nell'istanza di SQL Server in cui si crea il gruppo di disponibilità e deve essere accessibile all'istanza del server.
CheckboxDeve trattarsi di un database di lettura/scrittura. I database di sola lettura non possono essere aggiunti a un gruppo di disponibilità.sys.databases (is_read_only = 0)
CheckboxDeve trattarsi di un database multiutente.sys.databases (user_access = 0)
CheckboxNon deve essere utilizzato AUTO_CLOSE.sys.databases (is_auto_close_on = 0)
CheckboxUtilizzare il modello di recupero con registrazione completa (noto anche come modalità di recupero con registrazione completa).sys.databases (recovery_model = 1)
CheckboxDeve disporre di almeno un backup completo del database.

Nota: dopo aver impostato un database sulla modalità di recupero con registrazione completa, è necessario un backup completo per iniziare la catena di log del recupero con registrazione completa.
Creazione di un backup completo del database (SQL Server)
CheckboxNon deve appartenere ad alcun gruppo di disponibilità esistente.sys.databases (group_database_id = NULL)
CheckboxNon deve essere configurato per il mirroring del database.sys.database_mirroring Se il database non fa parte del mirroring, tutte le colonne con prefisso "mirroring_" sono NULL.
CheckboxPrima di aggiungere un database in cui è utilizzato FILESTREAM a un gruppo di disponibilità, verificare che FILESTREAM sia abilitato in ogni istanza del server in cui è o sarà ospitata una replica di disponibilità per il gruppo di disponibilità.Abilitare e configurare FILESTREAM
CheckboxPrima di aggiungere un database indipendente a un gruppo di disponibilità, verificare che l'opzione del server contained database authentication sia impostata su 1 in ogni istanza del server in cui è o sarà ospitata una replica di disponibilità per il gruppo di disponibilità.Opzione di configurazione del server contained database authentication

 Opzioni di configurazione del server (SQL Server)
System_CAPS_ICON_note.jpg Nota


Gruppi di disponibilità AlwaysOn funziona con qualsiasi livello di compatibilità del database supportato.

Restrizioni (database di disponibilità)

  • Se il percorso del file, inclusa la lettera di unità, di un database secondario differisce da quello del database primario corrispondente, si applicano le restrizioni seguenti:

    • Creazione guidata Gruppo di disponibilità/Procedura guidata Aggiungi database a gruppo di disponibilità: l'opzione Completo nella pagina Seleziona sincronizzazione dati iniziale non è supportata.

    • RESTORE WITH MOVE: per creare i database secondari, i file di database devono essere RESTORED WITH MOVE in ogni istanza di SQL Server in cui è ospitata una replica secondaria.

    • **Impatto sulle operazioni di aggiunta di file: ** un'operazione di aggiunta di file successiva nella replica primaria può generare un errore nei database secondari. Questo errore può causare la sospensione dei database secondari. Questa situazione, a sua volta, può causare l'attivazione dello stato NON IN SINCRONIZZAZIONE delle repliche secondarie.

      System_CAPS_ICON_note.jpg Nota


      Per informazioni sulla risposta a un'operazione di aggiunta di file errata, vedere Risolvere i problemi relativi a una operazione di aggiunta file non riuscita (Gruppi di disponibilità AlwaysOn).

  • Non è possibile eliminare un database che attualmente appartiene a un gruppo di disponibilità.

Completamento per database protetti tramite crittografia TDE

Se si utilizza TDE (Transparent Data Encryption), la chiave asimmetrica o il certificato per la creazione e la decrittografia di altre chiavi deve essere identico in ogni istanza del server in cui viene ospitata una replica di disponibilità per il gruppo di disponibilità. Per altre informazioni, vedere Spostare un database protetto da TDE in un'altra istanza di SQL Server.

Autorizzazioni (database di disponibilità)

È richiesta l'autorizzazione ALTER per il database.

Attività correlate (database di disponibilità)

AttivitàArgomento
Preparazione di un database secondario (manuale)Preparare manualmente un database secondario per un gruppo di disponibilità (SQL Server)
Creazione di un join di un database secondario a un gruppo di disponibilità (manuale)Creare un join di un database secondario a un gruppo di disponibilità (SQL Server)
Modifica del numero di database di disponibilitàAggiungere un database a un gruppo di disponibilità (SQL Server)

 Rimuovere un database secondario da un gruppo di disponibilità (SQL Server)

 Rimuovere un database primario da un gruppo di disponibilità (SQL Server)

Panoramica di Gruppi di disponibilità Always On (SQL Server)
Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server)
Connettività client AlwaysOn (SQL Server)


Aggiunte alla community

AGGIUNGI
Mostra: