AWS CLI and OCI CLI commands side by side for easier comparison. Below table compares AWS and OCI CLI commands for similar actions across both platforms, helping you easily switch between them or use both in your multi-cloud environment.
AWS CLI Command
OCI CLI Command
Configure AWS CLI: aws configure
Configure OCI CLI: oci setup config
EC2: List Instances: aws ec2 describe-instances
Compute: List Instances: oci compute instance list --compartment-id <compartment_ocid>
EC2: Start an Instance: aws ec2 start-instances --instance-ids <instance_id>
CloudFront: List Distributions: aws cloudfront list-distributions
Object Storage: Upload a File: oci os object put --bucket-name <bucket_name> --name <object_name> --file <local_file_path>
Below is a table comparing AWS and OCI commands related to Networking. These commands cover networking services like Virtual Private Cloud (VPC) in AWS and Virtual Cloud Network (VCN) in OCI. This table compares networking-related AWS CLI and OCI CLI commands for similar tasks like managing VPCs/VCNs, subnets, security groups, route tables, VPNs, and more. For both platforms, these commands allow you to configure, manage, and troubleshoot your networking infrastructure effectively.
VPC: List VPN Gateways: aws ec2 describe-vpn-gateways
VCN: List VPN Gateways: oci network vpn-gateway list --compartment-id <compartment_ocid>
Here’s a comparison table of AWS CLI and OCI CLI commands related to backup and restore from snapshots for both AWS and OCI. These commands cover common actions like creating snapshots, listing snapshots, and restoring from them.
EC2: Restore from Snapshot (Create volume from snapshot): aws ec2 create-volume --snapshot-id <snapshot_id> --availability-zone <availability_zone>
Block Volume: Restore from Snapshot (Create a new volume from a snapshot): oci bv volume restore --backup-id <backup_id> --availability-domain <availability_domain> --compartment-id <compartment_ocid>
Autonomous Database: Create a Backup (Autonomous DB snapshot in OCI): oci db autonomous-database backup create --autonomous-database-id <autonomous_db_ocid> --display-name <backup_name>
Autonomous Database: Delete a Backup (Delete Autonomous DB backup): oci db autonomous-database backup delete --autonomous-database-id <autonomous_db_ocid> --backup-id <backup_id>
RDS: Restore from Snapshot (Restore an RDS instance from snapshot): aws rds restore-db-instance-from-db-snapshot --db-instance-identifier <new_db_instance_id> --db-snapshot-identifier <snapshot_id>
Autonomous Database: Restore from Backup (Restore Autonomous DB from backup): oci db autonomous-database restore-from-backup --autonomous-database-id <autonomous_db_ocid> --backup-id <backup_id>
Key Points:
AWS EC2 primarily uses EBS snapshots for backup and restore of volumes. You can create a volume from a snapshot to restore it.
AWS RDS provides an option to create and restore database snapshots for RDS instances.
OCI Block Volume uses volume backups (backups of block volumes) to manage snapshots, and you can restore from backups to a new volume.
OCI Autonomous Database allows backup creation and restore for Autonomous Databases via backups.
Both AWS and OCI offer similar snapshot and restore functionalities but with slight differences in the specific commands and services they offer for database and block volume backups.
To perform a switchover and switchback using Oracle Data Guard with dgmgrl (Data Guard Manager command-line interface), you typically use the following steps. These steps assume you have already configured Oracle Data Guard and are familiar with the concepts of Primary and Standby databases.
1. Switchover from Primary to Standby Database
A switchover is a planned role reversal between the Primary and Standby databases. This process allows the Standby database to become the new Primary and vice versa.
Steps for Switchover:
Log in to Data Guard Manager (DGMGRL):
Open a command-line terminal on the Primary database machine and log into the Data Guard Manager using dgmgrl.
dgmgrl
Connect to the Data Guard Configuration:
Connect to your Data Guard configuration.
DGMGRL> connect sys/password@primary
Replace sys/password with the appropriate credentials and the correct TNS name for your primary database.
Check the Data Guard Status:
Before proceeding, it's good practice to check the status of the Data Guard configuration.
DGMGRL> show configuration;
Verify that the configuration is in sync and there are no issues.
Perform the Switchover:
Execute the switchover command to initiate the role reversal.
DGMGRL> switchover to standby;
Replace standby with the correct name of the standby database if needed.
This command will:
Automatically stop Redo Apply on the Standby.
Start Redo Apply on the new Primary.
Synchronize the new Primary with the old Standby.
If necessary, restart the Oracle instances to complete the switchover.
After the switchover completes, the old Primary will be the new Standby, and the old Standby will be the new Primary.
Verify the Switchover:
Check that the switchover was successful by viewing the configuration status.
DGMGRL> show configuration;
Ensure that the roles have been reversed correctly.
2. Switchback from Standby to Primary Database
Switching back is simply performing a reverse of the original switchover process, where the Primary database becomes the Standby again.
Steps for Switchback:
Log in to Data Guard Manager (DGMGRL):
Open a terminal on the current Primary (which was previously the Standby) and log into the Data Guard Manager using dgmgrl.
dgmgrl
Connect to the Data Guard Configuration:
Connect to the Data Guard configuration.
DGMGRL> connect sys/password@primary
Check the Data Guard Status:
Check the current status to ensure everything is running smoothly.
DGMGRL> show configuration;
Perform the Switchback:
Execute the switchover command again, but this time switch back to the original Primary (which is now the Standby).
DGMGRL> switchover to primary;
This command will:
Reverse the roles of the Primary and Standby databases once again.
Stop Redo Apply on the current Standby and resume it on the new Standby.
Synchronize the databases.
Verify the Switchback:
Check the Data Guard configuration to verify the new roles.
DGMGRL> show configuration;
Things to Consider:
Synchronization: Ensure that the database logs are synchronized before performing any switchover. You can use the show database verbose command to check the synchronization status.
Redundancy and Backup: Always ensure you have current backups of the databases before performing a switchover or switchback, as these operations can potentially cause downtime.
Log Archives: If you have the possibility of switching back during the switchover process, verify that all the archive logs have been applied correctly.
Data Guard Broker: If you're using Data Guard Broker, these operations can be performed automatically without manual intervention using DGMGRL commands.
By following these steps, you can successfully perform a switchover and switchback operation with Oracle Data Guard using dgmgrl. Always perform these operations during planned maintenance windows to minimize downtime.
For a comprehensive and official reference on performing switchover and switchback operations in Oracle Data Guard using dgmgrl, I recommend checking Oracle's official documentation:
Oracle Data Guard Concepts and Administration Guide: This is the most authoritative source for Data Guard operations, including switchover and switchback procedures.
In this blog, we are going to see data guard switch over by using data guard broker DGMGRL.
Data Guard Switchover:
A database can be in one of two mutually exclusive modes (primary or standby). These roles can be altered at runtime without loss of data or resetting of redo logs. A switchover is a role reversal between the primary database and one of its standby databases. A switchover guarantees no data loss.
This is typically done for planned maintenance of the primary system.
During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role.
The transition occurs without having to re-enable either database.
Overall steps:
1. Connect the primary database with DGMGRL Data Guard broker.
2. Switch over primary to standby database.
3. Connect Standby database.
4. Switch over standby to primary.
Step 1: Connect the primary database with the DGMGRL Data Guard broker.
[oratest@oracle admin]$ dgmgrl sys/oracle@orclDGMGRL for Linux: Release 19.0.0.0.0 - Production on
Fri Nov 12 13:19:44 2021 Version 19.9.0.0.0Copyright (c) 1982, 2019, Oracle and/or its affiliates.
All rights reserved.Welcome to DGMGRL, type "help" for information.
Connected to "orcl"
Connected as SYSDBA.
Step 2: Switch over primary to the standby database.
DGMGRL> switchover to orcl_stby;Performing switchover NOW, please wait...Operation requires a connection to instance "orcl" on database
"orcl_stby"Connecting to instance "orcl"...Connected as SYSDBA.New primary database "orcl_stby" is opening...Operation requires start up of instance "orcl" on database "orcl"Starting instance "orcl"...ORACLE instance started.Database mounted.Switchover succeeded, new primary is "orcl_stby"DGMGRL>Let's switch back to the original primary. Connect to the
new primary (orcl_stby) and switchover to the new standby database (orcl).
Step 3: Connect the Standby database.
[oratest@oracle admin]$ dgmgrl sys/oracle@orcl_stbyDGMGRL for Linux: Release 19.0.0.0.0 - Production on
Fri Nov 12 13:31:56 2021Version 19.9.0.0.0Copyright (c) 1982, 2019, Oracle and/or its affiliates.
All rights reserved.
Welcome to DGMGRL, type "help" for information.Connected to "orcl_stby"
Connected as SYSDBA.
Step 4: Switch over standby to primary
DGMGRL> switchover to orcl ;Performing switchover NOW, please wait...Operation requires a connection to instance "orcl" on
database "orcl"Connecting to instance "orcl"...Connected as SYSDBA.New primary database "orcl" is opening...Operation requires start up of instance "orcl" on database
"orcl_stby"Starting instance "orcl"...ORACLE instance started.Database mounted.Switchover succeeded, new primary is "orcl"DGMGRL>
Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery has enhanced DR Plan management to automatically add and remove DR Plan Steps in existing DR Plans whenever DR Protection Groups member resources are changed. Full Stack DR now automatically modifies all DR plans in place, based on the members you add or remove from protection groups, preserving any custom steps you’ve added to plans.
Figure 1: Enhanced plan management requires approving modifications after updating members of protection groups.
As your business systems and application stack evolve, your disaster recovery plans need to remain in lockstep. With this new feature, Full Stack DR makes it easy to manage these ongoing changes.
Maintaining the integrity of your recovery plans is job number one for disaster recovery administrators, and changes to member resources in protection groups have a profound impact on recovery steps in DR Plans. So, we’ve introduced the following simple workflow to help ensure plan integrity whenever protection groups change:
Refresh: Refreshing a DR Plan makes it easy to see what has changed by tagging steps that were added or removed.
Verify: Verifying a DR Plan commits the changes and activates the plan.
Let’s explore how easy using this new capability is. Adding, removing, or changing member resources in either the primary or standby protection group triggers the plan refresh workflow.
Updating member resources begins the process
Nothing changes about the way you add a member resource. You still choose the resource type and provide the appropriate properties needed to inform Full Stack DR what you need done with the object during a recovery.
Imagine that you want to add two more moving Compute instances to the DR Protection Group in the primary region, which currently contains two virtual machines (VMs) and a single volume group, as shown in figure 2.
Figure 2: The current members of the DR protection group.
After adding the two Compute instances, the protection group looks like Figure 3. It looks exactly like it has always looked after adding or removing member resources – nothing is different here.
Figure 3: Two more Compute instances have been added as members of the protection group.
Exploring the new workflow
Now you can begin to see the changes introduced with the enhanced plan management scheme. The state of all plans in the standby protection group changes to Needs attention (Needs refresh), while the plans in the primary protection group change to Inactive (Needs refresh).
Figure 4: The state of all plans changes to “Needs attention” after updating members of protection groups.
None of the plans can run in this state, so your ability to recover is completely offline until the plan refresh workflow is completed in the standby protection group. You must select each DR Plan and then select the Refresh button, as shown in Figure 5. This selection forces Full Stack DR to inspect the members in both the primary and standby regions and update the plan in the standby protection group.
Figure 5: A Refresh action button appears at the top of all plans in a “Needs attention” state.
The refresh operation tags any plan steps that have been added or removed so you can see all the changes that will be made before the plan is updated permanently in the next step.
Figure 6: Refreshed plans show all plan groups and steps that were changed, added, or removed.
To accept and make changes permanent, select Verify.
Figure 7: A Verify action button appears at the top of all DR Plans that have been refreshed.
The verify operation commits the changes, updates the plan, and removes the tags so everything appears as normal.
Figure 8: Steps have been added after the verify operation is completed.
You must refresh all existing DR Plans contained in the standby protrection group. The resource list page for plans in the Oracle Cloud Console shows the state of all the plans, which can help you track your progress.
Figure 9: Use the plans resource list in the Oracle Cloud Console to track your progress.
When all the plans in the standby protection group are active, you’re ready to go. You still must refresh the DR Plans in the peer region, but you can recover from outages in the primary OCI region at this point in the process. Plans always run from the standby protection group.
Figure 10: Ensure that all DR Plans have been refreshed and verified in the standby region.
Refreshing plans in the primary protection group
The DR Plans in the primary protection group are still in an Inactive (Needs refresh) state and also need refreshing. However, you can’t modify recovery plans contained in protection groups with the primary role, including refreshing, and verifying. So, you must perform a switchover so that you can refresh the plans in peer region.
Figure 11: Plans must be refreshed in primary DR Protection Group after switchover.
Conclusion
Keeping up with change can be complex, but Full Stack DR has made the job of managing change just a little simpler with this new enhancement. The new DR Plan refresh feature automatically rebuilds plans, while protecting the user-defined steps that you have taken so much time to perfect.
