Re: A few questions to real pgsql gurus - Mailing list pgsql-general

From Dmitry Tkach
Subject Re: A few questions to real pgsql gurus
Date
Msg-id 3E5A538F.7030601@openratings.com
Whole thread Raw
In response to A few questions to real pgsql gurus  ("mike McGire" <mmcgire@hotmail.com>)
Responses Re: A few questions to real pgsql gurus  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
We have looked into a bunch of backup/replication solutions when switching our production site from informix to
postgres,and 
none of the ones we looked at was particularly attractive :-(

So, we ended up sticking with the following configuration:

- The database files sit on a NetApp box (this is a very reliable disk array with parity control etc...
plus, it has a 'snapshot' capability, that allows you to take a live snapshot of any directory in real time - that
creates
a read-only copy of the content of that directory within a second or so).
- The snapshots are taken hourly by a cron job on the whole database (older snapshots get removed after a while), and
themost recent snapshot 
gets backed up to the tape every night.
- Both primary and fail-over servers look at the same copy of the database on the NetApp (only one server is up at any
givenmoment, of course), thus 
eliminating the need in replication.

This gives us the ability to do the 'point-in-time' restore from a snapshot if necessary, and no, we cannot restore a
particulartable 
(cannot imagine a situation when we'd ever want to do that tough)...

The only potential problem we might have with this setup is with what happens if the NetApp box itself dies (we still
havethe tape backups, but 
it would take a while to restore one of them back to disk - so we won't be able to have the immediate fail  over), but
wedecided that we can 
live with it, because we only have one NetApp anyway, so, even if we did have replication, we'd be replicating on the
samedevice, and still have 
a problem if it goes south.... The box is pretty reliable anyway, with a lot of redundancy, so, it is unlikely that it
crashesso badly, that there 
is no way to recover...

As for functions and triggers. we are doing everything in C - I personally find plpgsql not only slow, but also having
verycryptic syntax, 
and not very flexible (there is lots of stuff that you can do in C, that just cannot be done in plpgsql)... besides, I
wasjust not too 
happy about having to learn yet another language :-)

Dima






mike McGire wrote:
> Hi
>
> We are working on a project and our client wants to use PostgreSQL as the
> backend, since it will be a very mission critical 24x7 live environment, I
> have to know a few things about postgresql before we can consider it.
>
> 1) Backups : Going through the documents I can see that there are no
> incremental backups available in postgres yet, I may have overlooked it,
> therefore, I would like to know:
>
>     a) Am I right on the incremental backup ?
>     b) what would be the performance impact of taking frequent backups
>        ( Lets say every 2-3 hours ).
>     c) Is it possible to restore tables selectively from a backup.
>     d) Can we do a point in time restore from the backups.
>
> 2) Failover :
>
>    a) is it possible to create a cluster of 2 (primary & secondary)
>       databases.
>    b) is it possible to configure an auto-failover to the secondary
>       database in case primary dies.
>    c) how reliable the replication is in postgresql, can a) & b) be
>       implemented using replication.
>
>       Auto-failover is very crucial for this project, so I would like
>       to get as many reliable solutions for that as possible including
>       3rd party applications ( like NetApp or whatever ) if there are
>       any.
>
> 3) Functions & triggers : Our project would be heavily dependent on
>    functions and triggers :
>
>    a) I see postgresql supports many procedural languages, so what
>       should be the preferred language to be used for functions/
>       procedures ( i.e. is PL/PGSQL as fast as C is etc ).
>
> Thanks
> Mike
>
>
>
>
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: no "+" operator for smallint and bigint
Next
From: Tom Lane
Date:
Subject: Re: A few questions to real pgsql gurus