For instance, PostgreSQL has a number of projects that facilitate clustering. Slony-I is a stable open source replication framework (http://www.slony.info/). PGCluster provides a multi-master replication facility (think Oracle RAC). PGpool allows front end load balancing of connections.
As an alternative, you can use Point-In-Time-Recovery (PITR), also known as "log shipping", to transfer copies of your write-ahead log files from a master server to a warm standby. PITR allows you to have an exact replica of your master database, modulo whatever delay you incur in the log transfer itself.
For those who haven't aren't familiar with write-ahead logs, they function much like the logging in modern filesystems: changes are written there before being flushed to disk, so any incomplete transactions can be replayed from the logs if the server goes down unexpectedly.
Of course, the log-shipping method doesn't allow your secondary server to serve as a read-only replica as MySQL's built-in replication does. Largely for that reason, (depending on your workload and requirements, of course) MySQL may be a better choice. However, I've found Postgres PITR to be an excellent option for low to medium-traffic databases in those cases where I'm willing to trade the possibility of the loss of a few seconds' updates for guarantees that my DDL, object identities, and constraints will be maintained consistently between my replicas.
For those who are curious, the PostgreSQL docs online have a decent introduction into the use of write-ahead logs for replication and backups: