I wrote up an interesting layout last year which features DRBD pairs in two data centers (DC1,DC2) with as follows

• DRBD Pair in DC1 (db1 and db2)
• DBVIP for Primary of DRBD Pair1 is 10.1.2.30
• DRBD Pair in DC2 (db3 and db4)
• DBVIP for Primary of DRBD Pair2 is 10.1.2.40
• Have MySQL Circular Replication Between DRBD Primaries
• Have the 10.1.2.40 as Master_Host for DBRD Pair 1
• Have the 10.1.2.30 as Master_Host for DBRD Pair 2

MySQL high availability, failover and replication with Latency

MySQL Replication : 1 Slave / Multiple Masters

Here is why I suggested this: Using two data centers, you setup automatic failover for DRBD Pair in one data center. Let the other DRBD Pair in the second data center be for DB disaser site with it own local redundancy and failover. Should you ever loses one data center, the other data center is fully read with it own local failover setup. Your app would just have to use the DBVIP of the other database center in such a catastrophic case.

Please keep in mind that using DRBD in conjunction with MySQL is only beneficial if all of your data uses the InnoDB Storage Engine. Hard failovers in DRBD could easily result in crashed MyISAM tables.

Here is another setup to consider:

As with DRBD setups, any DRBD Secondary would provide just a Disk-Level copy of your MySQL Folder. It is available as a warm standby. MySQL is not being run on the DRBD Secondary. If you want the third DB server to become hot standby, ditch DRBD altogether and use pure MySQL Replication. With three DB servers, using db3 at a remote site, simply setup the following:

+--> db1 --> db2 --> db3 -->+
^                           |
|                           V
+<--------------------------+

Using your rudimentary failover, now you have two hot standby servers. You just have to make sure each DB server has a unique server_id value. I also recommend using MySQL 5.5 because it uses SemiSync Replication which is more sensitive to communication failures and stop Replication better. You will have to setup the appropriate heartbeats and timeouts.

Based strictly on your question, the topology you want is not possible. Why?

Here is what you presented (call it Topology#1)

    a -> b
    b -> c
    c -> a

and you want it to be (call it Topology#2)

    a -> c
    b -> c

Since ServerC cannot execute CHANGE MASTER TO with multiple host/port combinations, Topology#2 is mechanically impossible.

I have addressed this as to why IT IS NOT POSSIBLE:

• Feb 03, 2012 : One slave, multiple masters MySql
• May 15, 2011 : Is Multi Master Single Slave possible in mySQL DB? (My ServerFault Post)

Now, it you want to turn Topology#1 into this (call it Topology#3)

    a -> b
    a -> c

this is quite possible. Here are the steps:

STEP01) On ServerB, run STOP SLAVE;

STEP02) On ServerC, run SHOW SLAVE STATUS\G and check to make sure Exec_Master_Log_Pos is no longer updating.

STEP03) On ServerB, run SHOW SLAVE STATUS\G.

STEP04) Record Relay_Master_Log_File (call it RMLF) and Exec_Master_Log_Pos (call it EMLP) from STEP03 (For the sake of example, let RLMF='mysql-bin.000345' and EMLP=98765)

STEP05) On ServerC, run the following (Using RMLF and EMLP from STEP04):

STOP SLAVE;
CHANGE MASTER TO
master_log_file='mysql-bin.000345',
master_log_pos=98765;`
START SLAVE;

STEP07) On ServerB, run START SLAVE;

STEP08) On ServerA, run STOP SLAVE;

Going forward, have all INSERTs, UPDATEs, and DELETEs occur on ServerA only.