JavaScript must be enabled to correctly display this content
Replicate data between cloud databases in different regions with VCN peering
Learn to set up and configure Oracle Cloud Infrastructure GoldenGate and Virtual Cloud
Network (VCN) peering to replicate data between two Autonomous Databases located in
two different regions.
Oracle Cloud Infrastructure GoldenGate enables you to replicate data in supported OCI
databases located in different regions with private endpoints. This example demonstrates how
to connect OCI GoldenGate in Phoenix (Region A) to an
Autonomous Transaction Processing (ATP) instance in Frankfurt (Region B) with a private
endpoint.
In Region A, create a VCN (VCN A) with
two regional subnets:
Public (10.0.0.0/24)
Private (10.0.1.0/24)
On the VCN A Details page, under Resources, click
Dynamic Routing Gateway Attachments, and then
click Create DRG Attachment.
In the Create DRG Attachment panel, select the DRG you created, and
then click Create DRG Attachment.
In the DRG Attachments list, click the DRG name in the Dynamic Routing
Gateway column. You're brought to the DRG Details page.
On the DRG Details page, under Resources, click
Remote Peering Connection Attachments, and
then click Create Remote Peering
Connection.
In the Create Remote Peering Connection panel, enter a name, leave the
default settings as is, and then click Create Remote Peering
Connection. An RPC attachment is automatically added to
the DRG and its peering status set to New (not peered).
In the Remote Peering Connections Attachments list, under
Remote Peering Connection, click the RPC
name.
On the RPC Details page, for OCID, click
Copy.
Note:
You can temporarily
paste the OCID to a text editor for later use.
Repeat the previous step in Region B to create a VCN (VCN B) with
two regional subnets and DRG:
Public (192.168.0.0/24)
Private (192.168.1.0/24)
On Region B's RPC Details page, click Establish
Connection, select Region A's RPC, and then paste Region A's RPC
OCID. The Peer Status is then set to Peered.
On VCN A's Details page, under Resources, click Route
Tables, and then click route table for private
subnet-<VCN Name>.
Click Add Route Rules.
In the Add Route Rules panel, complete the following fields, and then click
Add Route Rules:
Target Type: Dynamic Routing Gateway
Destination CIDR Block: 192.168.1.0/24
On VCN B's Details page, under Resources, click Security
Lists, and then click security list for private
subnet-<VCN Name>.
Click Add Ingress Rules.
In the Add Ingress Rules dialog, complete the following fields and then click
Add Ingress Rules:
Source Type: CIDR
Source CIDR: 10.0.1.0/24
IP Protocol: TCP
Source Port Range: All
Destination Port Range: 1522
Note:
This is the default
port to access Oracle Autonomous Database (ADB) instances.
On VCN B's Details page, under Resources, click Route
Tables, and then click route table for private
subnet-<VCN Name>.
Click Add Route Rules.
In the Add Route Rules panel, complete the following fields and then click
Add Route Rules:
Target Type: Dynamic Routing Gateway
Destination CIDR: 10.0.1.0/24
Task 2: Create a
deployment
Ensure that you use VCN A in Region A, which was peered with VCN B in
Region B.
To see which regions OCI GoldenGate is available in, see
Cloud Data
Regions.
Repeat step 1 to create a Listening and a Forwarding endpoint in VCN B.
Manage Rules for VCN A:
Go back to VCN A, click on DNS Resolver.
Under Resources, click Rules and then click Manage
rules:
In the Manage rules panel, for Rule
condition, select Domains from the dropdown.
For Domains, enter the DNS Domain Name for
VCN A.
You can also add your ADB domain name if
you're planning to connect to it. For example, if your
region is Phoenix, then your ADB domain name would be:
adb.us-phoenix-1.oraclecloud.com
For Source endpoint, select a Listening
endpoint for VCN B from the dropdown.
For Destination IP address, enter your
destination IP address.
Click Save changes.
Note:
See Resolver
Rules for more information about creating a
resolver rule.
You select 'Dedicated endpoint' for Traffic
routing method.
Ensure that the domain used by
the FQDN provided in the connection string or
wallet is being correctly forwarded to the
appropriate DNS Resolver using its Rules. See
Resolver
Rules for more information.