## 2.5.2.4 Log Retention and Multitarget System Replication
When the primary system replicates data changes to more than one secondary system, you should use force log retention and log retention propagation to reach an optimized re-sync and avoid a full data shipping after takeover or other disconnect situations.
## Force log retention
Force log retention is used on a system to retain log until it's actively disabled. To use force log retention, enter the value force\_on\_takeover for the enable\_log\_retention configuration parameter.
If enable\_log\_retention = force\_on\_takeover is configured, the log will be retained during replication for all direct secondaries until a takeover is executed. During takeover, the parameter is set to force . This means the log will be retained independently of any secondary system.
##  Example
A typical scenario is described in the following steps:
1. Configure all systems with [system\_replication]/enable\_log\_retention = force\_on\_takeover
2. During takeover on a secondary system, if force\_on\_takeover is set, the value is changed to enable\_log\_retention = force . This means that starting from the takeover, the log is retained until it's explicitly disabled.
3. Re-register all required systems until the landscape is fully functional again.
4. Reset [system\_replication]/enable\_log\_retention = force\_on\_takeover on the system on which takeover has been executed before re-establishing the original configuration.
The configuration must be done manually (for example, by the administrator or using setup scripts) because the SAP HANA system doesn't know when the system landscape has been completely reconfigured.
## Log retention propagation
Log retention propagation is used to retain the log based on the smallest savepoint log position in the whole system replication landscape. Log retention propagation should be enabled if you want to re-order your systems in a complex system replication setup.
This can be done by setting the following parameter in global.ini: [system\_replication]/ propagate\_log\_retention = on . If you want to propagate log retention in a system replication landscape between all systems, this parameter should be set on all systems in the landscape.
When you set this parameter on a system, it behaves as follows:
- The system sends to its source system the minimum log position of its own savepoint and the retained log position it gets from all direct secondaries as retained position.
- The system sends the minimum log position of its own savepoint and the retained log position it gets from all direct secondaries to the secondaries as retained log position.
- The system uses the minmum log position it gets from all direct secondaries and its source system (if not primary) as own retained log position.
## Example
To explain these concepts we are using the setup described in Multitarget System Replication . In this setup, primary system A replicates data changes to secondary system B located in the same data center. Primary system A also replicates data changes to the secondary system C located in another data center. Secondary system C is a source system for a further secondary system D located in the same data center with system C. For a quick overview, use the graphic below:
<!-- image -->
If there is a takeover on secondary system B, you must register system C to B and system A to B to recreate the original configuration. To avoid a full data shipping for both systems, system B must retain all the log until systems A and C have synced again. This can't be accomplished by setting global.ini/ [system\_replication]/enable\_log\_retention = on because system B doesn't know how many systems must be re-attached until the landscape is back in its functional state.
Force log retention should be used on system B until systems A and C are registered again and synced.
If you want to re-order your systems, enable log retention propagation. Log retention without propagation only affects the direct neighbors. For example, if system D is stopped in this setup, system C retains log for D, but not for A and B. If system D is re-attached to systems B or A and propagation is not turned on, log could be missing because systems A and B do not retain their log with respect to D.
## Related Information
SAP HANA Multitarget System Replication [page 142]
Disaster Recovery Scenarios for Multitarget System Replication [page 145]