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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
