SQLite produktiv auf einem VPS betreiben

Die richtige Produktionsdatenbank auf einem VPS: SQLite

SQLite in einer Produktionsumgebung auf einem VPS zu betreiben, ist für die meisten kleinen Anwendungen die richtige Entscheidung. Der Grund ist einfach: Ein Prozess auf einer Maschine, der in eine Datei schreibt, benötigt keinen Datenbankserver. Es gibt keinen Daemon, den Sie überwachen müssen, keinen Port, den Sie mit Firewall-Regeln absichern müssen, kein Passwort, das Sie regelmäßig ändern müssen, und keine zweite Maschine, die verfügbar bleiben muss. Eine Abfrage ist ein Funktionsaufruf und kein Netzwerk-Roundtrip. Eine Seite mit vierzig Abfragen verursacht daher vierzig Funktionsaufrufe.

Die Einschränkungen sind klar und relevant. SQLite erlaubt in der gesamten Datenbankdatei immer nur einen Writer gleichzeitig. Außerdem kann die Datei nicht von zwei Maschinen gemeinsam verwendet werden. Für einen einzelnen VPS mit einer einzelnen Anwendung sind beide Einschränkungen unproblematisch. Sobald Sie dieses Modell überschreiten, werden beide Einschränkungen zu einem Ausschlusskriterium. Dieser Leitfaden behandelt die Einstellungen, mit denen Sie SQLite auf einem Server sicher betreiben, die kontinuierliche Sicherung mit Litestream und den Punkt, an dem Sie auf eine andere Lösung wechseln sollten.

Installieren Sie zuerst das Kommandozeilenprogramm. Alle folgenden Schritte wurden unter Ubuntu 24.04 ausgeführt.

sudo apt update
sudo apt install -y sqlite3
sqlite3 --version

Der Befehl gibt eine mit 3. beginnende Version sowie ein Build-Datum und einen Source-Hash aus. Ubuntu 24.04 enthält Stand Oktober 2026 SQLite 3.45.1. Ihre Anwendung verwendet diese Binärdatei wahrscheinlich nicht: Die meisten Laufzeitumgebungen bringen eine eigene Kopie der SQLite-Bibliothek mit, die häufig neuer ist. Prüfen Sie daher die Version, die Ihr Datenbanktreiber meldet, bevor Sie sich auf eine aktuelle Funktion verlassen.

Warum der WAL-Modus die erste Änderung ist

Standardmäßig verwendet SQLite ein Rollback-Journal. Bevor eine Seite geändert wird, kopiert SQLite die ursprüngliche Seite in eine -journal-Datei und bearbeitet anschließend die Datenbank direkt. Dafür wird die gesamte Datei sicherheitshalber exklusiv gesperrt. Daher wartet jeder Lesevorgang, solange ein Schreibvorgang läuft. Auf einem Laptop fällt das nicht auf. Auf einem Webserver hält ein langsamer Schreibvorgang jede Anfrage auf, die auf die Datenbank zugreift.

Der WAL-Modus (Write-Ahead-Log) kehrt diese Reihenfolge um. Ein Schreibvorgang hängt die neuen Seiten an eine separate -wal-Datei an und lässt die Hauptdatenbank unverändert. Leser greifen weiterhin auf die Hauptdatei in dem Snapshot zu, mit dem sie begonnen haben. Dadurch blockieren Leser den Schreibvorgang nicht, und der Schreibvorgang blockiert die Leser nicht. Später kopiert ein Checkpoint die angesammelten WAL-Seiten zurück in die Hauptdatenbank. Diese eine Änderung trägt wesentlich dazu bei, dass SQLite hinter einer Webanwendung verwendet werden kann.

WAL-Modus aktivieren und bestätigen, dass er bestehen bleibt

mkdir -p ~/app
sqlite3 ~/app/app.db "PRAGMA journal_mode=WAL;"

