QMapShack und MySQL

Aloha,

vor ein paar Tagen bin ich auf QMapShack gestoßen auf der Suche nach einer möglichst plattformübergreifend verfügbaren Software (Windows und Linux konkret) zur Verwaltung relativ umfangreicher Wegpunkt/POI-Sammlungen plus Routenplanung zwischen ausgewählten Punkten einer Sammlung von verschiedenen Clients aus. QMapShack funktioniert dafür ausgezeichnet, mein Dank an die Entwickler. Nur...

Die naheliegende Idee für mein Einsatzszenario ist ja, alle Projekte in einer zentralen Datenbank zu speichern anstatt in lokalen Containern. Da das ganze Konstrukt möglichst auch unterwegs funktionieren soll per Windows-Laptop, hab' ich deshalb versuchsweise eine MySQL-Datenbank bei meinem Webspace-Hoster eingerichtet (gleich vorweg: tiefgreifende Konfigurationsänderungen sind da nicht möglich). Soweit so gut, grundsätzlich tut das. Aber nur ein paar Minuten lang, dann verliert QMapShack den Connect zur Datenbank und kann sie augenscheinlich auch nicht neu aufbauen. D.h. ich muss Routen etc. lokal zwischenspeichern, QMapShack schließen und neu starten, dann steht auch die MySQL-Datenbank wieder zur Verfügung.

Als DAU will ich mich eigentlich nicht in Vermutungen versteigen, woran's liegt und wie sich's beheben lassen würde. Vielleicht hat irgendjemand hier ja einen Tipp, wo mein Fehler liegt und wie ich's besser machen kann. Das Logfile von QMapShack sieht so aus, als würde nach dem initialen open in Richtung Datenbank nichts passieren, und wenn ich dann eben zu lange warte mit dem Anstoßen einer Abfrage oder Änderung, hat der Server die Verbindung zwischenzeitlich beendet. Die Fehlermeldung im Log ist immer ein lapidares

Zitat

[warning] QSqlError("2006", "QMYSQL: Die Abfrage konnte nicht ausgeführt werden", "MySQL server has gone away")

Vorläufig kann ich mit dem beschriebenen Workaround leben, neue Projekte zunächst lokal zu halten und beim nächsten Start dann in die MySQL-Datenbank zu schieben; ich bin am Überlegen, versuchsweise eine vorhandene MariaDB-Instanz in meinem LAN zu verwenden mit weitergehenden Konfigurationsoptionen, könnte darauf aber unterwegs nicht connecten, also suboptimal.

Danke vorab für jeden Tipp.

