Einleitend: Ich mag beides (im Subject erwähnte) nicht besonders -
und bin möglicherweise etwas naiv an das ganze rangegangen. Es ist
auch gut möglich, dass ich in den letzten 2 Stunden beim googlen
massiv die falschen Begriffe verwendet habe - also bitte um
Verzeihung falls das a) "altbekannt" ist und b) total einfach zu
lösen ...

Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
nicht mehr wirklich total super.

Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
Damit die webuser nix umstellen muessen, bleiben alle datenbanken
einfach auf dem einen sql server.

Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
werden schlank gegen den Datenbank-Host abgebogen.

ABER: php versucht krampfhaft den unix domain socket zu verwenden,
wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
drinnen steht (WTF?!)). Ich mag jetzt aus verständlichen Gründen
nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
und "localhost" durch "127.0.0.1" ersetzen ...

Also wie kriege ich auf den socket auf den Webservern? gibt es sowas
wie einen "proxy" dafür? Ich fasse auch ein Master/Slave ins Auge -
jedoch kann man da "mischen" - also master als mysql4 und die slaves
mysql5? Ich sehe auch keinen enormen gewinn darin irgendwas zu
replizieren (am besten überhaupt nix) - ich will nur die queries
durchgereicht haben. Wenn ich also *keine* datenbanken bei den
replicate-do-db= einträgen angebe - gibts die an den slaves dann
trozdem?

Oder Übersehe ich hier noch eine ganz einfache und naheliegende
Möglichkeit? Am allerliebsten wäre mir ein "promitiv-proxy", der
einfach nur /tmp/mysql.sock abgreift uns das am Datenbank-host
ebendort wieder einwirft? Gibts sowas fertig oder muss man das
selbst machen?

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Hallo,

Clemens Zauner wrote:
> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
> drinnen steht (WTF?!)). Ich mag jetzt aus verständlichen Gründen

Ist immer so.

> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
> und "localhost" durch "127.0.0.1" ersetzen ...

man sed :]

Vielleicht hilft das weiter?

| mysqli.default_port string
|
| The default TCP port number to use when connecting to the database
| server if no other port is specified. If no default is specified, the
port will
| be obtained from the MYSQL_TCP_PORT environment variable, the
| mysql-tcp entry in /etc/services or the compile-time MYSQL_PORT constant,
| in that order. Win32 will only use the MYSQL_PORT constant.

Ich vermute (!), dass du per
| php_admin_value mysqli.default_port "127.0.0.1:3301"
(oder was auch immer der Port ist) in der Lage sein solltest,
standardmäßig eine TCP-Verbindung statt eines Unix-Sockets zu erzwingen.
Wie gesagt, nur eine Vermutung, hier ist wohl Trial-and-Error angesagt :)

Viele Grüße,
Michael

Clemens Zauner <cz+usenet [at] onlineloop.com> wrote:
>
> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
> nicht mehr wirklich total super.

Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
problems mit der gebotenen Sorgfalt erfolgt ist.

> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).

Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.

> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
> einfach auf dem einen sql server.

Diesen Satz verstehe ich nicht. Aber egal.

> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
> werden schlank gegen den Datenbank-Host abgebogen.

Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
irgendwie "umbiegen"?

> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
> drinnen steht (WTF?!)).

Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
auf Betriebssystemen, die keine UNIX-Sockets haben.

> Ich mag jetzt aus verständlichen Gründen
> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
> und "localhost" durch "127.0.0.1" ersetzen ...

M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
daß alle PHP-Applikationen dirty hacks sein müßten.

Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
weise die Applikationen, für die das einfach geht. Dem Rest kannst du
schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
schlechter Performance leben müssen.

> Also wie kriege ich auf den socket auf den Webservern? gibt es sowas
> wie einen "proxy" dafür?

Es spricht nichts dagegen, einen Proxy zu machen, der zwischen einem
UNIX-Socket und einem entfernten INET-Socket vermittelt. Ich kenne
kein solches Programm (aber vielleicht Google). Ich halte das auch für
eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.


XL

Michael Ziegler <haettstegern [at] hoster.invalid> wrote:
> Clemens Zauner wrote:
>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>> drinnen steht (WTF?!)). Ich mag jetzt aus verständlichen Gründen
>
> Ist immer so.

Wie soll ich sagen ... "brilliant". Ehrlich.

>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>> und "localhost" durch "127.0.0.1" ersetzen ...
>
> man sed :]

Hnnng. ich vermute, das macht mehr kaputt... Denn einfach "localhost"
durch 127.0.0.1 zu ersetzen hat sicher in mindestens einem Fall
irgendeinen nebeneffekt (weils in dem Fall z.B. gerade nix mit
mysql zu tun hat).

> Vielleicht hilft das weiter?
>
> | mysqli.default_port string

Ummm die verwenden fast alle anscheinend nicht mysqli sondern das normale
mysql, zum beispiel mit aufrufen ala "$this->db = mysql_connect($h,$u,$p);"
sonst müsste es ja "mysqli_connect(...);" sein, oder?

> Ich vermute (!), dass du per
> | php_admin_value mysqli.default_port "127.0.0.1:3301"

Ich habs mit mysqli.default_port und mysql.default_port versucht; vergeblich,
auch verschiedene values (also ohne host-part, ...) - Auswirkungen null.

> (oder was auch immer der Port ist) in der Lage sein solltest,
> standardmäßig eine TCP-Verbindung statt eines Unix-Sockets zu erzwingen.

Ja - *genau* das möchte ich. Es wäre ja schon viel gewonnen, wenn
die "intelligenz" von dem zeug so weitgehend wäre bei einem connect
nach "localhost" bei offensichtlicher Abwesenheit des Sockets
dann doch eine TCP-Session zu "probieren".

> Wie gesagt, nur eine Vermutung, hier ist wohl Trial-and-Error angesagt :)

Ich hatte schon einiges an "Trial" und genausoviel "Error". Hmmpf.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Clemens Zauner <cz+usenet [at] onlineloop.com> wrote:
> Michael Ziegler <haettstegern [at] hoster.invalid> wrote:
>> Clemens Zauner wrote:
>>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>>> drinnen steht (WTF?!)). Ich mag jetzt aus verständlichen Gründen
>>
>> Ist immer so.
>
> Wie soll ich sagen ... "brilliant". Ehrlich.

http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.ht ml

"MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, ...

mysql_real_connect() attempts to establish a connection to a MySQL
database engine running on host.
....

The value of host may be either a hostname or an IP address. If host
is NULL or the string "localhost", a connection to the local host is
assumed. For Windows, the client connects using a shared-memory
connection, if the server has shared-memory connections enabled.
Otherwise, TCP/IP is used. For Unix, the client connects using a Unix
socket file. For local connections, you can also influence the type of
connection to use with the MYSQL_OPT_PROTOCOL or MYSQL_OPT_NAMED_PIPE
options to mysql_options(). The type of connection must be supported by
the server. For a host value of "." on Windows, the client connects
using a named pipe, if the server has named-pipe connections enabled.
If named-pipe connections are not enabled, an error occurs."


http://dev.mysql.com/doc/refman/5.0/en/mysql-options.html

"int mysql_options(MYSQL *mysql, enum mysql_option option,
const char *arg)

Can be used to set extra connect options and affect behavior for a
connection.
....

MYSQL_OPT_PROTOCOL (argument type: unsigned int *)

Type of protocol to use. Should be one of the enum values of
mysql_protocol_type defined in mysql.h."


mysql.h:

enum mysql_protocol_type
{
MYSQL_PROTOCOL_DEFAULT, MYSQL_PROTOCOL_TCP, MYSQL_PROTOCOL_SOCKET,
MYSQL_PROTOCOL_PIPE, MYSQL_PROTOCOL_MEMORY
};


-> man *kann* das hacken - wenn man es kann ;-)