Der Befehl gibt wal aus. Diese Ausgabe ist nicht nur Dekoration. PRAGMA journal_mode gibt den Modus zurück, in dem sich die Datenbank tatsächlich befindet. Eine Antwort mit delete bedeutet daher, dass die Änderung fehlgeschlagen ist und weiterhin das Rollback-Journal verwendet wird.

Der WAL-Modus bleibt dauerhaft aktiviert. Er ist ein Flag im Datenbank-Header und keine verbindungsspezifische Einstellung. Deshalb führen Sie den Befehl einmal pro Datenbankdatei aus. Jede spätere Verbindung übernimmt diese Einstellung, auch nach einem Reboot. Überprüfen Sie das mit einer neuen Verbindung.

sqlite3 ~/app/app.db "PRAGMA journal_mode;"

Erstellen Sie jetzt eine Tabelle und prüfen Sie, welche Dateien auf der Festplatte erscheinen.

sqlite3 ~/app/app.db <<'SQL'
CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY, body TEXT NOT NULL);
INSERT INTO notes (body) VALUES ('first row');
SQL
ls -l ~/app/

Jetzt gibt es drei Dateien: app.db, app.db-wal und app.db-shm. Die Datei -wal enthält bereits bestätigte Seiten, für die noch kein Checkpoint ausgeführt wurde. Die Datei -shm ist ein gemeinsam genutzter Speicherindex, den jede Verbindung einbindet, damit alle Verbindungen denselben Inhalt des WAL kennen. Beide Dateien gehören zur Datenbank und sind keine temporären Dateien. Wenn Sie während des laufenden Anwendungsbetriebs nur app.db kopieren, fehlen in der Kopie alle aktuellen Commits. Wenn Sie app.db löschen und die beiden anderen Dateien beibehalten, wendet SQLite diese veralteten WAL-Seiten auf jede neue Datei an, die unter diesem Namen erstellt wird. Auf diese Weise beschädigen Benutzer eine neue Datenbank, wenn sie eine Datenbank zurücksetzen möchten.

Die Verbindungseinstellungen, die jede Produktionsanwendung benötigt

Nur journal_mode wird in der Datenbank gespeichert. Jede andere Einstellung unten gilt pro Verbindung. Ihre Anwendung muss sie daher für jede geöffnete Verbindung setzen, einschließlich jeder Verbindung, die ein Pool im Hintergrund erstellt.

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA synchronous = NORMAL;
PRAGMA foreign_keys = ON;

busy_timeout = 5000 weist SQLite an, bei einer gesperrten Datenbank bis zu 5000 Millisekunden lang neue Versuche zu unternehmen, bevor database is locked zurückgegeben wird. Der Standardwert ist 0. Daher schlägt SQLite standardmäßig sofort fehl, sobald sich erstmals zwei Schreibvorgänge überschneiden. Das Setzen dieses einzelnen Werts beseitigt die meisten Sperrfehler, die SQLite selbst zugeschrieben werden.

synchronous = NORMAL ist im WAL-Modus die richtige Einstellung. Der Kompromiss muss jedoch verstanden werden. Bei FULL ruft SQLite bei jedem Commit fsync für das WAL auf. Bei NORMAL wird stattdessen bei Checkpoints synchronisiert. Die SQLite-Dokumentation beschreibt den Verzicht eindeutig: Transaktionen sind nach einem Stromausfall oder einem harten Reset nicht mehr dauerhaft gespeichert. Die Datenbank kann durch diesen Stromausfall nicht beschädigt werden. Sie verlieren lediglich die letzten Commits, die noch nicht auf die Festplatte geschrieben wurden. Auf einem VPS ist das normalerweise der richtige Kompromiss, weil dadurch ein fsync aus dem Pfad jedes einzelnen Schreibvorgangs entfernt wird.

foreign_keys = ON ist aus Gründen der Abwärtskompatibilität standardmäßig deaktiviert und gilt pro Verbindung. Ein Schema mit zahlreichen REFERENCES-Klauseln erzwingt keinerlei Integritätsregeln, solange nicht jede Verbindung diese Einstellung aktiviert.

