There are various single-site architectures available, as described in this section:
This replication has two servers—one master and one slave, and an application connecting to an IP address of the master as follows:
This is the most simple setup; the Virtual IP address (VIP) can be manually moved. However, in the event of failure of the master, there is a possibility of some data loss and a manual VIP failover can take time. To set this up, go through the recipes Designing a replication setup, Configuring a replication master, and Configuring a replication slave without synchronizing data in Chapter 5, High Availability with MySQL Replication.
Two servers, both configured as slaves to the other server, with a management agent such as MMM (which was covered in Chapter 5 in the recipes Multi Master Replication Manager (MMM) and Managing and using Multi Master Replication Manager (MMM)) for automated failover and health checking. It can be shown as follows:
This has the advantage of simplicity (although, it is more complex than master / slave architecture) with automated and faster failover. However, similar to all replication-based high-availability designs, there is a risk of data loss here.
This involves two servers connected either to a redundant shared-storage device such as a shared disk array, which was covered in Chapter 6, High Availability with MySQL and Shared Storage, or by using block-level replication such as DRBD and a cluster manager for automated failover, which was covered in Chapter 7, High Availability with Block Level Replication. The architecture diagram can be shown as follows:
The other type of shared storage is block-level replication—DRBD shown as follows:
This has the advantage of extremely fast failover and, if configured correctly, there are no lost transactions in the event of a failover. The disadvantage is that it has relatively poor performance. Better performance, which is similar to or greater than the previous two architectures, can be achieved with local storage that requires expensive hardware such as Fibre Channel connectivity to a SAN or Dolphin Interconnects for DRBD.
MySQL Cluster requires a minimum of three servers connected together in a local network as covered in detail in the first four chapters in this book. In the following example, the application is hosted on two servers, which are running SQL nodes that allow the application to connect to the localhost MySQL Server. A load balancer is therefore required to distribute users of the application between the two servers and to conduct health checking. It can be shown in the following diagram:
