Constans, Camille (C.C.) wrote:
I read the mysql book and they said we shouldnt use
replication for Read and
Write.
We have to set up a master server, only one for writing, and slaves server
for reading. We dont need to have a permanent connection between master and
slaves, that's fun !
Sorry, I was kind of writing in my own special language again. You're
quite right CC, in fact that's basically what I meant.
My idea is to have multiple web servers, each with their slave database.
There will be one master database, presumably remaining on pliny for the
time being. When a web server needs to read the database, it reads its
own local copy. When it needs to write, it contacts pliny (whether pliny
is in the next rack or on the other side of the world), and sends its
updates. Pliny will send all updates to the slaves.
Larousse may also send some read queries to pliny, if pliny isn't too busy.
But as far as I understood, we need to lock the master
for each new slave,
this could take time with Go of data we have....
We already do this for backup. We would just have to record where in the
binary log each backup occurs. Then we would copy the backup dump, set
up the database, inform the slave of where it's up to in the binary log,
and then start the replication.
Andre Engels wrote:
Would it not be better to keep the mirrors read-only,
and have them
redirect to the master for write-access? To have writing in several
places causes significant overhead in avoiding edit conflicts and such.
I'm not too worried about edit conflicts, due to Brion's great new
detection method. It's the "and such" that has me slightly anxious --
i.e. stuff that we haven't thought of yet. At the moment, I don't know
of any particular overhead other than network lag.
It will be slower to write from a remote server, which is why I
suggested editors be redirected to larousse when they log in. About 90%
of editing activity is performed by logged in users.
-- Tim Starling