channel.db auf LND Lightning Nodes verkleinern

Heute schauen wir uns an, wie wir die Kanaldatenbank, die sogenannte channel.db auf LND Lightning Nodes verkleinern können. Dieser Leitfaden ist für fortgeschrittene Noderunner, NICHT für neue Nodes oder kleine persönliche Nodes, ausser, ihr habt wirlich viele Kanäle am laufen. Der Leitfaden richtet sich mehr an jene Node-Betreiber, die täglich eine Menge an Routings durchführen, viele Kanäle schließen/öffnen, Händler mit vielen generierten Rechnungen, fehlgeschlagenen Rechnungen und mit viel erzeugtem Traffic.

Wenn ihr gerade erst Neuling seid und einen frische Node startet, ist diese Anleitung etwas, dass man sich für später aufbewahren kann.

Um was geht es überhaupt

Die channel.db ist eine essentielle Datenbank auf Lightning Nodes im Lightning Network, einem Layer-2-Zahlungsprotokoll, das auf der Blockchain von Bitcoin aufbaut, um schnelle, skalierbare Transaktionen zu ermöglichen. Diese Datenbank spielt eine zentrale Rolle in der Verwaltung und dem Betrieb einer Lightning Node.

Die Datei channel.db, die sich in den Unterordnern von LND befindet, wächst mit der Zeit immer weiter an, bis sie ziemlich schwer zu verwalten ist und eine Dateikorruption bei einer größeren Datei wahrscheinlicher als bei einer kleineren ist. Zudem wird diese Datei in den Speicher geladen, sodass, je kleiner sie ist, umso weniger Speicher bzw RAM wird verwendet. Sie beeinflusst auch die Reaktionszeit eurer Node für das Routing von Zahlungen.

Zusammenfassend ist es also ziemlich sinnvoll, diese Datei so klein wie möglich zu halten.
Warum habe ich diesen Artikel geschrieben gemacht? Ich las mehrere Beiträge auf Github über das Problem, mit großen db-Dateien umzugehen und die zunehmende Verlangsamung der Nodes. Ausserdem gibt es ziemlich wenig Anleitungen, wie man selber die Kanal Datenbank kompaktiert, also habe ich beschlossen, eine Anleitung zu schreiben.

Diejenigen, die in letzter Zeit feststellen, dass ihre Nodes seltsam und langsamer reagieren, werden mit dieser kurzen Anleitung sicherlich etwas Erleichterung erfahren.

channel.db Grösse überprüfen

Die Grösse der channel.db kann man mit dem ls -lh schnell überprüfen. Empfehlenswert ist die Datenbank ab 3GB zum ersten mal zu kompaktieren. Je nachdem auf welchen System lautet liegt die channel.db an folgendem Ort und kann mit der flag -lh grössentechnisch gesichtet werden:

Umbrel

ls -lh /root/umbrel/app-data/lightning/data/lnd/data/graph/mainnet/

Raspiblitz

sudo ls -lh /mnt/hdd/lnd/data/graph/mainnet/

BTCPay Server

ls -lh /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/graph/mainnet/

Exemplarisch, bei mir ist die channel.db bereits 2.6GB gross:

channel.db kompaktieren

Wir müssen zuerst ein paar Vorbereitungen erledigen und ein paar Änderungen durchführen, damit die kompaktieren möglich ist. Wir schauen uns die kompaktieren auf 3 verschiedenen Systemen an, BTCPay Server, Umbrel und dem Raspiblitz. Wenn wir schon dabei sind führen wir gleich noch ein paar weitere Optimierungen durch, welche die Performance der Nodes erhöht.

Umbrel Fullnode

Die Durchführung des kompaktieren auf einem Umbrel System ist ziemlich einfach. Öffnet eure Lightning Node, und geht oben rechts mit den 3 Punkten in die Einstellungen:

Navigiert runter zu Optimizations und aktiviert folgende Settings:

db.bolt.auto-compact=true
db.bolt.auto-compact-min-age=168h

gc-canceled-invoices-on-startup=1 
gc-canceled-invoices-on-the-fly=1
ignore-historical-gossip-filters=1
start sync-freelist=1
stagger-initial-reconnect=1
payments-expiration-grace-period=9999h

Haltet nach den richtigen Konfigurationen Auschau, indem ihr die kleine rot markierte Beschriftung beachtet:

db.bolt.auto-compact-min-age=168h beschreibt zum Beispiel, dass die kompaktierung der channel.db erst durchgeführt wird, wenn die Datei das letzte mal vor 168 Stunden verkleinert wurden ist. Wenn ihr die Einstellungen deaktiviert, wird die channel.db jedesmal bei neustart von LND kompaktiert. Das kann jedesmal zu langen Ladezeit führen bis die Node aktiv ist.

BTCPay Server

Auf dem BTCPay Server ist ein spezielles Fragment zu aktivieren, damit die Kompaktierung aktiv wird. Loggt euch auf dem Server via SSH ein, und führt folgenden Befehl aus:

