MySQL Replication is available on all platforms supported by MySQL, and since it isn't operating system-specific it can operate across different platforms.

Replication is asynchronous and can be stopped and restarted at any time, making it suitable for replicating over slower links, partial links and even across geographical boundaries.

Data can be replicated from one master to any number of slaves, making replication suitable in environments with heavy reads, but light writes (for example, many web applications), by spreading the load across multiple slaves.

Data can only be written to the master. In advanced configurations, though, you can set up a multiple-master configuration where the data is replicated around a ring configuration.

There is no guarantee that data on master and slaves will be consistent at a given point in time. Because replication is asynchronous there may be a small delay between data being written to the master and it being available on the slaves. This can cause problems in applications where a write to the master must be available for a read on the slaves (for example a web application).

Scale-out solutions that require a large number of reads but fewer writes (for example, web serving).

Logging/data analysis of live data. By replicating live data to a slave you can perform queries on the slave without affecting the operation of the master.

Online backup (availability), where you need an active copy of the data available. You need to combine this with other tools, such as custom scripts or Heartbeat. However, because of the asynchronous architecture, the data may be incomplete.

Offline backup. You can use replication to keep a copy of the data. By replicating the data to a slave, you take the slave down and get a reliable snapshot of the data (without MySQL running), then restart MySQL and replication to catch up. The master (and any other slaves) can be kept running during this period.

Offers multiple read and write nodes for data storage.

Provides automatic failover between nodes. Only transaction information for the active node being used is lost in the event of a failure.

Data on nodes is instantaneously distributed to the other data nodes.

Available on a limited range of platforms.

Nodes within a cluster should be connected via a LAN; geographically separate nodes are not supported. However, you can replicate from one cluster to another using MySQL Replication, although the replication in this case is still asynchronous.

Applications that need very high availability, such as telecoms and banking.

Applications that require an equal or higher number of writes compared to reads.

Provides high availability and data integrity across two servers in the event of hardware or system failure.

Can ensure data integrity by enforcing write consistency on the primary and secondary nodes.

Only provides a method for duplicating data across the nodes. Secondary nodes cannot use the DRBD device while data is being replicated, and so the MySQL on the secondary node cannot be simultaneously active.

Can not be used to scale performance, since you can not redirect reads to the secondary node.

High availability situations where concurrent access to the data is not required, but instant access to the active data in the event of a system or hardware failure is required.

Very fast, RAM based, cache.

Reduces load on the MySQL server, allowing MySQL to concentrate on persistent storage and data writes.

Highly distributable and scalable, allowing multiple servers to be part of the cache group.

Highly portable - the memcached interface is supported by many languages and systems, including Perl, Python, PHP, Ruby, Java and the MySQL server.

Data is not persistent - you should only use the cache to store information that can otherwise be loaded from a MySQL database.

Fault tolerance is implied, rather than explicit. If a memcached node fails then your application must be capable of loading the data from MySQL and updating the cache.

High scalability situations where you have a very high number of reads, particularly of complex data objects that can easily be cached in the final, usable, form directly within the cache.