Quali sono gli scenari per l'utilizzo di mirroring, log shipping, replica e clustering in SQL Server

Question

Per quanto ne so SQL Server fornisce 4 tecniche per una migliore disponibilità.

Penso che questi sono i principali scenari di utilizzo, in sintesi: -

1) La replica sarebbe in primo luogo adatto per gli scenari online-offline di sincronizzazione dei dati (laptop, dispositivi mobili, server remoti).

2) la distribuzione dei log potrebbe essere utilizzato per avere un server di failover con commutazione manuale, mentre

3) mirroring del database è una tecnica di failover automatico

4) clustering di failover è un tipo avanzato di mirroring del database.

Ho ragione?

Grazie.

Answer 1

Il clustering di failover è una tecnologia di disponibilità che fornisce ridondanza a livello di hardware e si basa sulla tecnologia di clustering di Windows, ovvero non è specifica per SQL Server.

Ad esempio, il processore esplode sul server A. Fortunatamente il server A fa parte di un cluster di SQL Server e quindi il server B assume il compito di fornire il servizio SQL Server in pochi secondi. Tutto ciò si verifica automaticamente ed è trasparente per gli utenti del database e/o l'applicazione che viene servita dal cluster.

La differenza principale tra il mirroring del database e il clustering è che SQL Clustering fornisce ridondanza a livello di istanza mentre il mirroring del database fornisce ridondanza a livello di database.

Il seguente collegamento fornisce un confronto tra queste due tecnologie che è possibile trovare di utilizzo.

http://msdn.microsoft.com/en-us/library/ms191309(SQL.90).aspx

distribuzione dei log è considerato più di una tecnologia di ridondanza.

Ad esempio, può essere utilizzato per fornire una copia completa dell'ambiente primario, in genere utilizzato come warm standby che può essere portato manualmente online. Questo può essere utilizzato per fornire ridondanza aggiuntiva alla strategia di backup. La distribuzione del log può anche essere utilizzata per scaricare i report da un server primario creando una copia di sola lettura del database di produzione in un percorso/server alternativo.

La replica è una tecnologia piuttosto diversificata e può essere utilizzata per soddisfare una serie di scenari diversi, la cui scelta determinerà il tipo specifico di replica implementato.

Ad esempio, la replica di tipo merge può essere utilizzata per supportare l'elaborazione distribuita distribuendo il carico di lavoro di un'applicazione su più server, ad esempio architetture di elaborazione distribuite.

La replica di unione richiede spesso un'applicazione relativamente attenta al proprio ambiente. Anche le tecniche come la risoluzione dei conflitti devono essere prese in considerazione al fine di assicurare la coerenza dei dati nell'intero ambiente integrato.

La replica transazionale può essere utilizzata in modo simile alla registrazione delle spedizioni, tuttavia è possibile limitare gli oggetti specifici che vengono replicati nell'abbonato. Questo può essere utile se solo un sottoinsieme di tabelle è richiesto per scopi di reporting.

Spero che questo chiarisca le cose per voi un po '. È possibile trovare un'ampia documentazione relativa a ciascuna di queste tecnologie all'interno dei libri di SQL Server online o cercando ogni tecnologia in Google. Detto questo, se hai qualche domanda specifica sarei felice di aiutarti, quindi sentiti libero di mandarmi una linea.

Cheers, John

Answer 2

In SQL 2008 Enterprise c'è anche qualcosa chiamato Change Data Capture (CDC) che stiamo usando con successo dove lavoro.

Abbiamo un database eccessivamente normalizzato che rende troppo difficile ottenere informazioni. Avevamo bisogno di cambiare la struttura dei dati nello stesso momento in cui replichiamo questi dati su un altro server per i report e così via.

Funziona molto bene per noi.

Answer 3

La spedizione e la replica dei log AFAIK sarebbero probabilmente più adatte al contrario.

La distribuzione dei log è una sincronizzazione pianificata, quindi la replica sarebbe più adatta per la commutazione manuale perché il server di backup sarebbe aggiornato come potrebbe essere a meno che non si presentasse alcun problema di comunicazione (tuttavia, la distribuzione dei log avrebbe lo stesso problema).

dati offline non sono sensibili ai ritardi come server di backup, ma personalmente non vedo affatto la necessità di log-shipping, non riesco a vedere quando sarà mai più adatto alternativa alla replica (ma potrebbe essere che la replica non sia stata implementata prima di sql2005)

Forse sto confondendo la replica con il mirroring, e come nota, il mirroring non ti dà il failover automatico, solo il cluster HA ti dà tale funzionalità, ovvero:

utilizzando atleast SQL server 2005 standard, Windows Enterprise e una memoria dati condivisa (come una SAN).