Hi Dalton,


...testing showed that you had spread out the

> database across a single cluster of machines - if you have a break in the
> network, the version of nuodb that I was looking at could not heal.
>

Version 1 allows storage managers to rejoin the database after a partition
has been resolved.

>
>
>
> "What are the recovery methods if members of the cloud detach due to
> network fragmentation � does the whole database die or does the fragments
> of the database continue to work and then reconcile the work processed once
> the network is re-established?"
>
> *Answer Given*
>
> "Should a network partition occur only one segment will remain active and
> only if that segment meets the minimal requirements defined by the systems
> administrator. Other segments will remain offline until the partition is
> resolved, then they will rejoin and synchronize data with the master
> segment. If your design require a system that can partition, run
> independently and then synchronize when reconnected then we suggest that
> each logically independent segment of the database in fact be its own
> physical database."
>

That answer is correct. When the storage managers are partitioned, only
those storage managers in the larger partition allow transactions to
commit. When the partition is resolved, the previously inactive storage
managers synchronize their archives with the continuously running storage
managers and become part of the solution again.

>
>
> Has that answer changed in the newer releases?

No, but I doubt that you are asking that two halves of a partition continue
to operate without communication and then rejoin. Remember that only
storage managers are seriously affected. A transaction engine that can
communicate with the active storage managers remains active and fully
capable. Clients that can see any transaction engine that does have a
connection to an active storage manager can connect to that transaction
engine.

> Can the different segments
> separate and reattach, re-applying work without loss of data that was
> committed on two separate segments?

Commits are not allowed in separate segments.

> Can those segments continue to
> work independently until the connection reconnects? Does nuodb reconcile
> the work without having the various tiers/clients needing any understanding
> of the various elements involved?

No.

> I am truly curious as we spent years on
> in house middle tier solutions that do this for us.
>

I can imagine. The problem NuoDB solves is made somewhat simpler by
separating transaction handling from storage.

>
>
>
> Now, if you read the whole email, I began by equating the risk of ram drive
> vs any other medium and stated that there is risk and loss of ACID unless
> you have taken a great deal of precautions.
>
>

Durability is a question of "How many swings of the ax?" In memory and on
SSD is one level. Add a UPS and you get another level, add a disk and you
get another level, but none of they survive a machine room fire. Off-site
storage adds another level, but a twelve foot hurricane surge ... and so
on, up to the next ice age.

Best regards

Ann


[Non-text portions of this message have been removed]