From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Decibel!" <decibel(at)decibel(dot)org> |
Cc: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: PITR backup to Novell Netware file server |
Date: | 2007-08-08 00:38:47 |
Message-ID: | 46B8CA47.EE98.0025.0@wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
> >>> Decibel! <decibel(at)decibel(dot)org> 08/07/07 4:51 PM >>>
> On Tue, Aug 07, 2007 at 02:12:29PM -0500, Kevin Grittner wrote:
> > > Copying a 16MB file that's already in memory isn't exactly an intensive
> > > operation...
> >
> > That's true for the WAL files. The base backups are another story. We will
> > normally have a database vacuum analyze between the base backup and the users
> > being in there to care about performance, but that's not always the case --
> > sometimes jury trials go late into the night and could overlap with this a
> > base backup. And some judges put in a lot of late hours; although they don't
> > tend to bang on the database very heavily, they hate to be made to wait.
>
> Ahh... well, that's something where rsync could actually help you since
> it allows you to put a bandwidth cap on it. Another option is that some
> OSes (FreeBSD for one) will respect process priority when it comes to
> scheduling IO as well, so if you nice the backup process it hopefully
> wouldn't impact the database as much.
Thanks for the suggestions. A new OS is not in the cards any time soon, but
I think the --bwlimit option makes sense -- there's not a lot of point moving
it from the database server to the file server faster than the WAN can take it,
anyway. I suppose I could "nice" the rsync requester on the database side, too.
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Tena Sakai | 2007-08-08 00:45:25 | postgres authentication |
Previous Message | Fabricio Peñuelas | 2007-08-08 00:19:17 | ssl and odbc standar driver |