AliCremerU333 0 Report post Posted November 10, 2003 Hallo, nachdem ich leider auch vom Bug in MySQL 4.0.15a bezüglich des plötzlichen "Verschwindens" von einzelnen Foren, Themen, Beiträgen, Mitgliedern, Gruppen, etc. betroffen bin, möchte ich hier mal für alle ebenfalls Betroffenen (z.B. diejenigen, die bei Puretec hosten lassen) meine Erfahrungen und einen kleinen Tip loswerden. Der Bug in MySQL 4.0.15a sorgt dafür, daß zufällig und ohne erkennbares Muster jeweils ein einzelner Eintrag einer (meist) stärker frequentierten Tabelle der Datenbank gelöscht wird. Es betrifft i.d.R. immer nur einen Eintrag (Zeile) und nicht ganze Tabellen. Der Fehler ist auch insofern schwer reproduzierbar, da er nur sporadisch und an nahezu beliebiger Stelle in der DB auftritt. Betroffen sind oftmals Tabellen, die sehr viele Zugriffe haben, da dort auch schon rein statistisch die Wahrscheinlichkeit aufgrund der höheren Zugriffszahl größer ist. Eine weitere Eingrenzung ist, daß der Bug wohl nur bei nicht transaktionssicheren Tabellentypen wie MyISAM auftritt. In meinem Board traten kurz nach der Umstellung der Puretec-MySQL-Server von MySQL 3.23.xx auf MySQL 4.0.15a die ersten Fehler auf: Zuerst verschwand ein Forum, dann verschwand hier mal ein Thread, da mal ein Beitrag und auch einen User hat es erwischt. Glücklicherweise fertige ich generell jeden Tag ein komplettes Backup der Datenbank an. Seit den ersten Fehlern habe ich dies sogar zweimal pro Tag gemacht, was teilweise auch notwendig war. Deshalb hielt sich der Schaden in Grenzen und ich konnte die fehlenden Einträge anhand des Backups sehr leicht wieder rekonstruieren. Man kann es nicht oft genug sagen: Macht regelmäßig Backups!!! Auch wenn es lästig erscheinen mag. Im Schadensfall ist dann das Theater groß, wenn die Backups nicht regelmäßig angefertigt wurden! Also laßt das Kind nicht erst in den Brunnen fallen, sondern legt euch eine gewisse Disziplin diesbezüglich zu. Es kann euch nur nützen! Der zweite Tip für Betroffene ist: Versucht, eure Tabellen auf einen transaktionssicheren Tabellentyp umzustellen, sofern euer Hoster dies in seiner MySQL-Kompilation aufgenommen hat. Es empfiehlt sich hier der Tabellentyp InnoDB. Ein kleiner Nachteil soll aber auch nicht unerwähnt bleiben: InnoDB unterstützt keine Volltextindizierung und der Speicherplatzverbrauch ist etwas größer. Nach der Konvertierung der Tabellentypen von MyISAM zu InnoDB ist der Bug seither nicht mehr feststellbar gewesen. Probleme aufgrund der Konvertierung sind bei mir nicht aufgetreten. Entweder ihr verwendet phpMyAdmin oder ihr führt die Umstellung manuell per SQL-Query durch: ALTER TABLE tabelle TYPE = INNODB Gruß, AC PS: Stefan, ich habe mir deine Abhandlung zur "Wiederherstellung verlorener Themen" angesehen. Da hast du dir wirklich viel Arbeit gemacht und es ist dir auch gut gelungen. Verdient Anerkennung! ;) Share this post Link to post
Helge 192 Report post Posted November 10, 2003 Das gleiche Problem scheint hier auch zu bestehen, denn hier fehlten auch schon 2 Themen ;) Share this post Link to post
Stefan 0 Report post Posted November 10, 2003 PS: Stefan, ich habe mir deine Abhandlung zur "Wiederherstellung verlorener Themen" angesehen. Da hast du dir wirklich viel Arbeit gemacht und es ist dir auch gut gelungen. Verdient Anerkennung! Danke, das hört man gerne. Deine Ausführung zu dem Problem ist aber auch sehr gut und ich werde es in meinem Beitrag zum Workaround mal verlinken. :) Share this post Link to post
Tankred 0 Report post Posted November 10, 2003 Ein kleiner Nachteil soll aber auch nicht unerwähnt bleiben: InnoDB unterstützt keine Volltextindizierung ... Das ist genau mein Problem: #1214 - The used table type doesn't support FULLTEXT indexes Das bekam ich bei dem Versuch der Umwandlung meiner posts Tabelle. Hat jemand einen Tipp, wie ich das lösen könnte? Share this post Link to post
Stefan 0 Report post Posted November 10, 2003 Einen Tipp kann ich dir nicht geben, aber eine Lösung. Geh mal mit phpMyAdmin in die entsprechende Tabelle, dort wo dir die Struktur angezeigt wird. Scroll dort weiter runter zu der Tabelle mit den Feldern Name Typ, Kardinalität, Aktion und Feld. Dort sind garantiert noch Zeilen mit dem Typ FULLTEXT und diese muß du löschen, anschließend funktioniert die Umstellung. ;) Share this post Link to post
Tankred 0 Report post Posted November 10, 2003 (edited) Eine Lösung ist natürlich super und sie funzt wunderbar DANKE! Noch eine Frage: man muss ja nicht alle Tabellen umstellen, sondern nur die "betroffenen" wie topics, posts, messages, usw.. Jetzt steht da über diesen: "InnoDB free: 11264 kB" bedeutet das, dass Inno DB die Gesamtgröße der Tabelle limitiert? Kann ja fast nicht sein, denn das scheint wohl eher die Größe der Tabelle zu sein. Aber was bedeutet dann in diesem Zusammenhang "free"? Edited November 10, 2003 by Tankred Share this post Link to post
Stefan 0 Report post Posted November 10, 2003 Jedoch sollte man auch folgenden Hinweis auf der MySQL Seite beachten. ACHTUNG: Konvertieren Sie KEINE MySQL-Systemtabellen von MyISAM in InnoDB-Tabellen! Das wird nicht unterstützt. Wenn Sie es dennoch tun, startet MySQL nicht mehr, bis Sie die alten Systemtabellen aus einer Datensicherung wiederhergestellt haben oder sie mit dem mysql_install_db-Skript neu erzeugen. Ich werde mir die ganze Thematik mal genauer anschauen und mich schlau machen. Share this post Link to post
Tankred 0 Report post Posted November 10, 2003 Oh je! Dann aber schnell das Daily Backup einführen!!! Share this post Link to post
AliCremerU333 0 Report post Posted November 11, 2003 (edited) "InnoDB free: 11264 kB" bedeutet das, dass Inno DB die Gesamtgröße der Tabelle limitiert? Kann ja fast nicht sein, denn das scheint wohl eher die Größe der Tabelle zu sein. Aber was bedeutet dann in diesem Zusammenhang "free"? Die o.g. Angabe bezieht sich auf den von InnoDB derzeit reservierten Tabellenplatz, und zeigt an, wieviel von diesem Tabellenplatz derzeit noch für Operationen zur freien Verfügung steht. Das heißt aber nicht, daß die Tabelle nur noch maximal die angegebene Größe des freien Speicherplatzes einnehmen kann, da die Segmente / Daten-Dateien aneinander gehängt / miteinander verknüpft werden und bei Bedarf der eigentliche Tabellenplatz automatisch vergrößert wird. Die Tabellen können also auch erheblich größer werden ... Die maximale Größe des Tabellenplatzes (Tablespace) beträgt 4 Milliarden Datenbank-Seiten. Das ist auch die maximale Größe für eine Tabelle. Die minimale Größe des Tabellenplatzes (Tablespace) beträgt 10 MB. InnoDB hat eine ganz spezielle Speicherplatzverwaltung. Der Hoster muß für InnoDB spezielle Optionen in der Konfigurationsdatei angeben, die u.a. die Größe der Daten-Dateien auf dem Server beeinflussen. (Das sind aber alles Einstellungen, die der Administrator eines DB-Servers zu tätigen hat und den Anwender i.d.R. nicht zu kümmern braucht.) Die Daten-Dateien, die Sie in der Konfigurationsdatei definieren, formen den Tabellenplatz (Tablespace) von InnoDB. [...] Der Tabellenplatz (Tablespace) besteht aus Datenbankseiten, deren vorgabemäßige Größe 16 KB beträgt. Diese Seiten werden bis zu einer Ausdehnung von 64 aufeinander folgenden Seiten gruppiert. Die 'Dateien' innerhalb eines Tabellenplatzes (Tablespace) werden in InnoDB Segmente genannt. [...] Wenn ein Segment innerhalb des Tabellenplatzes anwächst, weist ihm InnoDB die ersten 32 Seiten individuell zu. Danach fängt InnoDB an, dem Segment ganze Ausdehnungen zuzuweisen. InnoDB kann einem großen Segment bis zu vier Ausdehnungen auf einmal hinzufügen, um gute Sequentialität für die Daten sicherzustellen. [...] Wenn Sie eine Anfrage SHOW TABLE STATUS FROM ... LIKE ... ausführen, um den verfügbaren freien Platz im Tabellenplatz festzustellen, berichtet InnoDB den Platz, der in völlig freien Ausdehnungen im Tabellenplatz sicher benutzt werden kann. InnoDB reserviert immer einige Ausdehnungen für Säuberungs- und interne Zwecke. Diese Ausdehnungen werden nicht in den freien Platz einbezogen. Jedoch sollte man auch folgenden Hinweis auf der MySQL Seite beachten. ACHTUNG: Konvertieren Sie KEINE MySQL-Systemtabellen von MyISAM in InnoDB-Tabellen! Das wird nicht unterstützt. Wenn Sie es dennoch tun, startet MySQL nicht mehr, bis Sie die alten Systemtabellen aus einer Datensicherung wiederhergestellt haben oder sie mit dem mysql_install_db-Skript neu erzeugen. Auf die MySQL-Systemtabellen hat man als Anwender sowieso keinen Zugriff. Das ist eigentlich nur für den Admin des Hosters interessant (oder bei lokalen MySQL-Umgebungen auf dem eigenen Rechner), nicht für die User, die lediglich eine Datenbank bei einem Hoster benutzen. Gruß, AC Edited November 12, 2003 by AliCremerU333 Share this post Link to post
Stefan 0 Report post Posted November 11, 2003 Oh man, ich war gestern wohl etwas arg müde, hab das mit den Systemtabellen ganz überlesen und das es sich nur darauf bezieht. Also dann nochmal für alle, die ich in Panik versetzt habe, es besteht also keinerlei Bedenken, neben den angesprochenden Nachteilen, die Tabellen umzustellen. :) Share this post Link to post
AliCremerU333 0 Report post Posted November 12, 2003 Oh man, ich war gestern wohl etwas arg müde, hab das mit den Systemtabellen ganz überlesen und das es sich nur darauf bezieht. Macht nichts, war ja schon etwas spät. Übrigens ist die Umstellung auf InnoDB gerade für sehr große Boards mit sehr hohen Zugriffszahlen und großer Datenbank zu empfehlen, da gerade bei diesen Boards die Vorteile transaktionssicherer Tabellentypen wie InnoDB besonders zur Geltung kommen, vor allem bei hoher Serverlast. Gruß, AC Share this post Link to post
kingofcomedy 0 Report post Posted November 26, 2003 Der zweite Tip für Betroffene ist: Versucht, eure Tabellen auf einen transaktionssicheren Tabellentyp umzustellen, sofern euer Hoster dies in seiner MySQL-Kompilation aufgenommen hat. Es empfiehlt sich hier der Tabellentyp InnoDB. Ein kleiner Nachteil soll aber auch nicht unerwähnt bleiben: InnoDB unterstützt keine Volltextindizierung und der Speicherplatzverbrauch ist etwas größer. Nach der Konvertierung der Tabellentypen von MyISAM zu InnoDB ist der Bug seither nicht mehr feststellbar gewesen. Probleme aufgrund der Konvertierung sind bei mir nicht aufgetreten. Da ich auch zu den "4.0.15a - Geschädigten" gehöre, habe ich vor einiger Zeit einzelne DB-Tabellen bei meinem Forum auf InnoDB umgestellt, da mir das auch vom tollen PureTec-Support empfohlen (hatte dabei Glück den richtigen Supporter erwischt zu haben) wurde. Der Fehler tritt aber trotzdem weiterhin gelegentlich auf. Ich hoffe mal, dass das ganze mit 4.0.16 ein Ende hat, aber wer weiss, wann die Version installiert wird. :) Share this post Link to post
Ratman 0 Report post Posted November 27, 2003 sorry, a bissl ot, aber ich kanns mir ned verkneifen ... welcher hoster is bitte wirklich so dämlich, die allerneuste und ungetestete version zu nehmen? tuts nicht auch noch eine v3 für ein paar wochen? z.b. die 3.23.58 - rennt, und das recht gut. aber ok, mich würds nicht wundern, wenn gleich alle mit alphreleases in den startlöchern stehen würden. solche sachen sind halt ein eindeutiger beweis für, welche hoster gut sind, und welche nicht. my2cents für jene die glauben, das 5,-hoster gut sein müssen *bg* Share this post Link to post
AliCremerU333 0 Report post Posted November 27, 2003 (edited) Puretec wird die Umstellung nur aus einem einzigen Grund gemacht haben: Performance. Die MySQL-Server waren schon immer stark ausgelastet. Und da MySQL 4 nicht nur schneller, sondern auch ressourcenschonender ist, konnten die Admins bei Puretec wohl nicht widerstehen. Mir wäre es auch lieber gewesen, sie hätten noch etwas länger mit der Umstellung gewartet. Sonst ist man bei Puretec in solchen Dingen auch etwas konservativer gewesen ... Der Fehler tritt aber trotzdem weiterhin gelegentlich auf. Bei mir ist er seitdem nicht mehr aufgetreten. Keinerlei Probleme mehr ... Gruß, AC PS: Die sind gerade fleißig beim Updaten. Auf meinem zweiten MySQL-Server läuft bereits 4.0.16, auf dem ersten noch 4.0.15a. Wer weiß, ob der Fehler in 4.0.16 schon gefixt ist. Ich bleibe auf jeden Fall bei InnoDB. Edited November 27, 2003 by AliCremerU333 Share this post Link to post
Andy 0 Report post Posted November 27, 2003 Hier bei uns läuft auch schon der MySQL-Server mit der Version 4.0.16, und seitdem hatten wir auch keine Probleme mehr gehabt. Ich denke und hoffe, daß verschwundene Themen nun hier bei uns der vergangenheit angehören :) Share this post Link to post
kingofcomedy 0 Report post Posted November 27, 2003 welcher hoster is bitte wirklich so dämlich' date=' die allerneuste und ungetestete version zu nehmen?[/quote'] Ich denke nicht, das PureTec eine neue MySQL-Version ungetestet installiert. PS: Die sind gerade fleißig beim Updaten. Auf meinem zweiten MySQL-Server läuft bereits 4.0.16' date=' auf dem ersten noch 4.0.15a.[/quote'] Hier bei uns läuft auch schon der MySQL-Server mit der Version 4.0.16' date=' und seitdem hatten wir auch keine Probleme mehr gehabt.[/quote'] Na dann will ich mal hoffen, das die 4.0.16 auch bald meinen Server erreicht, und die Probleme damit behoben sind. Share this post Link to post
AliCremerU333 0 Report post Posted November 27, 2003 welcher hoster is bitte wirklich so dämlich' date=' die allerneuste und ungetestete version zu nehmen?[/quote'] Ich denke nicht, das PureTec eine neue MySQL-Version ungetestet installiert. Ungetestet ist da überhaupt nichts. Bugs sind heutzutage Normalität. Leider! Ich möchte mal diejenige komplexe Software sehen, die keine Bugs oder Sicherheitslücken hat. Das ist beim Umfang des Programmcodes schlichtweg unmöglich! Man kann nur versuchen, die Anzahl Bugs zu minimieren. Genauso wenig wie es absolute Sicherheit gibt, gibt es bugfreie Software. Entwickler werden wissen, was ich meine. Und ein Hoster muß bei jeder neuen Version von MySQL / PHP / etc. erstmal aus den Sourcen die individuell angepaßten Binaries kompilieren. Kein (seriöser) Hoster benutzt vorkompilierte Binaries (sofern es diese für die benutzte Plattform gibt), da diese nicht auf die individuellen Notwendigkeiten und Bedürfnisse angepaßt sind und i.d.R. diverse zusätzliche Funktionen, die zusätzlich einkompiliert werden müssen, nicht beinhalten (z.B. bei MySQL: Unterstützung für transaktionssichere Tabellentypen). Da wird wirklich alles bis zum Erbrechen ausgetestet, protokolliert und analysiert, bevor eine Umstellung für die Kunden gefahrlos und für den Hoster bis auf's letzte Detail optimiert stattfinden kann. Gruß, AC Share this post Link to post
Ratman 0 Report post Posted November 27, 2003 Da wird wirklich alles bis zum Erbrechen ausgetestet, protokolliert und analysiert, bevor eine Umstellung für die Kunden gefahrlos und für den Hoster bis auf's letzte Detail optimiert stattfinden kann *g* - man merkts ... Share this post Link to post
kingofcomedy 0 Report post Posted November 27, 2003 Da wird wirklich alles bis zum Erbrechen ausgetestet, protokolliert und analysiert, bevor eine Umstellung für die Kunden gefahrlos und für den Hoster bis auf's letzte Detail optimiert stattfinden kann *g* - man merkts ... Der Fehler tritt so selten auf, das man den wohl selbst bei einem ausgiebigem Test nicht unbedingt entdecken muss. Jede Software hat vermutlich Fehler, die nur in ganz bestimmten Situationen auftreten. Share this post Link to post
Tankred 0 Report post Posted November 27, 2003 1&1 Puretec: bei mir läuft jetzt auch die 16er Version. Share this post Link to post
kingofcomedy 0 Report post Posted November 29, 2003 Der Fehler tritt aber trotzdem weiterhin gelegentlich auf. Bei mir ist er seitdem nicht mehr aufgetreten. Keinerlei Probleme mehr ... Kommando zurück. Ich hatte damals unter phpMyAdmin 2.5.3b (oder so ähnlich) folgenden Befehl benutzt, um auf InnoDB umzustellen: ALTER TABLE ibf_posts TYPE=InnoDB; Dauerte ca. eine halbe Minute und dann kam wie üblich der Text, das der Befehl erfolgreich ausgeführt wurde. Aber wie ich gestern festgestellt habe, war das wohl nicht wirklich der Fall. Hab gestern mal direkt unter Operationen (diesmal phpMyAdmin 2.5.4) den Tabellentyp auf INNO DB umgestellt, und siehe da, diesmal scheint es wirklich geklappt zu haben. Und was sehe ich: Die Tabellengrösse ist von ca. 41 MB auf ca. 71 MB angestiegen. Da habe ich wieder direkt auf MyISAM umgestellt, da ich ja leider "nur" 100 MB Platz in meiner DB habe. P.S.: Noch läuft MySQL 4.0.15a. Share this post Link to post
AliCremerU333 0 Report post Posted December 2, 2003 Die Tabellengrösse ist von ca. 41 MB auf ca. 71 MB angestiegen. Ist normal. Bei mir war es aber ein Nullsummenspiel. Zuerst habe ich die FULLTEXT-Indizes in normale Indizes umgewandelt und dabei ca. 40% bis 50% an Speicherplatz für diese Tabellen in der DB eingespart. Nach der Umstellung auf InnoDB wurden diese Einsparungen wieder verbraucht. Jetzt wird bei mir ungefähr genauso viel Speicherplatz belegt wie vor der Umstellung unter Verwendung von Volltextindizierung. Übrigens scheint Puretec den für die Indizes benötigten Speicherplatz nicht in die max. DB-Größe einzurechnen. Bei den Quota-Ergebnissen und der Anzeige des noch freien DB-Speicherplatzes wird bei mir jedenfalls nur der Verbrauch der eigentlichen Tabellen und nicht deren Indizes angerechnet (habe ich doch gleich mal mit und ohne Indizes nachgerechnet). Der zusätzliche Speicherplatzverbrauch von InnoDB ist ebenfalls nicht enthalten. Gruß, AC Share this post Link to post
kingofcomedy 0 Report post Posted December 2, 2003 (edited) @AliCremerU333: Ich warte jetzt erstmal, bis "mein" Server auf 4.0.16 umgestellt wurde, und ob der Fehler dann weiterhin auftritt. :) Edited December 2, 2003 by kingofcomedy Share this post Link to post
kingofcomedy 0 Report post Posted December 12, 2003 PS: Die sind gerade fleißig beim Updaten. Auf meinem zweiten MySQL-Server läuft bereits 4.0.16' date=' auf dem ersten noch 4.0.15a.[/quote'] Hier bei uns läuft auch schon der MySQL-Server mit der Version 4.0.16' date=' und seitdem hatten wir auch keine Probleme mehr gehabt.[/quote'] Na dann will ich mal hoffen, das die 4.0.16 auch bald meinen Server erreicht, und die Probleme damit behoben sind. So, heute nacht hat MySQL 4.0.16 auch meinen ersten DB-Server erreicht. Jetzt heisst es abwarten, wann wieder die ersten Datensätze verschwinden. :lol: Share this post Link to post