Eine weitere Einstellung wird erst später relevant. SQLite führt automatisch einen Checkpoint aus, sobald das WAL auf mehr als 1000 Seiten anwächst. Die Arbeit übernimmt die Verbindung, die zu diesem Zeitpunkt gerade eine Transaktion abschließt. Für sich genommen ist das unproblematisch. Wenn Litestream ausgeführt wird, stellt sich jedoch die Frage nach dem Zeitpunkt, weil Litestream die Kontrolle über die Checkpoints behalten muss.

Warum database is locked weiterhin auftritt, nachdem Sie busy_timeout gesetzt haben

Dies ist der Fehler, der viele wieder zu Postgres führt. Er hat eine konkrete Ursache.

Ein busy_timeout installiert einen Busy-Handler. SQLite garantiert jedoch nicht, dass dieser aufgerufen wird.

Wenn SQLite feststellt, dass der Aufruf des Busy-Handlers zu einem Deadlock führen könnte, gibt es stattdessen SQLITE_BUSY an die Anwendung zurück.

Der vermiedene Deadlock tritt bei einer Hochstufung der Transaktion auf. Ein alleinstehendes BEGIN bedeutet in SQLite BEGIN DEFERRED. Wenn die erste Anweisung danach ein SELECT ist, befinden Sie sich in einer Lesetransaktion. Wenn ein späteres UPDATE in derselben Transaktion zu einer Schreibtransaktion werden muss und eine andere Verbindung seit Beginn Ihres Lesevorgangs geschrieben hat, kann SQLite Sie nicht warten lassen. Ihr Snapshot ist bereits veraltet. Das Warten würde lediglich zu einem Deadlock zwischen den beiden Verbindungen führen. Die Dokumentation beschreibt das Ergebnis direkt:

Nachfolgende Schreibanweisungen stufen die Transaktion zu einer Schreibtransaktion hoch, wenn dies möglich ist. Andernfalls wird SQLITE_BUSY zurückgegeben.

Ihr Timeout von 5000 Millisekunden wird überhaupt nicht berücksichtigt. Der Fehler tritt sofort auf. Deshalb wirkt es, als hätte die Einstellung keine Wirkung.

Die Lösung besteht aus einem Wort.

BEGIN IMMEDIATE;
UPDATE notes SET body = 'edited' WHERE id = 1;
COMMIT;

BEGIN IMMEDIATE übernimmt die Schreibsperre am Anfang, bevor etwas gelesen wird. Es gibt keine Hochstufung. Daher muss kein Deadlock vermieden werden. Der Busy-Handler wird angewendet, und die Verbindung wartet, bis sie an der Reihe ist, statt sofort fehlschlägt. Lassen Sie schreibgeschützte Transaktionen weiterhin verzögert beginnen. Jede Transaktion, die einen Schreibvorgang enthält, sollte sofort beginnen.

Die zweite Ursache für Sperrfehler ist schwerer zu erkennen: eine offene Schreibtransaktion während langsamer Vorgänge. SQLite serialisiert Schreibvorgänge. Eine Transaktion, die geöffnet wird, eine externe API über das Netzwerk aufruft und anschließend einen Commit ausführt, blockiert daher während dieses gesamten Aufrufs alle anderen Schreibvorgänge. Lesen Sie die benötigten Daten, schließen Sie die Transaktion, führen Sie den langsamen Vorgang aus und öffnen Sie anschließend eine kurze Schreibtransaktion, um das Ergebnis zu speichern.

Kontinuierliches Backup mit Litestream

Eine nächtliche Kopie verliert bis zu einen Tag an Schreibvorgängen. Außerdem kann die Ausführung von cp gegen eine aktive SQLite-Datenbank eine Kopie erzeugen, die sich nicht öffnen lässt. Zwei Verfahren sind sicher. sqlite3 app.db ".backup /path/to/backup.db" verwendet die Online-Backup-Schnittstelle von SQLite und funktioniert auch mit einer verwendeten Datenbank. Litestream geht weiter: Es überwacht das WAL und überträgt Änderungen kontinuierlich in den Objektspeicher. Dadurch sinkt der Datenverlust im schlimmsten Fall von einem Tag auf etwa eine Sekunde.

