[HeidiSQL] Wie ist der DB-Export implementiert?

[Medium]

Ich habe hier 2 gegenseitig redundante MariaDBs als jeweiliges Backup zur anderen bei Hardwareausfällen etc. Wenn tatsächlich mal etwas passiert, habe ich das Problem, dass die DBs nicht mehr synchron sind, und man einige Handgriffe tätigen muss, um das wiederherzustellen. Unter anderem sollten beide DBs mit denselben Daten starten. Das habe ich bisher so gemacht, dass ich die Export-Funktion von HeidiSQL genutzt habe, was ja netterweise auch direkten DB->DB Export bietet.

Wie wird das dort gemacht? Gibt es in MySQL/MariaDB bereits einen Mechanismus dies komfortabel "machen zu lassen", oder klamüsert Heidi sich hier sämtliche CREATEs zusammen und doktort die INSERTs selbst? Ich hoffe natürlich auf ersteres, da ich gern ein kleines Tool bauen will, was diese "Resynchronisation" für mich vereinfacht.

[hhcm]

Zitat:

Zitat von Medium (Beitrag 1453025)

... dass ich die Export-Funktion von HeidiSQL genutzt habe, was ja netterweise auch direkten DB->DB Export bietet.

Wie wird das dort gemacht? ..

Schau doch nach. https://github.com/HeidiSQL/HeidiSQL

Bzw. Wenn du MyDAC nutzt, warum dann nicht TMyDump ? https://www.devart.com/mydac/docs/de...ac.tmydump.htm

[Medium]

Manchmal sollte man einfach mal genauer in seine Komponentenliste schauen! :D Das ist ja perfekt, danke dir!

[Codehunter]

Nur mal so aus Interesse: Wie hast du die Redundanz realisiert bei MariaDB? Die Replikation sollte doch automatisch für Synchronität sorgen. Das ist doch in der freien Version neben der MPL-lizensierten DLL der große Vorteil ggü. Mysql, dass du eine vollständige Replikation hast.

[Medium]

Eben genau über die Replikation. Die funktioniert genialerweise auch bidirektional, was genau das ist was ich brauchte.

Ich hatte in der Vergangenheit, als ich auf diese Lösung umgestellt habe, noch das Problem, dass 2 Instanzen meiner Programme versuchten in ihre jeweils lokale DB Instanz identische Datensätze zu schreiben, wodurch die Replikation aufgrund von Schlüsselkonflikten abbrach. Ich denke all diese doppelten Schreiboperationen jetzt raus zu haben, will aber dennoch zur Sicherheit gern eine Tool zur schnellen Wiederherstellung haben. Auch für den Fall, wenn eine Rekonstruktion aufgrund von Ausfällen nötig wird. Das binlog existiert nämlich nicht seit Anfang an, sodass ich daraus niemals ein full rebuild machen kann. (Zudem würde ich es gern auf 4-6 Monate purgen, da es sonst droht sehr groß zu werden.) Für den absoluten GAU gibt es natürlich noch nächtliche Komplett-Backups auf 2 anderen Rechnern in je 2 anderen Gebäuden, die zudem alle 2-3 Tage auch auf Band landen.

[Codehunter]

Sehr vorbildliche Verfügbarkeitslösung! :-D

Um der Vollständigkeit halber auf deine Eingangsfrage zurück zu kommen: Der Export bei HeidiSQL ist ohne externe Komponenten realisiert, alles selbst geschrieben. Das ist hier auch deshalb nötig, weil HeidiSQL (zumindest rudimentär) neben MariaDB und Mysql auch Postgres und SQL Server unterstützt.

[Medium]

Zitat:

Zitat von Codehunter (Beitrag 1453070)

Sehr vorbildliche Verfügbarkeitslösung! :-D

Ja, ein längerfristiger Ausfall der Produktionsanlage die da dran hängt wäre sehr teuer für unseren Kunden. Dort werden (mittlerweile) die Zwischenprodukte für nahezu alle weiteren Produktionsstätten hergestellt. Daher ist da jetzt alles doppelt, teils dreifach vorhanden. Die Replikation war der letzte Schritt da hin. Zudem auch Sicherheitsrisiko, da ohne das PC System Temperaturanstiege durch mögliche aber sehr unwahrscheinliche Spontanreaktion von Rohstoffen nicht zeitnah erkannt würden, und dann läuft alles von Lager-Flutung bis automatischem Großeinsatz der Feuerwehr an. Das möchte man scheinbar nur ungern :D

Zitat:

Um der Vollständigkeit halber auf deine Eingangsfrage zurück zu kommen: Der Export bei HeidiSQL ist ohne externe Komponenten realisiert, alles selbst geschrieben. Das ist hier auch deshalb nötig, weil HeidiSQL (zumindest rudimentär) neben MariaDB und Mysql auch Postgres und SQL Server unterstützt.

Ahh ok, das macht Sinn! Dann habe ich ja Glück, dass DevArt hier schon aktiv war. Ich habe auch keine Trigger oder SPs in dieser DB, und die Rechteverwaltung ist auch separat und sehr simpel. Noch habe ich es nicht ausprobiert, aber dem Anschein nach könnte das eine sehr gute Lösung sein, die wenig genug Aufwand für ein Internes unregelmäßig genutztes Tool erfordert. Wenn mich das mehr als 2-3 Tage kosten würde, wäre es nicht mehr zu rechtfertigen gewesen denke ich.

[Codehunter]

Zitat:

Zitat von Medium (Beitrag 1453083)

Zitat:

Zitat von Codehunter (Beitrag 1453070)

Sehr vorbildliche Verfügbarkeitslösung! :-D

Ja, ein längerfristiger Ausfall der Produktionsanlage die da dran hängt wäre sehr teuer für unseren Kunden. Dort werden (mittlerweile) die Zwischenprodukte für nahezu alle weiteren Produktionsstätten hergestellt. Daher ist da jetzt alles doppelt, teils dreifach vorhanden. Die Replikation war der letzte Schritt da hin. Zudem auch Sicherheitsrisiko, da ohne das PC System Temperaturanstiege durch mögliche aber sehr unwahrscheinliche Spontanreaktion von Rohstoffen nicht zeitnah erkannt würden, und dann läuft alles von Lager-Flutung bis automatischem Großeinsatz der Feuerwehr an. Das möchte man scheinbar nur ungern :D

Ich hoffe, bei alldem was da so geschäftskritisch an MariaDB hängt, dass es eine kleine Spende an die Foundation gab...

[Medium]

Die Installationen wurden von unserem Kunden gestellt. Ich werde ihn mal darauf hinweisen. Wir selbst nutzen es aber auch seither für ein paar kleinere Dinge, sodass wir da sicherlich auch mal ein Dankeschön da lassen könnten. Da hast du völlig Recht.

[p80286]

[OT]
Ist HeidiSQL so etwas ähnliches wie die Kröte?

Gruß
K-H
[/OT]

[Medium]

Ich fürchte ich weiß nicht, was du mit Kröte meinst :gruebel:

[p80286]

Entschuldige, Toad ist gemeint.

Gruß
K-H

[Medium]

Ich komme mir jetzt doppelt blöd vor, aber auch das hilf mir keinen Meter weiter :D

[mkinzler]

Toad ist ein Datenbank-Verwaltungswerkzeuge in der gehobenen Preiskategorie.

[Medium]

Ahhhh! Da DBs nicht im Kern unseres Hauptgeschäftsfelds liegen, bleiben mir solche Sphären weitestgehend verschlossen. Ich vermute mal, dass HeidiSQL im Vergleich dann mehr eine frisch geschlüpfte Kaulquappe ist :-D

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1453213)

..der gehobenen Preiskategorie.

Daher kommt auch der Ausdruck "..eine Kröte schlucken.."

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1453213)

Toad ist ein Datenbank-Verwaltungswerkzeuge in der gehobenen Preiskategorie.

Zitat:

Zitat von Medium (Beitrag 1453214)

Ahhhh! Da DBs nicht im Kern unseres Hauptgeschäftsfelds liegen, bleiben mir solche Sphären weitestgehend verschlossen. Ich vermute mal, dass HeidiSQL im Vergleich dann mehr eine frisch geschlüpfte Kaulquappe ist :-D

Hm. Ich kannte die Kröte bisher noch gar nicht. Hab jetzt nur mal die Produktseite für Toad Edge überflogen, was ja augenscheinlich das Äquivalent zu HeidiSQL darstellt. Also soooo dolle reißt mich das jetzt nicht vom Hocker. Mag sein, dass das bei den anderen Kröten besser aussieht aber was da für Mysql/MariaDB so geboten wird, das deckt HeidiSQL mehr als ab.

[jobo]