export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;opt-lnd-autocompact"

Dieser Befehl fügt die Kompaktierung dem BTCPay Server hinzu. Leider führt der Server die Kompaktierung nun jedesmal bei einem Neustart des Systems oder LND durch, die Einstellung db.bolt.auto-compact-min-age können wir aber durch einen kleinen Umweg setzen. Legt euch ein neues Fragment an mit dem Befehl:

nano /root/btcpayserver-docker/docker-compose-generator/docker-fragments/opt-lnd-additionals.custom.yml

Fügt hier wieder folgenden Inhalt hinzu, aber ohne die Einstellung db.bolt.auto-compact=true da dieses schon im autocompact Fragment enthalten ist:

db.bolt.auto-compact-min-age=168h 
gc-canceled-invoices-on-startup=1  
gc-canceled-invoices-on-the-fly=1 
ignore-historical-gossip-filters=1 
start sync-freelist=1 
stagger-initial-reconnect=1 
payments-expiration-grace-period=9999h

Speichert mit strg+o und beendet mit strg+x. Fügt das Custom Fragment mit der Export Funktion hinzu:

export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;opt-lnd-additionals.custom"

Um die neuen Einstellungen zu laden, führt ihr einmal folgenden Befehl aus:

. /root/btcpay-server/btcpay-setup.sh -i

Vergesst nicht den Punkt mit einzufügen! Danach startet der Server neu, und läd die neuen Einstellungen mit in die entsprechenden Docker-Container.

Hier findet ihr ausserdem eine Liste aller Fragmente für den BTCPay Server.

Raspiblitz Fullnode

Auf dem Raspiblitz ist das Datenbank Compacting bereits aktiviert. Es wird standardmässig ausgeführt, sollte die channel.db ältern als 672 Stunden sein. Die Kompaktierung wird dann bei neustart von LND durchgeführt. Es kann sinnvoll sein, die Zahl etwas herunter zu setzen, da bei einer grossen Anzahl Kanälen, saumässig viel Arbeit auf den Raspiblitz zu kommt. Ausserdem setzen wir auch die anderen Optimierungen, wie bei Umbrel und dem BTCPay Server. Schauen wir uns an, wie wir das tun:

Stoppt als erstes LND mit dem Befehl:

sudo systemctl stop lnd.service

Öffnet danach eure lnd.conf mit

sudo nano /mnt/hdd/lnd/lnd.conf

Packt den folgenden Inhalt in die die Konfigurationsdatei mit rein, und zwar so wie im Beispiel danach geordnet:

db.bolt.auto-compact=true 
db.bolt.auto-compact-min-age=168h 
gc-canceled-invoices-on-startup=1  
gc-canceled-invoices-on-the-fly=1 
ignore-historical-gossip-filters=1 
start sync-freelist=1 
stagger-initial-reconnect=1 
payments-expiration-grace-period=9999h

Die Konfiguration müssen an die korrekten Stellen:

Speichert die Konfiguration mit strg+o und beendet wieder mit strg+x

Startet LND neu mit:

sudo systemctl start lnd.service

Achtung, aufgepasst!

Bei einem kleineren System kann es teilweise mehrere Minuten bis Stunden gehen, um die Datenbank zu kompaktieren. Ein Raspiblitz, auf dem mehrere dutzend Kanäle laufen, auf dem die channel.db bereits mehrere Gigabyte hat, kann es gut und gerne mal 1-3 Stunden dauern, bis die Datenbank kompaktiert worden ist. Es heisst also einfach; WARTEN! In diesem Moment braucht ihr Geduld, teilweise viel Geduld. Macht nichts Dummes, starte die Node nicht neu oder zieh ihn nicht aus der Steckdose. Es ist normal, dass der Start mehr Zeit in Anspruch nimmt.

Der Teil der Kompaktierung ist relativ heikel. Falls die Node während dieser Phase abgeschalten wird, sind all eure Kanäle nachher mit hoher wahrscheinlichkeit beschädigt. Katzen und Hunde am besten während dieser Zeit aus dem Zimmer sperren!

Abschluss

Mit den ls -lh Befehlen oben, könnt ihr anschliessend die Grösse der Datenbank nochmals überprüfen. Der Screenshot von mir war nach der Kompaktierung, die Datenbankgrösse betrug vorher ca 4.7GB. Eine regelmässige Ausführung der Kompaktierung hält eure Node, schnell, schlank, und verringert die Gefahr einer Datenbank Korruption. Die Kanaldatenbank wird natürlich trotzdem immer weiter anwachsen. Nach einem Jahr Routen, in Kombination mit vielen Kanälen kann die Datenbank auch gern mal 15 bis 20GB in Anspruch nehmen. Wichtig ist hier, die Datenbank regelmässig zu kompaktieren, und dass ihr dafür genug Resourcen zur Verfügung habt. Für grössere Routing Nodes, ist der Raspiblitz auf einem Pi, also nicht geeignet.