MariaDB10 + phpMyAdmin auf DSM: Große Datenbanken unimportierbar

[Elrob]

Ich möchte hier ein Problem ansprechen, das ich bereits vor zwei Jahren an Synology gemeldet habe – ohne jede vernünftige Reaktion bis heute.

Ich betreibe ein MediaWiki mit einer Datenbankgröße von 5,2 GB (Sokradia). Export über phpMyAdmin funktioniert problemlos. Der Import dagegen ist auf DSM praktisch unmöglich.

Und das ist nicht nur bei mir so.

Synology hat es selbst nicht geschafft, den eigenen Export wieder zu importieren. Ich habe Synology 2025 gebeten, den Vorgang zu testen. Sie haben meine Datenbank exportiert – und konnten diesen Export anschließend nicht in eine andere Datenbank importieren. Seitdem: Funkstille.

Warum ist das so?

• phpMyAdmin läuft über HTTP → Upload‑Limits, Timeouts, Memory‑Limits• DSM‑PHP ist hart begrenzt (512 MB Upload, 30 Sekunden Laufzeit, 128 MB Memory)
• große SQL‑Dateien brechen ab
• MariaDB10 wird während DSM‑Backups sogar beendet
• phpMyAdmin ist veraltet (5.2.2‑1102), meldet selbst ein Update auf 5.2.3
• Konfiguration ist fehlerhaft („Cookie‑Verschlüsselungsschlüssel zu lang“)
• MariaDB10 (10.11.11‑1551) wird kaum gepflegt

Ergebnis:
• Große Datenbanken sind über phpMyAdmin nicht importierbar.
• Synology weiß das seit Jahren.
• Synology hat es selbst nicht hinbekommen.
• Trotzdem wird phpMyAdmin weiterhin als „Admin‑Tool“ ausgeliefert.

Zum Vergleich: Wikipedia, Perrypedia und alle professionellen MediaWiki‑Installationen nutzen niemals phpMyAdmin für große Datenbanken. Sie arbeiten ausschließlich über die Shell:

Das funktioniert immer – aber Synology bietet diese Möglichkeit im Paketzentrum nicht an und dokumentiert es auch nicht.

Ganz ehrlich: Wenn Synology bestimmte Pakete nicht supporten kann oder will, wäre es dann nicht sinnvoller, diese gar nicht erst auszuliefern?Oder den Nutzern zumindest zu erlauben, funktionierende Versionen aus anderen Quellen zu installieren?

So wären:

• Synology aus der Support‑Miseré raus
• die Nutzer nicht auf veraltete oder fehlerhafte Pakete angewiesen
• und Synology müsste nicht ständig erklären, warum etwas „eigentlich nicht vorgesehen“ ist

Aktuell ist es genau andersherum:

Synology liefert Pakete aus, die nicht gepflegt werden – aber verhindert gleichzeitig, dass Nutzer moderne, funktionierende Versionen selbst installieren können.

Meine Fragen an die Community:
• Ist das normal, dass Synology seit Jahren keine Lösung liefert?
• Nutzt jemand MariaDB10 produktiv mit großen Datenbanken?
• Warum wird phpMyAdmin ausgeliefert, wenn es für echte Datenmengen unbrauchbar ist?
• Warum gibt es keine Updates für MariaDB10 und phpMyAdmin?
• Hat Synology die Web‑/Datenbank‑Pakete aufgegeben?



Ich bin gespannt auf eure Erfahrungen.

 

[luddi]

Aber der Import dieser besagten 5,2 GB großen Datenbank über die command line klappt vermutlich problemlos?

 

[Ulfhednir]

Ich will hier gar nicht auf alle Punkte eingehen, weil das Forum hier im Grunde der falsche Empfänger ist. Ich will aber erstmal so viel sagen: phpMyAdmin dürfte für die meisten 0815-Zwecke als Verwaltungstool ausreichen. Deine Datenbank hat schon eine gewisse Größe, da würde ich ohnehin hinterfragen, ob das aktuelle Setting überhaupt optimal ist. Was ich direkt zumindest an eine Fragestellung anknüpfen würde

• Hat Synology die Web‑/Datenbank‑Pakete aufgegeben?

Es ist tatsächlich lange (zumindest mir) bekannt, dass die im Paketzentrum angebotenen Pakete nicht regelmäßig gepflegt sind. Gefühlt kommt 1x bei einem Major-Release hier ein Update, was dann aber ebenfalls schon veraltet ist. Wer ernsthaft daran interessiert ist eine 3rd-Party-Software produktiv zu nutzen, sollte sich anderweitig orientieren. Die meisten Pakete sind derweil über Docker verfügbar - damit ist man nicht an Synologys Update-Politik gebunden.

 