TOAD bietet Administrations- und Entwicklungsfunktionen für viele DB Systeme an. Dazu gehört dann bspw. auch eine Programmier- und Debugfunktion eines RDBMS, falls es das kann.
Ist schon "etwas" her, dass ich es genutzt habe, seit dem hat es sicher nichts an Funktionen eingebüßt.
Glaub mittlerweile gibt es vieles auch gestaffelt und abgespeckt nur für jeweils eine DB modular, in kreuz und quer, also auch Modelierung, Analyse, usw.
Ich würde sagen, als Vollversion eher Ochsenfrosch als Kröte.

[Medium]

Mh, da hast du Recht. Da kann ja die MySQL Workbench sogar 100x mehr. Wobei ich ~150€/a jetzt nicht "hochpreisig" finde. In Anbetracht des gebotenen im Vergleich zu den freien Tools aber trotzdem zu viel - zumindest dem Anschein den die Website vermittelt nach.

[Codehunter]

Zitat:

Zitat von jobo (Beitrag 1453234)

Ich würde sagen, als Vollversion eher Ochsenfrosch als Kröte.

Zitat:

Zitat von jobo (Beitrag 1453230)

Daher kommt auch der Ausdruck "..eine Kröte schlucken.."

Na dann: Mahlzeit :-D

EDIT: Sagen wir einfach: Für meinen Bedarf bei MariaDB reicht HeidiSQL vollkommen. Ich wäre dagegen froh, wenn HeidiSQL auch Firebird unterstützen würde. Denn was es da an freien Tools so gibt ist nicht unbedingt der Burner.

[jobo]

Also die Preise von Toad (nur) für Oracle gehen bis ca 11T Euro.

Und ja: Firebird Tools sind nicht der Hit.

[mkinzler]

HeideSQL ist ja in Delphi geschrieben und OS.

https://github.com/HeidiSQL/HeidiSQL

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1453242)

HeideSQL ist ja in Delphi geschrieben und OS.

https://github.com/HeidiSQL/HeidiSQL

Weiß ich weil ich auch schon Teile beigesteuert habe ^^ Aber um da Firebird zu integrieren ist die interne Struktur nicht flexibel genug und meine freie Zeit ebenso. Man müsste also eigentlich bei Null anfangen.

[HeZa]

Zitat:

Zitat von jobo (Beitrag 1453240)

Also die Preise von Toad (nur) für Oracle gehen bis ca 11T Euro.
Und ja: Firebird Tools sind nicht der Hit.

Bei meinem letzten Job habe ich SQL Workbench/J (http://www.sql-workbench.net/) sehr lieb gewonnen.

Ist OpenSource, in Java geschrieben, von einem deutschen Entwickler, der auch per eMail erreichbar war.
Unterstützt so ziemlich alles für das es einen entsprechenden JDBC-Treiber gib (bei uns war es MySQL, PostgreSQL, DB2, Firebird).

Was mir gefallen hat:

• mehrere SELECTS in einem Editierfenster mit Syntax-Highlighting und Code-Vervollständigung
  Mit der Möglichkeit ein SELECT, alle oder nur die selektierten auszuführen, jedes SELECT hat dabei ein eigenes Tab mit der Ergebnismenge.
• Eine DUMP-Funktion um schnell eine oder mehrere Tabellen zu kopieren
  Über DB-Grenzen hinweg auch zwischen DBs verschiedener Hersteller
• Gute Exportmöglichkeiten (Excel, CSV, Text etc)
• Gute Such- und Übersichtsfunktionen für Metadaten
• DB-Struktur Vergleich
• Tabellendaten Vergleich
• alles automatisierbar
• super Dokumentation
  Unbedingt lesen wenn man wirklich wissen will was das Tool alles kann (Jede Option beschrieben, Englisch)

Kostenlos kenne ich nichts besseres.
So dafür wollte ich immer schon mal Werbung machen, weil es das Projekt verdient hat. :-D

Ciao HeZa

[jobo]

Zitat:

Zitat von HeZa (Beitrag 1453307)

Zitat:

Zitat von jobo (Beitrag 1453240)

Und ja: Firebird Tools sind nicht der Hit.

Bei meinem letzten Job habe ich SQL Workbench/J (http://www.sql-workbench.net/) sehr lieb gewonnen.
...
Kostenlos kenne ich nichts besseres.
So dafür wollte ich immer schon mal Werbung machen, weil es das Projekt verdient hat.

Ich muss wohl meine Aussage zurücknehmen. Es gibt offenbare mehrere gute, Produkt-unspezifische Entwicklungsumgebungen, die dann "natürlich" auch für Firebird laufen. (In Anführungsstrichen, weil auch ein austauschbarer (Java) Treiber nicht allein die Besonderheiten einzelner Produkte abbildet).