MySQL Fragen
Jan-Benedict Glaw
jbglaw at lug-owl.de
Sun Jan 21 17:15:13 CET 2001
On Sat, Jan 20, 2001 at 10:06:54PM +0100, Dennis Wetzig wrote:
> Hi,
>
> ich habe zwei Fragen bzgl. MySQL
>
> a) Hat jemand Erfahrungen damit, was passiert, wenn zwei Datenbankdaemons auf
> ein und denselben Datensatz zugreifen. Ich habe einen NFS-Server auf dem
> mysqlds auf mehreren Systemen auf die selben Datensaetze zugreifen. Geht das
Aua... Locking über NFS funktioniert in keinem Fall richtig (es sei denn,
man stellt ein lock file in place und wartet min. xxxxx sec., bis
der lokale Cache über den Haufen geworden ist. Aber das tut mysql
zum Glück nicht)...
> ueberhaupt? Wenn ja: Sind Aenderungen der Datensaetze dann immer sofort auf
> beiden Systemen sichtbar oder puffert der mysqld Daten zwischen? Wie sieht es
Mysql schreibt die Datensätze, aber das heißt noch lange nicht, daß
sie dann auf der Platte sind; und schon garnicht über NFS...
> mit Tabellocks aus? Ist der Tabel dann nur auf dem mysqld gelockt, der den
> Lock-Befehl bekommen hat, oder auch auf beiden Systemen?
Nur für einen Thread in einem Mysql-Prozeß, also *nur* auf *einem*
der Rechner.
> b) Was passiert, wenn ein mysql-Tabel > 2GByte wird, also das Limit erreicht.
Du kannst keine INSERTs mehr machen, und UPDATEs sind vermutlich
auch nicht mehr drin, weil diese temporär Speicher in der Tabelle
brauchen.
> Wird mysql dann automatisch die Tabelle auf mehrere Dateien splitten?
Nein. Aber das ist auch garnicht nötig. Nimm eine aktuelle glibc, einen
aktuellen Kernel und einen aktuellen mysqld, und das Gespann kann
mit Daten >2GB umgehen (zumindest laut Doku).
> Bin dankbar fuer jeden Tip und Erfahrungswert!
LFS funktioniert eigentlich mittlerweile ganz gut, und wenn man
gleich von vornherein ein 64bit-System benutzt, kann man eigentlich
garkeine Probleme bekommen;)
MfG, JBG
--
Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!!
/* Jan-Benedict Glaw <jbglaw at lug-owl.de> -- +49-177-5601720 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
"insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20010121/be1c3492/attachment.sig>
More information about the Linux
mailing list