Replica peer to peer in SQL Server 2005/08

Question

Qualcuno ha avuto esperienza nella configurazione di replica peer to peer utilizzando SQL Server 2005 o 2008?

In particolare, mi interessa sapere se sono state prese in considerazione altre opzioni / alternative e perché alla fine è stata scelta la replica P2P.

Se hai utilizzato la replica P2P:

Hai riscontrato problemi durante la sincronizzazione ed è stato facile da monitorare?

Quanto è stato / è facile risolvere i conflitti?

Hai dovuto apportare modifiche allo schema (ovvero sostituire le colonne di identità, ecc.)

In alternativa, se hai considerato la replica P2P e hai scelto un'altra opzione, perché l'hai esclusa?

Answer 1

(Dichiarazione di non responsabilità: sono uno sviluppatore, non un DBA)

Abbiamo impostato la replica di tipo merge di SQL Server 2005 per replicare tra due nodi attivi / attivi separati geograficamente per la resilienza in un sistema legacy.

Non so se sia facile da monitorare; al di fuori del mio mandato.

Crea trigger su ogni tabella per eseguire il meccanismo di pubblicazione / sottoscrizione, ognuno dei quali chiama la propria procedura memorizzata.

Nel nostro caso, è stato impostato per utilizzare le identità 1-1bn nel nodo 0, 1bn-2bn nel nodo 1 per evitare collisioni di identità (anziché utilizzare una chiave composita di NodeId + EntityId per ogni tabella o modificare le chiavi in essere GUID, ad esempio).

Penso che la latenza della replica sia di circa 15 secondi (tra Londra e New York sulla larghezza di banda dedicata).

È un dolore enorme lavorare con :

• Ci è voluto un appaltatore altamente pagato un anno per installarlo (garantito, parte di questo era dovuto alla natura legacy del design del DB)
• Ci manca qualcuno interno con le competenze per supportarlo (il DBA interno che avevamo impiegato ~ 6 mesi per impararlo, e da allora è passato)
• Gli aggiornamenti dello schema ora sono dolorosi . Da quello che ho capito:
  • Alcuni aggiornamenti devono essere eseguiti su un solo nodo; la replica si occupa quindi di capire cosa fare sugli altri nodi
  • Alcuni aggiornamenti devono essere eseguiti su entrambi i nodi
  • Gli aggiornamenti dei dati devono essere eseguiti su un solo nodo (credo)
  • Ora tutti gli aggiornamenti richiedono molto più tempo per essere eseguiti: dalla frazione di secondo impiega l'esecuzione di uno script di modifica DDL a ~ 30 minuti
• Non lo so per certo, ma penso che il requisito di larghezza di banda per la replica sia molto alto (nell'intervallo MBit / s)
• Presenta molti " rumore " oggetti (3 sprocs per tabella, 3 trigger per tabella) nel DB, il che rende scomodo trovare nell'esploratore oggetti l'elemento su cui si desidera lavorare.
• Non mai creeremo un terzo nodo per questo sistema, basato in gran parte sulla difficoltà percepita e sul dolore aggiunto che introdurrebbe al momento dello spiegamento.
• Ora manca anche un ambiente di gestione temporanea che rispecchi la produzione, perché è troppo doloroso da configurare.
• Aneddotico: il DBA che esegue l'installazione maledirebbe spesso il fatto che si trattava di un "MS v1" era costretto a lavorare con.
• Poco ricordato: il DBA doveva raccogliere diversi ticket di supporto prioritari per ottenere aiuto direttamente dagli Stati Uniti.

Concesso: parte del dolore coinvolto è dovuto al nostro ambiente specifico e alla mancanza di talenti interni per supportare questa configurazione. Il chilometraggio può variare.