XL

Axel Schwenke <axel.schwenke [at] gmx.de> wrote:
> The value of host may be either a hostname or an IP address. If host
> is NULL or the string "localhost", a connection to the local host is
> assumed. For Windows, the client connects using a shared-memory

Nutzt nix, das hatte ich recht rasch rausgefunden. Ich finds trotzdem
*dämlich*.

> -> man *kann* das hacken - wenn man es kann ;-)

Das ist alles ganz schon und gut; aber umschreiben ist nicht. das Teil
sollte wartbar bleiben. Immerhin haben ich die letzten 3 Monate damit
verbracht solche "loesungen" wieder zu entfernen.

Ist die Software wirklich so selbst herrlich, das nicht als tunable
zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
zur Suche, vermute aber immer mehr eine eine solche ganz woanders.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Axel Schwenke <axel.schwenke [at] gmx.de> wrote:
>> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
>> nicht mehr wirklich total super.
>
> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
> problems mit der gebotenen Sorgfalt erfolgt ist.

Das sei dir unbenommen.

>> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
>
> Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
> einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.

Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
Architektur hat gewisse Grenzen.

>> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
>> einfach auf dem einen sql server.
>
> Diesen Satz verstehe ich nicht. Aber egal.

Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
gar nichts anzugehen. Das skaliert. Als allererstes liegt es mir mal
am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
nicht mehr das, was ich unter "wartbar" verstehe).
Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
ist total hypsch redundant. Und wenn die Leistung knapp wird,
schnallt man halt noch mehr http-frontends dran.

Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
aber Essig mit dem Ansatz "ein Datenbankhost".
Nämlich genau wegen dem default-verhalten bei "localhost".

>> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
>> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
>> werden schlank gegen den Datenbank-Host abgebogen.
>
> Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
> glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
> irgendwie "umbiegen"?

Ja, klar. Geht die php-Dinger ja quasi genau gar nix an wo die Datenbank
läuft.

>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>> drinnen steht (WTF?!)).
>
> Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
> auf Betriebssystemen, die keine UNIX-Sockets haben.

Hmmm. Das eröffnet jetzt möglichkeiten. Mal die compile-flags durchsehen,
eventuell gibts sowas wie --has-no-domain-sockets.

>> Ich mag jetzt aus verständlichen Gründen
>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>> und "localhost" durch "127.0.0.1" ersetzen ...
>
> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".

Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
Letztere haben so den Vorteil dass sie leicht austauschbar sind.
Und quasi beliebig vervielfältigt werden können.
Backup/Restore ist in so einer Umgebung ein leichtes. Und Mission-
Critical sind nur mehr File- und Datenbankstorage, sowie der balancer
vorne.

> Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
> Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
> 95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
> etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
> daß alle PHP-Applikationen dirty hacks sein müßten.

Ja. *allerdings* lauft auf dem ding nicht eine App sondern ein paar
hundert. Ich bin mir sicher, dass die Inhaber der jeweiligen Web-
präsenzen nicht mehr im geringsten wissen, wer ihnen das vor Jahren
gecoded hat.

> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
> schlechter Performance leben müssen.

Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
extrem unaufgeräumt und nervig in der Maintainance.

> eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
> Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.

Glaube mir, ich starre das Drama schon einige Zeit an. Bisher hatte
ich zum Glück immer drängendere Baustellen (Mail, DNS, ..) gefunden.
Aber so langsam würde ich die Sache mit den Webservern angehen.
Eigentlich hatte ich mir das für Mai vorgenommen. Und abgesehen
von dem nervigen fall-back aufs Socket täte das ja ganz hypsch
funktionieren (es gibt Leute ohne php/mysql kombinationen).

Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
(wenn kein socket da, dann probiere doch mal TCP ...).

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Eine (zugegebenermassen nicht schöne) Lösung wäre einfach ein ssh Tunnel.

Du brauchst auf dem DB-Server einen SSH-Server und möglichst einen
dedzierten Benutzer (z.B. "dbtunnel").

Anschließend startest Du auf dem Webserver

ssh -Nfg -i -L3306:127.0.0.1:3306 dbtunnel [at] datenbankserver

Anschließend verlangt der Client nach dem Passwort von dbtunnel. Eine
Alternative wäre der Login via OpenSSH Schlüssel.

Damit öffnest Du einen Tunnel, der auf 127.0.0.1 alle Anfragen auf Port
3306 entgegennimmt, an den Datenbankserver weiterleitet und dort an den
Port 3306 weitergibt.

Der Charme dieser Lösung ist, daß das Forwarding für MySQL vollkommen
transparent ist, und du keinerlei Anpassungen an den Benutzerrechten des
MySQL Servers vornehmen musst. Es muß dort noch nicht einmal der Port
3306 offen sein, Port 22 reicht.

Du solltest nur die Timeout-Optionen des SSH Servers (auf dem DB-Host)
und des SSH Clients (auf dem Web-Host) noch etwas tunen, daß hier die
Verbindung nicht regelmäßig abgebrochen wird.



Grüße,


Alex



Clemens Zauner schrieb:
> Axel Schwenke <axel.schwenke [at] gmx.de> wrote:
>>> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
>>> nicht mehr wirklich total super.
>> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
>> problems mit der gebotenen Sorgfalt erfolgt ist.
>
> Das sei dir unbenommen.
>
>>> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
>> Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
>> einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.
>
> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
> Architektur hat gewisse Grenzen.
>
>>> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
>>> einfach auf dem einen sql server.
>> Diesen Satz verstehe ich nicht. Aber egal.
>
> Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
> Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
> gar nichts anzugehen. Das skaliert. Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).
> Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
> ist total hypsch redundant. Und wenn die Leistung knapp wird,
> schnallt man halt noch mehr http-frontends dran.
>
> Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
> auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
> aber Essig mit dem Ansatz "ein Datenbankhost".
> Nämlich genau wegen dem default-verhalten bei "localhost".
>
>>> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
>>> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
>>> werden schlank gegen den Datenbank-Host abgebogen.
>> Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
>> glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
>> irgendwie "umbiegen"?
>
> Ja, klar. Geht die php-Dinger ja quasi genau gar nix an wo die Datenbank
> läuft.
>
>>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>>> drinnen steht (WTF?!)).
>> Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
>> auf Betriebssystemen, die keine UNIX-Sockets haben.
>
> Hmmm. Das eröffnet jetzt möglichkeiten. Mal die compile-flags durchsehen,
> eventuell gibts sowas wie --has-no-domain-sockets.
>
>>> Ich mag jetzt aus verständlichen Gründen
>>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>>> und "localhost" durch "127.0.0.1" ersetzen ...
>> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
>
> Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
> entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
> Letztere haben so den Vorteil dass sie leicht austauschbar sind.
> Und quasi beliebig vervielfältigt werden können.
> Backup/Restore ist in so einer Umgebung ein leichtes. Und Mission-
> Critical sind nur mehr File- und Datenbankstorage, sowie der balancer
> vorne.
>
>> Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
>> Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
>> 95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
>> etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
>> daß alle PHP-Applikationen dirty hacks sein müßten.
>
> Ja. *allerdings* lauft auf dem ding nicht eine App sondern ein paar
> hundert. Ich bin mir sicher, dass die Inhaber der jeweiligen Web-
> präsenzen nicht mehr im geringsten wissen, wer ihnen das vor Jahren
> gecoded hat.
>
>> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
>> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
>> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
>> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
>> schlechter Performance leben müssen.
>
> Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
> extrem unaufgeräumt und nervig in der Maintainance.
>
>> eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
>> Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.
>
> Glaube mir, ich starre das Drama schon einige Zeit an. Bisher hatte
> ich zum Glück immer drängendere Baustellen (Mail, DNS, ..) gefunden.
> Aber so langsam würde ich die Sache mit den Webservern angehen.
> Eigentlich hatte ich mir das für Mai vorgenommen. Und abgesehen
> von dem nervigen fall-back aufs Socket täte das ja ganz hypsch
> funktionieren (es gibt Leute ohne php/mysql kombinationen).
>
> Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
> nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
> (wenn kein socket da, dann probiere doch mal TCP ...).
>
> cu
> Clemens.

