[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]