Litestream ist eine einzelne Go-Binärdatei, die neben Ihrer Anwendung läuft. Sie sitzt nicht zwischen der Anwendung und der Datenbank. Ihre Anwendung schreibt wie bisher in SQLite. Litestream liest das WAL und lädt die geänderten Daten hoch.

cd /tmp
curl -fsSL -O https://github.com/benbjohnson/litestream/releases/download/v0.5.14/litestream-0.5.14-linux-x86_64.deb
sudo dpkg -i litestream-0.5.14-linux-x86_64.deb
litestream version

v0.5.14 ist weiterhin die Version, die auf der offiziellen Linux-Installationsseite im Oktober 2026 dokumentiert ist. Danach wurden neuere Versionen veröffentlicht: v0.5.15 am 21. Juli 2026 und v0.5.17 als neuestes Tag am 31. August 2026. Passen Sie die Version in beiden Zeilen an das aktuelle Tag auf der Releases-Seite an. Verwenden Sie stattdessen das passende arm64-Paket, wenn Ihr VPS arm64 verwendet.

Die Konfigurationsdatei befindet sich unter /etc/litestream.yml. Beginnen Sie mit einer lokalen Dateireplikation. Damit testen Sie den gesamten Ablauf, ohne Cloud-Anmeldedaten zu benötigen.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      type: file
      path: /var/backups/litestream/app

Beachten Sie, dass das Feld replica im Singular steht. Litestream 0.5 hat das replicas-Array aus der 0.3-Serie durch einen einzelnen Replica-Block ersetzt. Eine Konfiguration mit zwei Einträgen schlägt beim Start fehl. Viele Anleitungen von Drittanbietern zeigen weiterhin das alte Array. Übernehmen Sie daher die obige Struktur und nicht das erste Beispiel, das eine Suche liefert. In der 0.5-Serie wurde außerdem das Unterkommando litestream wal in litestream ltx umbenannt, weil sich das Format der Backups auf dem Datenträger geändert hat.

Prüfen Sie die Konfiguration auf syntaktische Fehler, bevor Sie etwas aktivieren.

sudo litestream databases -config /etc/litestream.yml

Testen Sie anschließend den vollständigen Ablauf manuell. Diese Form verwendet die Konfigurationsdatei nicht und repliziert eine Datenbank in einen einzelnen Pfad.

mkdir -p /tmp/replica
litestream replicate ~/app/app.db file:///tmp/replica/app

Der Prozess läuft im Vordergrund weiter. Schreiben Sie in einer zweiten Shell eine Zeile und stellen Sie die Replica in einer neuen Datei wieder her.

sqlite3 ~/app/app.db "INSERT INTO notes (body) VALUES ('written after replication started');"
litestream restore -o /tmp/restored.db file:///tmp/replica/app
sqlite3 /tmp/restored.db "SELECT count(*) FROM notes;"

Die Anzahl enthält die neue Zeile. Ist das nicht der Fall, wurde die Änderung noch nicht synchronisiert: Litestream überträgt Daten in einem sync-interval, das standardmäßig 1 Sekunde beträgt. Warten Sie daher und führen Sie die Wiederherstellung erneut aus. Diese eine Sekunde ist zugleich Ihr Wiederherstellungspunkt. Bei einem Absturz gehen höchstens die Schreibvorgänge aus dem letzten Synchronisierungsintervall verloren. Keine Konfiguration kann diesen Wert auf null setzen.

Für den produktiven Speicher ersetzen Sie den Replica-Block durch eine S3-URL. Dies funktioniert mit Amazon S3 und mit S3-kompatiblem Objektspeicher anderer Anbieter.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      url: s3://your-bucket-name/app
      region: us-east-1

snapshot:
  interval: 24h
  retention: 24h

Speichern Sie Anmeldedaten nicht in dieser Datei. Litestream liest LITESTREAM_ACCESS_KEY_ID und LITESTREAM_SECRET_ACCESS_KEY aus der Umgebung. Hinterlegen Sie sie daher in einem systemd-Drop-in, das root gehört und den Modus 600 hat.