Eine (zugegebenermassen nicht schöne) Lösung wäre einfach ein ssh Tunnel.

Du brauchst auf dem DB-Server einen SSH-Server und möglichst einen
dedzierten Benutzer (z.B. "dbtunnel").

Anschließend startest Du auf dem Webserver

ssh -Nfg -L3306:127.0.0.1:3306 dbtunnel [at] datenbankserver

Anschließend verlangt der Client nach dem Passwort von dbtunnel. Eine
Alternative wäre der Login via OpenSSH Schlüssel.

Damit öffnest Du einen Tunnel, der auf 127.0.0.1 alle Anfragen auf Port
3306 entgegennimmt, an den Datenbankserver weiterleitet und dort an den
Port 3306 weitergibt.

Der Charme dieser Lösung ist, daß das Forwarding für MySQL vollkommen
transparent ist, und du keinerlei Anpassungen an den Benutzerrechten des
MySQL Servers vornehmen musst. Es muß dort noch nicht einmal der Port
3306 offen sein, Port 22 reicht.

Du solltest nur die Timeout-Optionen des SSH Servers (auf dem DB-Host)
und des SSH Clients (auf dem Web-Host) noch etwas tunen, daß hier die
Verbindung nicht regelmäßig abgebrochen wird.



Grüße,


Alex



Clemens Zauner schrieb:
> Axel Schwenke <axel.schwenke [at] gmx.de> wrote:
>>> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
>>> nicht mehr wirklich total super.
>> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
>> problems mit der gebotenen Sorgfalt erfolgt ist.
>
> Das sei dir unbenommen.
>
>>> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
>> Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
>> einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.
>
> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
> Architektur hat gewisse Grenzen.
>
>>> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
>>> einfach auf dem einen sql server.
>> Diesen Satz verstehe ich nicht. Aber egal.
>
> Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
> Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
> gar nichts anzugehen. Das skaliert. Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).
> Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
> ist total hypsch redundant. Und wenn die Leistung knapp wird,
schnallt man halt noch mehr http-frontends dran.
>
> Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
> auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
aber Essig mit dem Ansatz "ein Datenbankhost".
> Nämlich genau wegen dem default-verhalten bei "localhost".
>>> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
>>> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
>>> werden schlank gegen den Datenbank-Host abgebogen.
>> Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
>> glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
>> irgendwie "umbiegen"?
>
> Ja, klar. Geht die php-Dinger ja quasi genau gar nix an wo die Datenbank
> läuft.
>
>>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>>> drinnen steht (WTF?!)).
>> Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
>> auf Betriebssystemen, die keine UNIX-Sockets haben.
>
> Hmmm. Das eröffnet jetzt möglichkeiten. Mal die compile-flags durchsehen,
> eventuell gibts sowas wie --has-no-domain-sockets.
>
>>> Ich mag jetzt aus verständlichen Gründen
>>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>>> und "localhost" durch "127.0.0.1" ersetzen ...
>> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
>
> Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
> entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
> Letztere haben so den Vorteil dass sie leicht austauschbar sind.
> Und quasi beliebig vervielfältigt werden können.
> Backup/Restore ist in so einer Umgebung ein leichtes. Und Mission-
> Critical sind nur mehr File- und Datenbankstorage, sowie der balancer
> vorne.
>> Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
>> Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
>> 95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
>> etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
>> daß alle PHP-Applikationen dirty hacks sein müßten.
>
> Ja. *allerdings* lauft auf dem ding nicht eine App sondern ein paar
hundert. Ich bin mir sicher, dass die Inhaber der jeweiligen Web-
> präsenzen nicht mehr im geringsten wissen, wer ihnen das vor Jahren
> gecoded hat.
>
>> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
>> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
>> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
>> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
>> schlechter Performance leben müssen.
>
> Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
> extrem unaufgeräumt und nervig in der Maintainance.
>
>> eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
>> Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.
>
> Glaube mir, ich starre das Drama schon einige Zeit an. Bisher hatte
> ich zum Glück immer drängendere Baustellen (Mail, DNS, ..) gefunden.
> Aber so langsam würde ich die Sache mit den Webservern angehen.
> Eigentlich hatte ich mir das für Mai vorgenommen. Und abgesehen
> von dem nervigen fall-back aufs Socket täte das ja ganz hypsch
> funktionieren (es gibt Leute ohne php/mysql kombinationen).
>
> Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
> nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
> (wenn kein socket da, dann probiere doch mal TCP ...).
>
> cu
> Clemens.


Clemens Zauner schrieb:
> Axel Schwenke <axel.schwenke [at] gmx.de> wrote:
>>> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
>>> nicht mehr wirklich total super.
>> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
>> problems mit der gebotenen Sorgfalt erfolgt ist.
>
> Das sei dir unbenommen.
>
>>> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
>> Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
>> einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.
>
> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
> Architektur hat gewisse Grenzen.
>
>>> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
>>> einfach auf dem einen sql server.
>> Diesen Satz verstehe ich nicht. Aber egal.
>
> Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
> Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
> gar nichts anzugehen. Das skaliert. Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).
> Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
> ist total hypsch redundant. Und wenn die Leistung knapp wird,
> schnallt man halt noch mehr http-frontends dran.
>
> Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
> auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
> aber Essig mit dem Ansatz "ein Datenbankhost".
> Nämlich genau wegen dem default-verhalten bei "localhost".
>
>>> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
>>> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
>>> werden schlank gegen den Datenbank-Host abgebogen.
>> Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
>> glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
>> irgendwie "umbiegen"?
>
> Ja, klar. Geht die php-Dinger ja quasi genau gar nix an wo die Datenbank
> läuft.
>
>>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>>> drinnen steht (WTF?!)).
>> Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
>> auf Betriebssystemen, die keine UNIX-Sockets haben.
>
> Hmmm. Das eröffnet jetzt möglichkeiten. Mal die compile-flags durchsehen,
> eventuell gibts sowas wie --has-no-domain-sockets.
>
>>> Ich mag jetzt aus verständlichen Gründen
>>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>>> und "localhost" durch "127.0.0.1" ersetzen ...
>> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
>
> Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
> entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
> Letztere haben so den Vorteil dass sie leicht austauschbar sind.
> Und quasi beliebig vervielfältigt werden können.
> Backup/Restore ist in so einer Umgebung ein leichtes. Und Mission-
> Critical sind nur mehr File- und Datenbankstorage, sowie der balancer
> vorne.
>
>> Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
>> Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
>> 95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
>> etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
>> daß alle PHP-Applikationen dirty hacks sein müßten.
>
> Ja. *allerdings* lauft auf dem ding nicht eine App sondern ein paar
> hundert. Ich bin mir sicher, dass die Inhaber der jeweiligen Web-
> präsenzen nicht mehr im geringsten wissen, wer ihnen das vor Jahren
> gecoded hat.
>
>> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
>> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
>> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
>> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
>> schlechter Performance leben müssen.
>
> Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
> extrem unaufgeräumt und nervig in der Maintainance.
>
>> eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
>> Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.
>
> Glaube mir, ich starre das Drama schon einige Zeit an. Bisher hatte
> ich zum Glück immer drängendere Baustellen (Mail, DNS, ..) gefunden.
> Aber so langsam würde ich die Sache mit den Webservern angehen.
> Eigentlich hatte ich mir das für Mai vorgenommen. Und abgesehen
> von dem nervigen fall-back aufs Socket täte das ja ganz hypsch
> funktionieren (es gibt Leute ohne php/mysql kombinationen).
>
> Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
> nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
> (wenn kein socket da, dann probiere doch mal TCP ...).
>
> cu
> Clemens.

