DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:sender:reply-to:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	b=tvBuTtuBbfdrWJdwA8jEAAzDHO4DV6HESa5//6YJZN5JxNHwQ927clY12mgl9ehgBZ
	T1xcbpWTfbC/DBrQjw767X/d+4as7dGz8yNOYAbssRSyzX3RatrZj7zDePMZTtz07UiC
	xcHV2G5Ine7QFB7/Oke/f53Uy3IMfNTYQ3RN4=
MIME-Version: 1.0
Reply-To: koichi.szk@gmail.com
In-Reply-To: <201003121711.o2CHBHf27975@momjian.us>
References: <4B9A6E8B.4050303@magneta.com.cy>
	<201003121711.o2CHBHf27975@momjian.us>
Date: Sat, 13 Mar 2010 09:53:45 +0900
Message-ID: <ef4f49ae1003121653m2c69a15ar2fd5bb9d87d46d63@mail.gmail.com>
Subject: Re: Off-site storage for PITR logs
From: Koichi Suzuki <koichi.szk@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Nicos Panayides <nicos@magneta.com.cy>, pgsql-admin@postgresql.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry for that.    The bug was incorrect calculation of XNOOP record
size in GiST WAL when incremental log is created from the full backup.
  Because the bug impact is so serious, I'm rebuilding the test
environment which is taking long.   I'll report the cause of the bug
to hackers and bugs.

If GiST is not used, WAL compression works correctly but I'm not
comfortable to use lesslog with known bug.

----------
Koichi Suzuki


2010/3/13 Bruce Momjian <bruce@momjian.us>:
> Nicos Panayides wrote:
>> Hi,
>> I am planning an off-site backup solution for a fairly busy
>> (mostly-write) 8.3 database. The database is currently about 200GB in
>> size. I though about using log shipping and cold standby since it's easy
>> in terms of administration and also offers point in time recovery.
>>
>> The database generates about 3 PITR log files per minute. If my
>> calculations are correct the sites need to be connected with a 7MBit
>> connection and the logs will need about 68GB of storage per day!
>>
>> Does anyone have any suggestions on how to significantly reduce the
>> volume of log files or recommend another off-site backup solution that
>> would require less bandwidth and storage?
>
> I would use pg_lesslog to reduce the size of the WAL files:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0http://pgfoundry.org/projects/pglesslog/
>
> However, there is a bug in pg_lesslog so I wouldn't use it until that is
> fixed:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0http://archives.postgresql.org/pgsql-announce/=
2010-02/msg00005.php
>
> Koichi, do you have any update on this? =C2=A0I don't see that a new vers=
ion
> has been uploaded, and I also see no mention on the pgfoundry site about
> the bug.
>
> --
> =C2=A0Bruce Momjian =C2=A0<bruce@momjian.us> =C2=A0 =C2=A0 =C2=A0 =C2=A0h=
ttp://momjian.us
> =C2=A0EnterpriseDB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://enterprisedb.com
>
> =C2=A0PG East: =C2=A0http://www.enterprisedb.com/community/nav-pg-east-20=
10.do
>