SAP HANA system replication allows time travel for logical error mitigation. Therefore, you can start the secondary system in online mode from a previous point in time.
Secondary time travel can be used in the following situations:
- To quickly access data that was deleted in the original system.
- To intentionally keep the secondary system's log replay delayed. This can be used to read older data from the secondary system, while the secondary keeps replicating.
To prepare the secondary system for time travel, snapshots are kept on the secondary system for a defined time travel period. These snapshots can be used later to start the system at an earlier point in time. An additional log is retained on the secondary system, starting from the earliest time travel snapshot. After opening the old snapshot, the additional log has to be replayed to reach the requested point in time.
Note
You can only use secondary time travel with the following operation modes: logreplay or logreplay_readaccess.
Configuration Parameters
Several parameters are available for configuring secondary time travel.
Use the following parameters to configure secondary time travel. The parameters are defined in the system_replication section of the global.ini file. All parameters are set on the secondary system.
Secondary Time Travel – Parameter
| Parameter | Unit | Def, | Description |
| timetravel_max_retention_time | Min. | 0 | If set to 0, secondary time travel is turned off. If this parameter is set to a value different from 0, the secondary system can be brought online up to the defined time period in the past. |
| timetravel_snapshot_creation_interval | Min. | 1440 (24h) | Defines how frequently snapshots are created for secondary time travel. A new snapshot is created when the time period defined in this parameter has passed since the last snapshot creation. Snapshots older than the time period defined in time_travel_max_retention_time are dropped. |
| Parameter | Unit | Def, | Description |
| timetravel_call_takeover_hooks | true, FALSE | FALSE | Indicates if takeover hooks should be called during secondary time travel. |
| timetravel_logreplay_mode | auto, manual | auto | Defines how the log replay is executed on the secondary system.
|
Time travel snapshots are kept until they get older than the defined timetravel_max_retention_time parameter. If a takeover needs to be done from an earlier point in time, the snapshot that best fits the requested point in time is opened and the remaining changes are applied using logreplay.
Enable Secondary Time Travel
You can edit the secondary .ini file directly and activate using: hdbnsutil -reconfig
Note
Set the parameters carefully to avoid log full or disk full situations. For time travel to work, log and snapshots are kept online in the data area. Because of this, log and data grows on the secondary system when time travel is turned on. The system workload determines how much data is needed.
Note
Topology changes are not considered for secondary time travel, and travel operation cannot be supported beyond these changes.
After setting the parameters, the secondary system begins retaining log information and keeping created snapshots. After retaining sufficient log information and data, the secondary system is ready for time travel.
Monitoring Secondary Time Travel
You can monitor the retaining log and the created snapshots.
To monitor secondary time travel, the secondary system must be online. The current time travel range cannot be determined when the secondary system is offline.
Monitoring Secondary Time Travel
Determine the valid range for which time travel can be executed:
Monitor available snapshots using _SYS_DATABASES_SR_SITE_<sitename>.M_SNAPSHOTS at the primary site.
The hdbnsutil -sr_timetravel --printRange command provides a range for each service in which time travel can be executed.
Use SQL on the primary system with the _SYS_DATABASES_SR_SITE_<sitename>.M_SYSTEM_REPLICATION_TIMETRAVEL secondary proxy view.
Monitor the start time or log position of the system using: _SYS_DATABASES_SR_SITE_<sitename>.M_SYSTEM_REPLICATION_TAKEOVER_HISTORY
Execute Secondary Time Travel
You can start the secondary system in online mode from a previous point in time using the hdbnsutil -sr_timetravel command. During execution of hdbnsutil -sr_timetravel, the specified time and location are stored internally in a dedicated file in the SAP HANA directory. When calling hdbnsutil -sr_timetravel, it can be specified whether takeover hooks should be called. If the parameter is not explicitly specified, the default value from the configuration parameter timetravel_call_takeover_hooks is used.
The secondary system enters online mode at the specified point in time during restart. After restart, the other services read the requested point in time and open their persistence using this information. If the requested point in time cannot be reached, then time travel is aborted. A check ensures that there are time travel snapshots older than the start time for each service.
Execute Secondary Time Travel
Stop the secondary SAP HANA system.
Execute the following command:
hdbnsutil -sr_timetravel --startTime=<startTime> [--callTakeoverHooks=on|off] [--comment="Your Comment"].
Start the secondary SAP HANA system.
For startTime, use the following format specified in UTC: dd.mm.yyyy - hh.mm.ss
You can specify whether takeover hooks should be called. If the timetravel_call_takeover_hooks parameter is not explicitly specified, takeover hooks will not be called.
Use the --comment option to add a reason for the time travel. This comment is displayed in the M_SYSTEM_REPLICATION_TAKEOVER_HISTORY monitoring view in the COMMENTS column.
The secondary system will enter online mode at the specified point in time during restart. After restart, the other services read the requested point in time and open their persistence using this information. If the requested point in time cannot be reached, then time travel will be aborted. A check ensures that there are time travel snapshots older than the start time for each service.
Note
The call of hdbnsutil -sr_timetravel on the secondary system is not yet offered in the system replication app of the SAP HANA cockpit.
Execute Secondary Time Travel While Replication Continues
You can start the log replay at a previous point in time to read older data from the secondary system, while the secondary keeps replicating.
Execute Secondary Time Travel While Replication Continues
Stop the secondary SAP HANA system.
Execute the following command:
hdbnsutil -sr_timetravel --startTime=<startTime> --startMode=replicate
Start the secondary SAP HANA system.
Optional: Trigger the log replay manually with the following command:
hdbnsutil -sr_recoveruntil {--endTime=<timestamp> |max} [--nowait]
Optional: Stop the manual replay mode by setting the timetravel_logreplay_mode parameter back to auto or using:
hdbnsutil -sr_replaymode --mode={auto|manual}
After the system has started, the persistence has been opened on the specified point in time (--startTime). It is replicating the log, and log replay is not running.
In this state, log replay can be executed manually. By executing multiple replay until calls, the secondary site can be step wise rolled forward and data can be accessed in read access mode after each replay step.
Use max to trigger the log replay up to the newest possible point in time. In this case, the target timestamp is automatically determined by checking the valid time travel range for each service.
Use the --nowait option to specify if the command should be executed asynchronously.