On 7 Mai, 23:58, Clemens Zauner <cz+use... [at] onlineloop.com> wrote:
> Nutzt nix, das hatte ich recht rasch rausgefunden. Ich finds trotzdem
> *dämlich*.

"It's not a bug ... it's a feature" ... nachdem MySQL seine Wurzeln
bei mSQL (Minerva bzw. Mini-SQL) hat und es eigentlich von dort her
stammt, ist das =DCbel schon *sehr* alt ;-) Schon damals wurde das so
gehandhabt, dass "localhost" auf Unix-Sockets geht und nicht via TCP/
IP ... mit dem Murks unter Windows habe ich mich schon ausgiebig
auseinander gesetzt: Es soll funktionieren, aber einer von beiden hat
geschlampt ... entweder MySQL mit ihrem Windows-Port oder das PHP-Team
- mir ist es noch nicht gelungen, unter Windows statt per TCP/IP über
was anderes zu gehen ...

Egal: Auch wenn es eine Schweinearbeit ist - letzten Endes macht es
durchaus Sinn, die *ganzen* PHP-Skripte durchzuforsten und die Zugänge
zu MySQL auf einen Nenner (sprich: php.ini) zu bringen! Es ist höchst
grausam und gefährlich, solche Connections im PHP-Skript zu
definieren ... welche Datenbank (auf einem Server) verwendet werden
soll, dann kann angehen, aber User/Passwort/Host/Port haben dort
nichts verloren.

Insofern: Mach' Dir einmal die Arbeit, aber dann hast Du's sauber! Und
dann brauchst Du keine Tunnel-Bastellösungen mehr ...

> Ist die Software wirklich so selbst herrlich, das nicht als tunable
> zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
> zur Suche, vermute aber immer mehr eine eine solche ganz woanders.

Du schreibst was von "php" - was willst Du dann mit "my.cnf"? Das, was
Du suchst, ist in der "php.ini" ...

Gruß, Dirk

Clemens Zauner!

> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
> Architektur hat gewisse Grenzen.

64 GiB ab Pentium. Sollte reichen. Wenn man freilich am Board gespart
hat...


Gruß
Daniel

On 8 Mai, 08:46, Daniel Fischer <s... [at] erinye.com> wrote:
>> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
>> Architektur hat gewisse Grenzen.
> 64 GiB ab Pentium. Sollte reichen. Wenn man freilich am Board gespart
> hat...

Speicher und mehr als 32 Bit machen nur Sinn, wenn man vorher schon
alle Möglichkeiten ausgeschöpft hat ... von einer Trennung in zwei
oder mehr Systeme - WWW- und DB-Server getrennt - verspreche ich mir
auch mehr als vor einer Monster-Maschine. Billige Hardware hat den
Vorteil, dass sie leicht ausgetauscht ist ... siehe Prinzip "Google".
Zwei Maschinen, das heisst auch, dass die I/O getrennt ist und ein WWW-
Server hat u.U. ganz schön viel I/O ...

Gruß, Dirk

Clemens Zauner schrieb:

> Ist die Software wirklich so selbst herrlich, das nicht als tunable
> zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
> zur Suche, vermute aber immer mehr eine eine solche ganz woanders.

Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein
include-File, welches den Servernamen als Konstante oder Variable
definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
Thema "unfähigkeit"), der sich nun fürchterlich rächt. Diesen solltest
Du _jetzt_ ein- für allemal ausmerzen, anstatt zu versuchen, dieses
verkorkste Design von außen durch einen nicht minder verkorksten
Würgaround "lösen" zu wollen.

Gruß. Claus

Claus Reibenstein schrieb:
>
> Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
> hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein
> include-File, welches den Servernamen als Konstante oder Variable
> definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
> Thema "unfähigkeit"), der sich nun fürchterlich rächt. Diesen solltest
> Du _jetzt_ ein- für allemal ausmerzen, anstatt zu versuchen, dieses
> verkorkste Design von außen durch einen nicht minder verkorksten
> Würgaround "lösen" zu wollen.

Wenn das Skripte von Dritten sind, hat er gar nicht die Möglichkeit,
viel daran rumzuändern.
Und am expliziten Konfigurieren von user/host/port/passwort kommt man
beim Schreiben von PHP-Skripten in der Regel auch nicht herum.
Schließlich soll ja jeder, der auf einem Host untergebracht ist, seine
eigene Datenbank verwenden und nicht alle die gleiche.

Ich fürchte, da bleibt nichts anderes, als den Administratoren der
einzelnen Skripte den Umzug auf den neuen Datenbankhost schmackhaft zu
machen.
Oder, alternativ, eine Proxylösung zu finden und zu installieren. (Dazu
weiß ich aber nichts. Nach den bisherigen Reaktionen zu schließen, weiß
es auch sonst keiner hier.)

Grüße
Jo

On 8 Mai, 09:56, Joachim Durchholz <j... [at] durchholz.org> wrote:
> Wenn das Skripte von Dritten sind, hat er gar nicht die Möglichkeit,
> viel daran rumzuändern.

=DCberleg' mal, was Du da schreibst! Wenn das Auftragsarbeit ist und man
nimmt das *so* ab ... also da hat doch jemand ganz gewaltig bei seinen
Hausaufgaben geschlampt! Und welches gut strukturierte Projekt kennst
Du, bei dem man nicht an einer Stelle, sondern an 100 hart kodierte
Konfigurationssequenzen vorfindet?

> Und am expliziten Konfigurieren von user/host/port/passwort kommt man
> beim Schreiben von PHP-Skripten in der Regel auch nicht herum.
> Schließlich soll ja jeder, der auf einem Host untergebracht ist, seine
> eigene Datenbank verwenden und nicht alle die gleiche.

Ja, aber das ist nicht an 100 Stellen, sondern jeweils zentral in
einer Include-Datei! Oder hälst Du es für verantwortbar, dass bei x
Installationen weltweit jedesmal derselbe User mit demselben Passwort
Anwendung findet?

> Oder, alternativ, eine Proxylösung zu finden und zu installieren.

Grausam ... und bei einem Unix-Socket wohl kaum machbar, es sei denn,
man schreibt sich selber einen Proxy von Unix Socket nach TCP/IP-
Socket ...

Gruß, Dirk

Clemens Zauner schrieb:
> Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).

Doch, das geht. suexec+fastcgi+php-fcgi löst das.
Erfordert allerdings ein paar Dateien im Rootverzeichnis jeder
DocumentRoot; Apache handhabt die CGI-Konfiguration in dieser Hinsicht
reichlich dämlich.

> Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
> nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
> (wenn kein socket da, dann probiere doch mal TCP ...).

Jetzt mal davon abgesehen, dass es jedem Standard spottet, wenn man
zwischen localhost und 127.0.0.1 unterscheidet. Das ist wirklich Quark -
aber mysql macht's halt so.

Grüße
Jo

Dirk Ohme schrieb:
>
> Speicher und mehr als 32 Bit machen nur Sinn, wenn man vorher schon
> alle Möglichkeiten ausgeschöpft hat ... von einer Trennung in zwei
> oder mehr Systeme - WWW- und DB-Server getrennt - verspreche ich mir
> auch mehr als vor einer Monster-Maschine. Billige Hardware hat den
> Vorteil, dass sie leicht ausgetauscht ist ... siehe Prinzip "Google".
> Zwei Maschinen, das heisst auch, dass die I/O getrennt ist und ein WWW-
> Server hat u.U. ganz schön viel I/O ...

Fragt sich: was für IO?

Meist ist der Flaschenhals die Platte, nicht die RAM-Anbindung. Eine
zweite Platte dürfte da genau so viel bringen wie ein zweiter Server,
aber deutlich weniger Zeit, Geld und Nerven kosten.

