shadowing (like IB/Firebird)

David Garamond wrote:

Is there a feature similar to this currently in Postgres, or will there
be? Sometimes (like in a shared hosting environment), we cannot have the
luxury of hot-swapped RAID or expensive SAN, and it's nice to be able to
have a synchronous backup so that in case a disk fails, we can recover
to the last moment just before failure.

Will PITR offer this?

Pitr recovers from the last moment before failure. Not sure what
shadowing is.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

David Garamond wrote:

Is there a feature similar to this currently in Postgres, or will there
be? Sometimes (like in a shared hosting environment), we cannot have the
luxury of hot-swapped RAID or expensive SAN, and it's nice to be able to
have a synchronous backup so that in case a disk fails, we can recover
to the last moment just before failure.

Will PITR offer this?

Pitr recovers from the last moment before failure. Not sure what
shadowing is.

Sorry, should've at least described 'shadowing'. A shadow is a
synchronous page-level (I think) mirror file. That is, when you open a
database /disk1/dbname.fdb and then issue a:

CREATE SHADOW 1 '/disk2/dbname.fdb';
CREATE SHADOW 2 '/disk3/dbname.fdb';

then all 3 files will be kept synchronized at all times. Each subsequent
page write will go to all 3 files (if any of the write fails, the
transaction fails, so it's not unlike a synchronous replication).

Now suppose /disk1 fails, one of the shadow can be configured to
immediately take over as the master database, without any down time. We
can then add /disk4/dbname.fdb, for instance, to become a new shadow.

Alternatively, when a shadow fails, IB/Firebird can refuse further
transactions until there is another shadow coming up, so the database is
shadowed all the time.

--
dave

David Garamond wrote:

Bruce Momjian wrote:

David Garamond wrote:

Is there a feature similar to this currently in Postgres, or will there
be? Sometimes (like in a shared hosting environment), we cannot have the
luxury of hot-swapped RAID or expensive SAN, and it's nice to be able to
have a synchronous backup so that in case a disk fails, we can recover
to the last moment just before failure.

Will PITR offer this?

Pitr recovers from the last moment before failure. Not sure what
shadowing is.

Sorry, should've at least described 'shadowing'. A shadow is a
synchronous page-level (I think) mirror file. That is, when you open a
database /disk1/dbname.fdb and then issue a:

CREATE SHADOW 1 '/disk2/dbname.fdb';
CREATE SHADOW 2 '/disk3/dbname.fdb';

then all 3 files will be kept synchronized at all times. Each subsequent
page write will go to all 3 files (if any of the write fails, the
transaction fails, so it's not unlike a synchronous replication).

Now suppose /disk1 fails, one of the shadow can be configured to
immediately take over as the master database, without any down time. We
can then add /disk4/dbname.fdb, for instance, to become a new shadow.

Alternatively, when a shadow fails, IB/Firebird can refuse further
transactions until there is another shadow coming up, so the database is
shadowed all the time.

No, we don't have plans to do that. We will allow continuous logging so
a tar backup plus this log will bring you up to current.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sounds an aweful lot like RAID level one :-) Why would a DB system need to
do what RAID already does quite well?

Glen Parker wrote:

Sounds an aweful lot like RAID level one :-) Why would a DB system need to
do what RAID already does quite well?

I think IB/FB's shadowing was implemented before RAID was invented or
became popular. And as I said before, there are cases where we
don't/can't have RAID.

--
dave

Bruce Momjian wrote:

Sorry, should've at least described 'shadowing'. A shadow is a
synchronous page-level (I think) mirror file. That is, when you open a
database /disk1/dbname.fdb and then issue a:

CREATE SHADOW 1 '/disk2/dbname.fdb';
CREATE SHADOW 2 '/disk3/dbname.fdb';

then all 3 files will be kept synchronized at all times. Each subsequent
page write will go to all 3 files (if any of the write fails, the
transaction fails, so it's not unlike a synchronous replication).

Now suppose /disk1 fails, one of the shadow can be configured to
immediately take over as the master database, without any down time. We
can then add /disk4/dbname.fdb, for instance, to become a new shadow.

Alternatively, when a shadow fails, IB/Firebird can refuse further
transactions until there is another shadow coming up, so the database is
shadowed all the time.

No, we don't have plans to do that. We will allow continuous logging so
a tar backup plus this log will bring you up to current.

What about the future synchronous replication or clustering? Will this
feature do what shadowing in IB/FB does? Cause I've met a couple of
people that really love this feature and they cling to FB because of this.

Actually, what is needed is:

- an exact mirror at all times;
- a very simple, straightforward, and fast way to failover;

done by software.

--
dave

David Garamond wrote:

Now suppose /disk1 fails, one of the shadow can be configured to
immediately take over as the master database, without any down time. We
can then add /disk4/dbname.fdb, for instance, to become a new shadow.

Alternatively, when a shadow fails, IB/Firebird can refuse further
transactions until there is another shadow coming up, so the database is
shadowed all the time.

No, we don't have plans to do that. We will allow continuous logging so
a tar backup plus this log will bring you up to current.

What about the future synchronous replication or clustering? Will this
feature do what shadowing in IB/FB does? Cause I've met a couple of
people that really love this feature and they cling to FB because of this.

Actually, what is needed is:

- an exact mirror at all times;
- a very simple, straightforward, and fast way to failover;

done by software.

I recommend they keep clinging. :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 2004-04-26 at 23:43, Bruce Momjian wrote:

David Garamond wrote:

Now suppose /disk1 fails, one of the shadow can be configured to
immediately take over as the master database, without any down time. We
can then add /disk4/dbname.fdb, for instance, to become a new shadow.

Alternatively, when a shadow fails, IB/Firebird can refuse further
transactions until there is another shadow coming up, so the database is
shadowed all the time.

No, we don't have plans to do that. We will allow continuous logging so
a tar backup plus this log will bring you up to current.

What about the future synchronous replication or clustering? Will this
feature do what shadowing in IB/FB does? Cause I've met a couple of
people that really love this feature and they cling to FB because of this.

Actually, what is needed is:

- an exact mirror at all times;
- a very simple, straightforward, and fast way to failover;

done by software.

I recommend they keep clinging. :-)

