Risoluzione dei Conflitti di una Replica Peer To Peer in SQL Server

Nell’articolo https://www.iperiusbackup.net/replica-transazionale-peer-to-peer-in-sql-server/ si descrivono in modo approfondito i concetti e la configurazione di una replica peer to peer di database SQL Server. Si tratta di una modalità speciale di sincronizzazione di due o più database SQL Server, effettuata tra diversi server, anche distanti geograficamente. La replica consente una maggiore velocità “geografica” nell’accesso ai dati e costituisce una soluzione fondamentale per la disponibilità dei dati stessi, oltrechè una potente strategia di failover.

La replica Peer-To-Peer è quindi il metodo migliore per avere una elevata disponibilità dei dati su tutti i nodi. Tuttavia, la distribuzione dei dati potrebbe generare conflitti nel caso in cui i nodi vadano ad aggiornare gli stessi record. In uno scenario applicativo che garantisca una efficiente scalabilità, ogni applicazione dovrebbe poter leggere i dati provenienti da tutti i nodi e la modifica dovrebbe essere isolata a livello di singolo nodo. Si parla, in questo caso, di applicazioni correttamente partizionate. In caso contrario possono sorgere i cosiddetti “conflitti”. A partire da SQL Server 2008 è presente uno strumento di rilevazione e gestione dei conflitti.

Questo tutorial si applica a tutte le versioni di SQL Server Enterprise, comprese le più recenti SQL Server 2016, SQL Server 2017 e SQL Server 2019.

Per visualizzare lo strumento basta cliccare sulla “Pubblicazione Locale”, con il pulsante destro, e poi su “Visualizza Conflitti”:

appare la maschera di riepilogo dei conflitti rilevati per il database e la pubblicazione selezionata:

si seleziona la tabella, ad esempio “Computer”. L’utility ci mostrerà la schermata dedicata alla gestione:

nella prima sezione in alto sono elencati tutti i conflitti. Particolare attenzione va dedicata alla colonna “Reason”, che può mostrare i valori:

1. 0(Unknown)
2. 1(Resolved)
3. 2(Unresolved)

e alla colonna “Conflict Type” che può essere del tipo:

1. 1(Update Conflict conflict)
2. 2(Delete/Update conflict)
3. 3(Update/Delete conflict)
4. 4(Delete conflict)
5. 5(Insert conflict)

Un conflitto generato interrompe la sincronizzazione a meno che non sia stata impostata a true la proprietà dalla sottoscrizione “continua la replica anche quando viene rilevato un conflitto”. Con questa modalità si attiva un livello di tolleranza per i conflitti.

Il conflitto di Tipo 1, “Update / Update” si verifica quando due nodi stanno aggiornando lo stesso record;

Il conflitto di Tipo 2, “Delete / Update” si verifica quando un nodo elimina un record mentre l’altro lo sta aggiornando;

Il conflitto di Tipo 3, “Update / Delete” si verifica quando un nodo aggiorna un record e l’altro lo elimina;

Il conflitto di Tipo 4, “Delete” si verifica quando due nodi stanno eliminando lo stesso record (per chiave primaria);

Il conflitto di Tipo 5, “Insert” si verifica quando due nodi stanno inserendo una stessa chiave primaria;

Il gestore dei conflitti risolve automaticamente quasi tutte le casistiche, settandole a 1(Resolved). Più in dettaglio, nella risoluzione dei conflitti, ad avere la precedenza è sempre la transazione proveniente dal peer di origine che ha l’id più alto (originator id), lo stesso id che viene indicato in fase di configurazione della tipologia peer to peer e che serve a distinguere ogni singolo nodo.

Nella maschera del gestore dei conflitti una tabella mostrerà, nella prima colonna, i nomi dei campi, nelle altre colonne il “winner record” e il “loser record”, rispettivamente i dati che hanno avuto la precedenza e quelli ignorati e quindi perduti. In base alla logica applicativa possiamo valutare se il conflitto sarà stato bloccante oppure trascurabile. Tuttavia sarebbe opportuno un controllo accurato sul codice degli applicativi per partizionare al meglio le attività di aggiornamento dei dati evitando che più nodi vadano in conflitto sullo stesso record

Anche i conflitti segnati come 0(Unknown) possono essere ignorati. Generalmente avvengono quando un nodo elimina un record e l’altro non riesce ad aggiornarlo perché non lo rileva più. Tuttavia anche in questo caso risulta necessario apportare le dovute correzioni al codice per evitare la concorrenza sui medesimi dati.

I conflitti sui quali mostrare particolare attenzione sono sicuramente quelli contrassegnati come 2(Unresolved).  Anche in questo caso la tabella mostrerà il “winner record” e il “loser record”. Dovrà essere l’operatore a gestire manualmente il conflitto. Generalmente si interviene allineando i dati sui nodi coinvolti così da sbloccare il singolo record per la replica e rendere la base dati consistente.

Nel caso non fosse possibile gestire manualmente i dati si può intervenire eliminando il nodo dalla replica e ripristinarlo a partire dal backup originario.