Viele Backup-Systeme starten ein Backup für die MySQL bzw. MariaDB Datenbank mit folgendem Kommando:

FLUSH TABLES WITH READ LOCK;

Damit soll sichergestellt werden, dass möglichst alle Daten in den Datenfiles stehen, bevor ein Backup gestartet wird.

Aber Achtung!

Das geht in vielen Fällen gut, hat aber einen Haken: Wenn die Datenbank umfangreiche Statements bzw. Langläufer abarbeiten muss, kann es vorkommen, kann es zu folgenden Situationen kommen:

• Das Backup läuft mit dem FLUSH Tables Kommando in einen Timeout und bricht ab.
• Die wartende Backup Session blockiert andere Sessions, die mit neuen Statements auf das FLUSH TABLES warten und somit nicht abgearbeitet werden können.

Der Grund dafür ist ein GLOBAL READ LOCK, den das FLUSH TABLES Statement erzeugt. Dieser hängt hinter den Locks der laufenden Statements. Werden diese Verarbeitungen nicht rechtzeitig fertig, läuft der Backup-Client in eine Statement-Timeout und bricht das Backup ab.

Dieser GLOBAL READ LOCK wiederum blockiert alle weiteren Sessions, die ein Statement verarbeiten wollen, in der Datenbank geht's dann zu wie in den Verkehrsmeldungen von Wien am Montag morgen. 

Der Lock sieht in der DB so aus:

Der Langläufer in Session 8693868 sperrt das Backup in Session 8693825. Dabei ist es unerheblich, aus welchem Grund das Statement lange aktiv ist. Eine DWH Query ist eine Möglichkeit, ein UPDATE, das auf einen gesperrten Datensatz wartet und nicht weiterarbeiten kann, kann genauso die Ursache sein.

Echte Abhilfe dagegen gibt es nicht, wir können nur ein paar Ansatzpunkte für Workarounds anbieten:

• Wenn Sie ausschliesslich InnoDB Tables im System haben, könnte die Backup Software auf das FLUSH Tables verzichten. Die InnoDB sollte aus den Informationen, die in den Files vorhanden sind, immer mit einem Crash-Recovery wieder hochfahren können. Angefangende Transaktionen werden entsprechend zurückgerollt.
  Bei anderen Engines wie MyISAM ist das leider nicht so einfach möglich.
• Gemeinsam mit dem Applikationsteam müssen Zeitfenster definiert werden, in denen das Backup immer erfolgreich starten kann. In diesem Zeitfenster dürfen keine Langläufer aktiv sein.