Peter Childs wrote:
> Hot backup? Postgres 7.3 can't really do hot-backup! The only way
> to backup the database is to dump the entire thing. Two minites later this
> backup is only news and not exactly hot. Having to shut your database down
> to back it up would be down right nasty! But Since we don't yet have an
> update log. Even a dump will not get you back to the good point before
> your disk died.
> Mind you the truth is the downdate log should work for most cases.
> So take regualar backups... and use raid. I mean how often does an entire
> raid array fail at once?
There was a clever solution posted here for replicating database in near real
time. Use RAID for data directory. For backup break the RAID and pick up the
data image from broken part. That was clever one.
> I would love to see an Update Log on postgres. That and true
> replications (dual master) are the two biggest missing features in
> Postgres. If we had them we could run circles round mysql and oracle as
> well.
Postgresql do have update logs in form of WAL. However it can not do PITR with
log archiving if a node in cluster goes down for extended period. WAL does not
handle these situations in current design. Precisely, PITR is the feature that
implements this functonality.
Furthermore, mysql has replication is completely unrelated issue. Mysql didn't
have transactions so implementing replication didn't have so many constraints.
Postgresql has transactions for ages and it's replication has to support them
fully. That's what causing delays in true postgresql replication.
Design a mysql replicated cluster in a heavy concurrent update database and have
one of the node fail it. Let's see how mysql rolls back. ( FWIW, mysql rollback
time is proprotional to data in a transaction. So rolling back a 100MB
transaction isn't exactly so fast)
Shridhar
