Flux CMS DevBlog

I just committed a bunch of patches to support a MySQL Replication setup.

If you're using MySQL Replication with a master and one or more slaves, you should only write to the master (but you can read from all the slaves). We adjusted now the CMS, that all DB writes go to a different object than the reads. If you don't use replication (and just leave the config as it is), these won't be actually two objects, it's still just one MDB2 object. The popoon_pool class takes care of that.

For developers, this means that they should now use for all there DB write operations $GLOBALS['POOL']->dbwrite and for the read operations $GLOBALS['POOL']->db, as it was before. If you have to read from the DB immediatly after you wrote from and (and you're dependent on the written data), you should also us $GLOBALS['POOL']->dbwrite for reading in that case (cause of possible lag), but really only then. Otherwise you loose all the advantages of MySQL replication :)

People who just want to use that feature in their setup, see the example config file, should be quite self explanatory.

BTW, it's not that Flux CMS is extremely slow that we need that, but we're currently working on a project, which expects a lot of traffic in a short period of time and we want to be better safe than sorry :)

leo @ 10.07.2005 19:01 CEST
Saw the link to the 72h Project in Germany. This is realy a lot of trafic. Hopefully all will go well, we will have also this lot of intrest in switzerland and bitflux cms will work well ;-)