Die oben gezeigten Werte für Snapshots sind die Standardwerte. Der Standardwert für die Aufbewahrungsdauer führt jedoch häufig zu Missverständnissen. Die Aufbewahrungsdauer legt fest, wie lange Litestream Snapshots und die zugehörigen Dateien behält. Sie bestimmt damit auch, wie weit Sie eine Wiederherstellung zeitlich zurückführen können. Vierundzwanzig Stunden bedeuten, dass eine am Mittwochmorgen bemerkte fehlerhafte Migration aus dem Zustand von Montag bereits nicht mehr wiederherstellbar ist. In Litestream 0.5 ist die Aufbewahrungsdauer eine globale Einstellung im obersten snapshot-Block und keine Einstellung pro Replica. Für eine Woche ändern Sie diesen Block in retention: 168h und berücksichtigen den zusätzlichen Speicherbedarf. Eine Zeile retention: innerhalb des Replica-Blocks gehört zur Syntax der 0.3-Serie. Litestream 0.5 ignoriert sie ohne Fehlermeldung und verwendet weiterhin den Standardwert von 24 Stunden.

Testen Sie die Wiederherstellung, bevor Sie sie benötigen

litestream restore -o /tmp/check.db /home/appuser/app/app.db
sqlite3 /tmp/check.db "PRAGMA integrity_check;"
sqlite3 /tmp/check.db "SELECT count(*) FROM notes;"

Bei Angabe eines Datenbankpfads sucht litestream restore das passende Replikat in /etc/litestream.yml und lädt es herunter. PRAGMA integrity_check gibt ok für eine intakte Datei aus. Jede andere Ausgabe bedeutet, dass die wiederhergestellte Kopie nicht verwendet werden kann. Führen Sie diesen Test regelmäßig mit einem systemd-Dienst und Timer aus und prüfen Sie die Ausgabe. Solange Sie eine Sicherung nicht mindestens einmal wiederhergestellt haben, wissen Sie nicht, ob sie funktioniert.

Litestream unter systemd ausführen

Das Debian-Paket installiert eine litestream-Unit, die /etc/litestream.yml einliest.

sudo systemctl enable litestream
sudo systemctl start litestream
sudo journalctl -u litestream -f

Eine fehlerfreie Ausgabe nennt jede Datenbank aus der Konfiguration und bleibt anschließend bis auf regelmäßige Synchronisierungszeilen ruhig. Ein Fehler no such file or directory für den Datenbankpfad bedeutet, dass der Pfad in der Konfiguration falsch ist oder der Prozess ihn nicht lesen kann. Die Unit läuft standardmäßig als root. Das gewährt diesem Auftrag mehr Berechtigungen als erforderlich. Litestream muss sowohl die Datenbank als auch das Verzeichnis lesen und beschreiben können, in dem sie liegt. Litestream arbeitet mit den Dateien -wal und -shm neben Ihrer Datenbank. Weisen Sie Litestream daher das Benutzerkonto zu, unter dem Ihre Anwendung bereits läuft: appuser in diesen Beispielen.

# /etc/systemd/system/litestream.service.d/override.conf
[Service]
User=appuser
Group=appuser

Wenden Sie die Änderung mit sudo systemctl daemon-reload und sudo systemctl restart litestream an. Das Einrichten eines dedizierten Dienstkontos mit minimalen Berechtigungen dauert nur wenige Minuten. Dadurch läuft auf dem System kein zweiter root-Prozess, sondern nur ein Backup-Agent.

Wenn Sie den Server vollständig neu aufsetzen, ist die Reihenfolge wichtig. Die Datenbank muss wiederhergestellt werden, bevor die Anwendung startet. litestream restore akzeptiert -if-db-not-exists. Dieser Befehl beendet sich mit dem Status 0, wenn die Datei bereits vorhanden ist. Daher kann er bei jedem Boot ausgeführt werden. Fügen Sie ihn als ExecStartPre-Zeile in die Unit Ihrer Anwendung ein. Ein neuer VPS lädt die Datenbank dann herunter, während ein bereits eingerichteter VPS nichts unternimmt. litestream replicate bietet ein entsprechendes -restore-if-db-not-exists-Flag, wenn Sie die Einstellung lieber an einer einzigen Stelle verwalten möchten.

