On Mon, 30 Oct 2000 sasha@stripped wrote:
> As Sinisa has said, it would be better to use the internal replication
> capabilities and just send the update query to the master instead of all
> servers. Then the only issue you have to worry about is what to do when the
> master is down - the rest will be taken care of by the replication code.
Ok great - I'll have a look at the replication features of Mysql
asap. What are you supposed to do if the master fails? Tell another
maching to become the master and just let the old master become a slave
when it becomes available again. If there any built in features to
syncronise the old master with the other databases when it is ready to
> Why do you need to speak the protocol yourself? If you link againt
> libmysqlclient, you will get all the functionality you need to talk to the
> servers. Do you have a reason do go below the provided client API? Even in this
> case, you should still link against libmyclientclient and use the provided
> functions, such as mysql_real_connect() to establish connection, my_net_read()
> and my_net_write() to send/receive individual packets, etc. Look at the sources
> in libmysql/libmysql.c and libmysql/net.c - they are the best documentation.
Thanks, but I think you misunderstood me - I will certainly use the mysql
client library for the communication between the proxy and the database
servers, but I would like to have the proxy act like a normal mysql
database from the clients point of view. This way the clients cannot tell
if they are talking to a mysql database or the sql proxy, and you therefor
don't need to recode the clients of existing systems.
To do that I need to be able to do the server side of the communication,
and as far as I can tell, the libmysqclient library only offer functions
for the client side.
Bye, Peter Korsgaard