Hello and welcome to the SAP HANA Academy.
My name is Denys van Kempen
and in this video tutorial series
I will show you how to set up and manage SAP HANA system replication.
In this video, I will briefly discuss some of the concepts.
OK. Let's frame our topic a bit.
When you run a production system,
you want it to be available 24 by 7
but life is hard and stuff happens.
Hardware may fail, network cards, memory chips, CPUs,
and disasters - fires, floods and earthquakes - may occur.
This could impact your business.
So, how does SAP HANA help avoid undesired downtime situations?
What type of support for high availability is there?
Well, here we need to make a distinction
between problems that can be fixed by software
and situations that go way beyond that.
Because, as you know,
if your data center is underwater, a reboot will not help you much.
Now for the minor events there is fault recovery.
Should, for whatever reason, a service crash -
be it the index server, the actual database engine,
the name server, compile server, and so on -
these services will be restarted automatically by the watchdog service
Should, for whatever reason, the whole server crash
- the HANA host -
then its role can be taken over by a standby host.
You need to set this up and
this assumes you are running HANA as a
distributed system with a number of
servers (a number of hosts) and one or
more standby nodes configured.
System replication is listed here as well in the fault recovery section
because you can use it, for example, to perform near-zero downtime for upgrades.
We will look into this topic in a separate video.
System replication is also listed in the second section: disaster recovery.
Here we see the options we have with SAP HANA
to handle unexpected and unplanned downtime.
Obviously, the standard solution is backups.
This will be part of any high availability plan
and when we talk about backup
you will often hear the terms RPO and RTO.
RPO stands for the recovery point objective and
RTO for recovery time objective.
Both measurements you would like to have as small as possible.
Ideally, you want a backup that's not too old
and you want to be back online quickly after the disaster.
If we consider, for example, a recovery plan that includes a single back up each day at one in the morning
and we lose a disk at midnight
then we need to restore the database from backup
and then recover 23 hours of redo logs to get to the point of failure.
This will result in a very long time-to-recover.
So, typically, for production systems,
you might want to make more frequent backups to reduce the RTO,
the recovery time objective.
Should we have lost, in our example,
not only the disk with data files
but also the redo log files
this would mean that we could only restore the database from backup
but not do any recovery.
In this case, RTO would be short
but the recovery point will definitely not be
where we would like it to be
as with the loss of the redo logs we would also have lost valuable data as well.
Here we see a comparison on
RPO, RTO, cost and performance consequences.
‘Perf. ramp’, the ramp up time needed
to get back in business.
As always, you can get it fast, cheap, or good and you pick any two.
Backup gives disaster recovery at relatively low cost
but requires patience before we are back in business should something disastrous occur.
The more often you backup,
the more storage you need, hence, the cost will go up
plus it will still be relatively slow.
Storage replication will give you a zero or near-zero recovery point.
This concerns a hardware vendor solution
where disks or flash storage is replicated.
Typically, below the file system at the block device level.
So, it is completely transparent to the HANA database or
the Linux operating system.
The medium qualification for the recovery time is because some time is needed
for the replicated storage device to become active as main storage
and with nothing loaded in memory,
performance ramp up will be relatively long.
Our third option is system replication.
This involves having a shadow system up and running
that receives any update to the
production system as it occurs.
Should the primary site fail, then it can take over immediately
As a result, we have a zero RPO and a low RTO.
Basically, the time it takes to switch the IP addresses or
a DNS entry from the primary to the secondary site.
It's possible to set up multi-tiered system replication as well.
The third system could be well outside the datacenter.
Maybe even in a different part of the world.
The replication in the metro cluster will be synchronous
and in the geo cluster, the remote standby, asynchronous.
Depending on the requirements, there are three modes to choose from.
Asynchronous
means that the primary system sends the data to the secondary system
but does not wait for the data to arrive or to be committed.
Synchronous in-memory is the default setting.
Here the primary system commits the transaction after it receives a reply that the log was received by the secondary system.
This does not require the data to be persisted - written to storage, that is -
on the secondary system.
The transaction delay is shorter as a result.
The third option, synchronous, does require persistence.
This mode guarantees immediate consistency between both systems.
This mode also has the full sync option
and is even more restrictive
as transaction processing is suspended in case of communication failure
between the primary and secondary node
and this guarantees no data loss.
So if we return to our overview,
we can see that system replication provides a solution
for both fault recovery and disaster recovery.
Of course, this comes at a cost
as we need to have a duplicate system up and running, doing nothing.
The first question asked, then, is
can't we use the secondary system as non-production system for training, testing, and so on?
Well yes, of course you can.
However, there are some restrictions.
The production data on the secondary system cannot be pre-loaded in memory
as this is now occupied by your test system.
So the performance ramp up will be longer;
it will impact the recovery time, the RTO.
But considering that you now can use the
system while it waits for a disaster
that just might never happen, it may well be worth it
In the end, these are all business decisions.
System replication is documented in the SAP HANA Administration Guide, chapter 4.
You can read or download this guide, free of charge,
from SAP Help Portal on help.sap.com.
Thank you for watching this SAP HANA Academy video.