Manage peer deployments

Use peer deployments to implement your OCI GoldenGate disaster recovery plan.

Note: This article applies only to Data replication deployments.

About peer deployments

A peer deployment is a resource you create as a standby to your primary deployment in the event of a disaster or service disruption. It includes all the same primary deployment metadata, such as Trail and parameter files, Block volume, and File storage service replicas. A peer deployment can be local or remote. A local peer resides in the same region as the primary deployment, but in a different Availability Domain (AD) or Fault Domain (FD). A remote peer resides in a different region.

A primary deployment can have only one local or cross-region deployment peer. Peer deployments let you switch from the primary to the standby deployment when needed. When you perform a switchover to a peer deployment, the peer deployment you switch to becomes the primary.

Note: Peer deployments are billed at the same rate as primary deployments. Learn more about OCPU management and billing.

Stopping a primary deployment doesn’t stop the standby deployment, which continues to be billed. You must delete the standby deployments to prevent being billed.

Also note that you can’t change the size of the standby deployment, as it must remain the same size as the primary.

Limitations

• When creating peer deployments, the region list shows the available remote regions in which you can create a cross-region standby. When you add a standby database, the list of available regions only shows a remote region if your tenancy is subscribed to the remote region (you must be subscribed to the paired remote region).

• For cross-region disaster recovery, you must reconfigure Distribution Paths after switchover and modify the target host. You can do this in two ways:

  • (For GoldenGate version 23.10+ builds) In the OCI GoldenGate deployment console, select Distribution Service. View the Path Information of the Distribution Path or Target-Initiated Path, and then edit the Target URI.

  • Use a REST API call to perform the update:

    curl -u <username>:<password> -X PATCH https://<deployment-host>:443/services/v2/sources/<distribution-path-name> -d '{
       "target": {
       "uri": "wss://<new-target-deployment-host>:443/services/v2/targets?trail=<trail-name>"
       }
    }' \| jq .

  Note: If IAM is used for authentication, you must also create a new GoldenGate connection and assign it to the source deployment.

• Deployment truststore certificates are not copied to the cross-region standby peer, and two deployments cannot have the same FQDN. After standby is created, you must update the standby with SSL certs/key and update the FQDN for the new deployment inline with the supported domain name in the certs. Older certs self signed generated for a given region might not be valid for the standby region, so you may have to regenerate them and upload to the standby deployment.

Add a peer deployment

Before you begin

• Ensure that you have the minimum required policies added, specifically policies that allow GoldenGate deployments to use OCI Secrets replication and to use/manage OCI Secrets resources.

• Secrets aren't replicated until cross-region replication is enabled at the Secrets level. Ensure that you select the same region as the deployment's standby peer. Learn about configure cross-region secret replication. Ensure that you review “Permissions needed by resource principals to allow cross region secret replication” in the Required IAM Policy section.

  • If assigned connections don't use secrets, you'll encounter the following error:

    Standby peer cannot be created as following connections does not use secret id <OCID>

  • You must edit the connection to use secrets, or replace it with one that does use secrets.

• Configure Active Data Guard or Data Guard at the database level before you create the connection in OCI GoldenGate to ensure the connection string contains both the primary and standby information. If configured after creating the connection, ensure that you refresh the connection from the Actions menu on the connection's details page.

Add a peer deployment to a primary deployment:

1. On the primary deployment's Details page, select Disaster recovery.

2. On the Disaster recovery page, select Add peer.

3. In the Add peer deployment panel:

   1. Select the region in which to create the peer deployment.

      Note: The region list shows only the available remote regions in which you can create a cross-region standby.

   2. For Automatically select the best availability domain placement:

      • Select this option for the service to select the Availability domain and Fault domain on your behalf.

      • Deselect this option to select the Availability domain and Fault domain yourself.

4. Select Add.

The peer deployment appears in the list on the Disaster recovery page, where you can monitor its state until be becomes Active.

Note: Assigned connections with dedicated endpoints are created as shared endpoints in the standby region so that they use the deployment’s subnet and private endpoint by default. If needed, you can edit the connections in the standby region to use dedicated endpoints by manually specifying the subnet.

Switchover to a peer deployment

Learn to perform a switchover from a primary to a standby peer deployment.

Switchover from a primary to a standby peer deployment is a manual process. Switchover assumes the primary peer is still available and performs one last sync before starting the standby peer to ensure that all the metadata and data from the primary is present on the standby peer. Ensure that you subscribe to the necessary OCI GoldenGate Events to be kept informed of relevant deployment activities.

You can perform switchover from the primary deployment’s details page, or the cross-region standby deployment’s details page. To switch to a peer deployment:

1. On the deployment's Details page, select Disaster recovery.

2. In the Peer deployment list on the Disaster recovery page, from the Actions menu of the peer you want to switch to, select Switchover.

3. In the Switchover dialog window, confirm that you want to switch to this peer, and then select Switch.

4. The deployment status changes to Updating while the switchover is in progress.

When the switchover completes, the peer is now the primary and the primary becomes the peer.

Note: If you find that the standby database is behind the primary, refer to Extract Configuration on the Primary Cluster in Task 10: Configure Oracle GoldenGate Processes for parameters to handle database switchover operations.

Failover to a peer deployment

Learn to perform a failover from a primary to a standby peer deployment.

Failover uses the last successful sync point to start the standby peer and doesn’t try to connect to the primary. It’s possible that processes created after the last sync are not present on the standby peer.

You can perform switchover from the primary deployment’s details page, or the cross-region standby deployment’s details page. To switch to a peer deployment:

1. On the deployment's Details page, select Disaster recovery.

2. In the Peer deployment list on the Disaster recovery page, from the Actions menu of the peer you want to switch to, select Failover.

3. In the Failover dialog window, confirm that you want to switch to this peer, and then select Failover.

4. The deployment status changes to Updating while the failover is in progress.

When the failover completes, the peer is now the primary and the primary becomes the peer.

Note: If you find that the standby database is behind the primary, refer to Extract Configuration on the Primary Cluster in Task 10: Configure Oracle GoldenGate Processes for parameters to handle database switchover operations.

View peer deployment details

View peer deployment details in the Disaster Recovery tab of a primary deployment’s details page.

Peer deployment information displayed on this page includes:

• Role (Primary or Standby)
• State
• Region
• Availability Domain
• Fault Domain
• Precheck status, and when it was last run
• Role change details

Depending on whether the peer deployment is local or remote, you can perform the following actions from the Actions menu:

• Switchover
• Failover
• Launch precheck (remote)
• View precheck results (remote)
• Delete
• Copy OCID

Run a peer deployment precheck

You should run peer deployment prechecks regularly to ensure successful failover or manual switchover. The peer deployment precheck ensures that resources using password secrets are replicated to remote peers prior to switchover. Precheck includes checks for:

• Password secrets exists
• Secrets are replicated to the standby region
• Password secret exists in the standby region but doesn’t match the primary region after recent updates
• All assigned connections are valid and multiple hosts exist
• Assigned connections exist but must be updated because of recent changes

If precheck fails for any reason, ensure that you perform the necessary actions and then run the precheck again.

Delete a peer deployment

Delete a peer deployment when it’s no longer needed to stop recurring additional charges for unused resources.

To delete a peer deployment:

1. On the primary deployment's Details page, select Disaster recovery.

2. In the Peer deployment list, from the Actions menu of the peer you want to delete, select Delete.

3. In the Delete peer dialog window, confirm that you want to delete this peer, and then select Delete.

The state of the peer deployment changes to Deleting.