What is it?

In a nutshell, replication is a redundancy system. In its most basic form it allows the contents of a master database to be mirrored to a slave database. The slave is a read-only copy of the master and the slave can never update the master, so it is one-way synchronization. Replication has many options, including the ability to have multiple slaves for one master and pausing the replication process. The slave does not require a constant connection to the master, it can ‘catch-up’ with the master once a connection has been re-established. In that respect it is an asynchronous update.

Why use it?

The question as to why one would use something is the most important question when evaluating any technology, and the main focus of this article. Replication is useful in the following areas:

• accessibility/scale-ability:
  Replication can be used to create multiple sources of the same data. This means instead of multiple users accessing a single database, as long as those requests are read-only they can be spread out among multiple servers. It also means that backups can take place on the slave, and not affect the master.

Accessibility and performance should also be considered for cases where reports or complex queries might need to be run against the data, but you don’t want to affect performance on the main server. You can simply run them against a replicated slave on a different server, leaving the master unhindered.

• reliability:
  What happens if your master goes down? Users wouldn’t be able to perform write operations, but they could continue to access the information from a slave until the master could be brought online again.

• redundancy:
  If you have another application that needs access to the information contained within the database, you can replicate the data for use in your other application.

As an example, we recently utilized replication for a redundancy solution. We had an application that contained a vendor table and tools for maintaining it (CRUD). We were then tasked with building a separate application that required access to the same vendor data for read-only purposes. We could have written our queries to access the original application’s database directly, but that would put additional load on the database. It also would have reduced flexibility since it the new app would be dependent on an external database. For those two reasons we decided to replicate the vendor table for use in the new application. This reduced the load, as well as making it so if the original application’s server went down, the new application could continue running with the replicated data.

Conclusion

That should give a brief and high level overview of the potential uses of MySQL replication. The topic is actually quite broad, with more capabilities and configuration options. I have listed the most basic and common uses, but as with any tool, it can be used in new and creative ways. I recommend further reading starting with MySQL’s documentation.