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
Hi Robert:
On Thu, Mar 12, 2015 at 12:52 PM, Robert Inder wrote:
> On 11 March 2015 at 17:32, Francisco Olarte wrote:
>> This is, build an streaming replication slave, pg_dump from the slave. If
>> needed, restore in the master.
...
> I really like the idea of running pg_dump on the slave, but I
Hi Steven:
On Fri, Mar 13, 2015 at 9:03 PM, Steven Lembark wrote:
> > The thing is you can use desktop class machines for the slave. If you do
.
> If load on the backup server becomes an issue you might be able to
> make incremental pg_dump's onto tmpfs.
I'm curious, how do you make increme
On 12 March 2015 at 12:31, Thomas Kellerer wrote:
> 8.4 cannot run queries on the standby, you need to upgrade to a
> supported/maintained version for this
> (this feature was introduced in 9.0)
>
> In 9.x you can start the slave as a "hot standby" to allow read only queries
> which is what pg_
> The thing is you can use desktop class machines for the slave. If you do
> not have spare machines I would suggest a desktop class machine with big
> RAM and whatever disks you need for the DB plus an extra disk to pg_dump to
> ( so pg_dump does not compete with DB for the db disks, this really
Robert Inder schrieb am 12.03.2015 um 12:52:
> Postgres on the standby machine is continually reading those files.
> But that is all it will do. "pg_dump" just says "The database is starting up".
>
> Could/should I have something configured differently?
>
> Or Is this something that has changed w
Hi, Francisco,
On 11 March 2015 at 17:32, Francisco Olarte wrote:
> This is, build an streaming replication slave, pg_dump from the slave. If
> needed, restore in the master.
I really like the idea of running pg_dump on the slave, but I don't understand
how I could do it.
Postgres on our live
Thanks for your comments (so far:-)
I guess I'm pleased that nobody has said that I'm doing something stupid!
I'll certainly look at Slony and Barman.
And Stephane's suggestion of doing regular basebackups and keeping the
WAL files seems neat. If I under stand it, we'd use the/a standby
server
Have you looked into Barman? http://www.pgbarman.org/ It does what you
want. You can take a full daily backup and it keeps track of the WAL files
to allow for a PITR. It also allows you to run the backup from one of your
slaves.
The way we have it setup is as follows: We have three servers, one ma
Hello,
On 11/03/2015 11:54, Robert Inder wrote:
> We are developing a new software system which is now used by a number
> of independent clients for gathering and storing live data as part of
> their day to day work.
>
> We have a number of clients sharing a single server. It is running
> one Po
Hi Robert...
On Wed, Mar 11, 2015 at 11:54 AM, Robert Inder
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?
>
As you've been told before, pg
On Wed, Mar 11, 2015 at 9:55 AM, Andrew Sullivan
wrote:
> On Wed, Mar 11, 2015 at 09:40:09AM -0400, Joseph Kregloh wrote:
> > Have you looked into Barman? http://www.pgbarman.org/ It does what you
> > want. You can take a full daily backup and it keeps track of the WAL
> files
> > to allow for a
On Wed, Mar 11, 2015 at 09:40:09AM -0400, Joseph Kregloh wrote:
> Have you looked into Barman? http://www.pgbarman.org/ It does what you
> want. You can take a full daily backup and it keeps track of the WAL files
> to allow for a PITR.
I just had a look at the documentation (and the rest of your
On Wed, Mar 11, 2015 at 10:54:56AM +, Robert Inder wrote:
> But, at least while the system is under rapid development, we also
> want to have a way to roll a particular client's database back to a
> (recent) "known good" state, but without affecting any other client.
>
> My understanding is th
14 matches
Mail list logo
