Delayed replicas

So far, two main scenarios have been discussed in this book:

• Point-in-time Recovery (PITR): Replaying the transaction log as soon as something nasty has happened

• Asynchronous replication: Replaying the transaction log as soon as possible

Both scenarios are highly useful and can serve people's needs nicely. However, what happens if databases, and especially change volumes, start being really large? What if a 20 TB database has produced 10 TB of changes and something drastic happens? Somebody might have accidentally dropped a table or deleted a couple of million rows, or maybe somebody set data to a wrong value. Taking a base backup and performing a recovery might be way too time consuming, because the amount of data is just too large to be handled nicely.

The same applies to performing frequent base backups. Creating a 20 TB base backup is just too large, and storing all those backups might be pretty space consuming. Of course, there is always the possibility of getting around...