Die Austauschbarkeit spricht natürlich eher für eine Zweitmaschine.
Andererseits ist der Administrationsaufwand deutlich höher. Ich spreche
da aus persönlicher Erfahrung: zwei Logs auf Unregelmäßigkeiten
abzuklappern, zwei Maschinen mit Updates zu versorgen, zweimal
regelmäßig Lizenzschlüssel nachzutragen, usw. usw. - und bei zwei
Maschinen lohnt sich eine Automatisierung noch nicht wirklich. (Ab zehn
Maschinen sieht das wieder anders aus.)

Grüße
Jo

Am 08.05.2007 09:57 schrieb Dirk Ohme:
> On 8 Mai, 09:56, Joachim Durchholz <j... [at] durchholz.org> wrote:
>> Wenn das Skripte von Dritten sind, hat er gar nicht die Möglichkeit,
>> viel daran rumzuändern.
>
> Überleg' mal, was Du da schreibst! Wenn das Auftragsarbeit ist und man
> nimmt das *so* ab ... also da hat doch jemand ganz gewaltig bei seinen
> Hausaufgaben geschlampt! Und welches gut strukturierte Projekt kennst
> Du, bei dem man nicht an einer Stelle, sondern an 100 hart kodierte
> Konfigurationssequenzen vorfindet?
>

Wenn ich Clemens richtig verstehe, dann geht es um einen Hoster. D.h.,
die vermieten ihre Rechner samt Software an Leute, die "mal schnell"
irgendwas in PHP/MySQL zusammenhacken. Also vermutlich die Klientel,
die in dieser Gruppe immer wieder aufschlägt mit Fragen nach
Rezeptdatenbanken, Bereinigung von Lücken in auto_increment-Spalten
u.ä. Weder Ahnung vom Programmieren noch Lust oder Zeit, sich damit zu
beschäftigen, und warum sollte man ein Handbuch lesen... Die machen
nun vermutlich das, was sie irgendwo mal aufgeschnappt haben, nämlich
mysql_connect() mit den "passenden" Parametern aufzurufen.

Ein Hoster könnte sich die Arbeit machen, seine User zu erziehen. Aber
warum sollte er? Das kostet Geld, treibt also den Preis für sein
Angebot nach oben und Kunden von ihm weg.

>> Und am expliziten Konfigurieren von user/host/port/passwort kommt man
>> beim Schreiben von PHP-Skripten in der Regel auch nicht herum.
>> Schließlich soll ja jeder, der auf einem Host untergebracht ist, seine
>> eigene Datenbank verwenden und nicht alle die gleiche.
>
> Ja, aber das ist nicht an 100 Stellen, sondern jeweils zentral in
> einer Include-Datei! Oder hälst Du es für verantwortbar, dass bei x
> Installationen weltweit jedesmal derselbe User mit demselben Passwort
> Anwendung findet?
>

Nun, es dürften verschiedene sein.

>> Oder, alternativ, eine Proxylösung zu finden und zu installieren.
>
> Grausam ... und bei einem Unix-Socket wohl kaum machbar, es sei denn,
> man schreibt sich selber einen Proxy von Unix Socket nach TCP/IP-
> Socket ...

Da MySQL Open Source ist, gibt es noch eine andere Lösung. So oft
aktualisieren Hoster ihre Installationen ja ohnehin nicht, da kann man
auch mal in den Quellen von MySQL 5.0.x rumbasteln. Das hält dann
vielleicht bis 6.1 ;-)

Am 08.05.2007 10:01 schrieb Joachim Durchholz:

> Jetzt mal davon abgesehen, dass es jedem Standard spottet,

http://www.amazon.de/Dativ-ist-dem-Genitiv-sein/dp/346203448 0/ref=pd_bbs_sr_1/302-3765158-1095225?ie=UTF8&s=books&qid=11 78611807&sr=8-1

Joachim Durchholz <jo [at] durchholz.org> wrote:
> Dirk Ohme schrieb:
>>
>> Speicher und mehr als 32 Bit machen nur Sinn, wenn man vorher schon
>> alle Möglichkeiten ausgeschöpft hat ... von einer Trennung in zwei
>> oder mehr Systeme - WWW- und DB-Server getrennt - verspreche ich mir
>> auch mehr als vor einer Monster-Maschine. Billige Hardware hat den
>> Vorteil, dass sie leicht ausgetauscht ist ... siehe Prinzip "Google".
>> Zwei Maschinen, das heisst auch, dass die I/O getrennt ist und ein WWW-
>> Server hat u.U. ganz schön viel I/O ...
>
> Fragt sich: was für IO?
>
> Meist ist der Flaschenhals die Platte, nicht die RAM-Anbindung. Eine
> zweite Platte dürfte da genau so viel bringen wie ein zweiter Server,
> aber deutlich weniger Zeit, Geld und Nerven kosten.

Genau dieses Herumraten, was denn nun der Flaschenhals ist und ob
es eine Limitation der Hardware-Plattform oder einzelner Hardware-
Komponenten ist - genau das könnte man sich ersparen, wenn man das
Problem erst mal analysieren würde, bevor man in hektische Betrieb-
samkeit verfällt.

Wenn man ein Haus bauen will, macht man ja auch erst das Fundament,
bevor man die Fassade pinselt.


XL

Claus Reibenstein <4spammersonly [at] web.de> wrote:
> Clemens Zauner schrieb:
>
>> Ist die Software wirklich so selbst herrlich, das nicht als tunable
>> zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
>> zur Suche, vermute aber immer mehr eine eine solche ganz woanders.
>
> Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
> hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein
> include-File, welches den Servernamen als Konstante oder Variable
> definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
> Thema "unfähigkeit"), der sich nun fürchterlich rächt.

Wenn ich ihn richtig verstanden habe, sind das gar nicht seine Scripte
sondern die von irgendwelchen Usern/Kunden/whatever. Es ist also nicht
sein Designfehler.


> Diesen solltest Du _jetzt_ ein- für allemal ausmerzen, anstatt zu
> versuchen, dieses verkorkste Design von außen durch einen nicht minder
> verkorksten Würgaround "lösen" zu wollen.

Selbst wenn er den Kunden die richtige Einstellung (IP-Adresse statt
'localhost') vorgegeben hätte, hat er nun sein Problem: alle müssten
ihre Scripte ändern, weil sich die IP ändert. Da ist also nichts
dran zu ändern.

Nicht gleich immer losmotzen ...


Bye

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

Andreas Scherbaum schrieb:

> Claus Reibenstein <4spammersonly [at] web.de> wrote:
>
>> Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
>> hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein
>> include-File, welches den Servernamen als Konstante oder Variable
>> definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
>> Thema "unfähigkeit"), der sich nun fürchterlich rächt.
>
> Wenn ich ihn richtig verstanden habe, sind das gar nicht seine Scripte
> sondern die von irgendwelchen Usern/Kunden/whatever. Es ist also nicht
> sein Designfehler.

Das hat auch niemand behauptet.

>> Diesen solltest Du _jetzt_ ein- für allemal ausmerzen, anstatt zu
>> versuchen, dieses verkorkste Design von außen durch einen nicht minder
>> verkorksten Würgaround "lösen" zu wollen.
>
> Selbst wenn er den Kunden die richtige Einstellung (IP-Adresse statt
> 'localhost')

Es geht nicht um Hostname statt IP-Adresse (was übrigens noch falscher
wäre). Bitte lies noch einmal, was ich geschrieben habe.

> Nicht gleich immer losmotzen ...

Wieso "losmotzen"? Motzen sieht anders aus.

Gruß. Claus

Axel Schwenke schrieb:

> Joachim Durchholz <jo [at] durchholz.org> wrote:
>
> Wenn man ein Haus bauen will, macht man ja auch erst das Fundament,
> bevor man die Fassade pinselt.

