"AlwaysOn" non è sempre "Always On?"

Abbiamo creato un cluster di failover di Windows, quindi aggiunto due istanze di SQL Server come nodi di un cluster di failover di SQL Server.

Abbiamo impostato i server per utilizzare "Gruppi di disponibilità AlwaysOn" in Gestione configurazione SQL.

Per testare un failover, ho caricato ed eseguito una query lunga, quindi ho rimosso il nodo attivo utilizzando Gestione cluster di failover per arrestare il servizio cluster sul nodo attivo.

La query si è interrotta senza connessione e il server è risultato non disponibile per circa 20 secondi prima che il nodo venisse svuotato e il nuovo nodo prendesse il controllo.

Ho sbagliato? Come avrei dovuto configurarlo in modo che ci fosse una perdita di connettività minima o nulla?

AlwaysOn non è sempre attivo?

Hai un sacco di domande diverse qui.

D: Qual è la cosa "Sempre attiva"?

Microsoft utilizza quel marchio (che è stato scritto senza uno spazio prima del 2016) per descrivere due diverse funzionalità:

• Istanze cluster di failover (FCI): ciò che tuo nonno chiamava un cluster attivo / passivo
• Gruppi di disponibilità (AG) - come il mirroring del database, ma in alcuni casi funziona con gruppi di database (ma non con i database di sistema)

Usa questi termini per descrivere quale specifica funzione Sempre attiva stai utilizzando.

D: In caso di failover, sarà sempre attivo?

Né le FCI né le AG sono sempre attive. Durante un failover, le transazioni in esecuzione falliranno e i tentativi di connessione potrebbero non riuscire per 5-60 secondi (o più). Sta a te creare una logica di tentativi aggraziata nelle tue applicazioni o creare strumenti con funzionalità degradate come Stack Overflow .

Q: Come configuro Always On?

Varia notevolmente in base a:

• Quale funzione AO ​​stai utilizzando (FCI o AG)
• Il numero di nodi nel cluster
• Come vuoi gestire il quorum (votazione)
• Se si utilizza il failover automatico tramite un listener o un nome di computer virtuale

Queste sono grandi decisioni che implicano molto lavoro di architettura. Per informazioni più dettagliate, includi i dettagli sopra e saremo in grado di dirti di più su come configurarlo.

D: Non si tratta solo di selezionare la casella Sempre attivo?

No.

Potresti confondere le AG "Always ON" (gruppi di disponibilità) con le FCI (istanze del cluster di failover), entrambe dipendenti dal WSFC (cluster di failover di Windows Server).

Facendo clic su "Sempre attivo" non è ora possibile disporre di una configurazione AG. Devi impostare le repliche asincrone, sincronizzazione, sola lettura / failover, impostare la priorità e prendere altre considerazioni come l'app supporta questa configurazione. Ad esempio, l'app potrebbe utilizzare transazioni MSDTC tra database, che non sono supportate e possono causare danni irreversibili che richiedono un ripristino di backup.

In questo momento quello che stai vivendo è un failover FCI. E 'normale. Ciò interrompe i servizi su un nodo e avvia i servizi sull'altro nodo. Funziona a livello di ISTANZA. Viene installata una soluzione AG per database e i servizi sono in esecuzione su entrambi i nodi. SQL utilizza le API WSFC per mantenere i dati sincronizzati sulle repliche e il database esegue il failover su quella replica; non notare l'istanza.

Potresti voler fare molti test su questo prima di passare alla produzione.

Il mio metodo preferito per testare un failover in un AG è semplicemente disconnettere l'attuale primario. Basta interromperlo, spegnerlo dalla console, strappare la sua rete, uccidere il servizio SQL con un proiettile d'argento, qualunque cosa. Non dovresti testarlo da qualcosa di simile alla GUI perché non è così che funziona il caos.

_{Risposta wiki della community :}

Questo è il comportamento normale e previsto per un cluster.

È responsabilità dell'applicazione gestire la disconnessione con garbo. Qualsiasi transazione in volo andrà persa, poiché solo le transazioni impegnate vengono replicate tra i server.