MySQL - backup/restore führt zu Duplicate Entry Bug

  • Hintergrund: als ich die V 8.1 ausprobierte, stolperte ich über einige Bugs, die Kai zwischenzeitlich zügig korrigiert hat. Ich mußte aber zunächst wieder auf V 7.2 zurückgreifen und spielte die gesicherte Datenbank mit MySQL-Administrator wieder zurück. V 7.2 lief, viele Abfragen auch. Bis auf eine.


    Ich bekomme jetzt folgende Fehlermeldung:


    #23000DuplicateEntry '4D71...' for key 'group_key'


    Das Interessante ist, dass der Fehler auch schon in V 7.2 passiert, also nichts mit dem Upgrade auf V 8.1 zu tun hat. Ich habe ihn nur noch nie erlebt, weil ich bislang noch nie eine Datenbank zurückspielen mußte. D.h. beim Zurückspielen muss irgendetwas verändert worden sein, was zu diesem Fehler führt. Dabei ist die 32byte VARCHAR sicher nicht doppelt vorkommend. Zumal dies - wenn ich mit der Datenbank weitergearbeitet habe - regelmäßig mit anderen Entries (VARCHAR(32)) auftritt, die unmöglich alle doppelt vorkommen können.


    Ich vermute also, irgendwelche Tabelleneigenschaften wurden beim Zurückspielen stillschweigend mit MySQL-Administrator geändert. Aber welche könnten das sein?


    Weiss Kai vielleicht auch, wo der key "group_key" herkommt, den finde ich nämlich nicht in den zig Tabellen von Imabas? Ich selbst habe diesen key-Namen auch nicht in meiner Abfrage definiert.


    Zu ergänzen ist, dass im Web der #23000DuplicateEntry-Error bei backup/restore immer wieder beschrieben wird und etwas zu tun haben könnte mit dem Zeichensatz (UTF8 ). Er wurde auch beschrieben bei auto-increment Feldern, die eigentlich auch keine duplicate entries haben dürften. Zudem sind die ukey's von Kai keine Auto-Increments.
    Hier aber dürfte weder der Zeichersatz eine Rolle spielen, da es sich um eine 32byte Varchar handelt (also einen "ukey"), noch dürfte es sich um eine "wirkliche" Kollision handeln, weil die identische Abfrage (Query) vor der backup-restore-Prozedur via MySQL-Administrator stets problemlos lief.


    Was hat MySQL-Administrator verbrochen? Hat jemand oder Kai eine Idee?


    -Mino


    ps: Meinen Query-String möchte ich den Lesern hier ersparen, sende ich bei Bedarf aber mit PM gern zu.

  • Hallo Mino,


    ich habe das Thema mal hier hin geschoben, sehe darin keinen Bug in Imabas :-)


    Das Problem kann auftauchen wenn man nicht vorher alle Tabellen löscht, dann hält das Backup die Tabellen bei und hängt die neuen Daten rein und bumm :-?


    Tipp: Ich würde mir erstmal eine neue Datenbank anlegen und dann eine Wiederherstellung in dem neuen Datenbankschema machen, da sollte es eigentlich klappen.


    Denn wie du schon schriebst kann ja im Backup kein doppelter Eintrag drin sein, es handelt sich dabei schließlich um den Primärschlüssel. Und der doppelte Eintrag kann nur kommen wenn er versucht aus dem Backup heraus einen bestehenden Key dazuzufügen. Das sollte in der leeren Datenbank nicht auftreten.


    Das gleiche Problem war in diesem [thread=2074]Thread[/thread] auftreten...

  • Das sind ja schöne Aussichten. Ich habe natürlich fleißig weitergearbeitet mit den Tabellen. Wenn ich die Datenbank, die die Fehlermeldung bei Abfrage gibt, jetzt sichere und dann in eine "saubere" neue DB einspiele, habe ich doch nichts gewonnen, oder? Ich muß also die DB von V 7.2 wieder einspielen? Da sind also einige Tage Arbeit hin...


    Ist das wirklich so?


    Ich hatte natürlich nach dem Backup von V 7.2 und vor dem Restore meine Datenbank V 8.1 gelöscht mit dem MySQL-Administrator. Reicht das nicht? Sie war jedenfalls in der Schema-Liste nicht mehr sichtbar.


    Eine Suche nach duplicate entries dürfte wesentlich einfacher sein...


    Ich werde daher folgendes machen: eine der Sicherungen, die sicher noch funktionierten, werde ich zurückspielen in eine ganz neue DB mit anderem Namen und dann die Query testen. Ich berichte dann erneut.


    -Mino

  • Ergänzung zum Posting von vorhin:


    Ich habe die aktuellen drei Tabellen, in denen ich die Abfrage durchführe, die zum #23000DuplicateEntry-Error führt, auf duplicate entries im ukey überprüft mit


    Select count(*)
    From bilder // [auch überprüft: attrobjgroups, attrobjdata]
    Group by ukey
    HAVING COUNT(*)>1;


    Keine DuplicateEntries zu finden. Das Argument, dass durch fehlendes Löschen zusätzliche doppelte Datensätze beim Restore entstanden sind, gilt also (leider) nicht.


    -Mino

  • Ergänzung 2: MySQL-Update 5.0.14-nt -> 5.1.49 ist ursächlich für #23000Duplicate-Entry-Exception fuer key "group_key".


    Da ich wirklich ein Restore durchgeführt habe, ohne eine bestehende DB zu überschreiben, trifft der von Kai genannte Thread hier nicht zu. Ich erinnerte mich, dass ich vor ein bis zwei Wochen auch mein NAS (Synology DiskStation) aktualisierte mit dem DSM 3.0. Dort erfolgte auch ein Update der dort laufenden MySQL-Version.
    In mir schwante also, dass weder Kai (nie nicht!), noch Imabas 8.1 "Schuld" an dem DuplicateEntry-Schock sind, sondern vielleicht MySQL?!


    Nichts einfacher zu testen als das! Ich sicherte die aktuelle Datenbank von Imabas 8.1 (MySQL 5.1.49 auf DiskStation mit DSM 3.0) mit MySQL-Administrator und spielte sie mutig auf einen Rechner, der noch MySQL 5.0.14-nt laufen hat. Dort startete ich dann die Abfrage, die zu o.g. Exception führte: und jetzt sie läuft erfolgreich durch! (Sie braucht übrigens mehrere Stunden, wenn der Rechner nur 500 MB RAM hat.)


    Interpretation: entweder MySQL hat einen Bug bei seinen "group_key"s eingeführt, oder MySQL wurde verbessert und findet einen Fehler in meinem Query-String (was natürlich gar nicht nie nicht sein kann... grins).


    Fazit: Komplexe Abfragen (mit GROUP BY und HAVING und COUNT) können nach einem MySQL-Upgrade von 5.0.14-nt auf 5.1.49 zu einem Duplicate-Enry Error #23000 error für den key "group_key" führen. Dabei erstellt MySQL vermutlich eine temporäre Tabelle, in der die Goups einen Group_Key erhalten. Denn weder ich (in meiner Query) noch Kai (in den Imabas-Tabellen) haben einen Key / ein Feld "group_key" definiert.
    Denkbar ist, das bei Bereichsbegrenzungen des group_key Probleme bei Gigabyte-großen Tabellen eingeführt wurden. Es könnte passieren, dass weitere Imabas-Power-User auf diesen Error stoßen.


    Konsequenz: Hier liegt ein MySQL-Problem vor, eingeführt durch ein Versionsupdate.
    Ich werde versuchen, meine Query zu ändern. Zu meiner Freude kann ich erst mal ohne die befürchtete Neueingabe von Datensätzen in eine saubere DB locker mit V 8.1 weiterarbeiten. Ob ich mich in die MySQL-Foren reintraue, möchte ich allerdings bezweifeln... ;-)


    -Mino