Vor allem macht man erst mal einen Plan. Und wenn man dann erst beim
Bauen merkt, dass man die Toiletten vergessen hat, klatscht man halt
schnell noch irgendwelche hässlichen Dinger von außen dran (welches
Krankenhaus war das doch gleich?).

Gruß. Claus

Christian Kirsch schrieb:

> Am 08.05.2007 10:01 schrieb Joachim Durchholz:
>
>> Jetzt mal davon abgesehen, dass es jedem Standard spottet,
>
> http://www.amazon.de/Dativ-ist-dem-Genitiv-sein/dp/346203448 0/ref=pd_bbs_sr_1/302-3765158-1095225?ie=UTF8&s=books&qid=11 78611807&sr=8-1

-v

Gruß. Claus

Claus Reibenstein <4spammersonly [at] web.de> wrote:
>
> Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
> hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein

Ja. Klar.

> include-File, welches den Servernamen als Konstante oder Variable
> definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
> Thema "unfähigkeit"), der sich nun fürchterlich rächt. Diesen solltest

Ich sehe schon - du hast meine Postings entweder nicht gelesen,
oder nicht verstanden. Das sind webpages von *irgendwelchen*
Leuten, Ich denke nicht, dass der anbietende Dienstleiter
derartige Vorschriften machen sollte.

BTW habe ich zumindest schon mal 2 Präsenzen gefunden, die überhaupt
einen ganz anderen DB-Server ganz woanders verwenden.

> Du _jetzt_ ein- für allemal ausmerzen, anstatt zu versuchen, dieses
> verkorkste Design von außen durch einen nicht minder verkorksten
> Würgaround "lösen" zu wollen.

Noch mal: Das ist keine Daddelbox ("root-server") für eine Gruppe/
Person. Dort tummelt sich alles mögliche. Der kleinste gemeinsame
Nenner ist der Account.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Dirk Ohme <dirk_ohme [at] hotmail.com> wrote:
> On 8 Mai, 09:56, Joachim Durchholz <j... [at] durchholz.org> wrote:
>> Wenn das Skripte von Dritten sind, hat er gar nicht die Möglichkeit,
>> viel daran rumzuändern.
>
> Überleg' mal, was Du da schreibst! Wenn das Auftragsarbeit ist und man
> nimmt das *so* ab ... also da hat doch jemand ganz gewaltig bei seinen
> Hausaufgaben geschlampt! Und welches gut strukturierte Projekt kennst
> Du, bei dem man nicht an einer Stelle, sondern an 100 hart kodierte
> Konfigurationssequenzen vorfindet?

Was sollte da wer wo was abnehmen? Das sind hunderte, von einander
absolut unabhängige Projekte. Service alà "Webspace + Database";
Wer von den Accountinhabern was wie wo genau macht - und ob die
überhaupt php und/oder MySQL nutzen bleibt jeweils denen überlassen.

> Ja, aber das ist nicht an 100 Stellen, sondern jeweils zentral in
> einer Include-Datei! Oder hälst Du es für verantwortbar, dass bei x
> Installationen weltweit jedesmal derselbe User mit demselben Passwort
> Anwendung findet?

Ebensoviele User, ebensolviele Passwörter.

>> Oder, alternativ, eine Proxylösung zu finden und zu installieren.
>
> Grausam ... und bei einem Unix-Socket wohl kaum machbar, es sei denn,
> man schreibt sich selber einen Proxy von Unix Socket nach TCP/IP-
> Socket ...

Ich dachte da eher an "Unix Socket<->IP<->Unix Socket". Quasi sowas
wie wie ssh-portforward, nur halt für Unix-Sockets.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Alexander Wühr <aw [at] pdcem.com> wrote:
> Eine (zugegebenermassen nicht schöne) Lösung wäre einfach ein ssh Tunnel.
>

Eben leider *nicht*.

> Anschließend startest Du auf dem Webserver
>
> ssh -Nfg -L3306:127.0.0.1:3306 dbtunnel [at] datenbankserver

Den Portforward habe ich bereits gemacht (ohne ssh-tunnel, es gibt
effizientere Methoden). Ein "mysql [...] -h 127.0.0.1" geht auf den
Webservern. Ich komme aus der Netzwerkecke - und vermeide im
Normalfall nach Massgabe alles über L4. Daher auch mein etwas
- im Nachhinein betrachtet - naiver Ansatz.

Das *Problem* ist das, dass mysql/php bei einem Open auf "localhost"
anstelle "127.0.0.1" nicht TCP-Ports verwendet, sondern ein Unix
Socket (z.B: /tmp/mysql/mysql.sock). Und genau genau *hier* birnts
dann die scripts natürlich mit einem Error auf.

> Der Charme dieser Lösung ist, daß das Forwarding für MySQL vollkommen
> transparent ist, und du keinerlei Anpassungen an den Benutzerrechten des
> MySQL Servers vornehmen musst. Es muß dort noch nicht einmal der Port
> 3306 offen sein, Port 22 reicht.

Portforward reicht leider nicht.

cu
Clemens.

Clemens Zauner <cz+usenet [at] onlineloop.com> wrote:
> Axel Schwenke <axel.schwenke [at] gmx.de> wrote:

[anscheinend zu subtile Hinweise]

>> -> man *kann* das hacken - wenn man es kann ;-)
>
> Das ist alles ganz schon und gut; aber umschreiben ist nicht. das Teil
> sollte wartbar bleiben. Immerhin haben ich die letzten 3 Monate damit
> verbracht solche "loesungen" wieder zu entfernen.

Lies mal hier (und lies *alles*)
http://dev.mysql.com/doc/refman/5.0/en/mysql-options.html

Man *kann* Nutzung des TCP-Protokolls erzwingen. Man *kann* das auch in
eine my.cnf schreiben. Allerdings muß man dem Client explizit sagen,
daß man die Einstellungen aus dieser my.cnf verwenden will. Anscheinend
bietet das die 'mysql' Erweiterung von PHP nicht - aber man könnte es
hineinhacken. Man könnte auch an wenigen strategisch günstigen Stellen
ein mysql_options(..., MYSQL_OPT_PROTOCOL, ...) in den Code einstreuen.


> Ist die Software wirklich so selbst herrlich, das nicht als tunable
> zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
> zur Suche, vermute aber immer mehr eine eine solche ganz woanders.

Deine Anpielungen kannst du dir sonstwohin stecken. MySQL kennt nun mal
das Konzept "lokale Verbindung" und reserviert dafür ein paar magische
Hostnamen. Ob "localhost" eine gute Wahl war, darüber kann man sicher-
lich streiten. Aber nachdem diese Wahl nun mal getroffen wurde, wird
sie mit Sicherheit nicht geändert - Kompatibilität ist zu wichtig.

Der eigentliche Fehler besteht darin, daß PHP-Skripte annehmen, ihr
MySQL-Server müßte immer auf "localhost" laufen. Wenn der Herr PHP-
Pr0gger nur semi-bekloppt war, hat er vielleicht gar keinen Hostnamen
angegeben. In diesem Fall könnte dir mysql.default_host in php.ini aus
der Patsche helfen.


Und bitte versteh mich nicht falsch: du hast mein Mitgefühl dafür, daß
du so einen Haufen Mist supporten mußt. Aber für die Typen die so einen
Scheiß verbrechen, habe ich gar kein Mitgefühl. Also geh und LARTe sie!


XL

Joachim Durchholz <jo [at] durchholz.org> wrote:
> Clemens Zauner schrieb:
>> Als allererstes liegt es mir mal
>> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
>> nicht mehr das, was ich unter "wartbar" verstehe).
^^^^^^^
> Doch, das geht. suexec+fastcgi+php-fcgi löst das.

