MariaDB Datenbank löscht sich von selbst

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.

Oder gibt es einen Trigger, der Amok läuft?

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?

Warum fragst du nicht dbForge?

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.

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

...

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.

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.

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.