nicht angemeldet
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