Thread: shadowing (like IB/Firebird)
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? -- 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
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: > 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
Sounds an aweful lot like RAID level one :-) Why would a DB system need to do what RAID already does quite well? > 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.
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