mmofacts.com

Datenbankcrashs (errnr: 145) player.MYI

gepostet vor 18 Jahre, 5 Monate von Mahdi[TGP]
Ich bin am verzweifeln,
nachdem ein unbekannter Fehler von irgendjemand und irgendwo verursacht hat wird immer meine Datenbank zerstört oder besser immer die player.MYI Tabelle, also die mit an sich den meisten Daten der Spieler durch Backups konnte ich sie zwar wieder herstellen doch gestern und heute kam es zu drei weiteren Ausfällen.
Ohne zugriff auf den Server passiert es einfach. Es macht bumm, dann steht eben die Fehlermeldung da, player.MYI (errnr: 145).
Wenn ich in die Datenbank gucke kann ich mit der player-Tabelle nichts mehr anstellen und es steht lediglich in Benutzung da. Reparieren oder irgendeine Operation ist nicht möglich.
Ich hoffe, dass mir irgendjemand helfen kann!!! Ich würde den Namen dieses Forums wahrscheinlich in den Mond kratzten lassen, damit es jeder kennt!
Ich bitte um Hilfe!
Mfg. MAhdi
gepostet vor 18 Jahre, 5 Monate von TheUndeadable
Ich hatte das Problem auch mal, bei mir hat ein einfaches Upgrade der Datenbank auf die neueste Version geholfen...
Ansonsten würde ich überprüfen, ob sich irgendwelche Einträge im MySQL-Log befinden.
gepostet vor 18 Jahre, 5 Monate von Sarge
Also das kommt wahrscheinlich daher das deine MysqlDB im Betrieb crashte.
Dazu schaust du einmal in dein syslog bzw mysql errorlog bzw daemon.log je nach system etc.
Da wird vielleicht auch ein grund drinstehen (glück für dich) wahrscheinlcih aber nicht und du wirst noch eine fröhliche fehlersuche zeit vor dir haben ( ich würd nun ein schuß ins blaue wagen der nie verkehrt ist und manche Nerven schonen kann... lass auch einmal den Ram durchchecken bevor du dein system dann komplett durchmachst)
So nun zur Symptom bekämpfung:
Wenn auf deine Datenbank gerade schreibend zugegriffen wurde während sie crashte können die tabelles beschädigt werden und auch bzw vorallem die indezes. Dies ist wahrscheinlich bei Dir der Fall.
dazu fährst du am besten erstmal die DB herunter (mysqladmin -p shutdown )... wechselst in dein Datenbankverzeichnis (standardmäßig unter debian z.b. /var/lib/mysql/ ) ... dort führst du dann folgenden befehl aus "myisamchk -r * "
Dieser repariert dir deine Index Files . Nun startest du die datenbank wieder (mysqld_safe & ) .. und lässt als erstes nun noch nen tablecheck durchlaufen mit "mysqlcheck -c -A -p "
Dieser sollte nun hoffentlich keine Tabelles mehr als corrupted anzeigen und du kannst wieder loslegen.
gepostet vor 18 Jahre, 5 Monate von Kampfhoernchen
Ist mir ein einziges Mal passiert (MySQL3), da waren alle Index-Dateien einfach leer.
Ursache konnte ich nicht finden, immer gut wenn man Backups zur Hand hat.
gepostet vor 18 Jahre, 5 Monate von Mahdi[TGP]
Mmmhm ersteinmal danke für eure Hilfe!
Habe ich das richitg verstanden, dass es zu einen Tabellenfehler kommt, wenn im gleichen Moment in die Tabelle geschrieben wird wo jemand anderes aussließt?
Das wäre nähmlich ganz schlecht, da mein Spiel so angelegt ist, dass ständig abgefragt und wieder hingeladen wird. Ja eigentlich immer wenn ein Spieler was klickt, wir sowohl Abgefagt als auch geschrieben.
Also ein Beispiel versursacht es einen Fehler, wenn Person A den befehl UPGRADE player SET name='$name' WHERE id=1 aufruft und im gleichen Augenblick Spieler B
SELECT player goldMenge WHERE id=1
oder muss es sich um das geliche Feld handeln, damit der ehler ausgelöst wird also:
Spieler A
UPGRADE player SET name='$name' WHERE id=1
Spieler B
SELECT player name WHERE id=1
???
Mfg. mahdi
gepostet vor 18 Jahre, 5 Monate von Mahdi[TGP]
Das erste mal ist es am Sonntag letzte Woche passiert,
dann Gestern abend heute Morgen und heute Mittag. Also cih muss dringend diesen verdammten Fehler finden,
kann mir wenigstens jemand sagen,anch was cih zu suchen haben,
etwa nach einen derartigen Doppelzugriff wie im vorhergehenden Beitrag beschireben?
mfg. mahdi
gepostet vor 18 Jahre, 5 Monate von knalli
Nein... das eine Tabelle/DB crashed, ist das eine.. aber wenn währenddessen noch ein Schreibvorgang lief, ist das noch eine Stufe härter (vgl. Festplattenzugriff).
Aber dennoch.. das sollte eigentlich nicht passieren.. vllt verursacht ein anderer Prozess Probleme? Ich nehme jetzt auch mal an, dass DB auf dem gleichen Server wie die Scripts liegt..
gepostet vor 18 Jahre, 5 Monate von Sarge
Nein da hast du etwas ganz ganz falsch verstanden.
Gleichzeitig lesend&schreibend zuzugreifen ist kein Problem das regelt die Mysql Datenbank mit table locks bei myisam bzw innodb mit row locks.
Ich sehe auch nirgends wo irgendjemand soetwas geschrieben hat.
Les dir nochmal mein erstes Posting durch und führe die Befehle unter Symptom bekämpfung aus.
Und dann schau vorallem einmal dein syslog / mysql.err log / daemon.log
(standaradmäßig bei Debian:
/var/log/syslog
/var/log/daemon.log
/var/log/mysql.err
)
Und geh den Tag durch als der Fehler aufgetreten ist. Ich würd wetten dass da ein Eintrag vermerkt ist das deine MysqlDatenbank im betrieb crashte und neugestartet wurde.
Eine Angabe welche Distribution du nutzt wäre evtl hilfreich, ansonsten gehe ich von Debian aus.
Meine Kristallkugel ist nichtmehr die jüngste.
gepostet vor 18 Jahre, 5 Monate von Mahdi[TGP]
mhmm wir finden das nicht
alle webdinste basieren auf einem gesammtprogramm "xampp"
Wir haben einen Windowsserver
Mfg. MAhdi
gepostet vor 18 Jahre, 5 Monate von Fasi
Ist als Default das Error Logging von MySQL nicht ausgeschaltet? Muss doch im ini File aktiviert werden. Oder liege ich da falsch?
gepostet vor 18 Jahre, 5 Monate von knalli
Original von Mahdi[TGP]
mhmm wir finden das nicht
alle webdinste basieren auf einem gesammtprogramm "xampp"
Wir haben einen Windowsserver
Mfg. MAhdi

