5

Ho un'applicazione che mi piacerebbe avere il supporto di SQL Server Mirroring. Tuttavia, l'architettura è attualmente tale che più servizi WCF e connessioni DB saranno inclusi in una singola transazione MSDTC e Microsoft afferma che MSDTC non è supportato quando si utilizza il mirroring.Perché MSDTC non è supportato quando si utilizza il mirroring di SQL Server e il failover automatico?

Their explanation non è molto istruttiva:

Uno scenario simile può verificarsi quando si utilizza il mirroring del database con le transazioni di MS DTC. Ad esempio, il nuovo server principale contatta MS DTC dopo un failover. Tuttavia, MS DTC non è a conoscenza del nuovo server principale. Di conseguenza, MS DTC interrompe tutte le transazioni che si trovano nella fase di "preparazione al commit", anche se le transazioni sono considerate impegnate in altri database.

Quello che sto avendo un problema di comprensione è l'ultima frase. Qual è la differenza rispetto al caso in cui il server DB non fosse stato specchiato e fosse morto nello stesso momento? Qualcuno può spiegarmi questo? Devo essere in grado di spiegarlo agli altri nella mia organizzazione (oltre che ai clienti), ma non capisco perché MSDTC possa correttamente eseguire il rollback/compensare in uno scenario, ma non può farlo se uno dei partecipanti è un server SQL con mirroring (in modalità piena sicurezza).

risposta

7

MSDTC non è a conoscenza del mirroring. Pertanto, quando registra un gestore risorse in una transazione distribuita, saprà che RM con il suo nome, ad esempio Server A. Dopo che si verifica un errore, il registro comunicherà al nuovo principal "Vai contatto DTC" e vedrà quale è lo stato della transazione T '. Il nuovo principal, denominato Server B, passa a DTC e dice "I am server B, qual è il risultato della transazione T?" e il DTC gli dirà 'Vai via, non ti conosco, non sei iscritto nella transazione T'. Questo è ciò che l'articolo KB descrive anche:

Dopo un failover, il nuovo server principale non può connettersi al MS DTC del precedente server principale che utilizza lo stesso ID di risorsa. Pertanto, il nuovo server principale non può ottenere lo stato della transazione

Stai chiedendo "Come è affatto differente che se il server DB non è stato rispecchiato, e appena morto in quello stesso punto nel tempo?". La differenza è che se ciò si verificava, quando il database è ripristinato, verrà ripristinato su lo stesso server e questo server può contattare il DTC e chiedere di eseguire il rollback della transazione distribuita in cui è stato registrato.

+0

MSDTC avrebbe riavviato le altre risorse? O quella transazione distribuita attende fino a quando il server originale non ritorna? Che cosa fa il mirror partner quando MSDTC lo ignora (rollback? Commit? Genera un errore?) –

+2

In commit a due fasi c'è uno stato in cui DTC non può intervenire: dopo aver notificato alcuni RM che è OK al commit. In quel momento, il DTC non può cambiare idea sul risultato della transazione, e questo è il momento problematico in cui si verificherà un errore. Se il failover si verifica prima di questo momento, allora è semplice: basta chiedere a tutti gli altri RM di effettuare il rollback, nessun grosso problema. –

+0

Quindi diciamo che ci sono 3 RM coinvolti. Arriviamo alla fase che hai menzionato e a RM1 viene detto di impegnarsi. RM2 è il nostro SQL Server e, poiché ha fallito, non può essere raggiunto. Cosa succede a RM3? Viene detto di impegnarsi? Quanto dura questa transazione distribuita se il server originale non ritorna mai per dirlo al rollback? La transazione è stata eseguita dal mirror partner o no? Se c'è un posto dove posso andare a saperne di più in dettaglio, per favore indirizzami. Non sono stato in grado di trovare molto su questo argomento da solo. Grazie anche per il tuo aiuto! –

Problemi correlati