Wo SQLite auf einem VPS an Grenzen stößt

Netzwerkdateisysteme. Diese Einschränkung lässt sich nicht durch Konfiguration umgehen. Der WAL-Modus setzt voraus, dass alle Prozesse, die die Datenbank verwenden, einen kleinen Speicherbereich gemeinsam nutzen. Diesen stellt die Datei -shm bereit. Die SQLite-Dokumentation formuliert die Regel ohne Einschränkung:

Alle Prozesse, die eine Datenbank verwenden, müssen auf demselben Hostcomputer laufen. WAL funktioniert nicht über ein Netzwerkdateisystem.

Eine Datenbank auf einer eingebundenen NFS- (Network File System) oder SMB-Freigabe kann daher beschädigt werden. Kein Pragma verhindert das. Hier wird häufig eine wichtige Unterscheidung übersehen. Ein Netzwerk-Blockgerät, wie es die meisten VPS-Anbieter als zusätzlichen Speicher bereitstellen, erscheint unter Linux als gewöhnliche Festplatte mit einem gewöhnlichen Dateisystem. Das ist unproblematisch. Eine eingebundene Dateifreigabe ist etwas anderes.

Ein zweiter Anwendungsserver. Keine Einstellung macht diesen Betrieb möglich. Sobald zwei Maschinen auf dieselben Daten zugreifen müssen, benötigen Sie eine Datenbank, die über das Netzwerk kommuniziert. Planen Sie diesen Wechsel, solange dafür noch Zeit vorhanden ist.

Schreibintensive Workloads. Dass immer nur ein Prozess schreiben kann, ist eine Eigenschaft des Dateiformats und keine konfigurierbare Einstellung. Kurze Schreibvorgänge sind kostengünstig, weil jeder Commit an das WAL angehängt wird. Der Durchsatz hängt daher stärker von der Latenz kleiner Schreibvorgänge auf dem Datenträger als von der CPU ab. Unter NVMe im Vergleich zu SATA-SSD-Speicher auf einem VPS erfahren Sie, wie sich dieser Unterschied auswirkt. Das eigentliche Problem sind lange Transaktionen, weil sie alle anderen Schreibvorgänge hinter sich in die Warteschlange stellen.

Analytische Abfragen. SQLite ist ein für Transaktionen ausgelegter Zeilenspeicher. Ein Dashboard, das hundert Millionen Zeilen durchsucht, ist eine andere Aufgabe für ein anderes Werkzeug. DuckDB im Vergleich zu SQLite für Serveranwendungen beschreibt, wo diese Grenze liegt.

VACUUM während der Replikation. Ein vollständiges VACUUM schreibt die gesamte Datenbankdatei neu. Dadurch wird die seitenbasierte Nachverfolgung ungültig, auf die sich Litestream stützt. Die Litestream-Dokumentation rät davon ab, den Vorgang während aktiver Replikation direkt auszuführen. Stattdessen wird VACUUM INTO empfohlen. Dabei wird eine komprimierte Kopie in eine separate Datei geschrieben, während das Original unverändert bleibt. Wenn Sie die Bereinigung zwingend direkt in der bestehenden Datei ausführen müssen, ist das dokumentierte Verfahren aufwendiger als ein Neustart: Stoppen Sie den Replikator, führen Sie die Bereinigung aus, löschen Sie Litestreams verstecktes Verzeichnis zur Nachverfolgung neben der Datenbank sowie die vorhandenen Daten der entfernten Replik und starten Sie Litestream anschließend erneut, damit eine neue vollständige Momentaufnahme erstellt wird. Dadurch geht die bisher vorhandene Wiederherstellungsverlauf verloren.