Das "es geht" weiss ich auch. Ich habe das relevante oben mal
unterstrichen. Und unter "wartbar" verstehe ich nicht, dass ich
das "verstehe" und "handhaben kann" - sondern dass man das
Annähernd *jedem* in bestenfalls einer halben Stunde erklären
kann.

Ich will einfach eine minimale Anzahl von Sonderfällen in
den Konfigurationen.

> Jetzt mal davon abgesehen, dass es jedem Standard spottet, wenn man
> zwischen localhost und 127.0.0.1 unterscheidet. Das ist wirklich Quark -
> aber mysql macht's halt so.

Tja, wenn ich hier nicht in einer mysql-gruppe wäre, würde ich jetzt
ranten.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Christian Kirsch <ck [at] bru6.de> wrote:
> Da MySQL Open Source ist, gibt es noch eine andere Lösung. So oft
> aktualisieren Hoster ihre Installationen ja ohnehin nicht, da kann man
> auch mal in den Quellen von MySQL 5.0.x rumbasteln. Das hält dann
> vielleicht bis 6.1 ;-)

Ich will mich da auf keinen Fall unersetzbar machen. Ich würde das
gerne funktionsfähig abgeben & dann nie wieder anschauen müssen, weil
es einfach funktioniert.

Source-Code gefrickel ist das IMO ein schlechter Ansatz.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Ok, UDP geht nicht, hab ich wohl in den vorherigen Postings überlesen.

Muß der Zugriff unbedingt über UDP erfolgen, oder könnte man nicht
einfach in der my.cnf den Eintrag "skip-networking" auskommentieren?


vlg

Alexander

Clemens Zauner schrieb:
> Alexander Wühr <aw [at] pdcem.com> wrote:
>> Eine (zugegebenermassen nicht schöne) Lösung wäre einfach ein ssh Tunnel.
>>
>
> Eben leider *nicht*.
>
>> Anschließend startest Du auf dem Webserver
>>
>> ssh -Nfg -L3306:127.0.0.1:3306 dbtunnel [at] datenbankserver
>
> Den Portforward habe ich bereits gemacht (ohne ssh-tunnel, es gibt
> effizientere Methoden). Ein "mysql [...] -h 127.0.0.1" geht auf den
> Webservern. Ich komme aus der Netzwerkecke - und vermeide im
> Normalfall nach Massgabe alles über L4. Daher auch mein etwas
> - im Nachhinein betrachtet - naiver Ansatz.
>
> Das *Problem* ist das, dass mysql/php bei einem Open auf "localhost"
> anstelle "127.0.0.1" nicht TCP-Ports verwendet, sondern ein Unix
> Socket (z.B: /tmp/mysql/mysql.sock). Und genau genau *hier* birnts
> dann die scripts natürlich mit einem Error auf.
>
>> Der Charme dieser Lösung ist, daß das Forwarding für MySQL vollkommen
>> transparent ist, und du keinerlei Anpassungen an den Benutzerrechten des
>> MySQL Servers vornehmen musst. Es muß dort noch nicht einmal der Port
>> 3306 offen sein, Port 22 reicht.
>
> Portforward reicht leider nicht.
>
> cu
> Clemens.

Daniel Fischer <spam [at] erinye.com> wrote:
>> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
>> Architektur hat gewisse Grenzen.
>
> 64 GiB ab Pentium. Sollte reichen. Wenn man freilich am Board gespart
> hat...

Nix da. 32-Bit System können in echt 4 GByte adressieren; dann zieht man
noch mal deutlich was für die PCI-Infrastruktur ab. Dei Systeme mit
>4Gbyte funktionieren nach der Rosstäuscher-methode.

Klar, die entsprechenden HW-Vendors behaupten natürlich ganz gerne
wie toll das doch alles sei. Unterm strich ist es halt das alte 64K-Page
switching in einer aufgebohrten Variante.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Joachim Durchholz <jo [at] durchholz.org> wrote:
>> Zwei Maschinen, das heisst auch, dass die I/O getrennt ist und ein WWW-
>> Server hat u.U. ganz schön viel I/O ...
>
> Fragt sich: was für IO?

Alles an IO.

> Meist ist der Flaschenhals die Platte, nicht die RAM-Anbindung. Eine
> zweite Platte dürfte da genau so viel bringen wie ein zweiter Server,
> aber deutlich weniger Zeit, Geld und Nerven kosten.

Wer spricht hier von einer Platte? Zur zeit ist das ein Array,
Das zielsystem/Die Zielsysteme läuft/laufen dann von einem Storage
runter (Sowas macht auch Freude beim backup).

> Die Austauschbarkeit spricht natürlich eher für eine Zweitmaschine.
> Andererseits ist der Administrationsaufwand deutlich höher. Ich spreche
> da aus persönlicher Erfahrung: zwei Logs auf Unregelmäßigkeiten
> abzuklappern, zwei Maschinen mit Updates zu versorgen, zweimal
> regelmäßig Lizenzschlüssel nachzutragen, usw. usw. - und bei zwei
> Maschinen lohnt sich eine Automatisierung noch nicht wirklich. (Ab zehn
> Maschinen sieht das wieder anders aus.)

Das ist kein Problem, und ensprechende Mechanismen sind bereits vorhanden.
Das ganze steht und fällt mit dem mysql-socket.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Hallo Clemens,

> Source-Code gefrickel ist das IMO ein schlechter Ansatz.

Eigentlich lebt ein solches Projekt davon, dass Zusatzfunktionen für die
ein Bedarf besteht nicht auf einem einzelnen Rechner verhungern sondern in
den Source einfliessen.


Siegfried
--
http://www.schmidt.ath.cx

Axel Schwenke <axel.schwenke [at] gmx.de> wrote:
> Genau dieses Herumraten, was denn nun der Flaschenhals ist und ob
> es eine Limitation der Hardware-Plattform oder einzelner Hardware-
> Komponenten ist - genau das könnte man sich ersparen, wenn man das
> Problem erst mal analysieren würde, bevor man in hektische Betrieb-
> samkeit verfällt.

Wie ich schon ein andermal schrieb: Ich betrachte das jetzt schon
seit Monaten. Als "hektische Betriebsamkeit" verstehe ich das nicht.

> Wenn man ein Haus bauen will, macht man ja auch erst das Fundament,
> bevor man die Fassade pinselt.

Tja - eben alles Analysiert und ein Konzept erarbeitet, das auch ein
paar Jährchen halten sollte. Quasi beim Alpha-Testing ist halt das
MySQL-verhalten aufgefallen (Unix Domain vs. IP-Socket).
Gut - ich eventuell etwas blauäugig. Aber auf diese "Feature" bin
ich nicht wirklich bei der Reissbrett-planung gekommen. Wenn das
die totale Frickelware wäre hätte ich mir das vorher sicher genauer
angeschaut. Aber seit ein paar Jahren tönt ja MySQL immer wie
unglaublich professionell das jetzt in der Zwischenzeit sei.

Bei solchen Stunts kann man eigentlich nur mehr den Kopf schütteln.
Und ich kann fast nicht glauben, dass mein Begehr so ungewöhnlich
ist. Es kann ja auch sein, dass man das Verhalten aus Kompatibilitäts-
gründen noch drinnen hat. Aber bis zur version 5-irgendwas waere
ein tunable hier wahrscheinlich a) wenig Arbeit gewesen und hätte
b) sogar einen echten Impact.

Eine andere Option wäre ein lightweigth-Server auf den Webhosts,
die einfach auf den Parent durchreichen - aber das findet sich
zumindest zur Zeit anscheinend auch nicht.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Clemens Zauner!

> Daniel Fischer <spam [at] erinye.com> wrote:
>> 64 GiB ab Pentium. Sollte reichen. Wenn man freilich am Board gespart
>> hat...

^^ Das sollte "ab Pentium Pro" heißen.

