[Marked off-topic as this has, indeed, come a long long way from the original question]
> From: Johnny Kewl [mailto:[EMAIL PROTECTED] > but yes if the user could consider replication > and the required > dB design, much better than moving GB files around. Not always. For example, replication has the disadvantage that an application logic error can get replicated and break both your live and your backup database (although I accept that point-in-time log-based recovery can mitigate this). Point-in-time backups that are copied between machines have a long and honourable history; they're also often much easier for the ops team to get their heads round, where a replicated system can often set heads spinning in the ops team. You also have to be very careful with your replication setup - and the guarantees you give your client - in case of partial failures. For example, if commuinications to the second system fails, do you stop accepting transactions on the primary (potential loss of new business on an Internet site) or do you continue, but in the knowledge that if the primary fails you're now losing transactions and hence violating ACID principles from the client's point of view (potential loss of old business on an Internet site)? (As you can probably guess, I've designed and built my share of replicated databases - and supported them!) - Peter --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
