Re: You're not using MySQL's built-in replication???
I'm sorry, David Harper 1, it looks like you're either a troll or you don't actually read other people's comments, interjecting instead your personal experiences as though they were valid for all circumstances. I could cheerfully write an application such that it would work just fine with MySQL replication. I could also write one such that it didn't.
MySQL Master-Master replication would work for the application at hand, but it would also be a monumental bitch to set up and maintain. Master-Slave doesn't work and causes muchos big time problems in failover.
I can believe that your personal coding practices - and those of developers you work with - are subconsciously such that they "just work" with master-slave replication. Bully for you. That said, your experiences, tics, mannerisms, and stylistic choices are not present in all members of our species. Different people do different things. This results in configurations that even you, with your vast and phallus-enhancing experience haven't worked with. The job of the sysadmin is to beat the infrastructure into shapes that cope with such things. We don't always get to have things recoded to meet our desires.
Applications need to be aware of replication insomuch as the developers of those applications need avoid doing things that break replication. (Which I call a replication-aware application. It is designed with the idea that you need to do things "properly" from the beginning.)
One scenario in which things go sideways is when your production facing servers can't see the "master" DB at all. They can only see their local copy. (The DBs can talk to one another.) In the failover scenario where the DR site is now the "active" one then the DR site's system will start writing to the slave. Bringing up the primary site won't cause the slave to replicate back it's new data, but the automatics would switch the front-facing servers back. (Politics dictate that if real-time replication were occurring then automated failover and re-transfer would be gun-to-the-head forced.)
The application simply blows up if it cannot write to the DB (every single script writes something, even if it's only tracking data) and thus can't work with a read-only database copy. Worse, if I had a fully active setup on the DR site linked to a slave system I could measure the time before a pointy-haired-boss demanded that we switch our setup to pulling reports off the DR site's copy in minutes. As I said, every page performs writes and your databases suddenly start diverging.
For added fun and games, the web servers running the PHP on the DR site will never be allowed to "see" the master DB. (Routing rules.) The database servers could be set up to tunnel to one another for replication, but items in one site's DMZ would not be allowed to talk to backend systems in another site's DMZ.
These are scenarios that break replication. They are dealing with "real world stuff" that includes politics, bad design choices by developers and more. MySQL master-slave replication does not solve all ills.