Das mag jetzt nicht der Grund des Problems sein.. aber Windowsserver und obendrein das XAMPP Paket ist nun wirklich nicht das beste Voraussetzung eines produktiven Webservers.
Ich gebe ja zu, das ich auf meinem Notebook auch Xampp drauf habe, das ist zum Entwicklen (vor allem offline unterwegs) ideal.. aber nie im Leben auf einer richtigen Maschine (mal so als Tipp am Rande).
gepostet vor 18 Jahre, 5 Monate von TheUndeadable
> Das mag jetzt nicht der Grund des Problems sein.. aber
> Windowsserver und obendrein das XAMPP Paket ist nun wirklich
> nicht das beste Voraussetzung eines produktiven Webservers.
Mein Winserver läuft eigentlich rund um die Uhr auch bei hoher Last einwandfrei. Allerdings verwende ich immer die aktuellsten Versionen von PHP und MySQL. Windows-Server laufen mit PHP und MySQL eigentlich genauso zuverlässig wie unter Linux, zumindest habe ich noch keine Unterschiede feststellen können.
Wie es allerdings mit XAMPP aussieht: Keine Ahnung. Ich persönlich würde auf jeden Fall mal die aktuelle Version von MySQL aufspielen.
gepostet vor 18 Jahre, 5 Monate von Mahdi[TGP]
Wir haben jetzt ein Update drüber gebügelt und nun tut sich ein neues Probelm auf:
Alle Eingaben in Textboxen und Labels werden beim Posten nicht gepostet???
Ich habe das bisher so gemacht:
ein Eingabe Feld name='feld1'
in der Form die Action festgelegt action='?action=send'
und das Formular von oben ausgewertet mit
$action = $_GET['action'];
if($action == "send")
{
echo $feld1;
}
und er hat mir die Daten von Feld1 ausgegeben aber nun geshiet dies nicht mehr?
gepostet vor 18 Jahre, 5 Monate von Itchy
Funktioniert $_POST['feld1'] anstelle $feld1?
Wahrscheinlich war vor dem Update register_globals = 1 und jetzt eben nicht mehr. Du kannst natürlich dann auch wieder die Option in der Konfiguration freischalten, solltest Dir aber bewußt sein, daß damit so manche Sicherheitslücke in beliebten PHP Projekten (phpBB, phpNuke etc.) aufgerissen wurde.
gepostet vor 18 Jahre, 5 Monate von Mahdi[TGP]
Ja so gehts würde aber trotzdem gerne die register_globals = 1 setzten wo kann ich das tun (habe wie gesagt einen Xampp Windows server)
gepostet vor 18 Jahre, 5 Monate von Mahdi[TGP]
Ich danke euch allen echt Maßlos!!!
Hier lernt man den wahren wert von Foren kennen! Wahrhaftig mir wurd lange nciht an einem Tag so ausgiebig und effiezient geholfen großes Lob!
Ob das Hauptproblem durch das Serverupdate behoben ist weis cih noch nciht. aber es sit eine Maßnahme und ich hoffe ich muss hier nicht nochmal reinschreiben aufgrund erneuter Vorkommnisse.
Bis dahin,
Mfg. MAhdi

Auf diese Diskussion antworten