Nachtrag: Das Phänomen tritt gleichermaßen unter Windows wie Linux auf, liegt also offensichtlich nicht an der generischen qsqlmysql.dll, die ich mir für meine Windows-Installation aus dem Netz besorgen musste (von https://github.com/thecodemonkey86/qt_mysql_driver/releases). Da ich QMapShack 1.15 unter Ubuntu 20.04 LTS selber kompiliert hab' (dank DAU-freundlicher Anleitung auf https://www.mtb-touring.net/qms/qmapshack-linux-mint-20/), könnte ich da theoretisch herumspielen, wenn ich auch nur die Idee eines Ansatzpunktes hätte...

Grundsätzlich wäre ein Umstieg auf SQLite eine Option, wenn ich das mit MySQL nicht gebacken kriege. Allerdings bin ich skeptisch, wie gut SQLite das verträgt, wenn ich beim mobilen Einsatz mit dem Laptop und evtl. wackliger Verbindung mal den Connect verliere und die Dateisystemverbindung wegbricht. Hast Du da Erfahrungswerte?

Ok, aktueller Zwischenstand: Der fragliche MySQL-Server ist so konfiguriert, dass er idle connections nach 300 Sekunden kappt - das kann ich nicht ändern. Wie QMapShack seine Verbindungen zu Datenbanken parametriert, hab' ich noch nicht gefunden (bisher aber auch nur halbherzig unter Linux geguckt, da ich da die Sourcen schon auf der Platte habe). Der vorgesehene Weg scheint zu sein, über QSqlDatabase::setConnectOptions() ein "MYSQL_OPT_RECONNECT" zu konfigurieren, um vor einer Abfrage ggf. den Connect neu aufzubauen, wenn er verloren gegangen ist. Alternativ: Ich hab' in anderem Kontext bei z.B. HeidiSQL gesehen, dass da die Verbindung einfach über ein Ping in konfigurierbaren Intervallen aufrecht erhalten wird.

Momentan behelfe ich mir mit einer MariaDB10-Instanz auf einem Synology NAS im LAN mit ausreichenden Rechten, um solche Timeouts passend einzustellen. Das kann bzw. will ich nicht von außen erreichbar machen, insofern eigentlich suboptimal. Andererseits ist die Performance im LAN so atemberaubend viel besser, dass ich geneigt bin, bei dieser Lösung zu bleiben.

Zitat von kiozen

Kannst Du das mit `MYSQL_OPT_RECONNECT` mal ausprobieren? Die richtige Stelle sollte in `IDBMysql::setupDB` sein.

Danke für den Tipp . Ich bin nur skeptisch, ob ich vor dem Wochenende dazu komme, das auszuprobieren. Ich vermute stark, ich muss mich da erst einlesen...

Zitat von kiozen

Wer seine NAS liebt gibt keinen Port im Internet frei. Dafür gibt es VPN.

NAS von außen über VPN hatte ich in anderem Zusammenhang schon mal getestet. Da war der typische ADSL-Flaschenhals, der mickrige Upstream, die Spaßbremse. Ich würde jedenfalls erheblich schlechtere Performance erwarten als auf dem SQL-Server meines Webhosters.

Ok, ein quick&dirty eingebautes

db.setConnectOptions("MYSQL_OPT_RECONNECT=1");

funktioniert bei mir soweit. Die Verbindung zum quengeligen MySQL-Server bleibt bestehen (bzw. wird im Hintergrund reconnected), die MariaDB auf dem NAS ist auch noch ansprechbar, der debug output in der Konsole ist erfreulich fehlerfrei. Wenn ich das jetzt noch irgendwie nach Windows gezaubert bekomme, bin ich happy

Hmm. Ich bin nicht sicher, ob das die geschickteste Lösung ist. Quick&dirty funktioniert's in meinem spezifischen Environment. Datenbankserver lassen sich aber auf die wildesten Arten konfigurieren, weshalb setConnectOptions() ja ein gutes Dutzend Parameter zulässt allein schon für MySQL-Verbindungen.

Sicherlich ein Stecken mehr Arbeit, aber die einfachste und flexibelste Lösung wäre vielleicht, im Setup-Dialog der Datenbank ein zusätzliches Textfeld "Optionale Verbindungsparameter" anzubieten, den eingegebenen String a. in der Config spezifisch für diese Datenbank zu speichern und b. wenn nicht leer per db.setConnectOptions() abzufeuern. Wer mit Datenbanken arbeitet, sollte das hinkriegen, sich die richtigen Parameter selber herauszusuchen, denke ich.

Aber ist natürlich Deine Entscheidung. Für mich und mein Szenario funktioniert der PR auch so, wie Du ihn jetzt geschrieben hast

Kurz noch ergänzt: Als Bug würde ich's nicht unbedingt bezeichnen, da lässt sich aber trefflich streiten. Grundsätzlich funktioniert der Connect zu MySQL ja, nur nicht mit jeder denkbaren Serverkonfiguration.

Stichwort Bug: Das vor ein paar Stunden eingetragene Issue mit MySQL kann ich nicht nachvollziehen. Egal ob ich komplette Phantasiedaten eingebe zu einer nicht existenten Datenbank oder User/Passwort bei einer existierenden Datenbank falsch schreibe, QMapShack fängt den Fehler sauber ab, zeigt die eingerichtete DB als nicht verbunden und schreibt ins Log

Zitat

[debug] failed to open database QSqlError("1045", "QMYSQL: Es kann keine Verbindung aufgebaut werden", "Access denied for user xxx")

oder

Zitat

[debug] failed to open database QSqlError("1049", "QMYSQL: Es kann keine Verbindung aufgebaut werden", "Unknown database xxx")

oder

Zitat

[debug] failed to open database QSqlError("2005", "QMYSQL: Es kann keine Verbindung aufgebaut werden", "Unknown MySQL server host xxx")

Was allerdings stört an dieser Stelle: Wenn ich mich tatsächlich mal vertippt hab', kann ich die Verbindungseinstellungen nicht editieren. Wenn ich nichts übersehe, bleibt mir nur die Option, die Datenbank komplett neu einzurichten in QMapShack und den ersten Versuch zu löschen (oder in der Registry zu popeln). Das wäre insbesondere lästig, wenn ich im Nachhinein feststelle, ich muss mit den ConnectOptions herumspielen für eine verlässlich stabile Verbindung...

Jupp, unter Windows 10 Build 2004 getestet, also genau in der Umgebung, die der Ersteller angegeben hat; Linux ist bei mir mehr so eine Feierabend- und Wochenendgeschichte.

Was ich nicht getestet hab': Der Fehler könnte evtl. auftreten bei Verwendung einer falschen qsqlmysql.dll. Ihr liefert im Setup-Paket für Windows ja keine mit, der User muss sich die Bibliothek passend für QT 5.12.8 selber suchen.

Ich hab's mal offiziell eingetütet in der oben vorgeschlagenen Form mit Texteingabefeld etc. als "Enhancement". Auf die Art kommt vielleicht noch etwas Feedback von anderen MySQL-Nutzern mit womöglich geschickteren Vorschlägen.