Hi!
>>>>> "Matthias" == Matthias Urlichs <smurf@stripped> writes:
Matthias> Hi,
Matthias> sinisa@stripped:
>> In a case of clustering, MySQL part is limited to replication. Read a
>> mailing list archives on the subject.
>>
Matthias> Replication is rather easy. Not so easy is the automatic fallover part.
Matthias> If I send a query, and then the server crashes, what do I do?
Matthias> The client interface doesn't even have the concept of a query timeout,
Matthias> and TCP keepalives take up to two hours to time out. That's too long.
What do you mean? I just tried this by issuing a big query to a
server over TCP/IP and then doing a kill on the mysqld daemon on the
server; The client noticed this at once.
On the other hand, if the server goes done completely (and not only
mysqld), then you have to wait.
Matthias> Basically, I want the client to be able to send a periodic "are you still
Matthias> alive, and what's the status of your work on my query" request.
Matthias> Something like "mysqladmin processes", but limited to reporting on one
Matthias> specific connection, with an overall hard timeout so that I can, if
Matthias> necessary, decide that the server has died and retry the whole thing
Matthias> somewhere else.
With a threaded client this is easy. The problem here is that to
allow the above one would have to change a lot of things how the
socket protocol works; Currently every connection gets a dedicated
thread and no other thread is monitoring the connection.
One could of course change this to a pool of threads and one thread
polling the connections for queries and 'are you alive'
requests. Currently this isn't that high on our TODO list, but we are
thinking of eventually doing this..
Regards,
Monty
PS: Sorry for the late reply; I am still trying to catch up with the
mails that piled up during my vacation.
