I gruppi di disponibilità possono sostituire la replica transazionale?

Ho esaminato le nuove funzionalità di SQL Server 2012 e come può aiutare la mia situazione attuale.

Attualmente siamo su SQL Server 2008 R2 e repliciamo due database di server OLTP su un singolo server di report tramite replica transazionale. Quindi utilizziamo questi DB replicati per i report.

Sono interessato a sapere se SQL Server 2012 e i gruppi di disponibilità possono sostituirlo - quindi, invece della replica transazionale, utilizzerei i nuovi gruppi di disponibilità e rispecchii i database dei due server OLTP sul server di report - dove il reporting sarà in grado per accedere alle repliche di sola lettura.

Non sono sicuro che funzionerà bene, o addirittura affatto.

Vorrei allontanarmi dalla replica, in quanto causa problemi con la mia strategia di distribuzione (utilizzando VSDBCMD.exe). Vorrei anche evitare i ritardi di reinizializzazione della replica su DB di grandi dimensioni.

Qualcuno ha qualche buon esempio o esperienza con questo? È possibile eseguire il mirroring con repliche leggibili da più server su un singolo server secondo il normale mirroring nelle versioni precedenti?

Questo è stato inizialmente richiesto qui: /programming/10415225/mirroring-and-availability-groups-in-sql2012 Mi dispiace non credo di poter ancora migrare le domande.

— Meff
fonte

Risposte:

Passato dalla mia risposta su StackOverflow , solo per impedire ad altri di spendere sforzi per lo stesso tipo di risposta.

Personalmente penso che funzionerà molto meglio della replica transazionale, anche se non ho fatto alcun confronto formale tra i due in un vero scenario di migrazione. So che con la quantità di problemi che le persone hanno con la replica transazionale, rispetto anche al mirroring standard (e questo è un aggiornamento di quello), sei sicuramente tenuto ad avere meno problemi.

Il vantaggio più grande è che il secondario può essere contrassegnato come di sola lettura, quindi puoi eseguire tutti i rapporti che desideri e non influiranno affatto sul mirroring. Hai solo bisogno di beefier tempdb (dal momento che utilizza essenzialmente rcsi per farlo).

Naturalmente è necessario essere consapevoli del fatto che entrambe le parti dell'AG devono disporre di una licenza completa per poter utilizzare la replica per operazioni di sola lettura. E entrambe le parti devono essere in esecuzione su versioni specifiche di Windows (Enterprise o versione successiva su 2008 R2 e versioni precedenti; Standard o versione successiva su 2012 e versioni successive) perché richiedono il clustering di failover - le istanze SQL negli AG non devono essere raggruppate, ma devono trovarsi in cima a tale infrastruttura nel sistema operativo.

— Aaron Bertrand
fonte

Grazie Aaron, lo lascerò aperto per altre risposte, poiché spero di ottenere più opinioni qui di Stack Overflow :)

— Meff

Non preoccuparti, sospettavo che fosse per questo che l'hai ripetuto qui, e non stavi cercando di reprimerlo. Sto solo cercando di aiutare a ridurre lo sforzo.

— Aaron Bertrand

Ho pensato di sottolineare che Windows Server 2012 non richiede l'edizione Enterprise per il clustering di failover. Questo è ora disponibile in Standard.

— SomeGuy

@SomeGuy è vero, ma non lo è perché hanno tolto l'Enterprise Edition e si sono laureati Standard? Le quattro edizioni di Windows Server 2012 sono DataCenter, Standard (usato per essere Enterprise), Essentials (usato per essere SBS) e Foundations (sembra simile al Web?).

— Aaron Bertrand

Vantaggi della replica transazionale rispetto ai gruppi di disponibilità per i carichi di lavoro di reporting

Come contrappunto alla risposta precedente, ecco alcuni motivi per cui la replica transazionale può essere una soluzione migliore rispetto ai gruppi di disponibilità per la segnalazione dei carichi di lavoro.

È possibile replicare un sottoinsieme di tabelle nel database. Le repliche del gruppo di disponibilità sono sempre l'intero database. Se alcune tabelle contengono informazioni riservate, l'accesso al controllo è più semplice se tutto il reporting viene eseguito su un database che non include tali informazioni.
È possibile filtrare le righe che vengono replicate fornendo un livello elevato di granularità. Ad esempio, è possibile replicare le informazioni specifiche del reparto su una moltitudine di server di report dipartimentali, ognuno dei quali ha accesso solo alle proprie informazioni.
Puoi avere una strategia di indicizzazione completamente diversa tra l'editore e l'abbonato. Con i gruppi di disponibilità gli indici sono gli stessi e anche se le statistiche verranno create sulla replica e memorizzate in tempdb, ma non è possibile ottimizzare la replica fornita.
Problemi di sicurezza. In generale, gli utenti di report si collegano direttamente al database utilizzando SSMS, access o excel e si desidera limitare il loro accesso solo al database di report.

Se nessuno di questi è un grosso problema, i gruppi di disponibilità potrebbero essere la scelta migliore.

— StrayCatDBA
fonte