High availability groups im SQL 2012

[Stefan3110 11]

Hallo,

ich nutze die High availability groups im SQL 2012. Die erste Zeit funktioniert auch alles sehr gut. Nur heute Nacht sind mir die Transaction Logs übergelaufen.

Ich musste jetzt eine Datenbank aus der High availability group herausnehmen und konnte mit dem Recovery Model zu „Simple“ wechseln. Dies brachte mir 40GB Platz und der Server kann erst mal wieder arbeiten.

Was kann ich tun um so etwas zu verhindern? Ich möchte die DB wieder in die High availability group aufnehmen, aber dafür muss ich das Recovery Model auf „Full“ stellen.

 

Danke für Eure Hilfe

Stefan

[Dukel 454]

Machst du ein regelmäßiges Full und / oder Transaktionslog Backup?

Wenn nein, mache dieses, dabei werden die Transaktionslogs abgeschnitten (und gelöscht).

[DocData 85]

Wenn du das Recovermodel "Full" verwendest, dann musst du regelmäßig Transaktionsprotokoll-Sicherungen durchführen, also genau was Dukel schon gesagt hat.

 

Informationen dazu findest in der TechNet. *klick*

[Stefan3110 11]

Danke für Eure Hilfe.

 

Nutzt Ihr die High availability groups im SQL 2012? Eigentlich wollte ich auf dem 2. SQL Server das Backup laufen lassen. Damit der 1. in arbeiten kann.

[DocData 85]

Was für ein Horror-Workload hast du auf dem SQL, dass du über so ein Konstrukt nachdenkst?

[Dukel 454]

Es ist nicht ganz verkehrt Backups auf einem Sekundären Knoten machen zu wollen, wenn es das Feature jetzt gibt.

 

Nochmal: Wann / Wie oft machst du welche Backup's? Wie ist der tägliche Datenzuwachs?

[Stefan3110 11]

Wir sind im Aufbau einer Demo und Entwicklungsumgebung.

Darum auch die Iddee die Backups auf den Sekundären Knoten zu ziehen.

 

Bis jetzt haben wir noch kein richtiges Backup. Ab und an manuell, da wir noch am Einrichten sind. Sobald die Kisten produktiv gehen muss auch ein Backup laufen. Jetzt mache ich händisch eins aller ca. 2 Tage und eine Sicherung der virtuellen Maschienen.

[DocData 85]

Es ist nicht ganz verkehrt Backups auf einem Sekundären Knoten machen zu wollen, wenn es das Feature jetzt gibt.

 

Falscher Ansatz. Nicht die Features definieren wie etwas gemacht wird, sondern die formulierten Anforderungen. Wenn man sich das Featureset anschaut und dann überlegt was man wie macht, dann kommt sowas raus - irgendwie Murks.

[Dukel 454]

Hier kommt Murks heraus, da gar keine Backups gemacht wurden.

 

Ich wollte auch nicht sagen, dass die Features definieren was gemacht wird sondern dass bei vielen (wohl auch beim TO) der Wunsch da ist Backups auf einem Sekundären Knoten laufen zu lassen. Mit den AG's ist das jetzt endlich möglich und man kann dies nutzen ohne von einem extremen Workload auszugehen.

[DocData 85]

Klar kann man das machen aber zu welchem Preis?! Fasse doch mal den Kostenaspekt ins Auge oder das grundsätzliche Designparadigma KISS. Aber das ist nun wirklich OT.

[Dukel 454]

Was hat das mit dem Kostenaspekt zu tun?

[DocData 85]

Das ist OT. Wir können das gerne per PN weiterführen.

[Stefan3110 11]

Danke für Eure Hilfe.

Wie würdet Ihr in meinem Fall vorgehen? Backup soll über den Sekundären Knoten laufen. Aber auf dem Primären Knoten sollen die Logs nicht überlaufen. 

 

Grüße

Stefan

[Dukel 454]

Werden die Logs nicht auf allen Knoten abgeschnitten, wenn du ein Log Backup auf dem Sekundären Knoten machst?

[Stefan3110 11]

Das würde ich gern von jemanden wissen, der auch AG am laufen hat.