Friday, October 17, 2003 12:05, Tom Lane [mailto:[EMAIL PROTECTED] wrote:
>Murthy Kambhampaty <[EMAIL PROTECTED]> writes:
>> ... The script handles situations
>> where (i) the XFS filesystem containing $PGDATA has an
>external log and (ii)
>> the postmaster log ($PGDATA/pg_xlog) is written to a
r 16, 2003 13:37
>To: Josh Berkus
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: [ADMIN] [PERFORM] backup/restore - another area.
>
>
>On Thu, 16 Oct 2003 10:09:27 -0700
>Josh Berkus <[EMAIL PROTECTED]> wrote:
>
>>
Murthy Kambhampaty <[EMAIL PROTECTED]> writes:
> ... The script handles situations
> where (i) the XFS filesystem containing $PGDATA has an external log and (ii)
> the postmaster log ($PGDATA/pg_xlog) is written to a filesystem different
> than the one containing the $PGDATA folder.
It does? How
On Thu, 16 Oct 2003 10:09:27 -0700
Josh Berkus <[EMAIL PROTECTED]> wrote:
> Jeff,
>
> > I left the DB up while doing this.
> >
> > Even had a program sitting around committing data to try and corrupt
> > things. (Which is how I discovered I was doing the snapshot wrong)
>
> Really? I'm unclear
Jeff,
> I left the DB up while doing this.
>
> Even had a program sitting around committing data to try and corrupt
> things. (Which is how I discovered I was doing the snapshot wrong)
Really? I'm unclear on the method you're using to take the snapshot, then; I
seem to have missed a couple pos
On Thu, 16 Oct 2003 09:49:59 -0700
Josh Berkus <[EMAIL PROTECTED]> wrote:
> Jeff,
>
> > The downside is
> > this method will only work on that specific version of PG and it
> > isn't the"cleanest" thing in the world since you are essentially
> > simulating a power failure to PG. Luckly the WAL wo
Jeff,
> The downside is
> this method will only work on that specific version of PG and it isn't the
> "cleanest" thing in the world since you are essentially simulating a power
> failure to PG. Luckly the WAL works like a champ. Also, these backups can
> be much larger since it has to include the
On Tue, 14 Oct 2003, [EMAIL PROTECTED] wrote:
> I'm curious to what kind of testing you've done with LVM. I'm not
> currently trying any backup/restore stuff, but I'm running our DBT-2
> workload using LVM. I've started collecting vmstat, iostat, and
> readprofile data, initially running disktes
Jeff,
I'm curious to what kind of testing you've done with LVM. I'm not
currently trying any backup/restore stuff, but I'm running our DBT-2
workload using LVM. I've started collecting vmstat, iostat, and
readprofile data, initially running disktest to gauge the performance.
For anyone curious,
On 9 Oct 2003, Greg Stark wrote:
> I don't quite follow your #2 so I can only comment on the above idea of using
> an LVM snapshot. If you have the hardware and the LVM-fu to be able to do this
> properly I would recommend it.
>
Just to be a bit clearer incase it was my wording:
Method #2 is near
Jeff <[EMAIL PROTECTED]> writes:
> Idea #1:
> Use an LVM and take a snapshop - archive that.
> From the way I see it. the downside is the LVM will use a lot of space
> until the snapshot is removed. Also PG may be in a slightly inconsistant
> state - but this should "appear" to PG the same as i
Boy, I must be getting annoying by now huh?
Anyway, after the joys of Solaris being fast I'm moving onto another area
- backup & restore. I've been checking the archives and haven't seen any
"good" tips for backing up big databases (and more importantly,
restoring).
I've noticed while doing a ba
12 matches
Mail list logo
