Disclaimer

Saturday, 7 December 2024

Oracle GoldenGate Microservices Architecture

 

From OGG 12.3, a new kind of architecture has been introduced in Oracle GoldenGate known as “Microservices Architecture”. 

In this article, I will be explaining you the various components involved in it and their roles and responsibilities.






Oracle GoldenGate Microservices Architecture (OGG MA)

Oracle GoldenGate Microservices Architecture (OGG MA) enables data replication management through an HTML-based interface, using secure REST API interfaces for seamless operation.

In the Classic Architecture of Oracle GoldenGate, separate tools were required to monitor OGG instances. However, OGG MA consolidates all tools needed to configure, monitor, and administer deployments in a unified interface.


Key Components of Oracle GoldenGate Microservices Architecture

OGG MA introduces five major components, each with its own login console:

  1. Service Manager
  2. Administration Server
  3. Distribution Server
  4. Receiver Server
  5. Performance Metrics Server


Differences Between Classic and Microservices Architectures

  • In the Classic Architecture, data replication involved DataPump and Server Collector processes.
  • In OGG MA, these have been replaced by the Distribution Server and Receiver Server.
  • Extracts and Replicats remain unchanged across both architectures.



Roles and Responsibilities of OGG MA Components

1. Service Manager

  • Acts as a watchdog for other services within OGG MA.
  • Manages one or multiple Oracle GoldenGate deployments on a local host.
  • Maintains inventory and configuration data for deployments.
  • Enables starting/stopping instances and querying deployments from the Service Manager console.


2. Administration Server

  • Supervises, administers, and monitors processes in an OGG deployment, including both active and inactive processes.
  • Centralized control entity for managing replication components, replacing the Manager process in the Classic Architecture.
  • Features a REST API service interface accessible from HTTP/HTTPS clients, enabling process management without logging into the OGG server.
  • Key tasks include:
    • Managing Extract and Replicat processes: create, start, stop, and view status and reports.
    • Managing configuration files, checkpoint tables, supplemental logging, credential stores, and encryption keys.
    • Adding users and assigning roles.


3. Distribution Server

  • Replaces the multiple DataPump processes in Classic Architecture with a single instance service.
  • Distributes one or more trail files to one or more destinations.
  • Offers lightweight filtering without transformations and handles multiple commands and data streams concurrently.


4. Receiver Server

  • Replaces discrete Collector processes with a single instance service.
  • Central control for handling incoming trail files and coordinating with the Distribution Server.
  • Ensures compatibility with classic architecture pumps for remote deployments.

5. Performance Metrics Server

  • Collects and stores deployment performance metrics separately from the administration layer.
  • Available for both Microservices and Classic Architectures (from OGG 12.3 onwards).
  • Tasks include:
    • Querying various metrics (JSON or XML format).
    • Integrating with third-party metrics tools.
    • Viewing error logs, active process status, and system resource utilization.


6. Admin Client

  • A command-line utility similar to the Classic Architecture’s GGSCI.
  • Uses the REST API to perform control and configuration tasks.
  • Can be used to create and manage processes or configure Extracts and Replicats without graphical tools.

Key Components of OGG Microservices:

  • Service Manager: The Service Manager acts as the central point to monitor and manage all other services. It provides a web interface to view and manage deployments, configure processes, and monitor system health.

  • Administration Service: The Administration Service is the primary component responsible for the management of Oracle GoldenGate configurations. You can configure, start, stop, and manage replication tasks here.

  • Receiver Service: This service handles the receipt of trail files from the source system. It is designed to be fault-tolerant and ensures that data is reliably transferred between environments.

  • Distribution Service: This service is responsible for sending trail files (data) from the source to the target in a secure and efficient manner. It supports both push and pull models.
  • Performance Metrics Service: This service collects, processes, and presents performance-related data, allowing administrators to monitor the performance and health of the GoldenGate replication setup.

  • Deployment Service: The Deployment Service manages the actual Oracle GolgenGate processes (Extract, Replicat) and is used to deploy and manage the replication configurations.

Conclusion

Oracle GoldenGate Microservices Architecture provides a modernized approach to data replication management with enhanced functionality and streamlined tools. Its key components simplify configuration, monitoring, and administration, making it a robust solution for replication needs.




Let us see each component in detail :

Service Manager :

Once we complete installation of Oracle Golden Gate Microservice Architecture , we must then create a deployment where we can configure service manager. A single service manager instance can work for multiple deployment.

While configuring deployment using oggca we assign port number to service manager process generally 9001. We can connect service manager using http://localhost[ip]:9001 and then it will ask us for username and password .

With this process you will able to view and manage all deployment and associated servers with your deployment.

Admin Server  :

We can configure extract , replicat , credential store from Administration Server. We can add new extract , replicat from here and we can see if there are any critical events in replication or extract process means it also works like a manager in classic architecture.

Distribution Server :

Distribution Server works like a data pump extract in classic architecture. We can configure each option we can configure in a command line of data pump extract like source extract trail path , target server and path details. We can adjust trail file size etc. And all these things we can do with a GUI . From Distribution Server option we can check from where trail file is being read from and written to. To connect distribution server http://localhost[ip]:9003[port].

Receiver Server : 

In replacement of collector process at target server we have Receiver Server in Microservice Architecture. The task of Receiver Server is to collect trail files from Distribution Server and write out to remote trail files. We can always see overview of this service and can see which trail file it is writing to and which information is written.

and at last ,

Performance Metrics Server :

Oracle Golden Gate came with a new Performance Monitoring service in this architecture . We can monitor real-time performance. We can see much information regarding performance using this option.

Note : We must purchase a license of the Oracle Managment Pack for GoldenGate before you can use the GUI or associated metric APIs.





No comments:

Post a Comment

How to recovery PDB when PDB database is dropped in Oracle

  How to recovery PDB when PDB database is dropped :) [oracle@rac01 ~]$ sqlplus '/as sysdba' SQL*Plus: Release 21.0.0.0.0 - Product...