> Nix da. 32-Bit System können in echt 4 GByte adressieren; dann zieht man
> noch mal deutlich was für die PCI-Infrastruktur ab. Dei Systeme mit
> >4Gbyte funktionieren nach der Rosstäuscher-methode.

"32-Bit-System" sagt erstmal nichts darüber aus, wieviel Speicher die CPU
adressieren kann, sondern nur, dass sie in einem Takt 32 Bit von irgendwas
verarbeiten kann.

Der 16-Bit-Prozessor 8086 konnte 1 MiB adressieren, der 16-Bit-Prozessor
80286 konnte 16 MiB adressieren, und Intel-x86-CPUs ab Pentium Pro haben
eben einen 36 Bit breiten Adressbus und können daher 64GiB RAM ansprechen
und nicht nur 4GiB.

> Klar, die entsprechenden HW-Vendors behaupten natürlich ganz gerne
> wie toll das doch alles sei. Unterm strich ist es halt das alte 64K-Page
> switching in einer aufgebohrten Variante.

Du suchst "Segmentierung". Page Switching habe ich aus 64k-Zeiten anders
in Erinnerung :-)


Gruß
Daniel

Clemens Zauner <cz+usenet [at] onlineloop.com> wrote:
> Axel Schwenke <axel.schwenke [at] gmx.de> wrote:
>>
>> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
>> problems mit der gebotenen Sorgfalt erfolgt ist.
>
> Das sei dir unbenommen.

Schön. Dann sehen wir mal weiter ...

> Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
> Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
> gar nichts anzugehen. Das skaliert.

Das skaliert nur in dem (unwahrscheinlichen) Fall, daß die Datenbank
Däumchen dreht während Apache/PHP auf dem Zahnfleisch kriechen.

Das Hauptproblem besteht aber darin, daß sich jetzt mehrere
Applikationen beeinflussen. Wenn eine den Datenbankserver mit einem
Tablescan über eine 20GB Tabelle lahm legt, stehen 10 andere
Applikationen weil ihre Datenbank auf die Platte wartet.

> Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).

Schau mal guck. Du hast also noch mehr Probleme vom Typ "Chaos".

> Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
> ist total hypsch redundant. Und wenn die Leistung knapp wird,
> schnallt man halt noch mehr http-frontends dran.

Dieses Rezept ist nur tauglich, wenn es um *eine* Anwendung geht.
Und auch dann wird man früher oder später an die Grenze kommen,
wo die Datenbank das Bottleneck ist. Wenn man Pech hat, ist auch
Replikation keine Lösung und dann hat man ein richtiges Problem!

BTDT

> Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
> auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
> aber Essig mit dem Ansatz "ein Datenbankhost".

Deswegen ist es auch einfacher, Applikation und Datenbank auf *einer*
Maschine zu halten. Es ist noch lange nicht sauber, aber es ist
wenigstens handhabbar.

>> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
>
> Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
> entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
> Letztere haben so den Vorteil dass sie leicht austauschbar sind.
> Und quasi beliebig vervielfältigt werden können.

Nur in der Theorie. In der Praxis hast du mehrere Versionen von MySQL
und PHP. Und womöglich Applikationen, die bestimmte Kombinationen
voraussetzen. Also nix 1x Datenbankserver.

Und ein Proxy kann alle MySQL Anfragen von einem Webserver nur auf
einen Datenbankserver umleiten. Also müssen alle Applikationen schon
mal die gleiche MySQL-Version mögen. Im Endeffekt brauchst du also
für jede Kombination von PHP- und MySQL-Version mindestens einen
Webserver.

>> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
>> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
>> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
>> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
>> schlechter Performance leben müssen.
>
> Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
> extrem unaufgeräumt und nervig in der Maintainance.

Nur wenn man sich ungeschickt anstellt. Als Vorteil bekommt man
wesentlich bessere Möglichkeiten zum Tuning und Monitoring. Wenn 10
Applikationen auf einer Datenbank herumtrampeln, konkurrieren sie
ja z.B. auch um Caches. Es reichen schon 2 Applikationen um sich
gegenseitig die Caches leer zu schießen.


XL

Axel Schwenke <axel.schwenke [at] gmx.de> wrote:
>> Das ist alles ganz schon und gut; aber umschreiben ist nicht. das Teil
>> sollte wartbar bleiben. Immerhin haben ich die letzten 3 Monate damit
>> verbracht solche "loesungen" wieder zu entfernen.
>
> Lies mal hier (und lies *alles*)
> http://dev.mysql.com/doc/refman/5.0/en/mysql-options.html

Du wirst lachen, das hatte ich sogar.

> Man *kann* Nutzung des TCP-Protokolls erzwingen. Man *kann* das auch in
> eine my.cnf schreiben. Allerdings muß man dem Client explizit sagen,

Ich bin mittlerweile darauf gekommen, dass ein "protocol = TCP" in der
my.cnf anscheinend tatsächlich eine Reihe von Clients dazu bringt,
TCP zu verwenden (als default). Genauer gesagt habe ich da einfach
jemanden gefragt, der was davon versteht (von Datenbanken).

> daß man die Einstellungen aus dieser my.cnf verwenden will. Anscheinend
> bietet das die 'mysql' Erweiterung von PHP nicht - aber man könnte es

Ja. php ignoriert das. Anscheinend die ganze my.cnf. So verweifelt war
ich nämlich schon, dass ich nach der Doku in der C-API gesucht habe
(respekt vor dem Dokumentationsansatz).

> Deine Anpielungen kannst du dir sonstwohin stecken. MySQL kennt nun mal
> das Konzept "lokale Verbindung" und reserviert dafür ein paar magische
> Hostnamen. Ob "localhost" eine gute Wahl war, darüber kann man sicher-
> lich streiten. Aber nachdem diese Wahl nun mal getroffen wurde, wird
> sie mit Sicherheit nicht geändert - Kompatibilität ist zu wichtig.

Der Spass an der Sache ist, dass zum Beispiel "LOCALHOST" (oder auch
"LoCaLhOsT" dann sehr wohl über TCP ausweicht.

> Und bitte versteh mich nicht falsch: du hast mein Mitgefühl dafür, daß
> du so einen Haufen Mist supporten mußt. Aber für die Typen die so einen
> Scheiß verbrechen, habe ich gar kein Mitgefühl. Also geh und LARTe sie!

Ich wage mal zu behaupten, dass ein grossteil davon einfach nicht mehr
greifbar ist (gut, /me könnte jetzt nach den l33t coder-pseudonymen
googeln, die sich manchmal oben im Code finden, gleich neben so tollen
Statements wie "Linux RoXX" und d.gl.mehr)...

grml
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Clemens Zauner schrieb im Newsbeitrag
> Was sollte da wer wo was abnehmen? Das sind hunderte,
> von einander absolut unabhängige Projekte.

Dann bastel' Dir halt einen MySQL-Client, der Unix-Sockets deaktiviert
hat ... dann geht alles über TCP/IP. Du brauchst den Client bzw. die
libmysql.a nur einmal erzeugen ... so oft ändert sich das Protokoll
auch nicht, so dass Du bei einer MySQL-Serverumstellung aktiv werden
müsstest ...

Gruß, Dirk

Axel Schwenke schrieb im Newsbeitrag
> Lies mal hier (und lies *alles*)
> http://dev.mysql.com/doc/refman/5.0/en/mysql-options.html
>
> Man *kann* Nutzung des TCP-Protokolls erzwingen.

Mehr noch:
http://www.php.net/manual/en/ini.core.php#ini.sql.safe-mode

Zitat:
"sql.safe_mode boolean
If turned on, database connect functions that specify default values
will use those values in place of supplied arguments. For default
values see connect function documentation for the relevant database."

> Man *kann* das auch in eine my.cnf schreiben.

.... oder sich mit den Möglichkeiten bei PHP auseinander setzen!

Gruß, Dirk