Bug 48340

GemStone/S 64 Bit

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

All Platforms

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:


Last updated: 9/18/19