Bug 37973

Bug: 37973

Impact:

Critical

Product:

GemStone/S

Versions:

6.7.2.1, 6.7.2, 6.7.1, 6.7, 6.6.5, 6.6.4, 6.6.3.3, 6.6.3.2, 6.6.3, 6.6.2, 6.6.1, 6.6, 6.5.8, 6.5.7.5, 6.5.7, 6.5.6, 6.5.5, 6.5.4, 6.5.2, 6.5.1, 6.5, 6.3.1, 6.3, 6.2.x, 6.2, 6.1.6, 6.1.5, 6.1.x, 6.0.2, 6.0.1, 6.0

Platform:

ALL Platforms

Fixed In:

Multiple Stones can attach to SAN extents causing corruption

When starting up a GemStone system, the stone performs an initial check
that it has sole access to the extents by opening the first extent in
exclusive write mode.  If the open fails, the stone assumes that another
stone and associated processes are using that DB and will shutdown.

Unfortunately, some SAN (Storage Area Network) configurations can cause
this check to fail when the two stones are on different machines.  This
may be the case in a primary/fail-over configuration that uses the SAN
to make the extents/tranlogs appear as local files to both.

Allowing the second stone to startup and proceed to make changes to the
extents and tranlogs will cause massive corruption to the extents and
loss of data in the tranlogs.

Workaround

If you are using a SAN as part of a primary/fail-over configuration as
described above, you should provide some additional check to your
architecture to prevent accidently starting the fail-over stone while
the primary is still running (or vise-versa).  

Alternatively, you should configure the tranlogs to be in different
directories (perhaps having to copy the final tranlog from the primary to
the fail-over directory), to prevent overwriting the tranlog and loosing
data needed for a restore from backup / tranlog replay.