SQLite auf ZFS und DRBD

Beobachtung

SQLite erzeugt viele kleine und teilweise synchrone Schreibzugriffe. Abhängig vom verwendeten Journal-Modus werden neben den eigentlichen Datenbankseiten zusätzliche Journal- oder WAL-Daten geschrieben. Im Cluster home-tamay-cloud zeigten SQLite-Workloads auf replizierten ZFS-Volumes besonders hohe IO-Latenzen und eine starke Write Amplification.

Die Anwendung, das Dateisystem, das ZFS-Zvol und das physische Medium können unterschiedliche Blockgrößen verwenden. Kleine Änderungen der Datenbank müssen dadurch möglicherweise auf größere Blöcke des darunterliegenden Storage-Backends abgebildet werden.

SQLite
  |
  v
Dateisystem
  |
  v
ZFS zvol
  |
  v
DRBD-Replikation
  |
  v
Consumer-SSD

Erkenntnis

Ein ungünstiges Verhältnis zwischen den Schreibgrößen der Anwendung und den Blockgrößen des Storage-Backends kann zusätzliche Read-Modify-Write- und Copy-on-Write-Operationen verursachen. ZFS-Metadaten, synchrone Schreibzugriffe und DRBD-Replikation verstärken die daraus entstehende physische Schreiblast.

Die Kombination aus SQLite, ZFS, DRBD und einer Consumer-SSD ohne DRAM-Cache bildet deshalb einen ungünstigen Storage-Pfad. Eine kleine logische Änderung innerhalb der SQLite-Datenbank kann mehrere Schreiboperationen auf dem physischen Datenträger auslösen.

Konsequenz

SQLite-Workloads mit relevanter Schreiblast werden nicht ohne vorherige Messung auf replizierten ZFS-Volumes betrieben. Tests müssen das tatsächliche Dateisystem, den Journal-Modus, die Blockgrößen, die Replikation und ein realistisches Schreibmuster berücksichtigen.

Abhängig von den Anforderungen werden folgende Alternativen bevorzugt:

  • LVM-basierte LINSTOR-Volumes

  • Lokaler Storage ohne DRBD

  • NVMe-basierter Storage

  • PostgreSQL für Anwendungen mit höherer Schreiblast oder eigener Replikation

Die pauschale Deaktivierung synchroner Schreibzugriffe ist keine geeignete Lösung, da sie die zugesicherten Haltbarkeitseigenschaften der Anwendung oder des Dateisystems verändern kann.

Quellen