SEO

I know ppl are using it to do replication, but has anyone documented what
is involved in doing so?

thanks ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Apr 4, 2006, at 4:05 PM, Marc G. Fournier wrote:

> I know ppl are using it to do replication, but has anyone
> documented what is involved in doing so?
>
> thanks ...

I'll be curious to hear stories of people using it for replication.
The way I interpret replication, there's an available database (even
if read-only) on both ends. With PITR/on-line backups, the way I
understand it, there's no way to provide availability to the recovery
database because it's in a process of continuous recovery. It
qualifies as high availability in terms of a failover solution, but
the recovery database is not actually available until something
triggers it to recover, at which point any writing done to it causes
it to cease to be a replicant of the base database.

--
Thomas F. O'Connell
Database Architecture and Programming
Co-Founder
Sitening, LLC

http://www.sitening.com/
3004 B Poston Avenue
Nashville, TN 37203-1314
615-260-0005 (cell)
615-469-5150 (office)
615-469-5151 (fax)

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Tue, 4 Apr 2006, Thomas F. O'Connell wrote:

> On Apr 4, 2006, at 4:05 PM, Marc G. Fournier wrote:
>
> I'll be curious to hear stories of people using it for replication. The way I
> interpret replication, there's an available database (even if read-only) on
> both ends. With PITR/on-line backups, the way I understand it, there's no way
> to provide availability to the recovery database because it's in a process of
> continuous recovery. It qualifies as high availability in terms of a failover
> solution, but the recovery database is not actually available until something
> triggers it to recover, at which point any writing done to it causes it to
> cease to be a replicant of the base database.

We started a project on it here: http://pgpitrha.projects.postgresql.org/

So far we have a working version of it in CVS which we are using at
travelpost.com. You're correct, the secondary system is only available after
you complete the PITR recovery, but it works well for us currently. Right now
we just make base backups 3 times daily and restore all the way from the base
when we cutover. The first thing we'll be changing is that methodology (i.e.
we'll be going to a continuous recovery methodology). Hopefully we'll get
some interest from more folks soon and get some good ideas flowing.


--
Jeff Frost, Owner <jeff@frostconsultingllc.com>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Marc G. Fournier wrote:
>
> I know ppl are using it to do replication, but has anyone documented
> what is involved in doing so?
>
> thanks ...
We use linux HA and linux DRBD (~RAID1 mirror between disks across a
LAN) to provide a similar replication mechanism that runs "underneath"
the database rather than PITR between the database servers.

I see a lot of interest on this list for the WAL copying solution, and I
am wondering if that is because people have discounted a DRBD solution
or that it has been overlooked?

Thanks,
Robin




---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Robin,

On my part it's simply the fact that I currently have two servers in
different geographical locations - and cost of new hardware is a huge issue.


I have, however, recently developed an interest in rsync but I'm unsure as
to how PG on the standby server would handle a complete rsync'd data
directory.

Andy

> -----Original Message-----
> From: pgsql-admin-owner@postgresql.org [mailtogsql-admin-
> owner@postgresql.org] On Behalf Of Robin Iddon
> Sent: 05 April 2006 9:10 am
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] PITR Based replication ...
>
> Marc G. Fournier wrote:
> >
> > I know ppl are using it to do replication, but has anyone documented
> > what is involved in doing so?
> >
> > thanks ...
> We use linux HA and linux DRBD (~RAID1 mirror between disks across a
> LAN) to provide a similar replication mechanism that runs "underneath"
> the database rather than PITR between the database servers.
>
> I see a lot of interest on this list for the WAL copying solution, and I
> am wondering if that is because people have discounted a DRBD solution
> or that it has been overlooked?
>
> Thanks,
> Robin
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
> !DSPAM:14,44337b9c35048018610585!
>



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Wed, 5 Apr 2006, Robin Iddon wrote:

> Marc G. Fournier wrote:
>>
>> I know ppl are using it to do replication, but has anyone documented what
>> is involved in doing so?
>>
>> thanks ...
> We use linux HA and linux DRBD (~RAID1 mirror between disks across a LAN) to
> provide a similar replication mechanism that runs "underneath" the database
> rather than PITR between the database servers.
>
> I see a lot of interest on this list for the WAL copying solution, and I am
> wondering if that is because people have discounted a DRBD solution or that
> it has been overlooked?

IN my case, we don't run Linux, so any Linux solution is discounted

But, thx ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings