[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 19-Jun-16 10:57 AM
> To: info-vax at info-vax.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Re; Spiralog, RMS Journaling (was Re:
> FREESPADRIFT)
> 
> On 2016-06-19 01:46:17 +0000, Kerry Main said:
> 
> > I am not talking about just OpenVMS . This is platform agnostic and not
> >  specific to any OS. It is also a timeless core principle that is not
> > likely  going to change any time soon.
> >
> >
> > As I stated in my previous reply, by its very nature, write back &
> > asynch update strategies increase the risk of a significant event (site
> > lost or  system halted due to HW issue?) causing one to lose data.
> >
> >
> >
> > When you tell an application that the update was completed, and yet
> no
> > form of data persistence has taken place that transcends at least 2
> > sites, then there is a risk that data will be lost in the event of a
> > site
> >
> > and or server being lost.
> 
> And what do you think server-level replication is?  

Its asynchronous communications whereby the app thinks the data
has been updated, when in fact, it has not. 

Case in point:

- app thinks a multi- $M transaction has been completed. App
continues with post update processing.
- before async replication can complete, plane crashes into DC
- transaction update has not been written to remote site 
- result - Bank App thinks transaction was completed, but when 
the App is restarted at remote site, there are inconsistencies
and possibly huge legal/tech/regulatory issues to sort out.

>OpenVMS doesn't
> have any concept of this — wait, let me rephrase that, OpenVMS fully
> supports remote server-level replication, you just have to write and
> support and maintain all the necessary code involved — but other
> platforms do have this and are working to add this.   Remote access to
> redundant servers with either fast nonvolatile storage or with a way to
> reliably roll volatile storage to disk during an outage are faster than
> dinking around with tertiary and quaternary storage such as hard disks
> and tape.   Or you use the remote server as a replication log.   Though
> if you're at lower ranges of transactions but have a comparatively
> large budget — where most of the OpenVMS servers I've worked with
> are
> used — sure, your long-familiar synchronous-write-to SSD or disk works.
>  Even in the lower performance ranges, remote server replication may
> still be of interest, even there.
> 

You keep trying to bring this back to what OpenVMS has or has not.

It’s a platform agnostic issue. Applies to OpenVMS as well as every 
other platform on the planet.

You can reduce the time between data replication periods to reduce the 
chances of inconsistent data happening, but the bottom line is that for 
critical apps, when you tell the app with RPO=0 requirements that the 
update is complete, then that update has to be complete in both sites 
or it is rolled back. Data has to be consistent - even in the case where 
a plane hits the DC.

This is also where 2PC comes in as well.

To address your "grass is greener on the other side" type comments,
I would encourage you to review this recent (Feb 2016) distributed 
systems presentation "Architecting Distributed Databases for Failure":
https://www.infoq.com/presentations/data-integrity-distributed-systems?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=presentations_link&utm_content=link_text 
(click on InfoQ video)

The grass on the other side is certainly not as green as you like to 
make it out to be.

:-)

Regards,

Kerry Main
Kerry dot main at starkgaming dot com