none
DAG: Initial Seeding schlägt fehl RRS feed

  • Frage

  • Moin,

    bevor ich in meiner Produktion DAG einführe, möchte ich mich damit auf meiner Spielwiese vertraut machen. Leider schlägt schon die Erstsynchronisation fehl: Auf dem Zielserver erscheint MSExchangeRepl Error 2059:

    The required log file 3067 for MBX1-DB1\EX-MBX2 is missing on the active copy. If you removed the log file, please replace it. If the log file is lost, the database copy will need to be reseeded using Update-MailboxDatabaseCopy.

    Tatsächlich wird zwar die .edb übertragen, aber nicht ein einziges Logfile. Die Ordnerstruktur auf dem Zielserver wird dagegen angelegt (die Ordner IgnoredLogs, incseedInspect und inspector existieren). Unnötig zu sagen, dass ein Update-MailboxDatabaseCopy auch danebengeht.

    Wo kann der Fehler liegen?

    Danke, Georg.

    Dienstag, 3. April 2012 13:16

Antworten

  • Moin,

    Wo kann der Fehler liegen?

    na ja, sagt die Fehlermeldung ja aus -> eine Log-Datei fehlt.

    Damit bekommst Du kein Seeding zum Laufen.

    Zwei Möglichkeiten der Korrekt:
     - hebe die Bereitstellung der Daten im aktiven Knoten auf und stelle sie danach wieder bereit (dabei werden die Log-Dateien eingearbeitet)
     - hebe die Bereitstellung der Daten im aktiven Knoten auf, lösche alle Protokoll-Dateien (*.LOG, *.CHK, alle Temp-Dateien) und stelle die Datenbank wieder bereit

    Spätestens nach der zweiten Aktion sollte das Seeding klappen, weil dann neue Log-Dateien beginnend bei 1 angelegt werden. Eventuell muss Du auch die Kopie rausnehmen, alle kopierten Daten löschen und dann die Kopie neuerstellen.

    WICHTIG: Falls Du die zweite Variante nimmst, unmittelbar danach ein Fullbackup anstoßen, weil inkrementellen Backups nicht mehr nutzbar sind!


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Dienstag, 3. April 2012 14:13

