Dan Gorman <[EMAIL PROTECTED]> writes:
> I didn't however keep the snapshots around. I could try and re-set
> this scenario up. I was in the middle of doing some data migration
> with Netapp and wanted to just 'test' it to make sure it was sane.
> If you guys would like me to try to 'break' it
No, however, I will attach the postgreql.conf so everyone can look at
other settings just in case.
postgresql.conf
Description: Binary data
Regards,
Dan Gorman
On Jun 25, 2007, at 10:07 AM, Gregory Stark wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
WARNING: page 28900 of relation 166
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Reformatting and sorting, we have
>>
>> WARNING: page 28900 of relation 1663/16384/76718 was uninitialized
>> WARNING: page 28902 of relation 1663/16384/76718 was uninitialized
>> WARNING: page 26706 of relation 1663/16384/76719 was uninitialized
>> WA
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> WARNING: page 28900 of relation 1663/16384/76718 was uninitialized
>> WARNING: page 28902 of relation 1663/16384/76718 was uninitialized
>
>> WARNING: page 26706 of relation 1663/16384/76719 was uninitialized
>> WARNING: page 26708 of relation 1663/1638
Thanks for the pointers to a) make it readable and b) log min messages
I didn't however keep the snapshots around. I could try and re-set
this scenario up. I was in the middle of doing some data migration
with Netapp and wanted to just 'test' it to make sure it was sane.
If you guys would l
On Mon, 2007-06-25 at 12:34 -0400, Tom Lane wrote:
> Dan Gorman <[EMAIL PROTECTED]> writes:
> > Jun 21 00:39:43 sfmedstorageha001 postgres[3506]: [9-1] 2007-06-21
> > 00:39:43 PDTLOG: redo done at 71/99870670
This is mid-way through an xlog file.
> > Jun 21 00:39:43 sfmedstorageha001 postgres[
Dan Gorman <[EMAIL PROTECTED]> writes:
> Jun 21 00:39:43 sfmedstorageha001 postgres[3506]: [9-1] 2007-06-21
> 00:39:43 PDTLOG: redo done at 71/99870670
> Jun 21 00:39:43 sfmedstorageha001 postgres[3506]: [10-1] 2007-06-21
> 00:39:43 PDTWARNING: page 28905 of relation 1663/16384/76718 was
>
On Mon, 2007-06-25 at 08:28 -0700, Dan Gorman wrote:
> I took several snapshots. In all cases the FS was fine. In one case
> the db looked like on recovery it thought there were outstanding
> pages to be written to disk as seen below and the db wouldn't start.
>
> Jun 21 00:39:43 sfmedstorageh
Greg,
PG 8.2.4
Regards,
Dan Gorman
On Jun 25, 2007, at 9:02 AM, Gregory Stark wrote:
"Dan Gorman" <[EMAIL PROTECTED]> writes:
I took several snapshots. In all cases the FS was fine. In one
case the db
looked like on recovery it thought there were outstanding pages
to be written
to disk
"Dan Gorman" <[EMAIL PROTECTED]> writes:
> I took several snapshots. In all cases the FS was fine. In one case the db
> looked like on recovery it thought there were outstanding pages to be written
> to disk as seen below and the db wouldn't start.
>
> Jun 21 00:39:43 sfmedstorageha001 postgres[3
I took several snapshots. In all cases the FS was fine. In one case
the db looked like on recovery it thought there were outstanding
pages to be written to disk as seen below and the db wouldn't start.
Jun 21 00:39:43 sfmedstorageha001 postgres[3506]: [9-1] 2007-06-21
00:39:43 PDTLOG: redo
It's the latter, is snapshot of the durable state of the storage
system (e.g. it will never be corrupted)
Regards,
Dan Gorman
On Jun 22, 2007, at 11:02 AM, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
On Fri, 2007-06-22 at 13:12 -0400, Tom Lane wrote:
If you saw a problem I'd
"Tom Lane" <[EMAIL PROTECTED]> writes:
> AFAIK, actually workable methods of this type depend on filesystem
> cooperation, and are able to produce coherent snapshots of the logical
> (not necessarily physical) filesystem content at a specific instant.
I think you need filesystem cooperation in o
Koichi Suzuki <[EMAIL PROTECTED]> writes:
> Year, I agree we should carefully follow how Done really did a backup.
> My point is PostgreSQL may have to extend the file during the hot backup
> to write to the new block. It is slightly different from Oracle's case.
> Oracle allocates all the da
On Mon, 2007-06-25 at 19:06 +0900, Koichi Suzuki wrote:
> Year, I agree we should carefully follow how Done really did a backup.
> My point is PostgreSQL may have to extend the file during the hot backup
> to write to the new block.
If the snapshot is a consistent, point-in-time copy then I d
Hi,
Year, I agree we should carefully follow how Done really did a backup.
My point is PostgreSQL may have to extend the file during the hot backup
to write to the new block. It is slightly different from Oracle's case.
Oracle allocates all the database space in advance so that there could
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2007-06-22 at 13:12 -0400, Tom Lane wrote:
>> If you saw a problem I'd be inclined to question whether
>> there is some upstream component (OS or disk controller) that's
>> reordering writes.
> Given thats exactly what they do, constantly, I don'
On Fri, 2007-06-22 at 13:12 -0400, Tom Lane wrote:
> Dan Gorman <[EMAIL PROTECTED]> writes:
> > This snapshot is done at the LUN (filer) level, postgres is un-aware
> > we're creating a backup, so I'm not sure how pg_start_backup() plays
> > into this ...
>
> That method works too, as long as
Dan Gorman <[EMAIL PROTECTED]> writes:
> This snapshot is done at the LUN (filer) level, postgres is un-aware
> we're creating a backup, so I'm not sure how pg_start_backup() plays
> into this ...
That method works too, as long as you snapshot both the data files and
WAL files --- when you sta
Toru SHIMOGAKI wrote:
> Joshua D. Drake wrote:
>
>>> - If we don't use hardware level snapshot operation, it takes long time to
>>> take
>>> a large backup data, and a lot of full-page-written WAL files are made.
>> Does it? I have done it with fairly large databases without issue.
>
> You mea
>> So, if any data is written during taking snapshot, we can't assurance data
>> correctness *strictly* .
That sounds nothing like what I've heard called a "snapshot" before. Some
"filesystems" which aren't really filesystems but are also storage layer
drivers like Veritas (and ZFS?) allow you to
Toru SHIMOGAKI wrote:
Steve Atkins wrote:
- When we take a PITR base backup with hardware level snapshot operation
(not filesystem level) which a lot of storage vender provide, the
backup data
can be corrupted as Dan said. During recovery we can't even read it,
especially if meta-data
On Fri, 2007-06-22 at 17:23 +0900, Toru SHIMOGAKI wrote:
> Dan Gorman wrote:
> > Here is an example. Most of the snap shots worked fine, but I did get
> > this once:
>
> Thank you for your example. I'd appreciate it if I'd get any responses;
> whether
> we should tackle the problem for 8.4?
If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wasn't it select pg_start_backup('backuplabel');?
Andreas
Kurt Overberg wrote:
> You can use the psql command line to run:
>
> "select pg_start_backup();"
>
> ...then when you're done,
>
> "select pg_stop_backup();"
>
> if you want an example fro
You can use the psql command line to run:
"select pg_start_backup();"
...then when you're done,
"select pg_stop_backup();"
if you want an example from the unix command line:
psql -c "select pg_start_backup();" database_name
then
psql -c "select pg_stop_backup();" database_name
/kurt
On J
Ah okay. I understand now. So how can I signal postgres I'm about to
take a backup ? (read doc from previous email ? )
Regards,
Dan Gorman
On Jun 22, 2007, at 4:38 AM, Simon Riggs wrote:
On Fri, 2007-06-22 at 04:10 -0700, Dan Gorman wrote:
This snapshot is done at the LUN (filer) level, pos
On Fri, 2007-06-22 at 04:10 -0700, Dan Gorman wrote:
> This snapshot is done at the LUN (filer) level, postgres is un-aware
> we're creating a backup, so I'm not sure how pg_start_backup() plays
> into this ...
Postgres *is* completely unaware that you intend to take a backup, that
is *exactly
This snapshot is done at the LUN (filer) level, postgres is un-aware
we're creating a backup, so I'm not sure how pg_start_backup() plays
into this ...
Regards,
Dan Gorman
On Jun 22, 2007, at 3:55 AM, Simon Riggs wrote:
On Fri, 2007-06-22 at 11:30 +0900, Toru SHIMOGAKI wrote:
Tom Lane wro
On Fri, 2007-06-22 at 11:30 +0900, Toru SHIMOGAKI wrote:
> Tom Lane wrote:
> > Dan Gorman <[EMAIL PROTECTED]> writes:
> >>All of our databases are on NetApp storage and I have been looking
> >> at SnapMirror (PITR RO copy ) and FlexClone (near instant RW volume
> >> replica) for backing up
Dan Gorman wrote:
Here is an example. Most of the snap shots worked fine, but I did get
this once:
Thank you for your example. I'd appreciate it if I'd get any responses; whether
we should tackle the problem for 8.4?
Regards,
--
Toru SHIMOGAKI<[EMAIL PROTECTED]>
NTT Open Source Software Ce
Here is an example. Most of the snap shots worked fine, but I did get
this once:
Jun 21 00:39:43 sfmedstorageha001 postgres[3506]: [9-1] 2007-06-21
00:39:43 PDTLOG: redo done at 71/99870670
Jun 21 00:39:43 sfmedstorageha001 postgres[3506]: [10-1] 2007-06-21
00:39:43 PDTWARNING: page 28905
Joshua D. Drake wrote:
>> - If we don't use hardware level snapshot operation, it takes long time to
>> take
>> a large backup data, and a lot of full-page-written WAL files are made.
>
> Does it? I have done it with fairly large databases without issue.
You mean hardware snapshot? I know ta
Steve Atkins wrote:
- When we take a PITR base backup with hardware level snapshot operation
(not filesystem level) which a lot of storage vender provide, the
backup data
can be corrupted as Dan said. During recovery we can't even read it,
especially if meta-data was corrupted.
I can'
On Jun 21, 2007, at 7:30 PM, Toru SHIMOGAKI wrote:
Tom Lane wrote:
Dan Gorman <[EMAIL PROTECTED]> writes:
All of our databases are on NetApp storage and I have been
looking
at SnapMirror (PITR RO copy ) and FlexClone (near instant RW volume
replica) for backing up our databases. The pro
Toru SHIMOGAKI wrote:
> Tom Lane wrote:
> - When we take a PITR base backup with hardware level snapshot operation
> (not filesystem level) which a lot of storage vender provide, the backup
> data
> can be corrupted as Dan said. During recovery we can't even read it,
> especially if meta-da
Tom Lane wrote:
> Dan Gorman <[EMAIL PROTECTED]> writes:
>>All of our databases are on NetApp storage and I have been looking
>> at SnapMirror (PITR RO copy ) and FlexClone (near instant RW volume
>> replica) for backing up our databases. The problem is because there
>> is no write-suspe
Dan Gorman <[EMAIL PROTECTED]> writes:
>All of our databases are on NetApp storage and I have been looking
> at SnapMirror (PITR RO copy ) and FlexClone (near instant RW volume
> replica) for backing up our databases. The problem is because there
> is no write-suspend or even a 'hot backu
37 matches
Mail list logo
