On 3/11/15 6:46 AM, Andrew Sullivan wrote:
>> Is our current "frequent pg_dump" approach a sensible way to go about
>> >things. Or are we missing something? Is there some other way to
>> >restore one database without affecting the others?
> Slony-I, which is a PITA to administer, has a mode where you can ship
> logs off and restore them in pieces. The logs are not WAL, but Slony
> logs (which are produced by triggers and some explicit event writing
> for schema changes). So they work per-database. Schema changes are
> really quite involved for Slony, and there's overhead resulting from
> the triggrs, and as I said it's rather clunky to administer. But it's
> been around some time, it still is actively maintained, and it has
> this functionality. The PITR tools were, last I checked, pretty
> primitive. But the tool might work for your case. I don't know
> whether Bucardo or Londiste (two alternative systems that work on
> roughly the same principle) have this functionality, but I kind of
> doubt it since both were designed to get rid of several of the
> complexities that Slony presented. (Slony had all those complexities
> because it was trying to offer all this functionality at once.)
You could do something very similar with londiste by setting up a second
queue and delaying when you move data to it from the primary queue,
based on event_time.
Or now that I think about it... you might be able to do that right in
the replay process itself.
The big reason I prefer londiste over Slony is that it's extremely
modular, so it's easy to do stuff like this.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com