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