2 Getting Started with Oracle GoldenGate

A Service Manager acts as a watchdog for other services available with Microservices Architecture.

A Service Manager allows you to manage one or multiple Oracle GoldenGate deployments on a local host.

Service Manager is run as a system service and maintains inventory and configuration information about your deployments and allows you to maintain multiple local deployments. Using the Service Manager, you can start and stop instances, and query deployments and the other services.

The Administration Server supervises, administers, manages, and monitors processes operating within an Oracle GoldenGate deployment for both active and inactive processes.

The Administration Server operates as the central control entity for managing the replication components in your Oracle GoldenGate deployments. You use it to create and manage your local Extract and Replicat processes without having to have access to the server where Oracle GoldenGate is installed. The key feature of the Administration Server is the REST API service Interface that can be accessed from any HTTP or HTTPS client, such as the Microservices Architecture service interfaces or other clients like Perl and Python.

In addition, the Admin Client can be used to make REST API calls to communicate directly with the Administration Server, see What is the Admin Client?

The Administration Server is responsible for coordinating and orchestrating Extracts, Replicats, and paths to support greater automation and operational managements. Its operation and behavior is controlled through published query and service interfaces. These interfaces allow clients to issue commands and control instructions to the Administration Server using REST JSON-RPC invocations that support REST API interfaces.

The Administration Server includes an embedded web application that you can use directly with any web browser and does not require any client software installation.

Use the Administration Server to create and manage:

• Extract and Replicat processes

  • Add, alter, and delete

  • Register and unregister

  • Start and stop

  • Review process information, statistics, reports, and status including LAG and checkpoints

  • Retrieve the report and discard files

• Configuration (parameter) files

• Checkpoint, trace, and heartbeat tables

• Supplemental logging for procedural replication, schema, and tables

• Tasks both custom and standard, such as auto-restart and purge trails

• Credential stores

• Encryption keys (MASTERKEY)

• Add users and assign their roles

A Distribution Server is a service that functions as a networked data distribution agent in support of conveying and processing data and commands in a distributed deployment. It is a high performance application that is able to handle multiple commands and data streams from multiple source trail files, concurrently.

Distribution Server replaces the classic multiple source-side data pumps with a single instance service. This server distributes one or more trails to one or more destinations and provides lightweight filtering only (no transformations).

Multiple communication protocols can be used, which provide you the ability to tune network parameters on a per path basis. These protocols include:

• Oracle GoldenGate protocol for communication between the Distribution Server and the Collector in a non services-based (classic) target. It is used for inter-operability.

  Note:

  TCP encryption does not work in a mixed environment of Classic and Microservices architecture. The Distribution Server in Microservices Architecture cannot be configured to use the TCP encryption to communicate with the Server Collector in Classic Architecture running in a deployment. Also, the Receiver Server in Microservices Architecture cannot accept a connection request from a data pump in Classic Architecture configured with RMTHOST ... ENCRYPT parameter running in a deployment.

• WebSockets for HTTPS-based streaming, which relies on SSL security.

• UDT for wide area networks.

• Proxy support for cloud environments:

  • SOCKS5 for any network protocol.

  • HTTP for HTTP-type protocols only, including WebSocket.

• Passive Distribution Server to initiate path creation from a remote site. Paths are source-to-destination replication configurations though are not included in this release.

A Receiver Server is the central control service that handles all incoming trail files. It interoperates with the Distribution Server and provides compatibility with the classic architecture pump for remote classic deployments.

A Receiver Server replaces multiple discrete target-side Collectors with a single instance service.

Use Receiver Server to:

• Monitor path events

• Query the status of incoming paths

• View the statistics of incoming paths

• Diagnose path issues

WebSockets is the default HTTPS initiated full-duplex streaming protocol used by the Receiver Server. It enables you to fully secure your data using SSL security. The Receiver Server seamlessly traverses through HTTP forward and reverse proxy servers as illustrated in Figure 2-1.

Figure 2-1 Receiver Server Communication

Additionally, the Receiver Server supports the following protocols:

• UDT—UDP-based protocol for wide area networks. For more information, see http://udt.sourceforge.net/.

• Classic Oracle GoldenGate protocol—For classic deployments so that the Distribution Server communicates with the Collector and the Data Pump communicates with the Receiver Server.

The Performance Metrics Server uses the metrics service to collect and store instance deployment performance results. This metrics collection and repository is separate from the administration layer information collection.

You can monitor performance metrics using other embedded web applications and use the data to tune your deployments for maximum performance. All Oracle GoldenGate processes send metrics to the Performance Metrics Server. You can use the Performance Metrics Server in both Microservices Architecture and Classic Architecture.

Use the Performance Metrics Server to:

• Query for various metrics and receive responses in the services JSON format or the classic XML format

• Integrate third party metrics tools

• View error logs

• View active process status

• Monitor system resource utilization

The Admin Client is a command line utility (similar to the classic GGSCI utility).You can use it to issue the complete range of commands that configure, control, and monitor Oracle GoldenGate.

For more information on environment variables, see Setting Environment Variables.

The way that you use the Admin Client while similar is different in some ways in support of the MA design:

The Admin Client was designed with GGSCI as the basis. The following table describes the new, deleted, and deprecated commands in the Admin Client:

CONNECT
DISCONNECT
[START | STATUS | STOP] SERVICE
[ADD | ALTER | DELETE | INFO | 
[KILL START | STATS | STOP] 
[EDIT | VIEW] GLOBALS 
CD

* MGR 
* JAGENT 
* CREATE DATASTORE 
SUBDIRS 
FC 
DUMPDDL
INFO MARKER 

ADD CREDENTIALSTORE
[CREATE | OPEN] WALLET

The Microservices Architecture is designed with a simplified installation and deployment directory structure.

This directory structure is based on the Linux Foundation Filesystem Hierarchy Standard. Additional flexibility has been added to allow parts of the deployment subdirectories to be placed at other locations in the file system or on other devices, including shared network devices. The design is comprised of a read only home directory where you install Oracle GoldenGate and create a custom deployment specific directories as in the following:

The following table describes the key MA directories and the variables that are used when referring to those directories in an Oracle GoldenGate installation. When you see these variables in an example or procedure, replace the variable with the full path to the corresponding directory path in your enterprise topology.

You can change the default location of all of these to customize where you want to store these files.

In a configuration where the OGG_VAR_HOME is a local directory and the OGG_HOME is a shared read-only remote directory, many deployments with local OGG_VAR_HOME can share one read-only shared OGG_HOME.

This directory design facilitates a simple manual upgrade. To upgrade, you stop the services and then set the OGG_HOME in the web interface (or via a REST command) and then restart the processes. On the restart, Oracle GoldenGate picks up the updated environment variables. You simply switch a deployment to use a new Oracle GoldenGate release by changing the OGG_HOME directory path in your Service Manager to a new Oracle GoldenGate home directory, which completes the upgrade. You then must restart the MA servers, Extract processes, and Replicat processes.

Microservices Architecture is based on the REST API. After installing the Microservices Architecture, it is accessible through an HTML5 interface, REST APIs, and the command line.

This topic describes the roadmap for implementing Microservices Architecture components and clients.