Return to Answer

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

The basic idea would be to use MySQL Replication in conjunction with DRBD and ucarp

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 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. In the event of any sudden network latency, MySQL Replication between DataCenters would switch from Semisync to Async. Once conditions improve, then MySQL Replication would it switch back to Semisynch.

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.

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

The basic idea would be to use MySQL Replication in conjunction with DRBD and ucarp

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 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. In the event of any sudden network latency, MySQL Replication between DataCenters would switch from Semisync to Async. Once conditions improve, then MySQL Replication would it switch back to Semisynch.

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.

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

The basic idea would be to use MySQL Replication in conjunction with DRBD and ucarp

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 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.

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

The basic idea would be to use MySQL Replication in conjunction with DRBD and ucarp

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 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. In the event of any sudden network latency, MySQL Replication between DataCenters would switch from Semisync to Async. Once conditions improve, then MySQL Replication would it switch back to Semisynch.

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.

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

The basic idea would be to use MySQL Replication in conjunction with DRBD and ucarp

Here is what you would need:

• Two DRBD Clusters, one in each Data Center
• DRBD Primary has MySQL Running
• DRBD Primary at one Data Center running MultiMaster Replication with the DRBD Primary at other Data Center via ucarp
• Any needed read slaves at each Data Center would use the DBVIP established for use within MySQL at that Data Center via ucarp

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

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

The basic idea would be to use MySQL Replication in conjunction with DRBD and ucarp

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 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.