Re: OT: MySQL-Datenhandling

On Thu, 12 Feb 2004, Matthias LoCal Schonder wrote:

> Gestern hat sie Vormittags "angeblich" mit aktuellen Daten
> gearbeitet.. und nachmittags waren die wag... zwischen durch musste ich
> das Datenbanksystem neustarten (mysqladmin shutdown; safe_mysqld)
>
> Jedenfalls haben die Datenbankdateien (.MYD, .MYI, .frm) für die
> Rechnungsdatenbank das Datum 19.1.2003 .. und auch auf den
> Sicherungsbändern (Sicherung täglich, pro tag ein Bank... *schäm*) ist
> dieses Datum. Die anderen Datenbank sind aber "ganz normal" auf
> akutellem stand.

> Nun habe ich da einen User der der meinung ist er kann alles und er
> sagt nix wenn er etwas macht und ich stehe dann vor vollendeten
> Tatsachen. Er hat die Rechnungsdatenbank erstellt und auch die
> php-sachen dafür geschrieben. Seit ich ihm seine rechte extrem
> beschränkt habe, weil er unschöne Dinge auf dem Server angestellt hat,
> erstellt er seine Test-Datenbank unter Windows..
> Nun hat er folgendes gemacht.. er hat neue Tabellen für die
> Rechungsdatenbank auf eine Windowssystem erstellt und diese dann im
> laufenden Betrieb in das vorhandene Datenbankverzeichnis auf dem BSD
> geschoben. Er hat keine ersetzt sondern neue hinzugefügt..
> mit cp von seinem home ins verzeichnis von der Datenbank.
> Probelm bei der Sache.. owner von dem ding war er!
> Ich hab das zwar geändert sobald ich das gemerkt hatte.. aber ich weiss
> nicht mehr wann ich das gemacht hatte.. und er kann sich nicht erinnern
> wann er die tabelle kopiert hatte.

Wenn ich einfach neue Tabellen in ein Verzeichnis schiebe, sind sie docgh
noch lange nicht im Systemkatalog? Oder ist MySQL so "gut", eine
frischvorgeworfene Datei einfach "einzugemeinden"?

Du beschreibst ja schon ein paar Implikationen fuer die
Zugriffsberechtigungen. Woher soll die Datenbank die Grants fuer diese
unbekannten Tabellen herhaben?

Sollte man in eine MySQL-DB wirklich Tabellen durch Kopieren
"einschmuggeln" koennen, wuerde ich das eher fuer einen Bug, und nicht
fuer ein Feature halten. Aber von beidem hat ja MySQL mehr als genug;-)

> So nun hat er die Theorie aufgestellt, dass die mysql für diese Tabelle
> quasi ein lock gesetzt hat und alle Zugriffe temporär gespeichert
> hatte. Anfragen von users gingen dann auf die temporäre gespeicherten
> Sätze... und als ich dann die DB neugestartet habe, hätte die MySQL die
> temp dateien einfach gelöscht.

Nein, Aenderungen sind nach dem Commit in der DB oder schiefgelaufen.

> Für mich klingt diese Theorie zwar total daneben (3 Wochen Daten im RAM
> oder tempdatei [kenne ich bei mysql garnet]) und ich tippe immer noch
> auf einen Programmfehler. Nur nach 9 Stunden Suche bin ich mir nimmer
> 100% sicher und vielleicht weiss ja einer von euch was.

Ich tippe zunaechst auf einen organisatorischen Fehler. Ihr muesst erst
einmal klaeren, wie man an einer Datenbank mit- und nicht gegeneinander
arbeitet. Alles andere ist betriebsschaedigend.

Zur Klaerung solcher Sachverhalte sind nach dem derzeit herrschenden
Organisationsprinzip "Fuehrungskraefte" zustaendig;-)

Anyway, neue Tabellen werden mit "CREATE TABLE" erzeugt und nicht durch
Kopieren von Files. Wer dabei, wie auch immer, auf die Nase faellt, sollte
sich nicht wundern. Wer waehrend der Fahrt Reifen wechselt, landet halt
u.U. im Strassengraben.

Doofe Vermutung - die Kollegin hat seit drei Wochen unwissentlich auf der
Test-DB auf dem Windows-Rechner gearbeitet, auf der die neuen Skripte
getestet wurden.

Da Dein Kollege und Du Euch nicht gruen seid, sind leider auch die
Aussagen Deines Kollegen nicht verlaesslich.

Es gruesst
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 13 Feb 2004 - 00:43:48 CET