As you know, implementing a disaster recovery (DR) strategy to adequately protect our data recoverability and availability, plus our business continuity, can be a very stressful experience. What’s worse is that it could take a lot of effort and time to implement it properly. When talking about High Availability (HA) and Disaster Recovery (DR), it is always important to review your company’s Service Level Agreements (SLA) that are in place. For example, the RTOs, meaning the Recovery Time Objective, relates to how much time the business can afford to be without access to data, and RPO, meaning the Recovery Time Objective, relates to how much data the business can afford to lose in case of a disaster or incident situation. So, to make your life easier, I’m here to show you how quickly you can protect your Autonomous Database in the cloud against any unwanted disaster situation only by using Oracle Autonomous Data Guard.
Note: You can also find this blog post as a video here.
So, let’s stop talking about it and let me show you how easy it is to implement Autonomous Data Guard in just a few minutes. Let’s get started.
Well, we are here now, connected to OCI Generation 2. We can see that I have an Autonomous Database called “AUTONOMOUS-TEST-01” as ATP (Autonomous Transaction Processing) and it is available.
If I click on the database name, then go to Resources (1) and click on Disaster Recovery (2), I can see my disaster recovery strategy for the moment is Backup-based (3).
You need to understand that for the Backup-based DR type, the Recovery Time Objective (RTO) is one hour plus one hour per each, five terabytes in size, and my Recovery Point Objective (RPO) is one minute. If I have an Autonomous Data Guard instance protecting my primary database, my RTO drops significantly to 15 minutes, whereas my RPO would continue as one minute. So, let’s see how hard and complicated it is to create and implement Autonomous Data Guard.
All we need to do is click on add peer database, and you will see that currently, my primary database is on the West Coast of the US (Phoenix).
The next step would be to select the region to which we want to add the peer database; because I already have my primary on Phoenix, West Coast of the US, I will select a cross-region option like the Ashburn (1) region that is on the US East Coast as my DR site and select a compartment in the process. My compartment, in this case, is called “Francisco-test” (2), and the next step would be to select the Disaster Recovery Type I would use. I already have, by default, the Backup-based Disaster Recovery, where you can see the RTOs and RPOs I mentioned. Still, in this case, I will select an Autonomous Data Guard (3) with an RTO of 15 minutes and an RPO of one minute, and then, finally, I will click Add Peer Database (4). Now that I have that selected, I can relax and go for a coffee and enjoy it for a few minutes.
Now that my peer database is being created, I can see that the status of my ATP (Autonomous Transaction Processing) database changed to updating, and I can see that my autonomous standby database is being provisioned. That means I still have my backup as a DR strategy, but I am now provisioning my standby database with Autonomous Data Guard.
At this point, my DR environment has been fully provisioned and configured by Autonomous Data Guard, which is already providing me with the desired level of protection that I wanted as per my RTO and RPO requirements. Now, if I go to Resources and then to the Disaster Recovery section, I can see that my Autonomous Data Guard standby database is fully available
So now that I have my primary Autonomous Database protected by Autonomous Data Guard, it is time to see what I can do. For this, we will click these three buttons on the right side of my peer Autonomous Database (1). There, I can see that this menu gives me many exciting options: see the details of my Autonomous Data Guard, execute a switchover, convert my standby to a snapshot standby database, copy peer database OCID, update DR type, or disable that peer, that means this Autonomous Data Guard that I have available.
In this case, let’s try a switchover. Let’s click on the Switchover option in the previous menu. Because it is a cross-region switchover, it cannot be done from the primary database region (it is not supported), So I will then perform the Switchover by going to the region where my remote standby is (As you can see in the image below when trying to Switchover from the primary region it would give you an error message and a link to go to the peer region). So now that I clicked the link and moved to the Ashburn region, and I can see I am connected to my standby database, you must know the name of your primary database. In this case, it is “ADBTST01”.
I will now click “More actions” and select the Switchover option from the menu. Next, I will enter the peer database name to confirm that we want to do the switchover. And that’s it. All we need to do now is click ensure switchover to peer, and the magic happens.
I am now excited to see the switchover in action, protecting my data as we go through the role transition. As seen in the image below, the peer state has now changed to role-changing in progress.
A few moments later, I was informed that the switchover was completed, and my peer database is now available as the primary database with zero data loss.
Mission completed. But what about my standby database? Do I need to reprovision it? Let’s look at the Disaster recovery section of my current primary database. Wait a moment. Autonomous Data Guard has already taken care of that for me and is reviewing it.
I guess I will drink my coffee and wait. Once that is completed, I get the good news that my standby database is back up and running.
My data is once again entirely protected by Autonomous Data Guard (without any need for intervention from my side). As you can see above, the standby is in the green state. But this is not all. We noticed that we can efficiently execute a switchover, but how about a failover? When a primary becomes unavailable due to a disaster situation, the switchover option in the menu will change to a failover option. However, there are no worries here because with Autonomous Data Guard, when required, an automatic failover is automatically triggered. That means the Autonomous Database requires no user action. Since this is an automated action, the automatic failover can succeed only when no data loss will occur. In Autonomous Data Guard, the RTO is 2 minutes for automatic failover, and the RPO is 0. That’s all!
As shown, it is quick and simple to protect your Autonomous Database using Autonomous Data Guard (ADG). I hope you enjoyed this short example, and remember that having access to an accurate Autonomous Database is an incredible benefit.
Autonomous disaster recovery capabilities are a game changer that brings many competitive advantages to your business. You can practise everything you saw here and even more in a free lab at Oracle LiveLabs called “Manage and Monitor Autonomous Database”. This is a free lab that you can practice on your own time, and there, you will learn everything about Autonomous Database plus Autonomous Data Guard. Thank you so much for your time, and I hope you enjoyed this post!
Unique Competitive Advantages:
- Autonomous Database – Unique fully autonomous database in the market; many databases have some level of automation on them, but only Oracle has an autonomous database. More information here
- Autonomous Data Guard – A unique capability on top of a unique offering that allows your business to keep its critical production databases available to mission-critical applications despite failures, disasters, human error, or data corruption. More information here
- Full Stack Disaster Recovery – Only Oracle OCI can fully orchestrate/automate a DRP (Disaster Recovery Plan, including checking, testing, and executing it with one click). I am not discussing doing it only at the database level but for the entire stack (Network, Compute, Storage, Applications and, of course, at the database level) as per your business requirements. More information here