Should we recommend they submit a patch instead? :-)

Seriously though this sounds like it could be an extension of the
tablespaces implementation couldn't it?

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert Treat wrote:

On Mon, 2004-04-26 at 23:43, Bruce Momjian wrote:

David Garamond wrote:

Now suppose /disk1 fails, one of the shadow can be configured to
immediately take over as the master database, without any down time. We
can then add /disk4/dbname.fdb, for instance, to become a new shadow.

Alternatively, when a shadow fails, IB/Firebird can refuse further
transactions until there is another shadow coming up, so the database is
shadowed all the time.

No, we don't have plans to do that. We will allow continuous logging so
a tar backup plus this log will bring you up to current.

What about the future synchronous replication or clustering? Will this
feature do what shadowing in IB/FB does? Cause I've met a couple of
people that really love this feature and they cling to FB because of this.

Actually, what is needed is:

- an exact mirror at all times;
- a very simple, straightforward, and fast way to failover;

done by software.

I recommend they keep clinging. :-)

Should we recommend they submit a patch instead? :-)

Seriously though this sounds like it could be an extension of the
tablespaces implementation couldn't it?

They can do hardware mirroring, or software/OS mirroring. Why put that
in the database too? Seems like it would just complicate our code with
little payback.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

At 09:53 AM 4/27/2004 -0400, Bruce Momjian wrote:

Actually, what is needed is:

- an exact mirror at all times;
- a very simple, straightforward, and fast way to failover;

done by software.

They can do hardware mirroring, or software/OS mirroring. Why put that
in the database too? Seems like it would just complicate our code with
little payback.

I agree. This is best done by the various RAID solutions out there.

One of the things Postgresql lacks would be the clustering stuff where you
either run one database on multiple machines or a cluster of multiple
databases on multiple machines that work together, in order to either get
better scalability/performance and/or availability. I don't really know
what would be good ways to do these - hope someone figures them out.

Still, there's always the expensive "Big box" option where you put
postgresql on one of those big fault-tolerant servers. Even so, the limit
on how big the "Big box" can get is probably a lot lower than how big a
cluster can get.

Link.

On 4/26/04 3:25 PM, "Glen Parker" <glenebob@nwlink.com> wrote:

Sounds an aweful lot like RAID level one :-) Why would a DB system need to
do what RAID already does quite well?

One case I can think of is where the shadow is on a separate system (e.g. a
SAN or NetApps, another linux box, etc.). RAID doesn't protect you against
certain types of hardware failure. We recently lost a RAID 5 due to a
double disk failure. We've had high end boxes lose a RAID when just one
disk went out (theoretically shouldn't happen) - apparently when the disk
died it caused corruption elsewhere. I have also seen (a couple of times) a
controller go bad and proceed to write garbage all over the disks. The
mirroring worked quite well - we had a very nice file system full of
mirrored garbage.

Of course, none of these protect you against an errant application that did
a 'delete from' instead of 'delete from where'...

Wes

David Garamond wrote:

Actually, what is needed is:

- an exact mirror at all times;
- a very simple, straightforward, and fast way to failover;

done by software.

http://www.drbd.org/ works well for us and can be set up quickly and
from commodity parts.

wespvp@syntegra.com wrote:

died it caused corruption elsewhere. I have also seen (a couple of times) a
controller go bad and proceed to write garbage all over the disks. The
mirroring worked quite well - we had a very nice file system full of
mirrored garbage.

Does this mean software RAID is actually safer than hardware RAID?
(Since the OS and processor is usually more reliable than a disc
controller).

--
dave

On 4/27/04 11:48 PM, "David Garamond" <lists@zara.6.isreserved.com> wrote:

Does this mean software RAID is actually safer than hardware RAID?
(Since the OS and processor is usually more reliable than a disc
controller).

I'm not sure I would jump to that conclusion. If a controller went bad and
trashed a disk below a software RAID, who knows how the RAID software would
handle it? The only point I was making is that RAID usually, but not
always, protects against hardware failures. There are a number of things it
doesn't protect against. I'd guess in the last 15 years or so I've seen a
RAID not prevent data loss on a hardware failure an average of every 2-3
years +/-. The most recent was a couple of weeks ago when 2 disks failed
(the conjecture is that one died and took out the other, but no one knows
for sure). Then there's all the software failures - program errors,
corrupted file systems (we had that about a month ago on a ReiserFS), etc.

Wes

Kragen Sitaker wrote:

On Tue, Apr 27, 2004 at 10:36:24AM +0700, David Garamond wrote:

Glen Parker wrote:

Sounds an aweful lot like RAID level one :-) Why would a DB system need to
do what RAID already does quite well?

I think IB/FB's shadowing was implemented before RAID was invented

Heh, not likely.

I asked this on Firebird-General@yahoogroups.com list and Jim Starkey
(the original author) said that shadowing indeed was written before RAID
was invented (probably in early 80's or even late 70's). See the list
archive for more details.

or became popular.

That's quite possible.

--
dave