(MySQL) Fehlermeldung verrät mir Innenleben!?

[Philipp Hasenfratz]

Halihallo Forumer

ich habe gerade folgendes von der MySQL-DB erhalten:
Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

Die hat mich etwas verwundert und zum Denken angeregt; nachfolgend meine Interpretation
des MySQL-Innenlebens, würde mich interessieren, ob sie wahr ist:

MySQL ist die RDBMS und verwaltet die Ressourcen. Um alle Prozesse und Interaktionen zu
koordinieren ist ein alleiniger, ständig arbeitender Prozess nötig, welcher alle Anfragen
(sequenziell oder parallel, je nach Kontext) abarbeitet; es ist nicht möglich mehrere
Prozesse laufen zu lassen, welche parallel auf die Tablehandler[1] zugreifen (das wäre
katastrophal, da gleichzeitiges, schreibendes Zugreifen auf einen Record zu Datenverlust
führen würde). OK nur ein Prozess, aber mehrere Clients, die schnell bedient werden
wollen und Clientspezifische Daten verwaltet wissen wollen (ThreadID,
last_inserted_id, ...), wie soll das realisiert werden? - Nun denn, eine klassisches
Client-Server-Architektur, wo mehrere Clients (die Server für einen Client einer anderen
Applikation) auf den Server zugreifen und mit ihm über diese
ominöse /var/run/mysqld/mysqld.sock kommunizieren? - Halte ich eigentlich für keine
schlechte Idee, nur: Was wenn diese Datei (aus welchen Gründen auch immer) zerstört
wird (ja, Sockets können auch zerstört werden, aber warum gleich zwei Risiken auf
einmal)? - Was wenn tausende Clients zugleich auf diese Datei zugreifen wollen (klar,
flock, aber wo bleibt hier bitte die Performance?). Zudem das Problem, dass mehrere
Clients über dieselbe Datei kommunizieren (sonst stünde da wohl eine Nummer dabei) und
somit syntaktisch voneinander getrennt werden müssen => Datenserialisierung =>
Performance...
Funktioniert MySQL so? - Wenn nein, wie?

[1] Hier gehe ich davon aus, dass die Koordinierung der Interaktionen von der RDBMS
gesteuert werden und nicht vom Tablehandler; ich glaube in der Realität ist beides
vorhanden (wenn auch auf differierenden abstraken Ebenen).

Viele Grüsse

Philipp

[Odium]

Hallo,

»»es ist nicht möglich mehrere Prozesse laufen zu lassen, welche parallel auf die Tablehandler[1] zugreifen (das wäre katastrophal, da gleichzeitiges, schreibendes Zugreifen auf einen Record zu Datenverlust führen würde).

genaues kann ich dir nicht sagen, aber warum nur ein Prozess? Datensätze können je nach Zugriffsart verschlossen und nach Erledigung wieder geöffnet werden...

Stichworte: Monitor/Semaphore

Odium

[Philipp Hasenfratz]

Halihallo Odium

»»es ist nicht möglich mehrere Prozesse laufen zu lassen, welche parallel auf die Tablehandler[1] zugreifen (das wäre katastrophal, da gleichzeitiges, schreibendes Zugreifen auf einen Record zu Datenverlust führen würde).
genaues kann ich dir nicht sagen, aber warum nur ein Prozess? Datensätze können je nach Zugriffsart verschlossen und nach Erledigung wieder geöffnet werden...
Stichworte: Monitor/Semaphore

Das dachte ich eigentlich auch. Nur hat mich diese .sock Datei zu einer anderen Vermutung
gebracht. Ich hätte es auch anders gelöst, wenn ich mysql hätte programmieren müssen[1].
Nur, um mich nochmals zu wiederholen, hat mich diese "ominöse Datei"(tm) "verunsichert"
und mich zu der Interpretation gebracht, die ich gepostet habe. Ich halte es für absolut
aperformant, wenn alle Interaktionen mit der DB über einen Server-Prozess laufen würden;
OK, eine Zwischenlösung wäre, dass bestimmte, unkritische SELECT's ausgelagert werden...

Würde mich einfach interessieren, was denn die genannte Datei für eine Funktion hat.
Wäre ja möglich, dass da nur temporär Socket-Kommunikation geloggt wird, falls die
Socketverbindung abbricht um so zu ermöglichen, die Daten zu rekonstruieren und den
Datenverlust zu minimieren. Wäre eine andere Möglichkeit, die mir dazu einfällt.

[1] wohlverstanden, ich bin froh, dass nicht ;)   [wegen Umfang]

Viele Grüsse

Philipp