So räumst du deine Shopware-Datenbank planbar und sicher auf - mit Dry-Run, Audit-Log und geplanten Tasks.
Shopware 6.7, PHP 8.1 oder neuer, MySQL ab 5.7.4 beziehungsweise MariaDB ab 10.3 - letzteres wegen der Session-Timeouts über MAX_EXECUTION_TIME. Für die automatische Bereinigung muss ein Worker laufen.
Plugin im Shopware-Admin hochladen, installieren und aktivieren. Danach erscheint das Modul unter Erweiterungen, Datenbank Cleanup & Optimizer.
Das Modul zeigt die aktuelle Lage, die manuelle Bereinigung, die Einstellungen für den automatischen Lauf und das Protokoll.
Jedes Mal, wenn im Admin eine Bestellung bearbeitet wird, legt Shopware eine Arbeitskopie an - einen Draft. Wird die Bearbeitung abgebrochen statt gespeichert, bleibt dieser Draft in den Tabellen order und order_line_item liegen.
Über Monate summiert sich das. Irgendwann laufen Admin-Formulare wie die Vorgangspositionen in Timeouts, weil sie sich durch zehntausende verwaister Zeilen arbeiten müssen. Genau diese Zeilen entfernt das Plugin.
Gelöscht wird ausschließlich, was beide Bedingungen erfüllt:
0fa91ce3... wird nie angefasst.state_machine_history und sind nicht versionsgebunden. Sie werden nicht angefasst.Abhängige Tabellen wie order_address, order_delivery und order_transaction räumen sich über die Fremdschlüssel automatisch mit auf. Es bleiben also keine Reste zurück.
Der obere Bereich zeigt live, wie viele verwaiste Bestell- und Positionsversionen existieren und wie viele davon älter als sieben Tage sind. Das ist der ehrliche Blick darauf, ob sich ein Lauf überhaupt lohnt.
Die Vorschau vor dem ersten scharfen Lauf zu nutzen, ist sinnvoll - sie kostet nichts und zeigt die Größenordnung.
Optional läuft die Bereinigung selbstständig. Einstellbar sind das Intervall - stündlich, alle 2, 6 oder 12 Stunden, täglich oder wöchentlich - sowie das Mindestalter und die Aufbewahrungsdauer der Protokolleinträge.
messenger:consume. Ohne Worker passiert nichts.Jeder echte Lauf wird protokolliert, egal ob er aus dem Admin, per Konsole oder automatisch angestoßen wurde. Festgehalten werden Zeitpunkt, Auslöser, Benutzer, Anzahl gelöschter Zeilen und Dauer.
Während eines Laufs zeigt der Fußbereich einen Sekundenzähler. Der Vorgang lässt sich jederzeit abbrechen; bereits laufende DELETE-Batches werden noch sauber zu Ende geführt, damit die Datenbank konsistent bleibt.
Der erste Befehl zeigt nur an, was gelöscht würde. Der zweite räumt tatsächlich auf, mit Fortschrittsanzeige im Terminal.
--age-days, -a Standard: 7--batch-size, -b Standard: 50000--dry-run, -d--force, -fWenn die Tabellen bereits Probleme machen, hat sich dieser Ablauf bewährt:
Idealerweise in einer tmux- oder screen-Sitzung, damit der Lauf einen Verbindungsabbruch übersteht. Danach die automatische Bereinigung aktivieren, täglich mit sieben Tagen Mindestalter - dann bleibt es dauerhaft sauber.
InnoDB markiert gelöschte Seiten nur als frei und gibt den Platz nicht ans Dateisystem zurück. Erst dieser Befehl holt ihn wirklich:
Wenn ein Lauf unerwartet null Zeilen löscht, hilft dieser Endpoint bei der Ursachensuche:
Er liefert exakte Zählungen, Beispiel-Versions-IDs und einen Test-DELETE in einer Transaktion, die sofort zurückgerollt wird. Er verändert also nichts.
--age-days=0 mit Vorsicht: Ohne Altersfilter können aktive Bearbeitungen zerstört werden - jemand bearbeitet gerade eine Bestellung, und der Draft wird unter ihm weggelöscht. Der Standard von sieben Tagen ist der sichere Wert.Entweder gibt es nichts zu löschen, oder alle Kandidaten sind jünger als das Mindestalter. Der Diagnose-Endpoint zeigt, was Sache ist.
Das ist normal. Erst OPTIMIZE TABLE gibt den Platz frei.
Es fehlt ein aktiver Worker. Ohne Admin-Worker oder messenger:consume wird kein Scheduled Task ausgeführt.
Bei sehr großen Tabellen die Konsole nutzen. Die Oberfläche unterliegt dem HTTP-Timeout, das Terminal nicht.
Bei Fragen zum ersten Lauf auf einer großen Datenbank helfen wir gern - schreib uns über die Kontaktseite oder an info@stoneandwater.online.
Jede Einstellung des Plugins mit Standardwert und Erklärung, in derselben Reihenfolge wie im Administrationsbereich. Die Texte stammen direkt aus dem Plugin (Version 1.0.24).
Nur Versionen älter als X Tage löschen. Standardwert 7 schützt aktive Edit-Sessions. 0 = ohne Altersfilter (Vorsicht!).
Wie viele Zeilen pro DELETE-Statement entfernt werden. Höher = schneller, aber längere Tabellen-Locks. Erlaubt: 100 bis 1.000.000. Empfehlung: 50.000 (Default), bei sehr großen Tabellen auch 100.000-250.000. Möglich sind 100 bis 1000000.
Wenn aktiv, läuft das Cleanup im konfigurierten Intervall via Scheduled Task.
Wie häufig das automatische Cleanup laufen soll: stündlich, alle 2, 6 oder 12 Stunden, täglich oder wöchentlich.
Nur Versionen löschen, die mindestens X Tage alt sind.
Protokoll-Einträge älter als X Tage werden automatisch entfernt. 0 = unbegrenzt aufbewahren.
Schutzfilter für Phase 4 (aggressive). Niedriger = mehr wird bereinigt.
Zusätzlich ALLE non-live Commits älter als X Tage entfernen, auch wenn die zugehörige Version noch existiert. Empfohlen nach großen Bereinigungen.
Löscht alle log_entry-Einträge älter als X Tage. 0 = komplette Tabelle leeren (alle Einträge).
Tabellen kleiner als X MB ausblenden.
Listet Bestellungen auf, die mehr als X Einträge in der order-Tabelle haben (Live-Version mitgezählt).
Zwei Wege, derselbe Funktionsumfang - such dir aus, was besser zu deinem Setup passt.
Alle Preise netto zzgl. USt.
Du kaufst die Lizenz direkt bei uns und bekommst eine Rechnung von uns. Installation per Upload im Admin ohne SSH, Updates über unsere Lizenzplattform, Support direkt vom Entwickler.
Das Plugin wird im offiziellen Shopware Community Store gelistet. Installation und automatische Updates laufen dann über den Plugin Manager im Backend, die Abrechnung über deinen Shopware-Account. Sobald verfügbar, verlinken wir es hier.
Alle Funktionen auf der Produktseite. Bei Einrichtung und Cleanup-Strategie helfen wir gern.