none
AOAG Logbackups brechen ab RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    kurz zum eingesetzten Setup:

    AOAG SQL Server 2016
    synchroner Modus
    2 Nodes
    Backup Preferences: any replica

    ======================================

    Wir haben in der letzte Woche den Wert von Primary auf any Replica in den Backup Preferences geändert, damit wir auch von der inaktiven Node die Backups erstellen können.

    Und seit dieser Zeit bricht uns immer der Backupjob der Transactionlog auf der inaktiven Node mit dem folgenden Fehler ab:

    "Command: RESTORE VERIFYONLY ...  The step failed."

    Wir sichern die Transactionlogs alle 5 Minuten, auf beiden Nodes, und beide Scheduler starten um 00:00 Uhr und enden um 23:59 Uhr. Gesichert wird mit den Jobs von Ola Hallengreen.

    Wenn wir nun den Scheduler der inaktiven Node um 30 Sekunden nach "vorne" verlegen, laufen die Backupjobs der Transactionlogs wieder ohne Fehler durch.

    Kann mir jemand sagen, wie oder wodurch die beiden Backupjobs der Transactionlogs der beiden Server zusammenhängen?

    Ist der Schritt "RESTORE VERIFYONLY" der eigentliche Grund hierfür?

    Den Fehler konnten wir, wie oben beschrieben, dauerhaft beseitigen, indem der Scheduler geändert wurde. Aber ich möchte diesen Fehler gerne verstehen.

    Ich danke euch,

    Grüße

    Andreas

    Montag, 29. Oktober 2018 13:04
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Andreas,

    Der Backup Prozess prüft selbst auf welchem Server das Backup ausgeführt werden muss. Außer bei "Any" in jeder anderen Option wird das Backup gestartet und einer der Server führt den Backup Prozess durch. Alle anderen Server erkennen, dass sie nicht zuständig sind und machen nichts. Dies funktioniert auch in den Skripten von Ola voll automatisch. Da muss nichts händisch gemacht werden. Nur das "Any" solltest du dringend ersetzen.

    Du musst/solltest die Backups auf einen Fileserver sichern welcher von allen Servern erreichbar ist. Dort wird dann immer eine komplette Backup Kette liegen. Es spiel keine Rolle welcher Server gerade sichert. Es sei denn du hast "Any" in der Konfiguration. Dann darfst du den Backup Prozess nur auf genau einem Server starten.

    Ich nutze entweder immer die Option "Primär" oder "Sekundäre bevorzugen" dann ist immer sichergestellt durch das AlwaysOn welcher Server für die Backups zuständig sind. Dann darf aber keine lokale Ablage der Backups erfolgen. Die Backups immer zentral ablegen und ggf. von dort nochmals an einen zweiten Standort kopieren um auch die Backups redundant zu haben.

    Deine Fehlermeldung zeigt sehr schön, dass der Backupprozess schon auf einem Server gestartet war als der zweite mit der Sicherung beginnen wollte. Dieses Problem hast du in den anderen Backup Optionen nicht. Dort ist immer klar wer sichern muss. Deshalb hat das Backup auch mit dem Zeitversatz funktioniert da dann das erste Backup bereits abgeschlossen war als das zweite startet.

    Aufträge auf allen Server zur gleichen Zeit starten. Option "Primär" oder "Sekundär bevorzugen" wählen und Sicherung auf Netzlaufwerk / Fileserver ablegen. Bitte nicht die Option "nur Sekundär" wählen, da dort zwingend ein sekundärer Server online sein muss um ein Backup zu starten. Und da man ja den Cluster baut um Ausfälle eines Servers abzufangen hätte man dann genau in dem Moment kein Backup mehr wenn einer der Server wegen Wartung oder Störung nicht verfügbar sind.

    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Dienstag, 30. Oktober 2018 09:41
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Andreas,

    Bei dem Backup wird nur von einem Server ein Backup tatsächlich ausgeführt. Der/die anderen Server starten zwar den Job aber werden sofort wieder aufhören da es keine gleichzeitigen Backups geben kann. Das AlwaysOn handelt intern dann einen Server aus welcher den Backup Prozess übernimmt und die anderen tun nichts. Das ist auch so korrekt wird auch nicht anders funktionieren.

    Wenn deine Server aber dann zu dem Verifyonly kommen, wollen alle Server wieder mitspielen und versuchen alle auf die gleiche Backup Datei zuzugreifen, dies wird aber immer scheitern da ein gleichzeitiger Zugriff nicht möglich ist.

    Wenn du die Prozesse zu verschiedenen Zeiten startest wird jeder Prozess (da alleine) auch für sich der Backup Master sein und kann auf seine Backupdatei natürlich exklusiv zugreifen.

    Lass die Job bitte auf allen Servern zur gleichen Zeit laufen, sonst bekommst du immer pro Server und Plan eine zusätzliche Backupdatei und bis praktisch immer nur am sichern. 

    Die Angabe "Any" bedeute hier nur das irgendein Server diese Aufgabe übernimmt. Dies ist aber nicht immer gut. Und was dir klar sein muss ist, dass diese Einstellung eine massive Auswirkung auf die Lizenzierung hat. Nur wenn alle beide SQL Server voll Lizenziert sind darf man diese Option nutzen da es dies ausdrücklich eine Aktive/Aktive Konfiguration ist welche auch voll Lizenzpflichtig ist. Nur die Option "Primär" als Aktiv/Passive kann mit einer SQL Lizenz behandelt werden.

    https://download.microsoft.com/download/7/8/C/78CDF005-97C1-4129-926B-CE4A6FE92CF5/SQL_Server_2017_Licensing_guide.pdf

    https://sqlserverbhoch.wordpress.com/2016/08/13/db-sicherung-unter-alwayson-verfuegbarkeitsgruppen/

    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012




    Montag, 29. Oktober 2018 14:01
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Benjamin,

    vielen Dank für die ausführliche Antwort. Soweit ist fast alles verständlich, trotzdem habe ich noch Fragezeichen auf der Stirn. Das Positive vorweg, wir haben alles auf VM, daher ist auch alles lizensiert.

    Ich habe einen Screenshot beigefügt, welcher gut zeigt, dass die T-Log Backups der AdventureWorks auf zwei getrennten Speicherorten abgelegt werden. Wir sichern die T-Log Backups jeweils lokal auf den beiden in der AOAG beteiligten Nodes.

    Daher verstehe ich ja noch um so weniger, wieso sich hier was in die Quere kommen kann. Interessanterweise werden die TRN Files ja erstellt, aber die Jobs schlagen auf dem Secondary alle fehl.

    Das von dir oben beschriebene Szenario würde super passen, wenn wir, wie von Ola vorgeschlagen, auf einen gemeinsamen UNC Pfad sichern würden.

    Demnach sollte ja dann auch der noch im Job vorhandene Verify auf das lokale Backup ausgführt werden. Um das aber auszuschließen, haben wir kurz den Parameter "@Verify" rausgenommen. Der Fehler in den Jobs  besteht aber nach wie vor.

    Beste Grüße

    Andreas

    Dienstag, 30. Oktober 2018 07:23
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    die Sicherung der Log auf lokale Platten macht wenig Sinn. Wenn dir wirklich mal ein Server ausfällt und die lokalen Sicherung weg sind dann fehlt dir die Hälfte der nötigen Logs um die Datenbank wiederherstellen zu können. Nur die Logs von beiden Servern zusammen bilden eine vollständige Backup-Kette.

    Was hat die Tatsache, dass es eine VMs ist mit der Lizenzierung zu tun?

    Nur zum Verständnis: Das Backup auf dem Sekundären Knoten schlägt immer fehl? 

    Habe mir das Skript von Ola mal angesehen, das Verify sollte in deiner Konfiguration nicht das Problem sein. Kannst du mal in dem Job Verlauf den genauen Fehler raussuchen.

    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012


    Dienstag, 30. Oktober 2018 08:13
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich habe deine Konfiguration mal nachgebaut und bei mir wird immer nur auf einer Seite eine Backup Datei erzeugt. Ich verstehe daher gerade nicht wie du Backup Dateien auf beiden Seiten haben kannst.

    Nachtrag:

    In der Einstellung "Any" kann man auf allen Servern eine Backup Datei erzeugen. Aber damit machst du dir dann in deiner Konfiguration auch die LSN Kette kaputt und kannst bei Verlust eines Servers kein Backup wiederherstellen

    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012


    Dienstag, 30. Oktober 2018 08:31
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    danke dir schon mal für deine Zeit und die Antworten.

    Nur die T-Log Backupjobs auf dem Secondary schlagen fehl.

    Und wegen der Lizensierung, da wir alles virtuell haben, ist der eigentliche "Wirt" komplett lizensiert, das wollte ich damit sagen.

    Also, ich habe nun eine aussagekräftige Fehlermeldung gefunden:

    Log backup for database "AdventureWorks2016" on a secondary replica failed because the last backup LSN (0x0000002f:0000c747:0001) from the primary database is greater than the current local redo LSN

    Das macht ja, so gesehen, dann auch Sinn.

    Die Frage die sich mir stellt, wie sieht ein Best Practice Ansatz für die Sicherung einer AOAG aus.

    Wir ziehen die lokalen Backups regelmäßig via File-Sicherung von den lokalen Servern, das wäre sonst sträflicher Leichtsinn, da hast du Recht.

    Wir haben aktuell das Problem, dass nach einem Failover der AOAG die Backups "alt" sind, und wir daher sicherstellen möchten, dass wir zu jederzeit, und zu jeder möglichen Konstellation ein funktionales Backup der Datenbanken garantieren können.

    Wenn ich deinen Nachtrag verstanden habe, müssen wir im T-Log Backupjob zuerst prüfen, ob die Node primary ist. Wenn ja, Backups erstellen, wenn nein, Job einfach nicht ausführen.

    Beste Grüße

    Andreas

    Dienstag, 30. Oktober 2018 09:22
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Andreas,

    Der Backup Prozess prüft selbst auf welchem Server das Backup ausgeführt werden muss. Außer bei "Any" in jeder anderen Option wird das Backup gestartet und einer der Server führt den Backup Prozess durch. Alle anderen Server erkennen, dass sie nicht zuständig sind und machen nichts. Dies funktioniert auch in den Skripten von Ola voll automatisch. Da muss nichts händisch gemacht werden. Nur das "Any" solltest du dringend ersetzen.

    Du musst/solltest die Backups auf einen Fileserver sichern welcher von allen Servern erreichbar ist. Dort wird dann immer eine komplette Backup Kette liegen. Es spiel keine Rolle welcher Server gerade sichert. Es sei denn du hast "Any" in der Konfiguration. Dann darfst du den Backup Prozess nur auf genau einem Server starten.

    Ich nutze entweder immer die Option "Primär" oder "Sekundäre bevorzugen" dann ist immer sichergestellt durch das AlwaysOn welcher Server für die Backups zuständig sind. Dann darf aber keine lokale Ablage der Backups erfolgen. Die Backups immer zentral ablegen und ggf. von dort nochmals an einen zweiten Standort kopieren um auch die Backups redundant zu haben.

    Deine Fehlermeldung zeigt sehr schön, dass der Backupprozess schon auf einem Server gestartet war als der zweite mit der Sicherung beginnen wollte. Dieses Problem hast du in den anderen Backup Optionen nicht. Dort ist immer klar wer sichern muss. Deshalb hat das Backup auch mit dem Zeitversatz funktioniert da dann das erste Backup bereits abgeschlossen war als das zweite startet.

    Aufträge auf allen Server zur gleichen Zeit starten. Option "Primär" oder "Sekundär bevorzugen" wählen und Sicherung auf Netzlaufwerk / Fileserver ablegen. Bitte nicht die Option "nur Sekundär" wählen, da dort zwingend ein sekundärer Server online sein muss um ein Backup zu starten. Und da man ja den Cluster baut um Ausfälle eines Servers abzufangen hätte man dann genau in dem Moment kein Backup mehr wenn einer der Server wegen Wartung oder Störung nicht verfügbar sind.

    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Dienstag, 30. Oktober 2018 09:41
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    das klingt doch plausibel. Ich werde das so umsetzen.

    Danke nochmal für die ausführlichen und sehr gut verständlichen Antworten und Erklärungen.

    Beste Grüße

    Andreas

    Dienstag, 30. Oktober 2018 10:31
    |