Describing SAP HANA System Replication

System replication has the following advantages:

• Memory is continuously loaded on a secondary site in preparation for the possible takeover and occupies resources.

• Switch-over is faster than with storage replication or mirroring (2-5 minutes).

• There is a very short performance ramp (only minutes, not hours, without preparation).

System replication has the following disadvantage:

The hardware (memory and CPU) is actively used on the secondary site for the standby or shadow processes.

1. Delta Data Shipping (operation_mode=delta_datashipping)

   This mode establishes a system replication where occasionally (per default every 10 minutes) a delta data shipping takes place in addition to the continuous log shipping. The shipped redo log is not replayed on the secondary site.

2. Continuous Log Replay (operation_mode=logreplay)

   This mode does not require a delta data shipping anymore. Additionally, the shipped redo log is continuously replayed on the secondary site.

3. Continuous Log Replay with Active/Active (operation_mode=logreplay_readaccess)

   This mode is similar to the logreplay operation mode in that it continuously replays the redo log on the secondary site. Additionally, it allows read-only access to the secondary.

The events for the start of a transport are as follows:

1. The primary system creates an internal data package similar to a full data backup and transfers this initially to the secondary site. The transport happens asynchronously.
2. Log information is transferred in parallel to the initial data transfer. The log is transported asynchronously until the commit of the finished transaction occurs. With the commit, all other log information that is not yet transferred or written, as well as the final commit, must also be written synchronously. This must occur before the primary productively-used database can continue transactional work.
3. All load and unload operations of the main indexes and table columns are monitored and offered with the incremental data transfer to the secondary system. These main indexes and table columns are then loaded or unloaded equivalently to memory in preparation for the takeover.

The events during incremental transport are as follows:

1. With the help of the shadow memory concept operation of SAP HANA, small incremental backups are transferred to the delta data package every 10 minutes at the secondary site. The default parameter setting is 600 seconds.
2. With this delta data information, information from the loaded main indexes into SAP HANA on the primary site are also transferred to the secondary site. This is to prepare the main memory with these main indexes on the secondary site too.

Since the first version of system replication, the delta_datashipping operation mode has been the default replication method. With the logreplay operation mode, delta data shippings are no longer necessary. The takeover time has been reduced and more components are already initialized at replication time.

In the logreplay operation mode, the system replication uses an initial data shipping to initialize the secondary site. After that, only log shipping is complete and log buffers received by the secondary are replayed there. Savepoints are executed individually for each service, and column table merges are executed on the secondary site.

In the logreplay mode of operation, log segments can be marked as retained so that they can sync a secondary system after a disconnect.

With continuous log replay, delta data shipping cannot be used to sync a secondary site. This is because although the primary and secondary persistence are logically compatible, they are no longer physically compatible. This means that the data contained in the persistence is the same, but the layout of the data on pages can be different on the secondary site. Therefore, a secondary site can sync only using delta log shipping. This is relevant for the following situations:

• The secondary site has been disconnected for some time (for example, because of a network problem or temporary shutdown of the secondary site).
• A former primary site has been registered for failback.

The secondary site only uses the log in the online log area of the primary SAP HANA system for syncing. To sync the secondary site, the log must be retained for a longer time period than previously. If syncing using delta log shipping does not work, for example because the log has been reused, a full data shipping is necessary. To avoid this, the concept of log retention has been introduced.

The operation mode Log Replay Read Access is identical to the Log Replay mode with the exception that the secondary system is available in read only mode. This means that a SQL query can access (read) the data in the secondary, but the data can't be changed.

The operation mode Log Replay Read Access can be useful in an environment where OLPT and OLAP workloads are mixed, and you want to split these over the primary and secondary system.

The following prerequisites must be taken into account:

• Additional independent disk volume is needed for Development/QA systems. Because the secondary site requires the same I/O capacity as the primary site, the additional systems must not have a negative impact on the secondary’s I/O. Therefore, it is recommended to have a separate storage infrastructure for each system.

• The SIDs and instance numbers have to be different for Development/QA. The <instance number>+1 of the productive system must not be used, but must be free on both sites, because this port range is used for system replication communication.

• Preload of tables must be switched off on the secondary site, using the following parameter:

  global.ini/[system_replication]-> preload_column_tables=false

• The takeover process takes longer because no data is preloaded in memory at the secondary site (could still meet SLAs for disaster recovery).

• Development/QA systems need to be shut down in the case of a takeover.

• The global allocation limit on the secondary must be set in a way that the available memory covers the memory needed by the secondary system as well as the Development/QA systems, using the following parameter:

  global.ini/[memorymanager]-> global_allocation_limit

The advantages of system replication with a Development/QA system on a secondary site include the following:

• Development/QA is operated on the secondary site (mixed cost calculation).

• Synchronous and asynchronous solutions are available.

• The impact of synchronous solution on the primary site is at about 10% (in contrast to about 25% with storage replication).

• The transfer process from primary to secondary is optimized and a lesser transfer amount is necessary compared to storage replication.

• During the takeover to the secondary site, only a roll forward is necessary because the latest data synchronization point is necessary.

The disadvantages of system replication with a Development/QA system on a secondary site include the following:

• Table and column data cannot be loaded continuously into memory on the secondary site.

• Hardware (memory and CPU) is actively used for Development/QA and partly for the standby or shadow processes.

• Takeover is similar to storage mirroring (20 to 30 minutes at best).

• Performance ramp is similar to storage mirroring (1 to 3 hours).

• QA and Development need their own disk infrastructure carefully separated so as not to have influencing effects on each other.