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
Re: [ADMIN] PITR Based replication ...
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: [EMAIL PROTECTED] [mailto:pgsql-admin- [EMAIL PROTECTED] 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
Re: [ADMIN] PITR Based replication ...
Andy Shellam wrote: 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 Andy - agreed that DRBD is not appropriate for WAN-type environments (at least not unless the database is mostly read-only). There has just recently been a fairly extensive discussion on this list about how best to replicate the WAL files between two machines - I have no direct experience of this myself so will not comment on whether or not rsync is suitable. Cheers, 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
Re: [ADMIN] PITR Based replication ...
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] PITR Based replication ...
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
Re: [ADMIN] PITR Based replication ...
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 [EMAIL PROTECTED] 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
