nepixl
Goto Top

MySQL: autoincrement resettet sich nach Serverneustart

Hallo Gentlemen,

habe einen kleinen VPS angemietet um dort ein wenig die eigenen Ideen umzusetzen.

Auf der virtuellen Möhre läuft:
mysql  Ver 14.14 auf nem Ubuntu 16.04.1 Core

Nun zum Problem:
Seit geraumer Zeit (kämpfe bereits etwas länger mit meinem Problemchen, konnte es aber erst vor Kurzem so richtig reproduzieren) habe ich das Problem, das eine spezielle Tabelle in einer Datenbank (und nur die) den autoincrement Wert komplett resettet nach einem neustart des Servers.

Sprich:
Vor einem Neustart:
id = 1337
Nach einem Neustart:
id = 1

Das zerbröselt mir natürlich permanent weitere Queries.
Zugegeben: an dem SQL Server wurde bereits auch schon einiges rumgemurkst und z.B. den Strict Mode deaktiviert (Formatiert ihn!), jedoch läuft die Kiste an sich sonst ziemlich stabil und macht abgesehen von dem obigen Problem, was ich möchte.
Ein 'Neuaufsetzen' würde ich vorerst gerne vermeiden.

Tante Google wurde bereits penetriert jedoch nur mit mäßigem Erfolg. Einige ältere Einträge besagen, es sei ein "known Bug" .. aber damit möchte ich mich nicht abfrühstücken lassen, eine zielführende Lösung fand ich allerdings keine.

Anbei ein describe(Daten z.T. abgeändert) der betroffenen Tabelle:
+------------+-----------------------------------+------+-----+---------+----------------+
| Field      | Type                              | Null | Key | Default | Extra          |
+------------+-----------------------------------+------+-----+---------+----------------+
| id         | int(10) unsigned                  | NO   | PRI | NULL    | auto_increment |
| user_id    | bigint(20)                        | YES  | MUL | NULL    |                |
| asdf       | varchar(20)                       | YES  |     | NULL    |                |
| first_seen | datetime                          | YES  |     | NULL    |                |
| start_time | datetime                          | YES  |     | NULL    |                |
| end_time   | datetime                          | YES  | MUL | NULL    |                |
| timezone   | char(30)                          | YES  |     | NULL    |                |
| asdf2      | enum('a','b','c')                 | YES  |     | NULL    |                |  
| asdf3      | int(10) unsigned                  | NO   |     | NULL    |                |
+------------+-----------------------------------+------+-----+---------+----------------+

Falls Ihr weitere Informationen benötigt lasst es mich wissen, gerne liefe ich die Daten nach.

Interessant ist: dass weitere 14 Datenbanken auf diesem Server dieses Verhalten nicht vorweisen...
Kennt wer von Euch dieses Verhalten und hat evtl. sogar ein Workaround? (Abgesehen vom Srv neu aufsetzen :D)

Bin für jeden Ansatz dankbar da ich derzeit meine Tabellen selbst resetten muss, damit mir das ganze Kalkül nicht explodiert.

Beste Grüße und ein schönes Wochenende,
pixl

Edita: Cronjobs und Events sind keine angelegt was dieses Verhalten hervorrufen würde.

Content-ID: 399514

Url: https://administrator.de/contentid/399514

Ausgedruckt am: 24.11.2024 um 18:11 Uhr

certifiedit.net
certifiedit.net 26.01.2019 um 11:30:09 Uhr
Goto Top
Ich vermute, nicht deine DB hat das Problem, sondern deine Tabelle und oder dein Code sind, Zitat, rumgemurkst

Kümmer dich darum, damit sollte sich das Problem erledigen.
LordGurke
Lösung LordGurke 26.01.2019 um 13:58:53 Uhr
Goto Top
Mach mal in SHOW CREATE TABLE auf die Tabelle, vielleicht steht da was sinnvolles drin.

Habt ihr auch mal ein REPAIR TABLE nach einem Serverneustart gemacht?

Theoretisch kann das passieren, wenn es sich um eine MyISAM-Tabelle handelt und die zur Tabelle gehörende .frm-Datei nicht von MySQL geschrieben werden kann.
Dann sollte aber auch eigentlich spätestens der REPAIR dieses Problem ans Licht holen.
nepixl
nepixl 26.01.2019 um 15:04:08 Uhr
Goto Top
Zitat von @certifiedit.net:

Ich vermute, nicht deine DB hat das Problem, sondern deine Tabelle und oder dein Code sind, Zitat, rumgemurkst

Kümmer dich darum, damit sollte sich das Problem erledigen.
Hi Christian,

denke nicht, dass es am Code liegt. Habe dem Code(User) zum Test mal die DB Rechte entzogen => Gleiches Verhalten.

Kümmer dich darum, damit sollte sich das Problem erledigen.
Tipp des Tages....

Danke und Gruß
nepixl
nepixl 26.01.2019 um 15:06:29 Uhr
Goto Top
Zitat von @LordGurke:

Hi LordGurke,

Zugegeben: auf 'REPAIR TABLE' kam ich bisher nicht. :facepalm: - vielen Dank für den Anstoß.

Theoretisch kann das passieren, wenn es sich um eine MyISAM-Tabelle handelt und die zur Tabelle gehörende .frm-Datei nicht von MySQL geschrieben werden kann.

Das hört sich nach einer guten Idee an! Werde ich sobald ich wieder an meiner Kiste bin umgehend probieren und Dir/Euch Feedback leisten.

Besten Dank, Gentlemen.

Gruß
pixl