Replication allows you to take one database, make an exact copy of it on another server, and set one of them (the slave) to take all its updates from the other (the master). The slave reads the master's binary logs, which store all statements that change a database, and repeats these on its database, keeping the two in exact sync. However, since a replicating database simply repeats statements, the databases are not necessarily exactly in sync. What replication is not
Replication is not a backup policy. A mistyped DELETE statement will be replicated on the slave too, and you could end up with two, perfectly synchronized, empty databases. Replication can help protect against hardware failure though.
Replication is not an answer to all performance problems. Although updates on the slave are more optimized than if you ran the updates normally, if you use MyISAM tables, table-locking will still occur, and databases under high-load could still struggle (although you should always use InnoDB with Alfresco).
Replication is not a guarantee that the slave will be in sync with the master at any one point in time. Even assuming the connection is always up, a busy slave may not yet have caught up with the master, so you can't simply interchange SELECT queries across master and slave servers.
Backing up a busy MySQL server can be difficult when your clients demand access to the data 24 hours a day. Rather than deal with the complexity of implementing a backup process that minimizes the impact on your clients, you might find it easier simply to configure a slave server and back it up instead. Because the slave will have an exact copy of the data, it's just as good as backing up the master. Plus you'll never impact the clients who are using the master. You might even decide that you don't necessarily need or want to back up the data as long as you have the 'hot spare' slave database available in the case of problems with the master.
Note: MySQL 5.1 will have Multi-master replication.
Content Store Recovery
If content is lost due to a content store failure without backups, then content may be missing from the system. Depending on the replication or backup mechanism being used, the content metadata (stored in the database) may be more complete than the binary content (usually stored on the filesystem).
When the Web Client or CIFS browser encounters such content then the error is reported. At present, there isn't a tool that can browse the entire repository to work out which files are missing. But reindexing the repository will have the same effect.