Everything about secondary time travel of Secondary node

[rajarajeswari_kaliyaperum]

Secondary Time travel (SAP HANA >= 2.0 SPS 03 in context of system replication with operation modes logreplay or logreplay_readaccess)

1.What is secondary time travel? What are its uses ?

We can start the secondary system or the log replay at a previous point in time.

Secondary time travel can be used:

• To quickly access again data, which was deleted in the original system.


• o 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.Site:help.sap.com
  NOTE:Topology changes are not considered for secondary time travel, and travel operation cannot be supported beyond these changes
  
  
  

  2.How does secondary time travel works?

  
  The secondary time travel works based on snapshot data that gets retained in secondary for the specified time period .ie, 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 older point in time. Additional log will be retained on the secondary system starting from the oldest time travel snapshot. After opening the old snapshot, the additional log has to be replayed to reach the requested point in time.
  

  3.What are the pre-requisites for considering a time travel ?

  
  Below are the mandatory pre-requisites to use time travel feature .
  
  -You can use secondary time travel only with the operation modes logreplay or logreplay_readaccess.
  
  -Parameters:
  
  a.To prepare the system for time travel, the global.ini/[system_replication]/ timetravel_max_retention_time parameter must be configured on the secondary system. This parameter defines the time period to which the secondary system can be brought back   in the past.
  
  b.Optionally, the global.ini/[system_replication]/timetravel_snapshot_creation_interval parameter can be adapted to adjust the secondary's snapshot creation.
  
  After setting these parameters, the secondary starts retaining log and keeping created snapshots.
  

  4.How does the mode SYNC affects the primary upon using the time travel of secondary?

  
  Configuring the SYNC replication mode with the full sync option, does not lead to a freeze of the primary system upon secondary time travel
  

  5.How does storing snapshots for time travel affects the secondary system’s data and log volume ?

  
  For time travel to work, log and snapshots are kept online in the data area. Because of this, log and data will grow on the secondary system when time travel is turned on. The system workload determines how much data is needed. Set the parameters carefully to avoid log full or disk full situations
  

  6.What are the steps /commands to execute secondary time travel ?

  
  Steps:
  
  
  
  1. Stop the secondary system.
  
  
  2. Execute hdbnsutil -sr_timetravel --startTime=<startTime> [--callTakeoverHooks=on| off] [--comment="Your Comment"]
  
  
  
  Eg: hdbnsutil -sr_timetravel –startTime=25.06.2020 -01.00.00 –comment=”Seconday time travel to 25 June 2020 1 am UTC”
  
  For startTime use the following format specified in UTC: dd.mm.yyyy - hh.mm.ss You can specify if takeover hooks should be called. If the timetravel_call_takeover_hooks parameter is not explicitly specified, takeover hooks won't be called. For more             information on takeover hooks, see Implementing a HA/DR Provider. Use the --comment 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.
  
  
  
  1. Start the secondary system. The secondary system will enter in 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.
  

  7.Is it possible for us to start the log replay at a previous point in time to read older data from the secondary system, while the secondary keeps replicating ?

  
  Yes.
  
  Steps:
  
  
  
  1. Stop the secondary system.
  
  
  2. Execute hdbnsutil -sr_timetravel --startTime=<startTime> --startMode=replicate For startTime use the following format specified in UTC: dd.mm.yyyy - hh.mm.ss
  
  
  3. Start the secondary system. After the system has started, the persistence has been opened on the specified point in time, it is replicating log, and log replay is not running.
  
  
  4. Optional: Trigger the log replay manually with hdbnsutil -sr_recoveruntil {-endTime=<timestamp>|max} [--nowait]
  
  
  
  For <timestamp> use the following format specified in UTC: dd.mm.yyyy - hh.mm.ss .
  
  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 --nowait to specify if the command should be executed asynchronously.
  
  
  
  1. 
     

     Optional: Stop the manual replay mode by setting the timetravel_logreplay_mode parameter back to auto or using hdbnsutil -sr_replaymode --mode={auto|manual}

     
     
  
  
  
  

  8.Detailed information about the Time travel feature related parameters:

  
  The parameters are defined in the system_replication section of the INI file. All parameters are set on the secondary system
  
  
  
  1. timetravel_max_retention_time (minutes)(Default=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 point in the past.
  
  
  
  1. timetravel_snapshot_creation_interval(minutes)(Default=1440minites)
  
  
  
  Defines how frequently snapshots are created for secondary time travel. Time travel snapshots are kept until they get older than the defined timetravel_max_retention_time parameter. If time travel needs to be done on an older point in time, the snapshot that best fits the requested point in time will be opened and the remaining changes are applied via log replay. A new snapshot is created when the point in time defined in this parameter has passed since the last snapshot creation. Snapshots older than the point in time defined in time_travel_max_retention_time are dropped.
  
  
  
  1. timetravel_call_takeover_hooks(Default=False):
  
  
  
  Indicates if takeover hooks should be called during secondary time travel.
  
  
  
  1. timetravel_logreplay_mode (Default=auto):
  
  
  
  Defines how the log replay is executed on the secondary system.
  
  The following settings are allowed:
  
  
  
  • Auto The log replay is done automatically up to the newest possible log position.
  
  
  • Manual You must manually trigger the log replay up to the requested timestamp using the -sr_recoveruntil hdbnsutil command
  
  
  
  

  9.What can be monitored w.r.t secondary time travel and its related activities?  How does this behavior changes if the secondary is online / offline ?

  
  We 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 is offline.

  
  

  10.How can we determine the valid range for which time travel can be executed ?

  
  Below are the 2 ways by which valid range for time travel can be determined.
  
  
  
  1. Using hdbnsutil -sr_timetravel --printRange : This command provides a range for each service in which time travel can be executed.
  
  
  
  START_TIME: Contains the oldest possible point in time for which timetravel can be executed. As time travel is done for all services, the intersection of all ranges have to be checked to make sure, all services can reach the specified timestamp.
  
  END_TIME: Contains the last possible point in time for which timetravel can be executed. For slave services, this timestamp can be some time back without being outdated, if there was no more activity on this slave for some time. To ignore the slave                 volumes, only the lines for transaction master can be considered. Those are marked as MASTER in the COORDINATOR_TYPE column.
  
  2.Using SQL on the primary system via the _SYS_DATABASES_SR_SITE_<sitename>:


• M_SYSTEM_REPLICATION_TIMETRAVEL secondary proxy view . The start time or the log position of the system can be monitored using M_SYSTEM_REPLICATION_TAKEOVER_HISTORY.