[Elrob]

Aber der Import dieser besagten 5,2 GB großen Datenbank über die command line klappt vermutlich problemlos?

Even the command‑line import will fail with very large SQL files on DSM. Not because of MariaDB itself, but because DSM imposes several architectural limitations:

• the built‑in NGINX cannot be configured (timeouts cannot be increased)
• DSM blocks phpMyAdmin’s chunked upload mechanism
• large files cannot be uploaded to the NAS in the first place
• MariaDB10 is stopped during DSM backup operations

So yes, CLI import works for medium‑sized databases — but for very large dumps, DSM itself becomes the limiting factor.

 

[Elrob]

Danke für deine Einschätzung.

Mir geht es hier aber nicht darum, ob phpMyAdmin „für 0815‑Zwecke“ ausreicht oder ob man grundsätzlich Docker nutzen kann.

Der Punkt ist ein anderer:

Die Web‑/Datenbank‑Pakete im Synology‑Paketzentrum sind technisch so eingeschränkt, dass bestimmte Funktionen objektiv nicht mehr nutzbar sind.​

Das betrifft u. a.:

• fest verdrahtete NGINX‑Timeouts, die man nicht erhöhen kann
• hart limitierte DSM‑PHP‑Parameter (512 MB Upload, 30 s Laufzeit, 128 MB Memory)
• deaktivierte phpMyAdmin‑Chunk‑Upload‑Mechanik
• MariaDB10, das während DSM‑Backups einfach beendet wird
• veraltete und fehlerhafte phpMyAdmin‑Version
• kaum gepflegte MariaDB10‑Pakete

Das führt dazu, dass selbst der Command‑Line‑Import bei sehr großen SQL‑Dateien scheitern kann, weil DSM selbst Prozesse unterbricht oder Uploads verhindert.

Es geht also nicht darum, ob Docker eine Alternative ist – natürlich ist es das. Es geht darum, dass Synology im Paketzentrum Software anbietet, die in dieser Form nicht mehr funktionsfähig ist.

Und genau deshalb ist die Frage absolut berechtigt:

Hat Synology die Web‑/Datenbank‑Pakete aufgegeben?

Denn die technischen Einschränkungen sind nicht „0815‑bezogen“, sondern systembedingt. Wenn man etwas nicht supporten kann, dann überschreibt man nicht fremdparameter die der Entwickler z.B von Maria10DB mitliefert... Und da ist genau der Haken in DSM 7.X kann ich wohl das Konfigfile anpassen, was legitim ist. Aber was macht Synology ... Das neu konfigfile wird sofort beim Aufruf der Anwendung knallhart überschrieben.

 

[Elrob]

Genau hier liegt der eigentliche Knackpunkt:Jede zusätzlich installierte PHP‑Version aus dem Paketzentrum kostet CPU‑ und RAM‑Ressourcen, weil sie als eigener Dienst läuft.

Umso unverständlicher ist es, dass DSM diese PHP‑Pakete überhaupt nicht nutzt.

Stattdessen verwendet DSM:

• eine interne, versteckte PHP‑Version,
• die nicht im Paketzentrum erscheint,
• die nicht aktualisiert wird,
• die nicht konfigurierbar ist,
• und die nicht dieselbe ICU‑Version nutzt wie die installierten Pakete.

Diese interne PHP‑Version wird für:

• phpMyAdmin
• Web Station
• DSM‑eigene Webdienste
• interne DSM‑Skripte

verwendet — egal, welche PHP‑Versionen der Nutzer installiert hat.

Das führt zu mehreren Problemen:

• Doppelte PHP‑Stacks → unnötige CPU‑Last
• veraltete ICU (64.2) → inkompatibel mit MediaWiki 1.43.x
• harte Limits (512 MB Upload, 30 s Laufzeit, 128 MB Memory)
• fehlende Module
• nicht anpassbare NGINX‑Timeouts
• phpMyAdmin läuft auf einer PHP‑Version, die ich nie installiert habe

Kurz gesagt:

DSM ignoriert die PHP‑Pakete aus dem Paketzentrum vollständig und zwingt alle DSM‑Webdienste auf eine interne PHP‑Version, die technisch veraltet und stark limitiert ist.

Damit stellt sich die Frage völlig zu Recht:

Warum bietet Synology überhaupt PHP‑Pakete im Paketzentrum an, wenn DSM sie selbst nicht nutzt?​