Zwei Replikatoren für eine Datenbank. Führen Sie niemals zwei Litestream-Prozesse für dieselbe Datenbank oder dasselbe Replikationsziel aus. Die Dokumentation stellt ausdrücklich klar, dass Sie dies selbst verhindern müssen. Andernfalls entsteht eine Replik, die Sie nicht wiederherstellen können.

Was Litestream nicht abdeckt

Litestream schützt nur die Datenbankdatei. Für alles andere sind weiterhin Sie zuständig. Dazu gehören hochgeladene Dateien, die Anwendungskonfiguration, TLS-Zertifikate (Transport Layer Security) und die Unit-Dateien. Kombinieren Sie Litestream nach einem festen Zeitplan mit verschlüsselten Off-Host-Backups mit restic, damit beide Bereiche abgedeckt sind. Wenn die Maschine neu ist, behandelt die ersten zehn Minuten auf einem neuen VPS die Einrichtung des Benutzerkontos und der Firewall, die in dieser Anleitung vorausgesetzt wird.

FAQ

Ist SQLite für eine Produktionsanwendung ausreichend?

Für eine Anwendung auf einem Server: ja, sofern Sie den WAL-Modus aktivieren, ein Busy-Timeout festlegen und kontinuierliche Backups erstellen. Die relevanten Grenzen sind struktureller Art: Es kann jeweils nur einen Writer geben, und die Anwendung muss auf einem Host laufen. Eine Anwendung, die innerhalb dieser Grenzen bleibt, erhält eine Datenbank ohne Netzwerk-Hop und ohne separaten Prozess, den Sie überwachen müssen. Eine Anwendung, die diese Grenzen überschreitet, benötigt eine Client-Server-Datenbank. Keine Optimierung ändert daran etwas.

Warum erhalte ich nach dem Setzen von busy_timeout weiterhin database is locked?

Weil SQLite den Busy-Handler überspringt, wenn das Warten zu einem Deadlock führen könnte. Eine Transaktion, die mit einem einfachen BEGIN beginnt, ist aufgeschoben: Ein öffnendes SELECT versetzt sie in eine Lesetransaktion, und ein späterer Schreibvorgang muss die Transaktion hochstufen. Wenn eine andere Verbindung zwischenzeitlich geschrieben hat, gibt SQLite sofort SQLITE_BUSY zurück, statt Ihren Busy-Handler aufzurufen, weil Ihr Lese-Snapshot bereits veraltet ist. Starten Sie jede Transaktion, die schreiben soll, mit BEGIN IMMEDIATE. Dadurch wird die Schreibsperre von Anfang an angefordert, und das Timeout greift.

Kann ich meine SQLite-Datenbank auf einem Netzwerkspeicher ablegen?

Nicht auf einem Netzwerkdateisystem wie NFS oder SMB. Der WAL-Modus benötigt den gemeinsamen Speicher aller Prozesse über die Datei -shm. Laut SQLite-Dokumentation müssen sich alle Prozesse, die die Datenbank verwenden, auf demselben Hostcomputer befinden. Ein von Ihrem Provider bereitgestelltes und eingebundenes Netzwerkblockgerät ist etwas anderes: Linux erkennt darin einen normalen Datenträger mit einem normalen Dateisystem, und SQLite funktioniert dort.

Benötige ich Litestream, wenn ich bereits nächtliche Backups ausführe?

Das hängt davon ab, wie viele Daten Sie verlieren können. Ein nächtlicher Job bedeutet, dass bis zu vierundzwanzig Stunden an Schreibvorgängen verloren gehen können. Litestream synchronisiert ungefähr einmal pro Sekunde, sodass ein Absturz ungefähr die Schreibvorgänge der letzten Sekunde kostet. Litestream ist außerdem sicherer als das Kopieren der Datenbankdatei mit cp, weil dabei eine Datenbank während eines Schreibvorgangs erfasst werden kann. Litestream deckt nur die Datenbank ab. Lassen Sie daher zusätzlich ein allgemeines Datei-Backup laufen.