none
AVG und Transaktionen RRS feed

  • Frage

  • Hallo,

    hier der Übersicht halber in einem eigenen Thread meine zweite Frage:

    Kann mir jemand kurz gegenüberstellen wie sich Transaktionen unter AVG verhalten -  je nach Modus Synchron oder asynchron?

    Bitte um Korrektur, falls ich mich irgendwo irre...

    Synchron:

    Ein Commit kommt erst zu Stande, wenn auf Sekundären und! Primären comittet wurde.

    Es entsteht kein Verlust von TX bis dahin.

    Bei  Ausfall des Primären wird bei Wiederinbetriebnahme eine Synchronisierung der nach Ausfall aufgelaufenen TX stattfinden, da der sekundäre zw zum Primären wurde..

    Benutzer werden lediglich TX wiederholen müssen, da während des Failover die Connection wegbricht.


    Was passiert aber bei Ausfall des Sekundären...? Gehen trotzdem Commits?


    Asynchron:

    Beim Primären wird committet. Der Sekundäre kann "hinterherhinken".

    Bei Ausfall des Primären droht Verlust von Transaktionen. 

    Bei Wiederinbetriebnahme des ExPrimären werden die aufgelaufenen TX gesyncht.

    Bei Ausfall des Sekundäre pasiert nichts weiter. Bei Wiederinbetriebnaheme des Sekundären werden wird gesynct. 

    Ob Synchron oder Asynchron:

    Bei Ausfall des Sekundäre und einer späteren Wiederinbetriebnahme kann durchaus eine Zeit der Zustand async sein.

    So weit korrekt?

    Danke schon mal für eure Meinung

    Sonntag, 6. März 2016 17:08

Antworten

  • Hallo und guten morgen,

    zur ersten Frage. Wenn der passive Knoten ausgefallen ist dann werden die Transaktionen vom primären Konten verarbeitet und der Commit an die Nutzer/Applikation zurückgemeldet. Genau so als gäbe es die Verfügbarkeitsgruppe nicht. 

    ABER: So lange wie der sekundäre Knoten nicht erreichbar ist, kann das Transaktionslog zwar gesichert werden aber es wird nicht geleert. Somit wächst das LOG immer weiter. Sollte der sekundäre Knoten längere Zeit nicht laufen muss man sich überlegen den defekten Knoten als Replikat zu entfernen bzw. durch einen anderen Server ersetzten.

    Zur zweiten Frage:

    Ja je nach dem wie viele Transaktionen zum sekundären Konten übertragen werden müssen und wie umfangreich der Rollforward dieser Transaktionen ist kann es schon etwas dauern bis alles wieder gerade gezogen ist.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform
    MCSA: Windows Server 2012
    Blog

    Montag, 7. März 2016 06:55
  • Hallo Fumus

    so aus der Entfernung ist es schwer eine verlässliche Empfehlung zu geben. Wenn die Datenbank auf dem zweiten Knoten im Status Primär ist und auch normal läuft, würde ich das defekte Replikat aus der Verfügbarkeitsgruppe entfernen und neu in die Gruppe aufnehmen. Natürlich kann eine Sicherung nie schaden.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform
    MCSA: Windows Server 2012
    Blog

    • Als Antwort markiert Fumus Montag, 14. März 2016 08:31
    Montag, 14. März 2016 08:28

Alle Antworten

  • Hallo und guten morgen,

    zur ersten Frage. Wenn der passive Knoten ausgefallen ist dann werden die Transaktionen vom primären Konten verarbeitet und der Commit an die Nutzer/Applikation zurückgemeldet. Genau so als gäbe es die Verfügbarkeitsgruppe nicht. 

    ABER: So lange wie der sekundäre Knoten nicht erreichbar ist, kann das Transaktionslog zwar gesichert werden aber es wird nicht geleert. Somit wächst das LOG immer weiter. Sollte der sekundäre Knoten längere Zeit nicht laufen muss man sich überlegen den defekten Knoten als Replikat zu entfernen bzw. durch einen anderen Server ersetzten.

    Zur zweiten Frage:

    Ja je nach dem wie viele Transaktionen zum sekundären Konten übertragen werden müssen und wie umfangreich der Rollforward dieser Transaktionen ist kann es schon etwas dauern bis alles wieder gerade gezogen ist.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform
    MCSA: Windows Server 2012
    Blog

    Montag, 7. März 2016 06:55
  • Hallo Fumus,

    wenn deine Frage damit beantwortet ist würde ich dich bitten meinen Post als Antwort zu markieren.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform
    MCSA: Windows Server 2012
    Blog

    Freitag, 11. März 2016 11:21
  • Hallo 

    sorry hat ein wenig gedauert. Soweit mal danke für die Antwort bisher. Nun meine letzte Frage dazu:

    Nun hatte ich den Fall, dass auf dem Primären die HDD ausfiel. Der Failover ließ sich zu dem Zeitpunkt nur mit "Datenverlustswarnung" durchziehen.

    Nach dem erzwungenen Failover und Wiederherstellen der HDD (diese ist lediglich offline gegangen und wurde anschliessend wieder online geschaltet) konnte ich die Verfügbarkeitsgruppen nicht mehr zum synchen bewegen

    Was ich mach also in diesem Fall, wenn der Sync nicht zustande kommt, um möglichts wenig Datenverlust zu haben. 

    Sicherung des Sekundären und die Verfügbarkeitsgruppe neu in Betrieb nehmen?

    Danke schon mal


    Samstag, 12. März 2016 15:58
  • Hallo Fumus

    so aus der Entfernung ist es schwer eine verlässliche Empfehlung zu geben. Wenn die Datenbank auf dem zweiten Knoten im Status Primär ist und auch normal läuft, würde ich das defekte Replikat aus der Verfügbarkeitsgruppe entfernen und neu in die Gruppe aufnehmen. Natürlich kann eine Sicherung nie schaden.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform
    MCSA: Windows Server 2012
    Blog

    • Als Antwort markiert Fumus Montag, 14. März 2016 08:31
    Montag, 14. März 2016 08:28
  • Ok. danke.. 
    Montag, 14. März 2016 08:31
  • Nach einem Forced Failover ist ein automatisches Fortsetzen der Sitzung nicht sinnvoll und daher nicht so vorgesehen. Genau wie ein "forced failover" an sich ja auch immer manuell geschehen muss. Denn SQL Server kann nicht wissen, ob es zu Datenverlust kommt und ob das verschmerzbar ist. Daher ist das als erstes zu prüfen.

    Wenn dort kein Verlust droht, oder man die Daten manuell gesichert hat, kann man ein "resume" der Sitzung versuchen. Nur wenn das nicht geht, muss man sie wirklich neu aufsetzen. Das sollte aber eigentlich nicht erforderlich sein.

    Es kommt hier wirklich auf die kleinen Details an, die die üblichen Marketing-Folien oder MOC-Seminare leider nicht vermitteln, und daher bei Kunden oft zu unvorhergesehenen Ausfällen sorgen. Sie stecken aber in der Online-Hilfe und diversen Artikeln. Ich empfehle (mindestens) folgende Artikel in Vorbereitung auf den produktiven Einsatz genau durchzuarbeiten:

    Failover and Failover Modes

    Ausführen eines erzwungenen manuellen Failovers einer Verfügbarkeitsgruppe



    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Montag, 14. März 2016 09:16