Alle Antworten

  • Moin,

    Wo kann der Fehler liegen?

    na ja, sagt die Fehlermeldung ja aus -> eine Log-Datei fehlt.

    Damit bekommst Du kein Seeding zum Laufen.

    Zwei Möglichkeiten der Korrekt:
     - hebe die Bereitstellung der Daten im aktiven Knoten auf und stelle sie danach wieder bereit (dabei werden die Log-Dateien eingearbeitet)
     - hebe die Bereitstellung der Daten im aktiven Knoten auf, lösche alle Protokoll-Dateien (*.LOG, *.CHK, alle Temp-Dateien) und stelle die Datenbank wieder bereit

    Spätestens nach der zweiten Aktion sollte das Seeding klappen, weil dann neue Log-Dateien beginnend bei 1 angelegt werden. Eventuell muss Du auch die Kopie rausnehmen, alle kopierten Daten löschen und dann die Kopie neuerstellen.

    WICHTIG: Falls Du die zweite Variante nimmst, unmittelbar danach ein Fullbackup anstoßen, weil inkrementellen Backups nicht mehr nutzbar sind!


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Dienstag, 3. April 2012 14:13
  • Hallo Robert,

    danke für den Hinweis. Jetzt frage ich mich aber, warum ich das mit allen meinen Datenbanken erlebe. Aber wieso fehlen Logs?

    Ich nehme an, ich muss die Zahl hexadezimal übersetzen und bekomme dann den Filenamen... diese Logdatei wurde aber 90 Minuten vorher mit einem inkrementellen Backup ordnungsgemäß gelöscht. Warum also denkt die Replikation dann, dass Logs fehlen?

    Dankbar für jede Erleuchtung,

    Georg.

    Dienstag, 3. April 2012 15:18
  • Moin,

    Ich nehme an, ich muss die Zahl hexadezimal übersetzen und bekomme dann den Filenamen... diese Logdatei wurde aber 90 Minuten vorher mit einem inkrementellen Backup ordnungsgemäß gelöscht.

    na dann haben wir ja die Ursache.

    Ein Grund, warum MSFT die I/O seit 2007 so stark verringert hat, liegt darin, dass möglichst viele Festplattenaktionen zusammen gefasst werden. Vorher werden diese im RAM durchgeführt und von dort auch gelesen.

    Es kann also sein, dass Log-Dateien vorhanden sind, die nicht in der EDB-Datei drin sind. Wieviele kann man nicht sagen, das hängt vom RAM, der Datenmenge, usw. ab.

    Wenn Du nun ein Backup machst, werden die Log-Dateien abgeschnitten. Normalerweise passiert das aber nur mit denen, die noch nicht in der EDB enthalten sind (darum bleiben auch nach einem Backup immer ein paar Log-Dateien übrig).

    Unter ganz unglücklichen Konstellationen kann es nun sein, dass dier Sicherung fertig ist und Log-Dateien abschneidet, die noch nicht in der EDB-Datei enthalten sind. Das ist für die Datensicherheit zweitrangig, denn man hat ja noch das Backup.

    Aber Seeding geht dann nicht mehr, weil dafür eben Dateien fehlen.

    Darum war meine Empfehlung ja auch, die Bereitstellung einmal kurz aufzuheben. Dabei wird ein Soft-Recovery durchgeführt und alle Log-Dateien werden in die EDB-Datei eingearbeitet. Dann sind die nicht mehr erforderlich.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Dienstag, 3. April 2012 16:18
  • Ansonsten funktioniert es meistens auch die Logdateien auf den Ziel Server zu kopieren und anschließend ein Resume des Seedings durchzuführen.

    Gruß

    Jörg

    Dienstag, 3. April 2012 17:57
  • Hallo Robert,

    danke für die aufschlussreiche Erklärung. Ich würde aber denken, dass diese "unglückliche Konstellation" für die Datensicherheit nicht zweitrangig ist. Wenn ich das richtig sehe, würde die Datenbank bei einem Absturz des Exchange odes des IS in so einem Zustand nicht wieder mounten, so dass ich tatsächlich das Backup zurückspielen muss. In diesem Fall würde ich sagen, dass Microsoft über das Ziel hinweggeschossen ist.

    90 Minuten, in denen das gelöschte Logfile noch nicht in die EDB eingearbeitet worden ist? Das erscheint mir extrem. Ich kann mir nicht vorstellen, dass so viel Last auf der Maschine ist, dass sie das so lange nicht gebacken kriegt. Wir sind in einer Testumgebung, in der zur Simulation der Produktion ein LoadGen mit 200 durchschnittlichen Outlook 2007-Usern läuft. Der Ex2010 ist virtuell mit 1 vCPU und 8 GB RAM.

    Viele Grüße, Georg.

    Dienstag, 3. April 2012 18:53
  • Moin,

    Hallo Robert,

    danke für die aufschlussreiche Erklärung. Ich würde aber denken, dass diese "unglückliche Konstellation" für die Datensicherheit nicht zweitrangig ist. Wenn ich das richtig sehe, würde die Datenbank bei einem Absturz des Exchange odes des IS in so einem Zustand nicht wieder mounten, so dass ich tatsächlich das Backup zurückspielen muss. In diesem Fall würde ich sagen, dass Microsoft über das Ziel hinweggeschossen ist.

    ich muss auch ganz ehrlich sagen, dass ich das Verhalten noch nicht produktiv gesehen habe. Bisher habe ich das nur bei Testumgebungen erlebt, bei denen ZU WENIG Daten waren und diese daher nicht in die EDB aufgenommen wurden.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Mittwoch, 4. April 2012 14:33
  • Hallo Robert,

    naja, viel Last ist in der Testumgebung vermutlich trotz des LoadGen nicht.

    Gibt es eine Möglichkeit, dieses Verhalten etwa per Registry-Eintrag zu ändern?

    Viele Grüße, Georg.

    Mittwoch, 4. April 2012 14:41
  • >Gibt es eine Möglichkeit, dieses Verhalten etwa per Registry-Eintrag zu ändern?

    Nicht das ich wüsste.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Mittwoch, 4. April 2012 14:51
  • Ok, ich frage gelegentlich mal im US-Forum nach...
    Mittwoch, 4. April 2012 14:55
  • Mach das, würde mich interessieren, ob die meine Beobachten zu zu "früh" abgeschnittenen Log-Dateien bestätigen.

    (BTW: Das ist mir übrigens auch erst mit DAG aufgefallen, weil da das Seeding dann nicht mehr klappt.)


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Mittwoch, 4. April 2012 14:57
  • Hallo Robert,

    meine Anfrage im US-Forum war wenig ergiebig...

    http://social.technet.microsoft.com/Forums/de-DE/exchange2010/thread/a0e7b1e1-f149-4776-b318-23136b179965

    Ich bin jetzt dabei, DAG in der Produktion einzuführen, und habe, um das Wegräumen der Logdateien zu vermeiden, einstweilen auf differentielles Backup geschaltet. Dennoch bekomme ich den gleichen Fehler: Es fehlen Logs, die vor mehr als 4 Stunden angelegt worden sind... einfaches dismount und mount hilft nicht mehr... die zweite Methode habe ich noch nicht probiert. Was stimmt bei mir nicht?

    Wenn fehlende Logdateien ein so gängiges Problem beim Einrichten der DAG wären, müsste Tante Gockel doch viel mehr bei der Suche nach ""exchange 2010" msexchangerepl 2059" auswerfen...

    Georg.

    Donnerstag, 12. April 2012 12:26
  • Moin,

    Ich bin jetzt dabei, DAG in der Produktion einzuführen, und habe, um das Wegräumen der Logdateien zu vermeiden, einstweilen auf differentielles Backup geschaltet. Dennoch bekomme ich den gleichen Fehler: Es fehlen Logs, die vor mehr als 4 Stunden angelegt worden sind... einfaches dismount und mount hilft nicht mehr... die zweite Methode habe ich noch nicht probiert. Was stimmt bei mir nicht?

    das wüsste ich auch gerne. Eventuell ein Virenscanner, der Zugriffe blockiert.

    Wenn fehlende Logdateien ein so gängiges Problem beim Einrichten der DAG wären, müsste Tante Gockel doch viel mehr bei der Suche nach ""exchange 2010" msexchangerepl 2059" auswerfen...

    Sind sie definitiv nicht. Im Gegenteil, läuft das DAG-Thema sehr gut und stabil.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Donnerstag, 12. April 2012 13:00
  • Nein, einen Virenscanner oder andere Third-Party-Produkte (außer dem Backup - TSM) gibt es auf dem Exchange nicht (der Virenscanner läuft auf dem Gateway).


    Donnerstag, 12. April 2012 13:09
  • Das liegt am TSM, wir haben das Problem nämlich auch. Gibt imho da keine Lösung, ausser eben das von mir beschriebene manuelle Kopieren und dem anschließenden Resume.

    Gruß

    Jörg

    Donnerstag, 12. April 2012 14:32
  • Ja, ein querlaufendes Backup-Programm kann daran schuld sein.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Donnerstag, 12. April 2012 15:02
  • Und warum? Weil es Logdateien löscht, die nicht hätten gelöscht werden dürfen? Dann funktioniert es aber auch als Backup-Programm nicht anständig, oder?

    Georg.

    Donnerstag, 12. April 2012 15:06
  • Warum kann man aus der Ferne schlecht sagen, dafür sind die Programm zu unterschiedlich.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Donnerstag, 12. April 2012 16:27