This is actually an interesting scenario because [I addressed this in the DBA StackExchange back on March 29, 2011][1].

The basic idea would be to use MySQL Replication in conjunction with [DRBD][2] and [ucarp][3]

Here is what you would need:

- Two DRBD Clusters, one in each DataCenter
- DRBD Pair at each DataCenter connected via a Crossover Cable (perhaps using 192.168.x.x subnet)
- DRBD Primary has MySQL Running
- DRBD Primary at one DataCenter running MultiMaster Replication with the DRBD Primary at other DataCenter via ucarp (in both directions)
- Any needed read slaves at each Data Center would the DBVIP established for use within MySQL at that DataCenter via ucarp

Having this setup gives you block-level replication within both data centers. If you are using MySQL 5.5, you can have [Semisynchronous Replication][4] send SQL to the other DataCenter without waiting for the SQL to be executed, only acknowledged. This keeps any intermittency that standard MySQL Asynchronous Replication would normally cause a MySQL Master to a minimum.

CAVEAT

This setup will not prevent table corruption, particularly if MyISAM is involved. Even with DRBD, block-replication of a corrupt MyISAM table would produce...you guessed it, a corrupt MyISAM table in the DRBD Secondary. Therefore, it is preferable if all user data were InnoDB. 

  [1]: http://dba.stackexchange.com/questions/1974/mysql-high-availability-failover-and-replication-with-latency/1983#1983
  [2]: http://www.drbd.org/
  [3]: http://www.ucarp.org/project/ucarp
  [4]: http://dba.stackexchange.com/questions/4761/with-mysql-replication-what-level-of-resilience-is-possible/4769#4769