Replication has now become an essential feature for most MySQL users. The good news I can share at the same time is that the working and implementation of this concept is also less complicated. It involves a minimum of 2 servers: a master and a slave (in most cases). The slave makes use of the binary logs created by the master to update its database thereby keeping both of them in exact synchronization.
Issues Leading to the Need of Replication
Heavy Load:
Lets consider a website with an exponentially increasing number of users regularly. There will arrive a state in which the single database server could no longer handle the load anymore. If the server receives more number of read queries rather than write queries (which will be the normal case for most of the websites) then, the best choice will be to adopt replication into the current architecture. Here, the read queries refer to SELECT statements and the write queries refer to INSERT, UPDATE and DELETE statements.
Now I am going to explain how replication solves the issue of heavy load. When the concept of replication is implemented we will be having more than one server. Among these servers, the one named as master will receive queries related to write and make changes to its database immediately. Consequently, when the binary log is updated, the slaves update their database reading from the log files. The slaves on the other hand receive all read queries. Depending on the number of queries received, the number of slaves can be increased or decreased. Now by using any scheduling algorithm (Round Robin is an example), we can effectively load balance the incoming read queries to different slave servers so that all of them get equal workloads.
Backup: Anytime and Without Client Disturbance
During backup requirements, we normally stop MySQL or lock the read queries to get an exact backup. This may sometimes result in the annoyance of the clients who access the website during the process. Although there are a few clever techniques with which you may do this without the notice of the clients, things become very simple with replication.
The slaves always remain in exact synchronization with the master. In other words, the slaves will have another copy of the entire repository that the master processes. And hence backing up of a slave is similar and as good as backing up of the master. Also the presence of slaves as exact replicas will in most cases help avoid the need for backup of the master. This is because we always have the slaves as a spare in case of any misfortunes to the master.
Distribution of Data Without Respect to Distance:
Next issue I am to focus on deals with distributing copies of data in various locations that are geographically very apart which is not a trivial task. But the replication factor gives the flexibility that we require to make it trivial.
The master provides no errors even if the slave remains disconnected for some time. So in spite of the poor connection and other factors that may influence the link between the different destinations, a synchronized copy of the master can be made to exist in a geographically distant region.
Architectures of Replication
There are a few rules that I recommend to be kept in mind to better understand the different architectures.
- There needs to be a unique server ID for every slave
- There can be many slaves for a master
- There can be only one master for a slave
- Slaves can also function as masters
Master: Slave
This architecture best suits an environment, which has low number of write queries and high number of read queries. Effective load balance can be achieved by spreading the workload among the different servers. Here is an illustration.

Dual Master:
This kind of architecture is particularly useful when servers are geographically far apart. Although during interruptions, neither will have access to their data both will catch up from each other when the connection is reestablished. An extension of this architecture will be to have a slave on either side that is also diagrammatically shown below.
.

Pyramid:
In a large organization where there is diverse distribution in a hierarchical manner, a possible architecture like this will be the best suit. There is no necessity to configure every slave with the master as the slave above in the hierarchy can act as their master.

Although replication solves problems, it demands so much precision, which if not taken care of, can even result in the crash of the master database. Slaves are not always in synchronized state with their master. But with proper monitoring systems this can be detected. The concept of replication is provided by MySQL and can definitely improve overall performance if dealt with proper caution.