Ist "AlwaysOn" nicht immer "Always On"?


8

Wir haben einen Windows-Failovercluster erstellt und dann zwei Instanzen von SQL Server als Knoten eines SQL Server-Failoverclusters hinzugefügt.

Wir haben die Server so eingestellt, dass sie "AlwaysOn Availability Groups" in SQL Configuration Manager verwenden.

Um ein Failover zu testen, habe ich eine lange Abfrage geladen und ausgeführt und dann den aktiven Knoten mithilfe des Failover-Cluster-Managers heruntergefahren, um den Clusterdienst auf dem aktiven Knoten zu stoppen.

Die Abfrage wurde ohne Verbindung unterbrochen, und der Server wurde etwa 20 Sekunden lang als nicht verfügbar angezeigt, bevor der Knoten entleert und der neue Knoten übernommen wurde.

Habe ich das falsch gemacht Wie hätte ich das so konfigurieren sollen, dass es kaum oder gar keinen Konnektivitätsverlust gab?

Ist AlwaysOn nicht immer eingeschaltet?

Antworten:


19

Sie haben hier eine Reihe verschiedener Fragen.

F: Was ist das "Always On" -Ding?

Microsoft verwendet diesen Markennamen (der vor 2016 ohne Leerzeichen geschrieben wurde), um zwei verschiedene Funktionen zu beschreiben:

  • Failover Clustered Instances (FCIs) - wie Ihr Opa einen aktiven / passiven Cluster nannte
  • Verfügbarkeitsgruppen (AGs) - wie die Datenbankspiegelung, funktionieren jedoch in einigen Fällen mit Gruppen von Datenbanken (jedoch nicht mit den Systemdatenbanken).

Verwenden Sie diese Begriffe, um zu beschreiben, welche spezifische Always On-Funktion Sie verwenden.

F: Wird es bei einem Failover immer eingeschaltet sein?

Weder FCIs noch AGs sind wirklich immer aktiv. Während eines Failovers schlagen Ihre laufenden Transaktionen fehl und Verbindungswiederholungen können 5-60 Sekunden (oder länger) fehlschlagen. Es liegt an Ihnen, eine anmutige Wiederholungslogik in Ihre Anwendungen einzubauen oder Tools mit eingeschränkten Fähigkeiten einzubauen, wie dies bei Stack Overflow der Fall ist .

F: Wie konfiguriere ich Always On?

Es variiert dramatisch basierend auf:

  • Welche AO-Funktion verwenden Sie (FCIs oder AGs)?
  • Die Anzahl der Knoten im Cluster
  • Wie Sie mit dem Quorum umgehen möchten (Abstimmung)
  • Unabhängig davon, ob Sie das automatische Failover über einen Listener oder einen virtuellen Computernamen verwenden

Dies sind große Entscheidungen, die viel Architekturarbeit erfordern. Wenn Sie detailliertere Informationen benötigen, geben Sie die obigen Details an. Wir können Ihnen dann weitere Informationen zur Konfiguration geben.

F: Geht es nicht nur darum, das Kontrollkästchen für Always On zu aktivieren?

Nee.


3

Möglicherweise verwechseln Sie "Always ON" -AGs (Verfügbarkeitsgruppen) mit FCIs (Failoverclusterinstanzen), die beide von WSFC (Windows Server-Failovercluster) abhängen.

Wenn Sie auf "Immer an" klicken, wird nicht sichergestellt, dass Sie jetzt über eine AG-Konfiguration verfügen. Sie müssen asynchrone, synchronisierte, schreibgeschützte / Failover-Replikate festlegen, Prioritäten festlegen und andere Überlegungen anstellen, z. B. ob die App diese Konfiguration unterstützt. Beispielsweise verwendet Ihre App möglicherweise datenbankübergreifende MSDTC-Transaktionen, die nicht unterstützt werden und zu nicht behebbaren Beschädigungen führen können, für die eine Sicherungswiederherstellung erforderlich ist.

Derzeit tritt ein FCI-Failover auf. Das ist normal. Dadurch werden die Dienste auf einem Knoten gestoppt und die Dienste auf dem anderen Knoten gestartet. Dies funktioniert auf der Ebene INSTANCE. Pro Datenbank wird eine AG-Lösung eingerichtet, und die Dienste werden auf beiden Knoten ausgeführt. SQL verwendet die WSFC-APIs, um die Daten auf den Replikaten synchron zu halten, und die Datenbank wird auf dieses Replikat umgeschaltet. Beachten Sie nicht die Instanz.

Möglicherweise möchten Sie diesbezüglich viele Tests durchführen, bevor Sie es für die Produktion bereitstellen.


1

Meine bevorzugte Methode zum Testen eines Failovers in einer AG besteht darin, einfach die aktuelle Primärdatenbank zu trennen. Schalten Sie es einfach aus, schalten Sie es von der Konsole aus aus, ziehen Sie das Netzwerk herunter, beenden Sie den SQL-Dienst mit einer Silberkugel, was auch immer. Sie sollten es nicht über eine grafische Benutzeroberfläche testen, da Chaos nicht so funktioniert.


Am besten kurz vor Ende des Geschäftsjahres - Sie werden in der Regel viele Leute dazu bringen, die Secondaries auf diese Weise zu testen. Im Ernst, Sie haben Recht, obwohl dies zumindest zunächst erfolgen sollte, bevor das System in Produktion geht. In den bestmöglichen Szenarien würden Sie bei jedem Upgrade der Systeme von "Primär" zu "Sekundär" wechseln, sodass beide Systeme regelmäßig verwendet werden (Sie müssen jedoch sicherstellen, dass Ihre Hardware, Bandbreite usw. vorhanden sind vergleichbar).
RDFozz

0

Antwort des Community-Wikis :

Dies ist normales und erwartetes Verhalten für einen Cluster.

Es liegt in der Verantwortung der Anwendung, die Trennung ordnungsgemäß zu handhaben. Alle Transaktionen während des Flugs gehen verloren, da nur festgeschriebene Transaktionen zwischen Servern repliziert werden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.