From: | Alex Vinogradovs <AVinogradovs(at)Clearpathnet(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: WAL to RAW devices ? |
Date: | 2007-09-01 01:10:02 |
Message-ID: | 1188609002.6082.72.camel@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Yeah, that's the trick... I need high availability with
high performance and nearly real-time synchronization ;-)
Also, I've got FreeBSD here... ZFS will be out with 7.0
release, plus UFS2 has snapshotting capability too. But
the whole method isn't good enough anyway.
> Oh, I see.
>
> What I've seen described is to put a PITR slave on a filesystem with
> snapshotting ability, like ZFS on Solaris.
>
> You can then have two copies of the PITR logs. One gets a postmaster
> running in "warm standby" mode, i.e. recovering logs in a loop. The
> other one, in a sort of jail (I don't know the Solaris terminology for
> this) stops the recovery and enters normal mode. You can query it all
> you like at that point.
>
> Periodically you stop the server in normal mode, resync the snapshot
> (which basically resets the "modified" block list in the filesystem),
> take a new snapshot, create the jail and stop the recovery mode again.
> So you have a fresher postmaster for queries.
>
> It's not as good as having a true hot standby, for sure. But it seems
> it's good enough while we wait.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Darek Czarkowski | 2007-09-01 01:11:02 | Postgresql 7.3 on Red Hat Enterprise 5 (Problem with SEMMNI, SEMMNS) |
Previous Message | Alvaro Herrera | 2007-09-01 01:01:06 | Re: WAL to RAW devices ? |