Bug 48340

Bug: 48340

Impact:

Product:

GemStone/S 64 Bit

Versions:

3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.2, 3.3.1, 3.3, 3.2.17, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.0.4, 3.1.0.3, 3.1.0.2, 3.1.0.1, 3.1

Platform:

All Platforms

Fixed In:

3.6

Repository>>continuousRestoreFromArchiveLogs: does not work on extent copy

Documentation in the System Administration Guide presents two approaches to initially configuring a slave system for hot standby:

1.  Take extent copies of the primary, copy these to the slave system, and startstone -R -N before executing #continuousRestoreFromArchiveLogs:.

2.  Take a fullBackup of the primary, copy the backup file(s) to the slave system, and restore the backup on the slave before executing #continuousRestoreFromArchiveLogs:.

For now, the first approach does does not work:  the #continuousRestoreFromArchiveLogs: returns the expected output message and error (4048), but tranlogs *will not* be getting replayed as expected.

Workaround

Start the slave system with an out-of-box extent0.dbf and restore a full backup from the primary before executing #continuousRestoreFromArchiveLogs: