Depending on your requirements there are various architectures or ways that you can configure MySQL and MySQL Cluster. Below is just a summary of some of the most frequently used architectures to achieve high availability.
MySQL Master/Slave(s) Replication
MySQL master to slave(s) configuration is the most popular setup. In this design One(1) server acts as the master database and all other server(s) act as slaves.Writes can only occur on the master node by the application
*Analytic applications can read from the slave(s) without impacting the master
*Backups of the entire database of relatively no impact on the master
*Slaves can be taken offline and sync back to the master without any downtime
*In the instance of a failure a slave has to be promoted to master to take over its place. No automatic failover
*Downtime and possibly lost of data when a master fails
*All writes also have to be made to the master in a master-slave design
*Each additional slave add some load* to the master since the binary log have to be read and data copied to each slave
*Application might have to be restarted
In the diagram below the App(Application) talks to a load balancer/VIP/elastic IP. The application(App) is not configured to point directly to the address of the MySQL master node to reduce the configuration changes that might be required within the application (App) in the case of a failure.
Load Balancer – Configured with a fail over load balancing policy/algo(highest priority). In this configuration all requests are sent to a single route or the highest priority(master). Only in the instance of a failure will requests be sent to the alternative route(slave)
Elastic IP – The IP exposed to the application can be configured to point to the master database . When a failure is discovered on the master, the same IP can then be configured to point to the slave database.
VIP – Same as elastic ip above. Can be configured to point to the master/slave as required
MySQL Master/Master Replication
In a master-master configuration each master is configured as a slave to the other. Writes and reads can occur on both servers
*Applications can read from both masters
*Distributes write load across both master nodes
*Simple ,automatic and quick failover
* Loosely consistent
*Not as simple as master-slave to configure and deploy
In the diagram below the only significant difference between the master-slave diagram above is that replication(copying data) occurs on both sides of the masters and that both reads & writes can occur on either server.
The new kid in town based on MySQL cluster design. MySQL cluster was developed with high availability and scalability in mind and is the ideal solution to be used for environments that require no downtime, high avalability and horizontal scalability.
See MySQL Cluster 101 for architecture diagram and information related to MySQL
*(High Avalability)no single point of failure
*Very high throughput
*On-Line Operations(Schema changes etc)
There are other options available when looking for high availability architectures for MySQL and any other RDBMS systems such as MariaDB or PostgreSQL You could also look at the use of Shared storage , replication from the storage level and other methods to achieve high availability. Regardless to achieve true high availability a shared nothing architecture would be the recommend option. For the options of using shared storage(NFS)/ replication from the storage level(BLOCK) redundancy is just moved from the database layer to the storage layer.
At the end of the day the database architecture that you decide to use depend on your current and possible future requirements.