Manage peer 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:

Create a dynamic group that allows GoldenGate deployments to access resources in your tenancy:
```
name: <dynamic-group-name>
Matching rule: ALL {resource.type = 'goldengatedeployment', resource.compartment.id = '<location>'}
```
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.
- 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.

Add policies that allow GoldenGate deployments to use OCI Secrets replication and to use/manage OCI Secrets resources:

Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to use secret-replication in tenancy
Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to manage secrets in tenancy
Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to use vaults in tenancy
Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to use keys in tenancy
Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to use tag-namespaces in tenancy

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.

To add a peer deployment to a primary deployment:

On the primary deployment's Details page, select Disaster recovery.
On the Disaster recovery page, click Add peer.
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.
Click Add.

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

Switch to a peer deployment

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

Switchover from a primary to a peer deployment is a manual process. 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:

On the deployment's Details page, select Disaster recovery.
In the Peer deployment list on the Disaster recovery page, from the Actions menu of the peer you want to switch to, select Switchover.
In the Switchover dialog window, confirm that you want to switch to this peer, and then click Switch.
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.

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:

On the primary deployment's Details page, select Disaster recovery.
In the Peer deployment list, from the Actions menu of the peer you want to delete, select Delete.
In the Delete peer dialog window, confirm that you want to delete this peer, and then click Delete.

The state of the peer deployment changes to Deleting.