Advanced Rails - Building Industrial-Strength Web Apps in Record Time

122 | Chapter 4: Database

Since the Cluster software is simply a storage engine, the cluster is accessed through
a standard MySQL server with tables defined with the NDB backend. The server
accesses the cluster to fulfill requests from the client. The overall architecture is
shown in Figure 4-3.

Because themysqldservers only differ from nonclustered servers in their backend,
they can be replicated with binlogs just as nonclustered servers can. So, it is possible
to achieve long-distance master-slave replication among multiple clusters.

It is also possible to have severalmysqldservers accessing the same cluster and serv-
ing the same clients for redundancy. In the preceding diagram, the MySQL server is a
single point of failure; if it goes down, there is no way for the application to access
the cluster. There are three approaches to handling load balancing and failover when
multiple MySQL servers are involved:

• Modify the application code to handle failed servers and retry queries to differ-
  ent servers. Each MySQL server will have its own IP address in this scenario.


• Use a separate hardware or software load balancer between the application and
  the MySQL servers. This will create one Virtual I Paddress (VI P) that will be
  directed to one of the physical servers via DNAT. This method is expensive, as
  you need at least two load balancers for high availability.

Figure 4-3. MySQL Cluster architecture

Application code

mysqld

(NDB backend)

Management node

Data

node

Data

node

Data

node

Cluster

My SQL API