SQL Server – Spiegelung, doppelte IOPs auf dem Prinzipal und korrupte Datenbanken auf dem Mirror Se

[Kristof 0]

Hallo Zusammen,

wir planen unsere Datenbanken die auf einem MS SQL Server 2005 laufen gegen Ausfall abzusichern und haben uns aus Kostengründen für Spiegelung im Asynchronem Modus entschieden.

 

Wir haben bereits viel über Einrichtung der Spiegelung gelesen. Da aber keine praktischen Erfahrungen vorhanden sind haben wir einen IT-Spezialisten von einem großen Hardware Hersteller und noch einen von einer Partnerfirma zu Rate gezogen.

Beide behaupten:

• Die Spiegelung führt zur einer Verdopplung der IOPs auf dem Prinzipal Server.
• Mit korrupten Datenbanken auf dem Mirror Server zu rechnen ist.

Kann das stimmen? Wir haben bis jetzt nirgendwo Hinweise auf diese Behauptungen gefunden, vor allem, dass die Spiegelung im asynchronen Modus zwangsläufig zur korrupten Datenbanken führt.

 

Das Lese/Schreibverhältnis unseres SQl Server liegt bei 75%/25%.

 

Habt Ihr ähnliche Erfahrungen gemacht?

 

 

Danke schon mal.

 

Kristof

bearbeitet 4. Dezember 2013 von Kristof

[Dukel 454]

Wenn ihr einen Standard Server habt und kein Enterprise Server ist der Asynchrone Modus kein Kostenargument, da ihr dann auf die EE Version upgraden müsst.

 

Asynchron heißt, dass die Spiegel unter Umständen einen älteren Stand hat und Transaktionen verloren gehen können.

Dieser Modus ist nicht für Ausfall sondern für Disaster Recovery geeignet.

 

Wenn ihr Mirror nutzen wollt (ich denke die Kostengründe sind zwischen Mirror und Failovercluster Entscheidung) solltest Ihr den Synchronen Spiegel nutzen. Außerdem wollt ihr sicher keinen manuellen Failover nutzen und braucht dann noch einen 3. Server (Witness). Da reicht aber die Express Version.

[LiveeviL-Odw 2]

Hallo Zusammen,

Also das Stimmt der Asyncronmodus ist ein Enterprisefeature kostet Geld. Der AS Modus auch Performacemode gennant  wird zum lasten ausgleich gebrauch und nicht für eine DR Lösung eine DR lösung wäre z.B.  Logshipping ....

Wir nutzen den AS Modus zum lasten ausgleich d.h. wir haben eine Datenenbank mit über 5000 Commits pro Sekunde möchten aber alle Stunde einen Report erstellen der Report wird  über den Spiegel erstellt damit wir die Primärdatenbank nicht belasten. Asyncron heist nur das die Primäredatenbank nicht auf das Commit der 2ten Datenbank (Spiegel) wartet.

 

Beim Syncronen Modus wird im Prinzip ein Commit auf der Primären ausgeführt und die Database Engin des Primären wartet bis der Commit auf der Sekundären bestätigt wird. Erhöhte IO!

Beim Performancemode (Asyncronmodus) wird nicht auf den Commit vom Spiegel gewartet das heisst bei einem verlust des Primären kann ein Datenverlust auf der Sekundärenseite erfolgen. 

 

Performancemode = Asyncron = zur performace Optimierung bei vielen zugriffen Spiegel ist lesbar verfügbar = Enterprise ---- KEIN Automatic Failover möglich

High safetymode = Syncron = zur Ausfallsicherung Spiegel ist nicht lesbar  = erhöhte IO=  Standard  ----- Automatic Failover möglich

 

LG

Alex

bearbeitet 4. Dezember 2013 von LiveeviL-Odw

[Dukel 454]

Man kann sowohl Logshipping als auch Asychronous SQL Mirror für DR und für lesenden Workload (reporting) nutzen. Mirror macht lesenden Zugriff komplizierter als Logshipping da es diverse Einschränkungen hat.

Da der TO aber eine HA Lösung will hilft ihm der Asychrone Modus nicht weiter.

[LiveeviL-Odw 2]

Ich habe nichts anderes behauptet. Ich wollte nur die unterschiedlichen mirroring Lösungen beleuchten . Als Kosten günstigste Lösung , weil mit Standard Lizenz abdeckbar. Würde ich highsafty mode Spiegel als ha und logshipig als Kombination fahren. Hat sich bei uns bewehrt . Jetzt aber zur Frage: es gab unte SQL 2005 einen Bug das die Standby site gecrashed ist wenn nicht alles auf einen bestimmten patch stand war. Ich würde alles fix und Servicepacks installieren.