orkungedik/SAP-basis-dataset huggingface dataset:
## 2.5 Resync Optimization
Whenever the primary and the secondary system are disconnected, SAP HANA system replication is out of sync. To get in sync again, a shipping of the missing data is initiated.
The system tries to avoid a full data shipping and to achieve a resync with a delta data or a log shipping. To get the primary and the secondary system in sync again, their persistencies (that is, the data and log volumes) must be compatible. The system that is to be registered as the secondary system checks if its persistence is compatible with the primary system. If this check succeeds, a delta shipping can be carried out instead of requesting a full data shipping from the primary system.
A maximum of three checks are executed by the secondary system in the following order:
1. Check if the newest savepoint is compatible.
The to-be secondary system checks if its newest savepoint is compatible. This check most likely succeeds if the secondary system has just been shut down for a short time.
2. Check if the newest replication snapshot is compatible:
Replication snapshots are written on the system replication primary and secondary system while the replication is up and running. The replication snapshots are created on the secondary system each time a savepoint is written. On the primary system, the replication snapshots are created periodically (time and volume-based) to preserve a state that is known to be shipped to the secondary system. As the snapshot verification takes some time, a replication snapshot that is not yet verified to be shipped may have been created on the primary system.
This check most likely succeeds after a test takeover on the secondary system because this state has to be available also on the primary system.
3. Check if the active replication snapshot is compatible:
The active replication snapshot is a special replication snapshot created on the primary system and verified to be shipped to the secondary system. This check most likely succeeds during a failback operation because it's created on the old primary and the snapshot is verified to be shipped.
The first savepoint or snapshot that is compatible with the primary system will be used for delta data shipping. If none of the three savepoints or snapshots are compatible, then a full data shipping will automatically be carried out.
##  Note
If system replication is out of sync and you need to register again the initial secondary system, use the command hdbnsutil -sr\_register . It is not needed to unregister the secondary system before registering it again. Unregistering the initial secondary system before registering it would hinder an optimized resync and would trigger a full data shipping.
Depending on the chosen operation mode, two different techniques are in place to achieve a resync: data retention and log retention. For more information, see Data Retention or Log Retention
## Related Information
Data Retention [page 20] Log Retention [page 20]
## 2.5.1  Data Retention
Data retention is the technique used to resync the disconnected systems when using the delta\_datashipping operation mode.
With delta\_datashipping , the availability of the last snapshot, that was successfully sent to the secondary system, impacts the type of data sent by the primary system:
- If the last snapshot successfully sent to the secondary system is still available, the primary system sends the incremental data to get in sync again.
- If it is no longer available, a full data shipping is necessary to get in sync again.
The datashipping\_snapshot\_max\_retention\_time parameter with a default of 300 minutes specifies for how long the primary system will keep the snapshot. For more information about system replication parameters, see SAP HANA System Replication Configuration Parameters .
##  Note
If the connection to your secondary system is temporarily lost for a longer time than the default setting of the datashipping\_snapshot\_max\_retention\_time parameter, a delta data shipping is still possible.
In the following two use cases this parameter determines whether a full data shipping is necessary or a delta data shipping will be sufficient:
- The failback scenario After a takeover of the secondary system, the primary system is registered as a new secondary.
- The re-register scenario After a takeover of the seondary system, this system is re-registered as a secondary to the original system.
## Related Information
SAP HANA System Replication: Takeover and Failback [page 85] SAP HANA System Replication Configuration Parameters [page 62]
## 2.5.2  Log Retention
With the logreplay and logreplay\_readaccess operation modes, log segments can be marked as retained so that they can sync a secondary system after being disconnected.
With continuous log replay, delta data shipping cannot be used to sync a secondary system anymore. This is because although the primary's and secondary's persistence are logically compatible, they are no longer physically compatible. This means the data that is contained in the persistence is the same, but the layout of the data on pages can be different on the secondary system. Therefore, a secondary system can sync via delta log shipping only. This happens, for example, in the following use cases:
- The secondary system has been disconnected for some time (for example, because of a network problem or temporary shutdown of the secondary system).
- A former primary system has been registered for failback.
The secondary system only uses the log of the online log area of the primary system for re-syncing. The log must be retained for a longer time period than in the delta\_datashipping mode to be able to sync the secondary system. If getting in sync again doesn't work with delta log shipping (for example, because the log has been reused), a full data shipping becomes necessary. To avoid this, the concept of log retention has been introduced.
For more information on log retention in different scenarios, see Log Retention for Secondary Disconnect , Log Retention for Failback , and Log Retention and Multitarget System Replication .
The following parameters are significant for log retention:
- Use the enable\_log\_retention parameter to enable or disable log retention.
- Use the logshipping\_max\_retention\_size parameter to specify how the system behaves when many log segments of the type RetainedFree are created.
For a full description of the parameters, see SAP HANA System Replication Configuration Parameters .
## Related Information
Log Retention for Secondary Disconnect [page 21] Log Retention for Failback [page 22] Estimating the Maximum Retention Time [page 23] Log Retention and Multitarget System Replication [page 25] SAP HANA System Replication Configuration Parameters [page 62]
## 2.5.2.1 Log Retention for Secondary Disconnect
When a secondary system configured with the operation mode logreplay or logreplay\_readaccess is disconnected, the primary system will not reuse the log segments in the online log area that are required to sync the secondary system using delta log shipping.
These log segments are marked as RetainedFree until the secondary has successfully synced again. If a secondary system is stopped, the log volume will grow on the primary system until the log volume has filled up with log segments. Once the secondary system reconnects and has synced the missing log, these log segments are then set to Free and can be reused after that. This behavior is automatically turned on, if a secondary system with the operation mode logreplay or logreplay\_readaccess is registered.
Log segments are retained on the primary as long as the secondary system is registered, but not connected to the primary system.
##  Note
Therefore, if a secondary system is shut down and not used for a longer period of time, unregister it first, to prevent log volumes from accumulating on the primary system. However, in such a case a full data shipping will be necessary when the system reconnects.
##  Note
Log full means that no more log segments can be created in the log volume, because the log segment directory is full. Currently the number of log segments is roughly 10000. Disk full means that the disk is full, which is not necessarily the case in the log full situation. Log retention usually deals with disk full situations, because with 10000 log segments having each a size of 1 GB you can create 10 TB of log segments.
To understand for how long the SAP HANA system replication landscape will survive before running into a log full situation, see Estimating the Maximum Retention Time .
The logshipping\_max\_retention\_size parameter determines if a full log volume can be prevented at the price of a possibly necessary full data shipping when the system reconnects. The value of this parameter (default is 1 TB per log volume) should not exceed the size of the file system reserved for all log volumes.
## Related Information
Estimating the Maximum Retention Time [page 23]
## 2.5.2.2 Log Retention for Failback
On the secondary system, log retention is required to do a failback with optimized data transport.
The primary system periodically creates persistence snapshots during replication and provides the log position information to the secondary system. After takeover, when the old primary is started again as a secondary, the most recent snapshot is opened on the old primary system and the missing log is requested from the new primary system.
Log retention can occur in two situations:
- While replication is active
During replication, the secondary system keeps all log starting from the last snapshot position provided by the primary system. The old log is automatically released after a new snapshot has been created on the primary system. This behavior is turned on by default and it ensures that during replication only a few RetainedFree segments are kept online. They are needed to fill the gap between the primary snapshot and the current potential takeover log position.
- After a takeover
After takeover, the new primary has to keep the log until a new secondary system is registered and has synced the missing log. Because syncing can take some time, this behavior has to be turned on explicitly on the new primray system as follows:
global.ini/[system\_replication]/enable\_log\_retention = on
##  Recommendation
If you have a setup in which there will be frequent failbacks between two systems, we recommend that you set the following parameter on both system to simplify the configuration: global.ini/ [system\_replication]/enable\_log\_retention = on
##  Note
If the old primary system will not be reused as the new secondary system (failback), it should be disabled after the takeover using hdbnsutil -sr\_disable to prevent log volumes from accumulating on the new primary system. You can disable it with SAP HANA cockpit, SAP HANA studio, or using the command line.
## 2.6 Network Recommendations
The network connectionn between the primary and the secondary system impacts the overall performance of the SAP HANA systems involved in an SAP HANA system replication landscape.
The network throughput requirements of the communication channel used in SAP HANA system replication are influenced by the used operation modes. For more information, see Network Throughput .
The network latency requirements are influenced by the used replication modes. For example, for a synchronous replication mode the performance of the primary system is influenced by the time it takes until the acknowledgement from the secondary system arrives. For more information, see Distance Between Data Centers .
For more information about monitoring and configuring the network connection between the primary and the secondary systems for SAP HANA system replication, see System Replication Network Connection .
## Related Information
Distance Between Data Centers [page 27]
Network Throughput [page 28]
Data and Log Compression [page 30]
Data and Log Volume Encryption [page 31]
System Replication Network Connection [page 187]
## 2.6.1  Distance Between Data Centers
The network latency is influenced by the selected replication mode.
If the distance between your sites is less than 100 km, use the synchronous replication modes: SYNC or SYNCMEM.
If the data centers are more than 100 km apart, the asynchronous replication mode ASYNC is recommended. For more information, see the Check Network Configuration (Long Distance) section in Replication Performance Problems .
## Related Information
Replication Performance Problems [page 216] Replication Modes for SAP HANA System Replication [page 12] Monitoring the Network Latency [page 192]
## 2.6.3  Data and Log Compression
Data and log compression can be configured to reduce the amount of traffic between systems especially over long distances (for exmaple, when using the ASYNC replication mode).
Data and log compression can be used for the initial full data shipping, the sub sequential delta data shipping, as well as for the continuous log shipping.The following types of compression for log and data shipping are supported:
- Log
- Log buffer tail compression
- Log buffer content compression
- Data
- Data page compression
## Log Buffer Tail Compression
All log buffers are aligned to 4kb boundaries by a filler entry. With log buffer tail compression the filler entry is cut off from the buffer before sending it over the network and added again when the buffer has reached the secondary system. So, only the net buffer size is transferred to the secondary system.
The size of the filler entry is less than 4kb, this is the maximum size reduction per sent log buffer. If the size of the log buffers is large, the compression ratio is limited. Log buffer tail compression is turned on by default.
## Log Buffer and Page Content Compression
Log buffers and data pages shipped to the secondary system can be compressed using a lossless compression algorithm (lz4). By default content compression is turned off. You can turn it on by setting the following configuration parameters on the secondary system in the system\_replication section of the global.ini file:
- enable\_log\_compression = true
```
● enable_data_compression = true
```
Log buffer content compression works also in combination with log buffer tail compression. So, only the content part of the log buffer is compressed, without considering the filler entry.
## Related Information
External link to LZ4
## 2.6.4  Data and Log Volume Encryption
Depending on the version of your SAP HANA database, you must enable data volume encryption differently.
Before SAP HANA 2.0 SPS02, data volume encryption was enabled by setting the ini parameter global.ini/ persistence/data\_encryption=true .
Depending on the configuration of the inifile checker, this change was either automatically replicated to the secondary (for the setting globel.ini/[inifile\_checker]=replicate ) or you had to set it manually there as well. For more information, see Monitoring and Replicationg INI File Parameter Changes .
As of SAP HANA 2.0 SPS02, you must change the root keys used for data volume encryption and log volume encryption only in the primary system. The new keys will be propagated to all secondary systems. Enable or disable the data and log volume encryption in the primary system only. The setting will be propagated to all secondary systems as well. For details on enabling data and log volume encryption, see Enable Data and Log Volume Encryption in an Existing SAP HANA Database .
## Related Information
Monitoring and Replicating INI File Parameter Changes [page 158] Enable Data and Log Volume Encryption in an Existing SAP HANA Database
## 3.2 Configuring SAP HANA System Replication
You can configure system replication using SAP HANA cockpit, SAP HANA studio, or hdbnsutil.
##  Note
To configure system replication, the primary system must have been backed up at least once. For more information, see Backup and Recovery .
You can configure system replication using the following tools:
- SAP HANA cockpit
For more information, see Configure System Replication with the SAP HANA Cockpit .
- hdbnsutil
For more information, see Configure System Replication with hdbnsutil .
- SAP HANA studio
For more information, see Configure System Replication with the SAP HANA Studio .
##  Note
To configure SAP HANA system replication for tenant databases, all configuration steps must be done on the system database. However, the data backups must be created for the system database as well as for all tenant databases. After a new tenant database was created in an SAP HANA tenant database system running with SAP HANA system replication, a backup of this new tenant database is necessary to automatically start its replication. Otherwise the replication for this new tenant database will not start.
## Related Information
SAP HANA Database Backup and Recovery Configure System Replication with the SAP HANA Cockpit [page 39] Configure SAP HANA System Replication with hdbnsutil [page 51] Configure SAP HANA System Replication with the SAP HANA Studio [page 55]
## 3.2.1  Configure System Replication with the SAP HANA Cockpit
Use the SAP HANA cockpit to configure system replication between two SAP HANA systems.
## Prerequisites
- You have considered all the general prerequisites needed to set up system replication. For more information, see General Prerequisites for Setting Up SAP HANA System Replication .
- You have added both systems in the SAP HANA cockpit.
- You need the operating system user to set up a system replication landscape with the SAP HANA cockpit. For more information, see Operating System User &lt;sid&gt;adm and Connect to a Resource using Database Credentials .
## Context
Use the System Replication tile on the system overview page to configure system replication. Once the configuration is done, the tile displays information on the operation mode, the replication mode, the configuration type, and the status of system replication. For more information, see System Replication Tile .
To configure system replication in the SAP HANA cockpit, first enable system replication on the primary system and then register the secondary system.
You can configure system replication in two ways in the SAP HANA cockpit:
- From the primary system. For more information, see Configure System Replication from the Primary System .
You can use this method for tier 2 and tier 3 setups. Even though this method is easier, it doesn't work to configure multitarget or more than tier 3 setups directly from the primary system.
- From the primary and secondary systems. For more information, see Configure System Replication from the Primary and the Secondary Systems .
You can use this method to configure any system replication setups you want.
To configure system replication in the SAP HANA cockpit, first enable system replication on the primary system and then register the secondary system.
To change the configuration of an existing system replication, you can register again a previously stopped secondary system when a full data shipping is needed or when you want to change the operation mode. For more information, see Reinitialize the Secondary System .
For an example of a system replication configuration, see Example: Configure SAP HANA System Replication with the SAP HANA Cockpit .
## Related Information
System Replication Tile [page 40]
Configure SAP HANA System Replication from the Primary System [page 43]
Configure SAP HANA System Replication from the Primary and the Secondary Systems [page 45]
Reinitialize the Secondary System [page 46]
Example: Configure SAP HANA System Replication with the SAP HANA Cockpit [page 47]
## 3.2.1.1 System Replication Tile
The System Replication tile on the system overview page displays information about the operation mode, the replication mode, the configuration type, and the status of system replication.
For example, you can see on the System Replication tile when system replication is not configured:
<!-- image -->
After configuring system replication, the tile looks differently for the primary and the secondary system.
On the primary system's tile you can see the role of the system, the replication mode, the operation mode, and whether read access is enabled for Active/Active (read enabled) configurations.
This is an example of a system replication tile for the primary system:
<!-- image -->
On the secondary system's tile you can see the role of the system and the replication mode.
This an example of a system replication tile for the secondary system:
<!-- image -->
In an Active/Active (read enabled) configuration, the secondary system's tile displays also the logreplay\_readaccess operation mode:
<!-- image -->
The system replication tile of your secondary system indicates when the services are offline (for example, when you stop the secondary system to disable system replication):
<!-- image -->
## 3.2.1.2 Configure SAP HANA System Replication from the Primary System
To configure SAP HANA system replication, first enable system replication on the primary system and then register the secondary system. Use the SAP HANA cockpit to execute these separate steps in one configuration step from the primary system.
## Prerequisites
You have considered all the general prerequisites needed to set up system replication. For more information, see General Prerequisites for Setting Up SAP HANA System Replication .
## Context
This topic describes how to configure system replication from the primary system in SAP HANA cockpit in one configuration step. You can use this method for 2-tier and 3-tier setups.
##  Note
If you plan to add SAP HANA dynamic tiering to your landscape in the future, see SAP Note 2447994 before you enable HANA system replication. SAP HANA dynamic tiering requires certain communication ports, operation modes, and replication modes.
## Procedure
1. On the Overview page of the future primary system, choose the System Replication tile.
If you never configured system replication before, this tile displays the message System replication is not yet enabled for this system .
The System Replication page opens. If you performed a data backup before enabling system replication, this page displays the last data backup on the top left and the Configure System Replication button on the top right.
2. Choose Configure System Replication .
The System Replication Configuration dialog opens, allowing you to run the configuration in background.
3. Enter the logical name used to represent the primary system in the Tier 1 System Details screen area.
4. Enter the logical name used to represent the secondary system in the Tier 2 System Details screen area. Keep in mind that the secondary system must have the same SAP system ID (&lt;SID&gt;) and instance number
as the primary system so that they are identified as secondaries.
5. Select the secondary system host and mark the checkbox below this area to stop the system.
6. Select a replication mode. For more information on the available replication modes, see Replication Modes for SAP HANA System Replication .
7. Select an operation mode. For more information on the available operation modes, see Operation Modes for SAP HANA System Replication .
8. Decide whether to initiate a full data shipping or not.
9. Check Start Secondary after Registration .
10. Optional: To add a third tier to your system replication landscape configuration, click Add Tier 3 System on the bottom left.
11. Choose Configure .
## Related Information
General Prerequisites for Configuring SAP HANA System Replication [page 35]
Replication Modes for SAP HANA System Replication [page 12] Operation Modes for SAP HANA System Replication [page 14]
<!-- image -->
SAP Note 2447994
## 3.2.1.4 Reinitialize the Secondary System
You can register again a previously stopped secondary system using the SAP HANA cockpit.
## Context
You can register again a previously stopped secondary system. You must do this when a full data shipping is needed or when you want to change the operation mode.
## Procedure
1. On the Overview page of the stopped secondary system, choose the System Replication tile.
2. On the System Replication Overview , choose Reinitialize Secondary System on the top right.
3. On the System Replication Configuration page, you can now change the configuration. Change the operation mode or resync the persistencies using the Initiate full data shipping option.
The secondary system is up and running again.
## 3.2.1.5 Example: Configure SAP HANA System Replication with the SAP HANA Cockpit
Learn how to configure system replication with the SAP HANA cockpit from the primary system.
## Context
##  Note
To configure system replication, the primary system must have been backed up at least once. This step is included in the procedure described below. Skip this step, if the system was backed up before. For more information, see Backup and Recovery .
## Procedure
1. Create a full data backup for the system database as well as for all tenant databases.
- a. Choose the system database from the Resource Directory . This is the future primary system.
- b. Choose Manage database backups on the system overview page of the primary system.
<!-- image -->
<!-- image -->
- c. Choose Create Backup on the top right.
- d. Create a complete backup, choose a destination type, enter a prefix and the backup destination, then finally choose Back Up .
<!-- image -->
For example, the backup settings can look like this:
<!-- image -->
You can see the running backup progress for each service followed by the backup details once the backup is completed:
<!-- image -->
To see the data backups contained in the backup catalog, go back to the previous page using the arrow on top left.
- e. To back up also the tenant database, select it from the Resource Directory and proceed as described in the previous steps.
This is an example of the system database and the tenant database of the future primary in the resource directory:
<!-- image -->
<!-- image -->
2. To configure system replication, proceed as follows:
- a. Choose the system database that is going to be your primary system from the Resource Directory .
- b. On the System Overview page of the system database, choose the System Replication tile to configure the primary system.
- c. Choose Configure System Replication on the top right to configure system replication without having to switch to the future secondary system.
<!-- image -->
- d. Enter the required information on the System Replication Configuration page.
<!-- image -->
This is an example of possible configuration settings:
<!-- image -->
The overview shows now that the SAP HANA system replication configuration was successful:
<!-- image -->
## Related Information
Example: Configure SAP HANA Multitier System Replication with SAP HANA Cockpit [page 133] Backup and Recovery
## 3.2.2  Configure SAP HANA System Replication with hdbnsutil
You can configure SAP HANA system replication with the hdbnsutil command line tool.
## Prerequisites
You have considered all the general prerequisities needed to configure system replication. For more information, see General Prerequisites for Setting Up SAP HANA System Replication .
##  Note
For SAP HANA tenant database systems all databases must be backed up using hdbnsutil via the database name option:
- for the system database -d SystemDB
- for the tenant databases -d &lt;tenantDBName&gt;
## Procedure
1. Enable system replication on the primary system as follows:
- a. In the Administration editor of SAP HANA studio, choose the Configuration tab and ensure that log\_mode is set to normal in the persistence section of the global.ini file. Log mode means that log segments must be backed up. Log mode means that log
3. normal overwrite segments are freed by the savepoint (therefore only useful for test installations without backup and recovery).
- b. Do an initial data backup or create a storage snapshot. In multiple-container systems, the system database and all tenant databases must be backed up. For more information, see Create Data Backups and Delta Backups .
- c. As &lt;sid&gt;adm on the command line enable the primary for system replication and give it a logical name with the following command. The primary system must be online at this time:
cd /usr/sap/&lt;sid&gt;/HDB&lt;instancenr&gt;/exe
- ./hdbnsutil -sr\_enable --name=&lt;siteName&gt;
| Option Name   | Value           | Description                                                                                            |
|---------------|-----------------|--------------------------------------------------------------------------------------------------------|
| --name        | <primary_alias> | Alias used to represent your primary system and assign it as the primary system for system replication |
To check if the system has been successfully enabled for system replication with hdbnsutil run:
cd /usr/sap/&lt;sid&gt;/HDB&lt;instancenr&gt;/exe
- ./hdbnsutil -sr\_state
## 3.2.2.1 Example: Configure SAP HANA System Replication
This example shows you how to configure system replication with a single host system.
## Context
To configure system replication with two hosts, you may have to change the host names.
In this example a single host system is used. In multi-host systems all hosts have to be renamed.
##  Note
To rename hosts in a production system replication landscape, system replication must be first deactivated. This means you have to first unregister and disable the secondary system before renaming any hosts. Once you have renamed the hosts then you can enable recovery mode again and register the secondary system with the primary system to re-activate system replication.
## Procedure
1. Enable system replication on the primary system, with the hostname ej11.
2. Stop the secondary system. The primary system can stay online.
```
cd /usr/sap/<sid>/HDB<instancenr>/exe ./hdbnsutil -sr_enable --name=dcsite1
```
As &lt;sid&gt; adm
/usr/sap/hostctrl/exe/sapcontrol -nr &lt;instance\_number&gt; -function StopSystem HDB
3. Register the secondary system with the following command:
cd /usr/sap/&lt;sid&gt;/HDB&lt;instancenr&gt;/exe
```
./hdbnsutil -sr_register --name=dcsite2 --remoteHost=ej11 --remoteInstance=50 --mode=sync --operationMode=logreplay
```
Also see SAP Note 611361 Hostnames of SAP servers
4. Start the secondary system. This initiates the initial data transfer.
As &lt;sid&gt; adm
/usr/sap/hostctrl/exe/sapcontrol -nr &lt;instance\_number&gt; -function StartSystem HDB
## Related Information
Rename an SAP HANA System Host SAP Note 611361
## 3.3 Initializing the Secondary
Whenever the secondary is registered with the primary system, the goal is to get the persistence (that is, the data and log volumes) on the secondary system into a consistent state to the primary system.
After initially configuring system replication, a full data shipping takes place. This happens automatically, but it can also be done manually. For more information, see Initialize the Secondary with Storage Copy from Primary .
When initializing the secondary the following two situations can occur:
- The secondary system is completely unrelated to the primary system If the secondary system is unrelated to the primary system, a full data shipping is done. An in-place snapshot created on the disk of the primary system is initially sent to the secondary system. This initial full data shipping can be prevented by manual intervention and the secondary system can be initialized with a binary storage copy of the primary system's persistence. For more information, see
- Initialize the Secondary with Storage Copy from Primary .
- The secondary system is related to the primary system for one of the following reasons:
- It was already registered before as a secondary system to this primary and probably shut down for a time.
- It is a former primary system, which will become a secondary system though failback switching the replicating direction.
If the persistence (that is data and log volumes) of the secondary system is related to the primary system (it actually contains the persistence of the primary at a former time), the newly registered system can be synced with a delta data or log shipping avoiding a full data shipping.
After a new registration of the secondary system, a delta data or log shipping is always attempted. For more information, see Resync Optimization .
## Related Information
Initialize the Secondary with Storage Copy from Primary [page 58] Resync Optimization [page 19]
## 3.3.1  Initialize the Secondary with Storage Copy from Primary
The secondary system can be initialized using a binary storage copy from the primary system.
## Context
For this procedure copy only the data, not the log.
## Procedure
1. Create a consistent binary storage copy from the primary system for the persistence of all services. You can use the snapshot technology to create an IO consistent persistence copy. Create a full copy of the persistence using the IO consistent storage snapshots.
2. If you can't use the method above, create a consistent OS copy of persistence while the primary system is stopped.
2. Shut down the secondary system.
3. Transfer or mount the full copy on the secondary system.
4. Replace the persistence of the secondary system with the storage copy from the primary system.
5. Register the secondary system without [--force\_full\_replica].
6. Start the secondary system.
## Results
When the secondary system is started after the new registration, the initialization optimizations are carried out. The system checks if the persistence of the secondary system is compatible with the persistence of the primary system. The secondary system checks if its persistence is compatible with the persistence of the primary system. If this check succeeds, the secondary system requests only a delta data shipping.
## 3.5 Add and Remove Hosts in SAP HANA System Replication
You can add a new host to a replicated system with the SAP HANA lifecycle manager.
## Context
##  Note
Hosts must be added equally to both primary and secondary sites.
##  Note
Do not turn off system replication when adding a host.
##  Recommendation
It is recommended that a host is added to the secondary site before adding it to the primary site. This avoids the situation where the new host saves data without first being in sync.
## Procedure
1. Add a host to the secondary site and start it.
2. Add a host to the primary site and start it.
Replication begins automatically.
3. To remove a host, first remove it from the primary site and then remove the host from the secondary site.
## Related Information
Add Hosts Using the Command-Line Interface Remove Hosts Using the Command-Line Interface
## 3.6 Changing the Operation Mode
The operation mode can only be changed by stopping and re-registering the secondary system with the desired operation mode.
You can change operation modes using the hdbnsutil -sr\_register command and explicitly setting the new operation mode with the -operationMode option:
```
hdbnsutil -sr_register --remoteHost=<primary hostname> --remoteInstance=<instance number> --replicationMode=[sync|syncmem|async] --operationMode=[delta_datashipping|logreplay|logreplay_readaccess] --name=<siteName>
```
To start the replication with the new operation mode, start the secondary system:
```
sapcontrol -nr <instance_number> -function StartSystem HDB
```
##  Note
It is not necessary to unregister the secondary while changing the operation mode. The hdbnsutil -sr\_register command overwrites the previous register configuration. To understand the scenarios in which you should unregister a secondary system, see SAP Note 1945676 .
When changing the operation mode from delta\_datashipping to logreplay or logreplay\_readaccess , no full data shipping is necessary. Full data shipping is necessary, however, when switching from logreplay or logreplay\_readaccess back to delta\_datashipping .
## Related Information
SAP Note 1945676
## 3.7 Changing the Replication Mode
The replication mode can be changed without going through a full data shipping from the primary system to the secondary system afterwards.
To change the replication mode, use the following command on the online or offline secondary system:
```
hdbnsutil -sr_changemode --mode=sync|syncmem|async
```
In the M\_SERVICE\_REPLICATION view you can check whether the replication mode was changed correctly. The following command provides this information too:
```
hdbnsutil -sr_state --sapcontrol=1
```
## Related Information
M\_SERVICE\_REPLICATION System View [page 269]
## 3.10 Disabling SAP HANA System Replication
Remove a system replication configuration when you want to run the two systems separately or if you don't need this high availability and disaster recovery mechanism anymore.
To remove a system replication configuration, unregister the secondary and disable the primary system. For more information on the use cases of the -sr\_unregister command, see SAP Note 1945676 .
You can disable system replication using the following tools:
- SAP HANA cockpit
For more information, see Disable SAP HANA System Replication with the SAP HANA Cockpit .
- SAP HANA studio
For more information, see Disable SAP HANA System Replication with the SAP HANA Studio .
- hdbnsutil
For more information, see Disable SAP HANA System Replication with hdbnsutil .
## Related Information
Disable SAP HANA System Replication with the SAP HANA Cockpit [page 74]
Example: Disable SAP HANA System Replication with the SAP HANA Cockpit [page 75]
Disable SAP HANA System Replication with the SAP HANA Studio [page 81]
Disable SAP HANA System Replication with hdbnsutil [page 80]
SAP Note 1945676
## 3.10.1  Disable SAP HANA System Replication with the SAP HANA Cockpit
You can disable SAP HANA system replication in an SAP HANA system using the SAP HANA cockpit.
## Prerequisites
- The secondary system must be offline.
- You need the operating system user to disable system replication with the SAP HANA cockpit. For more information, see Operating System User &lt;sid&gt;adm and Connect to a Resource using Database Credentials .
## Procedure
1. Stop the secondary system from the Overall Database Status tile
2. Unregister the secondary system as follows:
- a. On the Overview page of the stopped secondary system, choose the System Replication tile.
The System Replication tile opens displaying the System Replication Overview .
- b. Choose Unregister this Secondary on the top right.
Depending whether your system should be online or offline after unregistering it, check the Start system after unregistration option in the confirmation dialog and choose OK . For more information, see SAP Note 1945676 .
3. Disable system replication on the primary system as follows:
- a. On the Overview page of the primary system, choose the System Replication tile. The System Replication tile opens displaying the System Replication Overview .
- b. Choose Disable System Replication on the top right and confirm that you want to disable system replication.
The Ignore the secondary system option allows you to disable the primary system even though the secondary is still attached. This could be relevant, if the secondary has been uninstalled in the meantime.
## Related Information
Connect to a Resource using Database Credentials Operating System User sidadm
SAP Note 1945676
## 3.10.1.1  Example: Disable SAP HANA System Replication with the SAP HANA Cockpit
Learn how to disable system replication with the SAP HANA cockpit.
## Prerequisites
- The secondary system must be offline.
- You need the operating system user to disable system replication with the SAP HANA cockpit. For more information, see Operating System User &lt;sid&gt;adm and Connect to a Resource using Database Credentials .
## Procedure
1. Stop the secondary system from the Overall Database Status tile.
<!-- image -->
The system replication tile on the overview page of the stopped secondary system indicates that all services are now offline.
<!-- image -->
2. Choose the system replication tile on the overview page of the stopped secondary system.
The system replication overview opens giving the possibility to unregister this secondary system:
<!-- image -->
3. Choose Unregister this Secondary on the top right.
A confirmation dialog opens.
4. Optional: Depending whether your system should be online or offline after unregistering it, check the Start system after unregistration option in the confirmation dialog and confirm.
For more information, see SAP Note 1945676 .
<!-- image -->
5. Switch now to the primary system. Choose the system replication tile of the primary system.
This tile indicates that the primary system is not connected to the secondary system anymore:
<!-- image -->
6. On the system replication overview choose Disable System Replication on the top right.
<!-- image -->
A confirmation dialog opens.
7. Confirm that you want to disable system replication.
<!-- image -->
The Ignore the secondary system option allows you to disable the primary system even though the secondary is still attached. This could be relevant, if the secondary has been uninstalled in the meantime.
On the overview you can now see that the primary system is disabled and system replication is not configured.
<!-- image -->
## Related Information
<!-- image -->
## 3.10.2  Disable SAP HANA System Replication with hdbnsutil
You can disable SAP HANA system replication with hdbnsutil .
## Prerequisites
- You are logged on to both systems as the operating system user (user &lt;sid&gt;adm) or are able to enter these credentials when prompted.
- The secondary system must be offline.
## Procedure
1. Stop the secondary system:
sapcontrol -nr &lt;instance\_number&gt; -function StopSystem HDB
2. On secondary system unregister the secondary system:
hdbnsutil -sr\_unregister --id=&lt;secondarySiteID&gt;
##  Note
If system replication is out of sync and you need to register again the initial secondary system, use the command hdbnsutil -sr\_register. It is not necessary to unregister the secondary system before registering it again.
For an overview of hdbnsutil -sr\_unregister use cases, see SAP Note 1945676 .
3. Disable system replication on the primary system as follows:
```
hdbnsutil -sr_disable
```
## Related Information
SAP HANA System Replication Command Line Reference [page 71]
<!-- image -->
SAP Note 1945676
## 3.10.3  Disable SAP HANA System Replication with the SAP HANA Studio
You can disable SAP HANA system replication in an SAP HANA system using the SAP HANA studio.
## Prerequisites
- You are logged on to both systems as the operating system user (user &lt;sid&gt; adm) or are able to enter these credentials when prompted.
- The secondary system must be offline.
## Procedure
1. Unregister the secondary system as follows:
- a. In the Systems view, right-click the primary system and choose Configuration and Monitoring
3. Configure System Replication . The Configure System Replication dialog opens.
##  Note
You can also access the Configure System Replication dialog from the Landscape System Replication tab.
- b. Choose Unregister secondary system and then Next .
- c. Enter the required system information and choose Next .
- d. Review the configured information and choose Finish .
2. Disable system replication on the primary system as follows:
- a. In the Systems view, right-click the primary system and choose Configuration and Monitoring Configure System Replication .
- b. Choose Disable system replication and choose Next .
- c. Review the configured information and choose Finish .
## 3.11 SAP HANA System Replication Setup for XS Advanced Runtime
In a system replication setup, all the data - including XS advanced runtime system data and application data is replicated to a secondary system.
XS advanced services and applications run only on the currently active system. On the secondary system, XS advanced services are in an idle state until the takeover takes place.
After the takeover, all XS advanced services are started which in turn brings up all XS advanced applications on the secondary system. Moreover, XS advanced services and applications use the same domains and certificates that were present in the primary system before the takeover started.
For this to work, the central point for XS advanced requests must be the same on the primary and the secondary systems. This is established by using a failover router similar to the host auto-failover setup. For more information about the host auto-failover setup, see Host Auto-Failover Setup with XS Advanced Runtime .
SAP HANA System Replication Setup for XS advanced
<!-- image -->
In case the failover router terminates SSL, the same rules apply as described in Host Auto-Failover Setup with XS Advanced Runtime .
For more information, see SAP Note 2300936 .
## Related Information
Host Auto-Failover Setup with XS Advanced Run Time SAP Note 2300936
## 4 SAP HANA System Replication: Takeover and Failback
Learn how to perform a takeover and a failback for planned or unplanned downtimes of the primary system.
## How can I perform a takeover and a failover?
This section describes how to perform a takeover and a failover with three different tools. Generally, you have to perform the following steps:
- Switch your active system from the current primary system to the secondary system
- Register the former primary as the secondary with the now active primary system. The roles are switched compared to the original setup.
## What types of takeover are available?
You can perform a standard takeover, a takeover with handshake, or an invisible takeover.
Perform a standard takeover when there are unplanned downtimes of the primary system. This can happen when the primary system has a serious problem and is not available. You can also perform a standard takeover for planned downtimes such as near zero downtime upgrades (NZDU).
Perform a takeover with handshake for a safe planned takeover while the primary is still running (for example, in NZDU). All new writing transactions on the primary system will be suspended and the takeover is first executed when all redo log is available on the secondary system. For more information, see Takeover with Handshake .
Perform an invisible takeover to achieve an automatic recovery of your sessions after takeover to your new primary. For dedicated client applications this takeover will be invisible. For more information, see Invisible Takeover .
## Where can I find more information?
The following SAP Notes are relevant for a full understanding of the basic concepts described in this chapter:
SAP Notes
SAP Note
<!-- image -->
Title
SAP HANA System Replication Takeover Decision Guideline
<!-- image -->
## Related Information
Takeover [page 86]
Client Connection Recovery After Takeover [page 92] Invisible Takeover and Restart [page 97] Takeover with Handshake [page 99] Failback [page 100] Checking the SAP HANA System Replication Status [page 159]
## 4.1 Takeover
The takeover process is the name for the task of switching your active system from the current primary system to the secondary system.
If your primary data center is not available (for example, because of a disaster or because of planned downtime) and a decision has been made to take over to the secondary data center, you can perform a takeover on your secondary system. To help you decide if a takeover is advisable, see the decision tree in SAP Note 2063657 .
We recommend to use third-party external tools to check if hosts, the network, and data center are still available. In addition, you can use python scripts to decide when a takeover should be carried out. For a detailed description of the available python scripts, see Checking the System Replication Status .
Once the takeover command runs, the former secondary system becomes the new primary system - more correctly, it becomes your new actively running system.
##  Note
The takeover does not include stopping the former primary system. It will still run, if you don't stop it.
You can perform a takeover using the following tools:
- SAP HANA cockpit
For more information, see Perform a Takeover with the SAP HANA Cockpit .
- hdbnsutil
For more information, see Perform a Takeover with hdbnsutil .
- SAP HANA studio
For more information, see Perform a Takeover with the SAP HANA Studio .
System replication: Hanging client processes after a takeover
## Related Information
<!-- image -->
Checking the SAP HANA System Replication Status [page 159]
Perform a Takeover with the SAP HANA Cockpit [page 87]
Example: Perform a Takeover with the SAP HANA Cockpit [page 88]
Perform a Takeover with hdbnsutil [page 91]
Perform a Takeover with the SAP HANA Studio [page 92]
Client Connection Recovery After Takeover [page 92]
Invisible Takeover and Restart [page 97]
Takeover with Handshake [page 99]
SAP Note 2063657