MySQL-NT und MySQL-Linux Inkomptibilität

Hallo!
In habe ich bereits geschrieben,
dass ich vorhabe eine MySQL Datenbank von Win2000 auf Linux zu
portieren. Ich habe mittlerweile das Backup auf dem Linux PC
zurückspielen können. Testweise habe ich auch noch eine neue VM mit
Windows XP und MySQL eingerichtet und dort das Backup zurückgespielt.
Jetzt tritt aber folgendes Phänomen auf: das eine System funktioniert
und das andere nicht :-(
Ich habe zum testen den User root ohne Passwort installiert. Die
Client-Software entsprechend konfiguriert. Auf die XP VM kann das
Programm zugreifen und die Datenbank benutzen. Bei Zugriff auf die Linux
VM bekomme ich folgende Meldung: "Unknown database: XXXX" - ich denke
also, dass es sich um ein Problem mit den Benutzer-Rechten handelt -
IMHO differiert die Linux Version hier von der NT Version.
Aber ein "show GRANTS" zeigt folgendes:
Win XP:
mysql> show GRANTS;
+----------------------------------------------------------- ----------+
| Grants for root@localhost |
+----------------------------------------------------------- ----------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+----------------------------------------------------------- ----------+
1 row in set (0.11 sec)

Linux - Slackware:
mysql> show GRANTS;
+----------------------------------------------------------- --+
| Grants for root@% |
+----------------------------------------------------------- --+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION |
+----------------------------------------------------------- --+
1 row in set (0.08 sec)

Welche Einstellung könnte ich unter Linux übersehen haben, die eine
Verbindung unterbindet?

Danke!


Gruß,
Andreas Weller

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Andreas Weller wrote:
> Programm zugreifen und die Datenbank benutzen. Bei Zugriff auf die Linux
> VM bekomme ich folgende Meldung: "Unknown database: XXXX" - ich denke

Droppe alle Databases auf der Linux Version, ausgenommen die mysql-Database.
Setze in der [mysqld]-Sektion der my.cnf auf Linux "lower_case_table_names =
1".
Lies Deine Dumps neu ein.

Jetzt wird es gehen.

Linux unterscheidet Groß- und Kleinschreibung, Windows nicht. Mit
lower_case_table_tables = 1 zwingst Du Linux dazu, alle Namen immer in
Kleinschreibung umzuwandeln. Dann tritt das Problem nicht auf.

Kris

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Andreas Weller wrote:

> Ich habe zum testen den User root ohne Passwort installiert. Die
> Client-Software entsprechend konfiguriert. Auf die XP VM kann das
> Programm zugreifen und die Datenbank benutzen. Bei Zugriff auf die Linux
> VM bekomme ich folgende Meldung: "Unknown database: XXXX" - ich denke
> also, dass es sich um ein Problem mit den Benutzer-Rechten handelt

Falsch gedacht!

Das Problem ist, daß Windows-Filesysteme nicht besonders konsistent mit
Groß-/Kleinschreibung umgehen. MySQL-Datenbanken (und manche Tabellen)
sind aber Filesystem-Objekte; nämlich Verzeichnisse bzw. Dateien.

Normalerweise ist das kein Problem - dann nämlich wenn man konsistent
immer die gleiche Schreibweise verwendet. Ansonsten kann MySQL über den
lower_case_table_names Parameter angewiesen werden, Workarounds für
bestimmte (IMHO kaputte) Filesysteme zu verwenden.

Die Details solltest du im Handbuch nachlesen.


XL

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Axel Schwenke schrieb:

> Das Problem ist, daß Windows-Filesysteme nicht besonders konsistent mit
> Groß-/Kleinschreibung umgehen.

Wieso "nicht konsistent"? Nach meinen Informationen ignoriert Windows
die Schreibung bei existierenden Dateien und übernimmt sie bei neuen. Es
sei denn, der Name passt ins alte 8.3-Schema. Dann wird der Name
komplett in Großbuchstaben gewandelt.

Wo siehst Du da irgendwelche Nicht-Konsistenzen?

> Normalerweise ist das kein Problem - dann nämlich wenn man konsistent
> immer die gleiche Schreibweise verwendet.

Mit "immer" meinst Du sicher "sowohl im Dateisystem als auch innerhalb
von MySQL-Queries". Problematisch können hierbei (Datei-)Namen sein, die
ins bereits zitierte 8.3-Schema passen.

> Ansonsten kann MySQL über den
> lower_case_table_names Parameter angewiesen werden, Workarounds für
> bestimmte (IMHO kaputte) Filesysteme zu verwenden.

Ich sehe an NTFS nichts Kaputtes. Bestenfalls ein paar DOS-Altlasten,
die gelegentlich Ärger bereiten können.

Grundsätzlich musst Du _immer_ mit Problemen rechnen, wenn Du Programme
und Daten von fremden Systemen übernimmst. Das liegt nun mal in der
Natur der Sache.

Gruß. Claus

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Claus Reibenstein schrieb im Newsbeitrag
> Ich sehe an NTFS nichts Kaputtes. Bestenfalls ein paar DOS-
> Altlasten, die gelegentlich Ärger bereiten können.

Ist es nicht eher ein Problem von MySQL, wenn es da nicht von sich aus
case-insensitive arbeitet? Ich dachte doch, dass es nach ANSI-SQL egal
ist, ob man Groß-/Kleinbuchstaben verwendet, da SQL case-insensitive
ist. Wenn das bei Tabellen aber von MySQL nicht berücksichtigt wird,
sondern 1:1 auf's Dateisystem abgewälzt wird (im Normalfall), dann
sehe ich das Problem bei MySQL.

So long,
-+- Dirk -+-

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Claus Reibenstein wrote:
> Axel Schwenke schrieb:
>
>> Das Problem ist, daß Windows-Filesysteme nicht besonders konsistent mit
>> Groß-/Kleinschreibung umgehen.
>
> Wo siehst Du da irgendwelche Nicht-Konsistenzen?

Ich habe hin und wieder den Effekt, daß ich ein File/Directory komplett
mit Großbuchstaben anlege, es mir aber später klein mit großem Anfangs-
buchstaben präsentiert wird. Ich habe gerade versucht, das nachzuvoll-
ziehen, aber prompt klappt es nicht.

Was ich gerade ausprobiert habe: wenn auf dem Fileserver (Samba) zwei
Files aaa und AAA liegen, werden mir zwar im Verzeichnislisting beide
angezeigt, aber egal welches von beiden ich öffne, ich bekomme jedes
Mal aaa (getestet u.a. mit Wordpad.exe). Tolle Wurst.

Ich hätte gern einen Schalter: dieses Filesystem case-sensitiv handlen.
Bzw. gleich: alle Filesysteme case-sensitiv handlen.

>> Normalerweise ist das kein Problem - dann nämlich wenn man konsistent
>> immer die gleiche Schreibweise verwendet.
>
> Mit "immer" meinst Du sicher "sowohl im Dateisystem als auch innerhalb
> von MySQL-Queries".

Ich meine eigentlich: innerhalb von SQL-Queries. Das schließt natürlich
die CREATE Statements ein. Ist aber eben blöd, wenn man nach

CREATE DATABASE FOO;
SHOW DATABASES;

die neue Datenbank als "Foo" angezeigt bekommt.

>> Ansonsten kann MySQL über den
>> lower_case_table_names Parameter angewiesen werden, Workarounds für
>> bestimmte (IMHO kaputte) Filesysteme zu verwenden.
>
> Ich sehe an NTFS nichts Kaputtes.

Ich schon. Allein die fehlende Dokumentation - und die daraus
resultierende Unmöglichkeit, einen Linux-Filesystemtreiber dafür zu
schreiben, disqualifiziert NTFS vollständig.

> Grundsätzlich musst Du _immer_ mit Problemen rechnen, wenn Du Programme
> und Daten von fremden Systemen übernimmst.

Aber nicht bei so einfachen Sachen. Tatsächlich ist das ein Fehler in
MySQL. Die 1:1 Abbildung von Datenbankobjekten auf Filesystemobjekte
war keine besonders gute Idee. Z.B. kann man bestimmte (nach dem SQL-
Standard absolut legale) Zeichen wie den / in SQL-Namen nicht benutzen.
Mit 5.1 kommt ja ein neues Encoding-Schema [1] für Datenbank-/Tabellen-
namen. Aber das GROSS/klein Problem ist damit nicht gelöst.

[1] http://dev.mysql.com/doc/refman/5.1/en/identifier-mapping.ht ml


XL

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Claus Reibenstein wrote:
>
> Grundsätzlich musst Du _immer_ mit Problemen rechnen, wenn Du Programme
> und Daten von fremden Systemen übernimmst. Das liegt nun mal in der
> Natur der Sache.

Aber gerade die Benennung der Tabellennamen im Dateisystem sollte definitiv
nicht Aufgabe des Benutzers sein. Schließlich verwendet er SQL, damit er
sich um die physische Speicherung seiner Daten keine Gedanken mehr machen muss.

Andernfalls kommt dieser andere Spruch hier wieder zum Tragen:

Network filesystem with SQL layer.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Axel Schwenke schrieb:

> Claus Reibenstein wrote:
>
>> Axel Schwenke schrieb:
>>
>>> Das Problem ist, daß Windows-Filesysteme nicht besonders konsistent mit
>>> Groß-/Kleinschreibung umgehen.
>>
>> Wo siehst Du da irgendwelche Nicht-Konsistenzen?
>
> Ich habe hin und wieder den Effekt, daß ich ein File/Directory komplett
> mit Großbuchstaben anlege, es mir aber später klein mit großem Anfangs-
> buchstaben präsentiert wird. Ich habe gerade versucht, das nachzuvoll-
> ziehen, aber prompt klappt es nicht.

Bei mir hat es zum Teil geklappt: ich habe mal eben drei Verzeichnisse
"klein", "GROSS" und "GeMiScHt" auf einem NTFS-Laufwerk unter Windows XP
angelegt. Der Explorer von Windows zeigt sie mir auch exakt so an.
Offensichtlich scheint Windows also auch bei so kurzen Namen - entgegen
meiner bisherigen Annahme - die Schreibweise zu übernehmen.

Dass andere Tools aus "GROSS" "Gross" machen, ist wohl eher ein Feature
(oder Bug, je nach Sichtweise) des jeweiligen Tools.

> Was ich gerade ausprobiert habe: wenn auf dem Fileserver (Samba) zwei
> Files aaa und AAA liegen, werden mir zwar im Verzeichnislisting beide
> angezeigt, aber egal welches von beiden ich öffne, ich bekomme jedes
> Mal aaa (getestet u.a. mit Wordpad.exe). Tolle Wurst.

Das scheint dann wohl aber eher ein Problem von Samba zu sein. Dieses
sollte zwei solche Dateien am Besten gar nicht erst zulassen.

> Ich hätte gern einen Schalter: dieses Filesystem case-sensitiv handlen.
> Bzw. gleich: alle Filesysteme case-sensitiv handlen.

Problem ist, dass Windows grundsätzlich caseinsensitiv arbeitet. Ein
solcher Schalter passt von daher gar nicht erst ins Konzept und würde
mit Sicherheit viele Anwendungen und wahrscheinlich sogar Windows selber
laufunfähig machen.

> Ich meine eigentlich: innerhalb von SQL-Queries. Das schließt natürlich
> die CREATE Statements ein. Ist aber eben blöd, wenn man nach
>
> CREATE DATABASE FOO;
> SHOW DATABASES;
>
> die neue Datenbank als "Foo" angezeigt bekommt.

Wichtig ist, wie die Programme sie sehen. Sehen diese weiterhin "FOO"
oder "Foo"? Letzteres würde ich schlicht als Bug bezeichnen.

Wie sieht das eigentlich bei InnoDB aus? Gibt es dort auch diese
Probleme? Dürfte eigentlich nicht.

Werd's bei Gelegenheit mal testen.

>> Ich sehe an NTFS nichts Kaputtes.
>
> Ich schon. Allein die fehlende Dokumentation - und die daraus
> resultierende Unmöglichkeit, einen Linux-Filesystemtreiber dafür zu
> schreiben, disqualifiziert NTFS vollständig.

Es gibt genügend NTFS-Treiber für Linux.

>> Grundsätzlich musst Du _immer_ mit Problemen rechnen, wenn Du Programme
>> und Daten von fremden Systemen übernimmst.
>
> Aber nicht bei so einfachen Sachen. Tatsächlich ist das ein Fehler in
> MySQL. Die 1:1 Abbildung von Datenbankobjekten auf Filesystemobjekte
> war keine besonders gute Idee. Z.B. kann man bestimmte (nach dem SQL-
> Standard absolut legale) Zeichen wie den / in SQL-Namen nicht benutzen.

Auch das sollte mit InnoDB eigentlich kein Problem mehr sein.

> Mit 5.1 kommt ja ein neues Encoding-Schema [1] für Datenbank-/Tabellen-
> namen. Aber das GROSS/klein Problem ist damit nicht gelöst.

Ich arbeite noch mit 4.1 (unter SuSE 9.3). Eine Migration auf neuere
Versionen traue ich mich nicht, da ich hierzu eine komplette,
funktionierende (!) Webseite upgraden müsste (never change a running
system).

Gruß. Claus

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Claus Reibenstein wrote:
> Axel Schwenke schrieb:
>
>> Was ich gerade ausprobiert habe: wenn auf dem Fileserver (Samba) zwei
>> Files aaa und AAA liegen, werden mir zwar im Verzeichnislisting beide
>> angezeigt, aber egal welches von beiden ich öffne, ich bekomme jedes
>> Mal aaa (getestet u.a. mit Wordpad.exe). Tolle Wurst.
>
> Das scheint dann wohl aber eher ein Problem von Samba zu sein. Dieses
> sollte zwei solche Dateien am Besten gar nicht erst zulassen.

Samba exportiert ja nur ein "richtiges" (d.h. case-sensitives)
Filesystem. Normalerweise greife ich darauf über NFS zu, das Samba ist
nur ein Notnagel, damit Windows überhaupt was vom Fileserver sieht.

>> Ich hätte gern einen Schalter: dieses Filesystem case-sensitiv handlen.
>> Bzw. gleich: alle Filesysteme case-sensitiv handlen.
>
> Problem ist, dass Windows grundsätzlich caseinsensitiv arbeitet. Ein
> solcher Schalter passt von daher gar nicht erst ins Konzept und würde
> mit Sicherheit viele Anwendungen und wahrscheinlich sogar Windows selber
> laufunfähig machen.

Eben. Micros~1 hat zwar irgendwann mal gegrokt, daß die Einschränkung
auf eine Sorte Buchstaben im Filesystem nicht mehr zeitgemäß ist
(vermutlich haben sie NTFS ohnehin nur zugekauft und das konnte das von
sich aus) - allerdings haben sie nicht mal reinen Tisch gemacht und
auch die Layer oben drüber case-sensitiv gemacht. Typische Frickelei
a'la Micros~1 halt. Euphemistisch abwärtskompatibel genannt.

>> Ich meine eigentlich: innerhalb von SQL-Queries. Das schließt natürlich
>> die CREATE Statements ein. Ist aber eben blöd, wenn man nach
>>
>> CREATE DATABASE FOO;
>> SHOW DATABASES;
>>
>> die neue Datenbank als "Foo" angezeigt bekommt.
>
> Wichtig ist, wie die Programme sie sehen. Sehen diese weiterhin "FOO"
> oder "Foo"? Letzteres würde ich schlicht als Bug bezeichnen.

Das ist ja gerade das Problem. Diese Information kommt 1:1 vom
Filesystem. Ein SHOW DATABASES macht intern in etwa
'find $DATADIR -type d -maxdepth 1'. Analog listet SHOW TABLES die
..frm Files auf. Wenn nun das Filesystem (oder irgendein anderer API-
Layer) den Case zerbröselt - bumm.

> Wie sieht das eigentlich bei InnoDB aus? Gibt es dort auch diese
> Probleme? Dürfte eigentlich nicht.

Jein. Das ist noch eine Spur schärfer. InnoDB *hat* ein internes data
dictionary. Im Prinzip eine interne SQL-Tabelle, die für jede Anwender-
tabelle eine Zeile enthält. Da drin wird der interne Tabellenname als
$DATABASE/$TABLE abgelegt. Allerdings wird das data dictionary nur für
InnoDB-interne Zwecke abgefragt.

>>> Ich sehe an NTFS nichts Kaputtes.
>>
>> Ich schon. Allein die fehlende Dokumentation - und die daraus
>> resultierende Unmöglichkeit, einen Linux-Filesystemtreiber dafür zu
>> schreiben, disqualifiziert NTFS vollständig.
>
> Es gibt genügend NTFS-Treiber für Linux.

Keine vernünftigen. Das Gehampel mit FUSE kann es ja wohl nicht sein.
Da kann ich die NTFS Partition auch gleich dem XP im Giftschra^W VMware
unterjubeln.

>> Mit 5.1 kommt ja ein neues Encoding-Schema [1] für Datenbank-/Tabellen-
>> namen. Aber das GROSS/klein Problem ist damit nicht gelöst.
>
> Ich arbeite noch mit 4.1 (unter SuSE 9.3). Eine Migration auf neuere
> Versionen traue ich mich nicht, da ich hierzu eine komplette,
> funktionierende (!) Webseite upgraden müsste (never change a running
> system).

Unter Linux hast du das Problem ja auch nicht. Du könntest relativ
problemlos zu einem anderen Linux, einem anderen UNIX, ja wahrschein-
lich sogar zu Windows migrieren. Nur wenn dich Windows erst einmal
"gelehrt" hat, daß Groß-/Kleinschreibung egal ist (und daß man den
Rechner kalt ausschalten kann und daß "Reboot" ein funktionierendes
Verfahren zur Behebung von Störungen ist und ...) dann wirst du es
schwer haben, wenn du es irgendwann mal richtig machen mußt.


XL

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: MySQL-NT und MySQL-Linux Inkomptibilität

Axel Schwenke schrieb:

> Claus Reibenstein wrote:
>
>> Axel Schwenke schrieb:
>>
>>> Was ich gerade ausprobiert habe: wenn auf dem Fileserver (Samba)
>>> zwei Files aaa und AAA liegen, [...]
>>
>> Das scheint dann wohl aber eher ein Problem von Samba zu sein.
>> Dieses sollte zwei solche Dateien am Besten gar nicht erst
>> zulassen.
>
> Samba exportiert ja nur ein "richtiges" (d.h. case-sensitives)
> Filesystem. Normalerweise greife ich darauf über NFS zu, das Samba
> ist nur ein Notnagel, damit Windows überhaupt was vom Fileserver
> sieht.

NFS gibt es auch für Windows. Das löst aber das Problem auch nicht.

Du hast also die Dateien nicht über Samba, sondern daran vorbei direkt
auf dem darunter liegenden Filesystem erstellt? Nun, dann hat Samba
natürlich ein Problem.

> Eben. Micros~1 hat zwar irgendwann mal gegrokt, daß die Einschränkung
> auf eine Sorte Buchstaben im Filesystem nicht mehr zeitgemäß ist
> (vermutlich haben sie NTFS ohnehin nur zugekauft und das konnte das
> von sich aus)

Dann sähe es bestimmt besser aus.

> - allerdings haben sie nicht mal reinen Tisch gemacht und auch die
> Layer oben drüber case-sensitiv gemacht. Typische Frickelei a'la
> Micros~1 halt. Euphemistisch abwärtskompatibel genannt.

Dem kann ich leider nur zustimmen.

>> Wichtig ist, wie die Programme sie sehen. Sehen diese weiterhin
>> "FOO" oder "Foo"? Letzteres würde ich schlicht als Bug bezeichnen.
>
> Das ist ja gerade das Problem. Diese Information kommt 1:1 vom
> Filesystem.

Kann eigentlich nicht sein. Der Windows-Explorer zeigt sie ja weiterhin
als FOO an.

> Ein SHOW DATABASES macht intern in etwa 'find $DATADIR -type d
> -maxdepth 1'. Analog listet SHOW TABLES die ..frm Files auf. Wenn nun
> das Filesystem (oder irgendein anderer API- Layer) den Case
> zerbröselt - bumm.

Ich tippe da eher auf den API-Layer.

>> Es gibt genügend NTFS-Treiber für Linux.
>
> Keine vernünftigen. Das Gehampel mit FUSE kann es ja wohl nicht sein.

FUSE kenne ich nicht. Mein Linux (SuSE 9.3) greift problemlos direkt auf
die NTFS-Partitionen zu. Allerdings nur lesend, was für meine Zwecke
aber ausreicht.

> Nur wenn dich Windows erst einmal "gelehrt" hat, daß
> Groß-/Kleinschreibung egal ist (und daß man den Rechner kalt
> ausschalten kann und daß "Reboot" ein funktionierendes Verfahren zur
> Behebung von Störungen ist und ...) dann wirst du es schwer haben,
> wenn du es irgendwann mal richtig machen mußt.

Zum Glück komme ich aus der Unix-Welt, bin also nur begrenzt
Windows-geschädigt :-)

Gruß. Claus