hi ih hab letzte Woche ein SQL Backup einer Datenbank mittels dbForge erstellt und wollte es nun auf einem neuen System wieder einspielen. dbForge schließt den Vorgang nach einigen Minuten fehlerfrei ab und ich kann die DB sehen mit 2 Mio. Einträgen. Wenn ich sie öffne scheint aber kein einziger Eintrag auf. Im Hintergrund scheint MariaDB die Datenbank zu löschen. Jedesmal wenn ich den Aktualisiert Button klicke, verringern sich die angeblichen Einträge bis schlussendlich 0 dort steht. Weiß jemand was hier passiert?
Ich hab zwar keine Ahnung von MariaDB, aber ich frage mich wieso man die Datenbankdatei nicht einfach normal kopiert als Backup. Weil bisher mache ich das mit JEDER Datenbank der letzten 35 Jahre so. Inkl. SQL und hatte noch nie Problem die wieder ans laufen zu bringen. @TO Vielleicht hast du die "alte" Datei ja noch in einen andere Backup. Ich würde sie da raus holen und einfach gegen den Mist da ersetzen. Und schau dir die Datei mal HEX an. Vielleicht erkennst du da ne Logik. Klingen tut deine Beschreibung so, als wenn das System eine Reorganisation durchführt und dabei alles was es als Schrott sieht löscht. Dazu reicht schon ein falsches Lösch-Bit/Bytes im Datensatz.
Gandalf schrieb: > ih hab letzte Woche ein SQL Backup einer Datenbank mittels dbForge > erstellt und wollte es nun auf einem neuen System wieder einspielen. Was für eine Art von Datei erstellt denn dieses Wunderding? > dbForge schließt den Vorgang nach einigen Minuten fehlerfrei ab und ich > kann die DB sehen mit 2 Mio. Einträgen. Wenn ich sie öffne scheint aber > kein einziger Eintrag auf. > > Im Hintergrund scheint MariaDB die Datenbank zu löschen. Jedesmal wenn > ich den Aktualisiert Button klicke, verringern sich die angeblichen > Einträge bis schlussendlich 0 dort steht. > > Weiß jemand was hier passiert? Anscheinend etwas sehr, sehr Merkwürdiges. Wenn Du noch auf die alte Datenbank zugreifen kannst, würde ich Dir zunächst empfehlen, ein Backup mit einem der Programme mysqldump oder mysqlpump zu erzeugen. Beide Programme gehören meines Wissens zu dem Lieferumfang von MySQL, ebenso wie das Programm mysqlimport, mit dem Du Deine Datenbank wiederherstellen kannst. Die Dokumentation zu diesen Programmen findest Du unten verlinkt. Ansonsten möchte ich Dir freundlich empfehlen, von Ratschlägen unseres Mitforisten "Schlaumaier" Abstand zu halten. Dieser Herr ist leider dafür bekannt, das sein Mitteilungsbedürfnis seine Kenntnisse übersteigt. [1] https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html [2] https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html [3] https://dev.mysql.com/doc/refman/8.0/en/mysqlimport.html
Der manuelle Zugriff und das Handling geschieht ueber phpMyAdmin ? Man kann sich das Backup ja mal ansehen, dort stehen SQL commands drin. Steht da am ende allenfalls ein drop * ?
Schlaumaier schrieb: > Ich hab zwar keine Ahnung von MariaDB, aber ich frage mich wieso man die > Datenbankdatei nicht einfach normal kopiert als Backup. Weil das Dateiformat häufig geändert wird, so dass die Dateien zu einer anderen Programmversion inkompatibel sind. Auch ein Wechsel des Betriebssystems (Linux/Windows) macht die Datenbank Dateien häufig (nicht immer) unlesbar. Datenbanken sichert man normalerweise in einem von Menschen und Maschinen lesbarem Textformat. Bei MariaDB sind das SQL Scripte mit CREATE und INSERT Kommandos.
Kann es sein, dass da autocommit aus ist, und am ende des Backup Script kein COMMIT steht? Oder gibt es eventuell irgend welche foreign keys, die Kaskadierend die zeug löschen, und alle Eintröge hängen mit solchen zusammen, und einer wird gelöscht? Oder ist vielleicht die SD Karte oder worauf auch immer es gespeichert ist kaputt, und schreibt die Änderungen nicht mehr, sagt es dem OS aber nicht? Vermutlich gibt es noch mehr mögliche Ursachen.
Steve van de Grens schrieb: > Datenbanken sichert man normalerweise in einem von Menschen und > Maschinen lesbarem Textformat. Bei MariaDB sind das SQL Scripte mit > CREATE und INSERT Kommandos. Besser noch: bei MariaDB ist ein Tool namens „mysqldump” dabei, mit dem man seine Datenbanken so sichern kann, dass diese Scripte rausfallen, die man anschließend direkt mittels „mysql“ wieder einlesen kann.
:
Bearbeitet durch User
DPA schrieb: > Kann es sein, dass da autocommit aus ist, und am ende des Backup Script > kein COMMIT steht? Wären die Einträge denn dann während des Einspielens überhaupt schon sichtbar? Zumal für eine andere Session, Stichwort MVCC?
Gandalf schrieb: > > ih hab letzte Woche ein SQL Backup einer Datenbank mittels dbForge > erstellt und wollte es nun auf einem neuen System wieder einspielen. dbForge? Dieses GUI-Spielzeug? Warum nimmst du nicht mysqldump (bzw. mariadb-dump, wenn du schon auf MariaDB bist)? > dbForge schließt den Vorgang nach einigen Minuten fehlerfrei ab und ich > kann die DB sehen mit 2 Mio. Einträgen. Wenn ich sie öffne scheint aber > kein einziger Eintrag auf. Bahnhof. > Im Hintergrund scheint MariaDB die Datenbank zu löschen. Sicher nicht. > Weiß jemand was hier passiert? Ich weiß ja noch nicht mal, was du gemacht hast. Und erwartest, was passieren soll.
1 | # alle Datenbanken in Dumpfile sichern |
2 | $ mariadb-dump --all-databases --result-file=/pfad/zum/dumpfile --host=xxx --user=yyy --password=zzz |
3 | |
4 | # Daten aus Dumpfile wieder herstellen |
5 | $ mariadb --host=xxx --user=yyy --password=zzz < /pfad/zum/dumpfile |
Das ist alles was man für Backup/Restore wissen muß. Zumindest wenn es so eine Winz-DB mit gerade mal 2 mio Rows ist. Das geht auch über das Netz (dann ersparst du dir, das Dumpfile von A nach B zu kopieren). Schlaumaier schrieb: > Ich hab zwar keine Ahnung von MariaDB, aber ich frage mich wieso man die > Datenbankdatei nicht einfach normal kopiert als Backup. Weil das bei einem laufenden Server nicht geht. Wenn man den Server herunter gefahren hat, dann geht auch das. Allerdings nur mit der gleichen Konfiguration (my.cnf). Und der Zielserver muß die gleiche oder eine neuere Version haben als der Quellserver. Und natürlich für das Einspielen des Backups auch herunter gefahren sein. Steve van de Grens schrieb: >> Ich hab zwar keine Ahnung von MariaDB, aber ich frage mich wieso man die >> Datenbankdatei nicht einfach normal kopiert als Backup. > > Weil das Dateiformat häufig geändert wird, so dass die Dateien zu einer > anderen Programmversion inkompatibel sind. Auch ein Wechsel des > Betriebssystems (Linux/Windows) macht die Datenbank Dateien häufig > (nicht immer) unlesbar. Quatsch mit Soße. Das Datenformat ist betriebssystemunabhängig (auch architekturunabhängig). Und spezifisch bei MariaDB kann ein neuerer Server immer auch die Daten einen älteren Servers lesen. MySQL garantiert das nur für das nächste Major-Release. DPA schrieb: > Kann es sein, dass da autocommit aus ist, und am ende des Backup Script > kein COMMIT steht? Auch albern. Wenn das Backup-Programm Transaktionen ins Backupfile schreibt, dann ist es auch dafür verantwortlich, die mit COMMIT abzuschließen. Aber standardmäßig werden multi-row INSERT Statements ins Backupfile geschrieben. Zumindest von mysqldump. Die sind auf allen Storage-Engines schnell (auch InnoDB mit Auto-Commit).
Schlaumaier schrieb: > Ich hab zwar keine Ahnung Stimmt soweit.. Gandalf schrieb: > Im Hintergrund scheint MariaDB die Datenbank zu löschen. Wohl kaum, jedenfalls nicht ohne die Anweisung bekommen zu haben dies zu tun. Läuft ein Prozess im Hintergrund, macht das dbForge Unsinn. Die DB macht das wohl kaum von selbst.
Axel S. schrieb: > DPA schrieb: >> Kann es sein, dass da autocommit aus ist, und am ende des Backup Script >> kein COMMIT steht? > > Auch albern. Wenn das Backup-Programm Transaktionen ins Backupfile > schreibt, dann ist es auch dafür verantwortlich, die mit COMMIT > abzuschließen. Wenn in der DB Autocommit ausgeschaltet ist, muss man am Ende ein Commit absetzen, auch wenn man nicht explizit eine Transaktion gestartet hat. Ja, das kann man global in der DB Config so einstellen. Und wenn man das gemacht hat, und am ende kein COMMIT macht, dann gibts einen rollback, auch wenn man vorher keine Transaktion explizit gestartet hat. Und das würde natürlich genau dann passieren, wenn im backup file keine Transaktionen sind.
DPA schrieb: > Axel S. schrieb: >> DPA schrieb: >>> Kann es sein, dass da autocommit aus ist, und am ende des Backup Script >>> kein COMMIT steht? >> >> Auch albern. Wenn das Backup-Programm Transaktionen ins Backupfile >> schreibt, dann ist es auch dafür verantwortlich, die mit COMMIT >> abzuschließen. > > Wenn in der DB Autocommit ausgeschaltet ist, muss man am Ende ein Commit > absetzen, auch wenn man nicht explizit eine Transaktion gestartet hat. Wie gesagt, wenn das Backup-Programm nicht gerade von einem absoluten Neuling verbrochen wurde (was ich mir angesichts des sonstigen Aufwands für dbForge nicht vorstellen kann) dann überschreibt es als eine der ersten Aktionen im Backupskript (sofern es ein solches überhaupt erzeugt) die AUTOCOMMIT Server-Variable. mariadb-dump (und mysqldump) streuen überdies noch SQL-Statements ein, die ein implizites COMMIT erzwingen. Z.B. ALTER TABLE. Und - als wäre das nicht genug - kann man die restored-ten Rows von einer anderen Session ohnehin nur sehen, wenn TRANSACTION_ISOLATION auf READ-UNCOMMITTED gesetzt ist. Auch nicht Standard. Aber das sind alles nur Spekulationen. Ich weiß nicht, was dbForge bei einem Backup überhaupt macht. Wie schon gesagt: wenn der TO unbedingt dbForge verwenden will, dann sollte er da nachfragen. Vielleicht ist es ja tatsächlich ein Bug.
hi sorry, war für ein paar Tage außer Gefecht das SQL sieht folgendermaßen aus
1 | -- phpMyAdmin SQL Dump |
2 | -- version 4.9.7 |
3 | -- https://www.phpmyadmin.net/ |
4 | -- |
5 | -- Host: localhost |
6 | -- Generation Time: Nov 19, 2022 at 07:26 PM |
7 | -- Server version: 10.3.32-MariaDB |
8 | -- PHP Version: 7.4.30 |
9 | |
10 | SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; |
11 | SET AUTOCOMMIT = 0; |
12 | START TRANSACTION; |
13 | SET time_zone = "+00:00"; |
14 | |
15 | |
16 | /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; |
17 | /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; |
18 | /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; |
19 | /*!40101 SET NAMES utf8mb4 */; |
20 | |
21 | -- |
22 | -- Database: `MyData_db` |
23 | -- |
24 | |
25 | -- -------------------------------------------------------- |
26 | |
27 | -- |
28 | -- Table structure for table `my_table` |
29 | -- |
30 | |
31 | CREATE TABLE `my_table` ( |
32 | `mobilenumber` bigint(20) DEFAULT NULL, |
33 | `firstname` varchar(500) DEFAULT NULL, |
34 | `lastname` varchar(500) DEFAULT NULL, |
35 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8; |
36 | |
37 | -- |
38 | -- Dumping data for table `my_table` |
39 | -- |
40 | |
41 | INSERT INTO `my_table` (`mobilenumber`, `firstname`, `lastname`) VALUES |
42 | (123456781, 'Max', 'Mustermann') |
43 | (987654321, 'Maria', 'Musterfrau') |
44 | ... |
45 | ... |
Gandalf schrieb: > das SQL sieht folgendermaßen aus > 1-- phpMyAdmin SQL Dump > 2-- version 4.9.7 > 3-- https://www.phpmyadmin.net/ > 4-- > 5-- Host: localhost > 6-- Generation Time: Nov 19, 2022 at 07:26 PM > 7-- Server version: 10.3.32-MariaDB > 8-- PHP Version: 7.4.30 > 9 > 10 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; > 11 SET AUTOCOMMIT = 0; > 12 START TRANSACTION; Hier wird eine Transaktion gestartet. Und vorher AUTO-COMMIT explizit abgeschaltet. > 13 SET time_zone = "+00:00"; > 14 > 15 > 16/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; > 17/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; > 18/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; > 19/*!40101 SET NAMES utf8mb4 */; > 20 > 21-- > 22-- Database: `MyData_db` > 23-- ... Jetzt wäre interessant, ob da am Ende noch eine Zeile mit COMMIT kommt. Also eigentlich eher nach den Daten für eine Tabelle. Und auch sonst spätestens alle 1000 Rows (ca.) Aber nachdem das ein phpMyAdmin Dump ist, habe ich keine Zweifel, daß die das richtig hinbekommen.
Axel S. schrieb: > Jetzt wäre interessant, ob da am Ende noch eine Zeile mit COMMIT kommt. > Also eigentlich eher nach den Daten für eine Tabelle. Und auch sonst > spätestens alle 1000 Rows (ca.) nein, nach dem letzten Eintrag kommt nix weiteres. >> 10 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; >> 11 SET AUTOCOMMIT = 0; >> 12 START TRANSACTION; > > Hier wird eine Transaktion gestartet. Und vorher AUTO-COMMIT explizit > abgeschaltet. könnte ich das autom commit nicht einfach auf 1 setzen?
Gandalf schrieb: > hi > sorry, war für ein paar Tage außer Gefecht > das SQL sieht folgendermaßen aus > -- phpMyAdmin SQL Dump Wie, jetzt ein phpMyAdmin Dump? Ich dachte es geht um dbForge? Wenn der Restore über PHP läuft können die Server Einstellungen, z.Bsp. max_execution_time das Problem verursachen. Das Script bricht wegen Überschreitung der Zeit ab und somit der abschließende Commit nicht ausgeführt. Nicht alle Fehler werden von der Anwendung abgefangen und angezeigt.
Kleiner Tipp: utf8 unterstützt nur einen kleinen Teil des Zeichensatzes. Für Leute aus dem Balkan reicht es schon nicht. utf8mb4 tut hingegen das, was man so allgemein erwartet (alle Zeichen unterstützen).
Steve van de Grens schrieb: > Kleiner Tipp: utf8 unterstützt nur einen kleinen Teil des Zeichensatzes. Das hab ich schon immer bescheuert gefunden, was mysql da macht. Entweder eine Anwendung macht UTF-8, oder es macht sonst was (UCS-2, UTF-16, UTF-32, etc.). Sowas wie 2 byte per Zeichen UTF-8 oder 4 byte per Zeichen UTF-8 gibt es nicht, das ist einfach kein UTF-8 mehr. Und einen Grund, solchen scheiss zu machen gibt es auch nicht. Nicht-lokalisierte Sortierung usw. ist da bei UTF-8, UTF-16be, etc. genau gleich. Und auch sonst kann man UTF-8 eigentlich immer wie eine erweiterte ASCII Codiereung behandeln...
Gandalf schrieb: > Axel S. schrieb: >> Jetzt wäre interessant, ob da am Ende noch eine Zeile mit COMMIT kommt. >> Also eigentlich eher nach den Daten für eine Tabelle. Und auch sonst >> spätestens alle 1000 Rows (ca.) > > nein, nach dem letzten Eintrag kommt nix weiteres. Wenn da nirgends "COMMIT;" drinn steht, hoffentlich ist der Dump dann überhaupt vollständig... Naja, versuch mal gaanz am Ende, eine Zeile mit dem Inhalt
1 | COMMIT; |
hinzuzufügen, und schau ob das hilft.
DPA schrieb: > solchen scheiss zu machen gibt es auch nicht. Unser Job wäre doch langweilig, wenn es nicht solche gemeinen Fallstricke gäbe.
Steve van de Grens schrieb: > Kleiner Tipp: utf8 unterstützt nur einen kleinen Teil des > Zeichensatzes. > Für Leute aus dem Balkan reicht es schon nicht. utf8mb4 tut hingegen > das, was man so allgemein erwartet (alle Zeichen unterstützen). Ach! Und was meinst du was die Zeile > 19/*!40101 SET NAMES utf8mb4 */; bewirkt? Ist die nur zum Spaß da? DPA schrieb: > Das hab ich schon immer bescheuert gefunden, was mysql da macht. Seit MySQL 8.0.x (bin zu faul, x nachzuschlagen) ist "utf8" ein Synonym für "utf8mb4". Das alte Verhalten (nur Zeichen aus der BMP, aka mit dem Codeverrat U+0001 bis U+FFFF) erreicht man mit "utf8mb3". MySQLs Beschränkung von UTF8 auf die BMP (basic multilingual plane aka Unicode < 2.0) sollte für alle europäischen Sprachen ausreichen. OK, Klingonisch ist nicht dabei. Der häufigste genannte Grund warum man Unicode abseits der BMP brauchen sollte sind nativ codierte (also nicht als ASCII-Art dargestellte) Emojis. Mir kommen gleich die Tränen ;-)
:
Bearbeitet durch User
Axel S. schrieb: > Ach! Und was meinst du was die Zeile >> 19/*!40101 SET NAMES utf8mb4 */; > bewirkt? Ist die nur zum Spaß da? Das ist eine Session Variable. Mir ging es um die Spezifikation der Tabellenstruktur, die letztendlich bestimmt, was die Tabelle speichern kann: Gandalf schrieb: > -- Table structure for table `my_table` > -- > CREATE TABLE `my_table` ( > `mobilenumber` bigint(20) DEFAULT NULL, > `firstname` varchar(500) DEFAULT NULL, > `lastname` varchar(500) DEFAULT NULL, > ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Axel S. schrieb: > Seit MySQL 8.0.x (bin zu faul, x nachzuschlagen) ist "utf8" ein Synonym > für "utf8mb4". Ich habe mal nachgeschlagen. Kann es sein, dass du dich falsch erinnerst?: "utf8: An alias for utf8mb3. In MySQL 8.0, this alias is deprecated; use utf8mb4 instead. utf8 is expected in a future release to become an alias for utf8mb4." https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html In MariaDB: "From MariaDB 10.6.1, the main name of the previous 3 byte utf character set has been changed to utf8mb3. If (old mode is) set, the default, utf8 is an alias for utf8mb3. If not set, utf8 would be an alias for utf8mb4." https://mariadb.com/kb/en/old-mode/ Gandalf schrieb: > -- Server version: 10.3.32-MariaDB Bei ihm hat utf8 also nicht den vollen Umfang, wie ich schon schrieb. Axel S. schrieb: > MySQLs Beschränkung von UTF8 auf die BMP (basic multilingual plane aka > Unicode < 2.0) sollte für alle europäischen Sprachen ausreichen. Wie gesagt sind wir in Zusammenhang mit Ländern auf dem Balkan auf Probleme gestoßen.
MariaDB darf man nur per Mariacron starten kann, wenn die Flasche leer ist verweigert Mariacron den Dienst.
Steve van de Grens schrieb: > Bei ihm hat utf8 also nicht den vollen Umfang, wie ich schon schrieb. Und was hat das mit dem Problem des TO zu tun?
Jens G. schrieb: > Und was hat das mit dem Problem des TO zu tun? Nichts, habe ich auch nicht behauptet. Es war nur ein Verbesserungsvorschlag ("Kleiner Tipp"). Eine große Sache wurde darauf, weil andere dem falsch widersprochen haben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.