18 Configure GoldenGate

Depending on your source or target environment setup, you may have to manually configure GoldenGate in order to perform certain tasks in Data Integration Platform Cloud.

Topics:

• Set up Your GoldenGate Environment

• Configure GoldenGate 11g for Database Cloud Service

• Configure GoldenGate 12c for Database Cloud Service

• Configure GoldenGate Manually to Work between On-Premises and Cloud

• Configure GoldenGate for MySQL Server Targets

• Configure GoldenGate for Big Data Targets

Set up Your GoldenGate Environment

Data Integration Platform provides four variants of GoldenGate bits, Oracle 12c, 11g, Big Data, and MySQL. Each variant has a setup file for the environment setup.

When you select Data Integration Platform Cloud Enterprise Edition, you can set up your GoldenGate environment as follows:

Note:

Make sure to set gghome in the path to access ggsci prompt :

PATH=%12CGGHOME%;%12CGGHOME%\lib12;%12CGGHOME%\crypto;%PATH%

1. For Oracle 12c, enter # source ~/.ggsetup in a Terminal window on your VM.

   GG for Oracle 12c installation: /u01/app/oracle/suite/gghome (Version: 12.3.0.1.2 OGGCORE_12.3.0.1.0_PLATFORMS_171208.0005_FBO)

   GG for Oracle 12c data: /u01/data/domains/jlsData/ggdata

   Agent logs: /u01/data/domains/jlsData/dipcagent001/logs

2. For Oracle 11g, enter # source ~/.ggsetup11g in a Terminal window on your VM.

   GG for Oracle 11g installation: /u01/app/oracle/suite/gghome11g (Version: 12.3.0.1.2 OGGCORE_12.3.0.1.0_PLATFORMS_171208.0005_FBO)

   GG for Oracle 11g data : /u01/data/domains/jlsData/ggdata/ggora11g

3. For BigData, enter # source ~/.ggbigdata in a Terminal window on your VM.

   GG bigData installation: /u01/app/oracle/suite/ggbigdata (Version: 12.3.0.1.0 OGGCORE_OGGADP.12.3.0.1.0GA_PLATFORMS_170828.1608)

   GG bigData data: /u01/data/domains/jlsData/ggdata/ggbigdata/

4. For MySQL, enter # source ~/.ggmysql in a Terminal window on your VM.

   GG mysql installation: /u01/app/oracle/suite/ggmysql (Version: 12.3.0.1.1 OGGCORE_12.3.0.1.0_PLATFORMS_170804.2007)

   GG mysql data: /u01/data/domains/jlsData/ggdata/ggmysqlData/

5. Locate the logs:

   LCM logs: (logs in /tmp/ are lost when rebooted or patched)

   /tmp/dics_install.log /tmp/idcs_patching.log 
   /u01/app/oracle/suite/dics/logs/dics_domain.log
   /u01/app/oracle/suite/dics/logs/dics_rcu.log

   SOLR logs: /u01/data/domains/jlsData/solr/logs/

   GoldenGate logs:

   /u01/data/domains/jlsData/ggdata/ggserr.log
   /u01/data/domains/jlsData/ggdata/ggora11g/ggserr.log
   /u01/data/domains/jlsData/ggdata/ggbigdata/ggserr.log
   /u01/data/domains/jlsData/ggdata/ggmysqlData/ggserr.log

   Patch and rollback logs: /tmp/upgrade.log /tmp/rollback.log

Configure GoldenGate 11g for Database Cloud Service

Once the basic connectivity is established by the agent to GoldenGate, the following procedure can be used to configure the agent to work with 11g GoldenGateHome:.

1. Stop the agent if it’s already running: ps -ef | grep mgr.
2. Stop any manager running in the system. This takes care of port conflicts, if there are any.
3. To stop the manager, launch the GGSCI console: # {GGHOME}/ggsci.
4. Stop the manager.
5. Set agentGoldenGateHome=${gghome11g} in the agent.properties file located under /u01/data/domains/jlsData/${agent_instance_home}/conf
6. Start the agent.

Configure GoldenGate 12c for Database Cloud Service

Before you can use an Oracle Database Cloud Service database deployment as a replication target in Oracle GoldenGate Cloud Service, you must configure its database as a valid replication database.

You can configure the database during database deployment creation by selecting Enable Oracle GoldenGate on the Service Details page of the provisioning wizard. If you don’t, you can configure it manually after the database deployment is created by using the dbaascli utility.

To configure the database manually after the database deployment is created:

1. Connect as the oracle user to the database deployment’s compute node.

   For detailed instructions, see Connecting to a Compute Node Through Secure Shell (SSH) in Administering Oracle Database Cloud Service.

2. Confirm that the database is not yet configured as a valid replication database:

   $ dbaascli gg status
   DBAAS CLI version 1.0.0
   Executing command gg status
   
   Golden Gate status: disabled.
   

   If the status is listed as disabled, you need to configure the database; if it is listed as enabled, you do not.

3. Configure the database as a valid replication database by using the dbaascli gg setup command:

   $ dbaascli gg setup
   DBAAS CLI version 1.0.0
   Executing command gg setup
   Enter Golden Gate admin username: admin-username
   Enter Golden Gate admin password: admin-password
   Re-enter Golden Gate admin password: admin-password
   Setting up Golden Gate
   Updating the registry
   Successfully setup GG

   Where:

   • admin-username is the database user name for Oracle GoldenGate Cloud Service access to the database:

     • For Oracle Database 11g, specify ggadmin.

     • For Oracle Database 12c, specify c##ggadmin.

   • admin-password is the password to use for the database user. You can use the administrator password provided when the database deployment was created, or you can use a different password that conforms to password requirements for Oracle Database users.

4. Close your connection to the compute node.

Configure GoldenGate Manually to Work between On-Premises and Cloud

This chapter includes the following sections:

• Configure Extracts and Data Pumps

• Configure Replication

Configure Extracts and Data Pumps

Oracle Data Integration Platform Cloud replication requires you to configure Extract and data pump process on source.

1. To connect to the replication node, use one of the following options:

   • Local trail (ExtTrail) on the local system

   • Remote trail (RmtTrail) on the remote system

   Note:

   Oracle Data Integration Platform Cloud trails support the continuous extraction and replication of database (on-premises or cloud) changes, storing these changes temporarily on cloud. A trail can reside on any platform that Oracle Data Integration Platform Cloud supports. (Oracle, MySQL, and Big Data databases are supported.)

   You can configure one Replication node to process a trail for target databases. After all the data has been consumed, Replicat can then purge the data using the MinKeepDays parameter. As long as Replicat remains current, your temporary storage requirements for trails can be low.

2. Format the Trail:

   •By default, trails are formatted in canonical format, allowing them to be exchanged rapidly and accurately among databases.

   Each trail file contains the following:

   • Record header area: Stored at the beginning of the file and contains information about the trail file itself.

     Trail File Information

     • Compatibility level

     • Character set (globalization function with version 11.2.1 and later)

     • Creation time

     • File sequence number

     • File size

     First and Last Record Information

     • Timestamp

     • Commit Sequence Number (CSN)

     Extract Information

     • Oracle Data Integration Platform Cloud version

     • Group name

     • Host name and Hardware type

     • Operating system type and version

     • DB type, version, and character set

   • Record data area: Contains a header area as well as a data area.

   • Checkpoints: Both Extract and Replicat maintain checkpoints into the trails. Checkpoints provide persistent processing whenever a failure occurs. Each process resumes where the last checkpoint was saved, guaranteeing that no data is lost. One Extract can write to one or many trails. One or many Replicat processes are involved in processing each trail.

   Note:

   Instead of the default canonical format, you can use alternative formats to output data.

   This feature is beneficial if database load utilities or other programs are used that require different input format.

   These alternative formats include:

   • Logical Change Records (LCRs)

   • FormatASCII

   • FormatSQL

   • FormatXML

3. Set Up a View

   Objective	Command
   To view the trail file header:	Logdump 1> fileheader on
   To view the record header with the data:	Logdump 2> ghdr on
   To add column information:	Logdump 3> detail on
   To add hexadecimal and ASCII data values to the column list:	Logdump 4> detail data
   To control how much record data is displayed:	Logdump 5> reclen 280

4. Keep a log of your session

   Objective	Command
   To start and stop the logging of a logdump session, use the Log option:	Logdump> Log to MySession.txt
   When enabled, logging remains in effect for all sessions of Logdump until it’s disabled with the Log Stopcommand:	Logdump> Log Stop

Supported Scenarios

This table describes different scenarios considering that integrated extract and integrated delivery are not supported on any of the non-Oracle databases.

Source	Target	Extract	Replicat
Oracle 11.x	Oracle Database Cloud Service	Integrated Extract is supported	Integrated and Coordinated Delivery supported
Oracle 12.1	Oracle Database Cloud Service	Integrated Extract is supported	Integrated and Coordinated Delivery supported
MySQL	Oracle Database Cloud Service	Only Classic Extract is supported	Integrated and Coordinated Delivery supported

Note:

With Oracle 12.1, when not using multitenancy, you can still use Classic Extract, however, it can’t be used when container/pluggable databases are used.

You can review detailed steps in the tutorial, Replicate On-Premises Data to Cloud with Oracle GoldenGate Cloud Service.

Configure Replication

Oracle Data Integration Platform Cloud replication requires connecting to and configuring database support for the replication node.

Configure a General Replication Process

1. Connect to the node defined in the Manager parameter file mgr.prm located at /u01/app/oracle/gghome/dirprm

2. Avoid using root user to run Data Integration Platform Cloud processes, otherwise some operations can fail to read using 'oracle' user.

In the following table, you can review the parameters and descriptions necessary to configure a replication process.

Parameter	Description
Port:	Establishes the TCP/IP Port Number on Which Manager Listens For Requests
DynamicPortList:	Specifies the ports that Manager can dynamically allocate
Autostart:	Specifies the processes to be restarted after abnormal termination
LagReportHours:	Sets the interval, in hours, at which Manager checks the lag for Extract and Replicat processing. Alternatively, this interval can be set in minutes.
LagInfoMinutes:	Specifies the interval at which Extract and Replicat send an informational message to the event log. Alternatively, this interval can be set in seconds or hours.
LagCriticalMinutes:	Specifies the interval at which Extract and Replicat send a critical message to the event log. Alternatively, this interval can be set in seconds or hours.
PurgeOldExtracts:	Purges the Data Integration Platform Cloud trails that are no longer needed, based on option settings.

Note:

If you copy and paste text into parameter files, then beware of editors that try to turn a double-minus into em—dashes.

Managing Trail Files Use the PurgeOldExtracts parameter in the Manager parameter file to purge trail files when Data Integration Platform Cloud has finished processing them.

Note:

Trail files, if not managed properly, can consume a significant amount of disk space!

Configure Replication process, using the DMZ (Demilitarized Zone) Server

A DMZ server is a public-facing computer host placed on a separate or isolated network segment. The intention of this server is to provide an addition layer of network security between servers in the trusted network and servers in the public network.

Follow the four high-level steps to configuring a replication from a non-cloud database to cloud.

1. Start the SSH Proxy Server on the DMZ Server.

2. Configure and start the Online Change Capture Process (Extract) on the on-premise server.

3. Configure and start the Data pump Extract on the on-premise Server (SOCKS PROXY pointing to DMZ Server).

4. Configure and start the Online Change Delivery Process (Replicat) on the GGCS server.

1. Start the SSH Proxy Tunnel Setup on the DMZ Server

• Start the SSH SOCKS Proxy Server on the DMZ Server

  Command Syntax:

  ssh –i <private_key file> -v –N –f –D <listening IP Address>:<listening IP port><GGCS Oracle User>@<GGCS IP Address>><socksproxy output file>2>&1

  Parameter	Description
  –i	Private Key file.
  -v	Verbose Mode.
  –N	Don’t execute remote command (used for port forwarding).
  –f	Run SSH process in the background.
  –D	Specifies to run as local dynamic application level forwarding; act as a SOCKS proxy server on a specified interface and port.
  2>&1	Redirect Stdout and Stderr to the output filelistening.
  IP Address	DMZ Server IP Address.
  listening IP port	TCP/IP Port Number.

• Verify that the SSH SOCKS Proxy server has started successfully.

  Check the socks proxy output file using the cat Unix command.

  Look for the:

  Local connections to <dmz-server:port> and

  Local forwarding listening on <ip_address> port <port #>.

  This information helps you to make sure you’re pointing to the right DMZ server address and port.

2. Configure and Start the Online Change Capture Process (Extract) on the On-premises Server

On the source server, create the online change capture (Extract) process, using the following commands:

GGCSI> add extract etpcadb, tranlog, begin now  
GGSCI> add exttrail ./dirdat/ea, extract etpcadb, megabytes 100  
GGSCI> start extract etpcadb  
GGSCI> info extract etpcadb detail

3. Configure and Start the Data pump Extract on the On-premise Server

On the source server, create the datapump (Extract) process, using the following commands:

GGCSI> add extract ptpcadb, exttrailsource ./dirdat/ea
GGSCI> add rmttrail ./dirdat/pa, extract ptpcadb, megabytes 100
GGSCI> start extract ptpcadb
GGSCI> info extract ptpcadb detail

4. Configure and Start the Online Change Delivery Process (Replicat) on the Cloud Server.

On the Data Integration Platform Cloud server, create the Change Delivery process (Replicat) using the following commands:

GGCSI> dblogin useridalias dipcuser_alias
GGSCI> add replicat rtpcadb integrated, exttrail ./dirdat/pa
GGSCI> start replicat rtpcadb
GGSCI> info replicat rtpcadb detail

You can review this detailed steps by following the tutorial Replicate On-Premises Data to Cloud with Oracle GoldenGate Cloud Service.

Configure GoldenGate for MySQL Server Targets

This chapter provides instructions for preparing your system for running Oracle GoldenGate. It contains the following sections:

• Ensure Data Availability

• Set Logging Parameters

• Add Host Names

• Set the Session Character Set

• Configure Bi-directional Replication

• Other Oracle GoldenGate Parameters for MySQL

• Prepare Tables for Processing

• Position Extract to a Specific Start Point

• Change the Log-Bin Location

Ensure Data Availability

Retain enough binary log data so that if you stop Extract or there is an unplanned outage, Extract can start again from its checkpoints. Extract must have access to the binary log that contains the start of the oldest uncommitted unit of work, and all binary logs thereafter. The recommended retention period is at least 24 hours worth of transaction data, including both active and archived information. You might need to do some testing to determine the best retention time given your data volume and business requirements.

If data that Extract needs during processing was not retained, either in active or backup logs, one of the following corrective actions might be required:

• Alter Extract to capture from a later point in time for which binary log data is available (and accept possible data loss on the target).

• Resynchronize the source and target tables, and then start the Oracle GoldenGate environment over again.

To determine where the Extract checkpoints are, use the INFO EXTRACT command. For more information, see GGSCI Command Interface in Reference for Oracle GoldenGate.

Set Logging Parameters

To capture from the MySQL transaction logs, the Oracle GoldenGate Extract process must be able to find the index file. index file in turn contains the paths of all binary log files.

Note:

Extract expects that all of the table columns are in the binary log. As a result, only binlog_row_image set as full is supported and this is the default. Other values of binlog_row_image are not supported.

Extract checks the following parameter settings to get this index file path:

1. Extract TRANLOGOPTIONS parameter with the ALTLOGDEST option: If this parameter specifies a location for the log index file, Extract accepts this location over any default that is specified in the MySQL Server configuration file. When ALTLOGDEST is used, the binary log index file must also be stored in the specified directory. This parameter should be used if the MySQL configuration file does not specify the full index file path name, specifies an incorrect location, or if there are multiple installations of MySQL on the same machine

   To specify the index file path with TRANLOGICOPTIONS with ALTLOGDEST, use the following command format on Windows:

   TRANLOGOPTIONS ALTLOGDEST "C:\\Program Files\\MySQL\\logs\\binlog.index"
   

   On Linux, use this format:

   TRANLOGOPTIONS ALTLOGDEST "/mnt/rdbms/mysql/data/logs/binlog.index" 
   

2. The MySQL Server configuration file: The configuration file stores default startup options for the MySQL server and clients. On Windows, the name of the configuration file is my.ini. On other platforms, it is my.cnf. In the absence of TRANLOGOPTIONS with ALTLOGDEST, Extract gets information about the location of the log files from the configuration file; however, even with ALTLOGDEST, these Extract parameters must be set correctly:

   • binlog-ignore-db=oggddl: This prevents DDL logging history table entries in the binlog and is set in the my.cnf or my.ini file.

   • log-bin: This parameter is used to enable binary logging. This parameter also specifies the location of the binary log index file and is a required parameter for Oracle GoldenGate, even if ALTLOGDEST is used. If log-bin is not specified, binary logging will be disabled and Extract returns an error.

   • log-bin-index: This parameter specifies the location of the binary log index. If it is not used, Extract assumes that the index file is in the same location as the log files. If this parameter is used and specifies a different directory from the one that contains the binary logs, the binary logs must not be moved once Extract is started.

   • max_binlog_size: This parameter specifies the size, in bytes, of the binary log file.

     Note:

     The server creates a new binary log file automatically when the size of the current log reaches the max_binlog_size value, unless it must finish recording a transaction before rolling over to a new file.

   • binlog_format: This parameter sets the format of the logs. It must be set to the value of ROW, which directs the database to log DML statements in binary format. Any other log format (MIXED or STATEMENT) causes Extract to abend.

     Note:

     MySQL binary logging does not allow logging to be enabled or disabled for specific tables. It applies globally to all tables in the database.

   To locate the configuration file, Extract checks the MYSQL_HOME environment variable: If MYSQL_HOME is set, Extract uses the configuration file in the specified directory. If MYSQL_HOME is not set, Extract queries the information_schema.global_variables table to determine the MySQL installation directory. If a configuration file exists in that directory, Extract uses it.

Add Host Names

Oracle GoldenGate gets the name of the database it is supposed to connect to from the SOURCEDB parameter. A successful connection depends on the localhost entry being properly configured in the system host file. To avoid issues that arise from improper local host configuration, you can use SOURCEDB in the following format:

SOURCEDB database_name@host_name

Where: database_name is the name of the MySQL instance, and host_name is the name or IP address of the local host. If using an unqualified host name, that name must be properly configured in the DNS database. Otherwise, use the fully qualified host name, for example myhost.company.com.

Set the Session Character Set

The GGSCI, Extract and Replicat processes use a session character set when connecting to the database. For MySQL, the session character set is taken from the SESSIONCHARSET option of SOURCEDB and TARGETDB. Make certain you specify a session character set in one of these ways when you configure Oracle GoldenGate.

Configure Bi-directional Replication

In a bi-directional configuration, there are Extract and Replicat processes on both the source and target systems to support the replication of transactional changes on each system to the other system. To support this configuration, each Extract must be able to filter the transactions applied by the local Replicat, so that they are not recaptured and sent back to their source in a continuous loop. Additionally, AUTO_INCREMENT columns must be set so that there is no conflict between the values on each system.

1. Configure Oracle GoldenGate for high availability or active-active replication according to the instructions in the Overview of Replicat in Administering Oracle GoldenGate.
2. To filter out Replicat operations in a bi-directional configuration so that the applied operations are not captured and looped back to the source again, take the following steps on each MySQL database:

   • Configure each Replicat process to use a checkpoint table. Replicat writes a checkpoint to this table at the end of each transaction. You can use one global checkpoint table or one per Replicat process See Overview of Replicat in Administering Oracle GoldenGate.

   • Specify the name of the checkpoint table with the FILTERTABLE option of the TRANLOGOPTIONS parameter in the Extract parameter file. The Extract process will ignore transactions that end with an operation to the specified table, which should only be those of Replicat.

     Note:

     Although optional for other supported databases as a means of enhancing recovery, the use of a checkpoint table is required for MySQL when using bi-directional replication (and likewise, will enhance recovery).

3. Edit the MySQL server configuration file to set the auto_increment_increment and auto_increment_offset parameters to avoid discrepancies that could be caused by the bi-directional operations. The following illustrates these parameters, assuming two servers: ServerA and ServerB.

   ServerA:

   auto-increment-increment = 2
   auto-increment-offset = 1
   

   ServerB:

   auto-increment-increment = 2
   auto-increment-offset = 2

Other Oracle GoldenGate Parameters for MySQL

The following parameters may be of use in MySQL installations, and might be required if non-default settings are used for the MySQL database. Other Oracle GoldenGate parameters will be required in addition to these, depending on your intended business use and configuration.

Table 18-1 Other Parameters for Oracle GoldenGate for MySQL

Parameter	Description
DBOPTIONS with CONNECTIONPORT port_number	Required to specify to the VAM the TCP/IP connection port number of the MySQL instance to which an Oracle GoldenGate process must connect if MySQL is not running on the default of 3306. DBOPTIONS CONNECTIONPORT 3307
DBOPTIONS with HOST host_id	Specifies the DNS name or IP address of the system hosting MySQL to which Replicat must connect.
DBOPTIONS with ALLOWLOBDATATRUNCATE	Prevents Replicat from abending when replicated LOB data is too large for a target MySQL CHAR, VARCHAR, BINARY or VARBINARY column.
SOURCEDB with USERID and PASSWORD	Specifies database connection information consisting of the database, user name and password to use by an Oracle GoldenGate process that connects to a MySQL database. If MySQL is not running on the default port of 3306, you must specify a complete connection string that includes the port number: SOURCEDB dbname@hostname:port, USERID user, PASSWORD password.Example: SOURCEDB mydb@mymachine:3307, USERID myuser, PASSWORD mypassword If you are not running the MySQL database on port 3306, you must also specify the connection port of the MySQL database in the DBLOGIN command when issuing commands that affect the database through GGSCI: DBLOGIN SOURCEDB dbname@hostname:port, USERID user, PASSWORD password For example: GGSCI> DBLOGIN SOURCEDB mydb@mymachine:3307, USERID myuser, PASSWORD mypassword
SQLEXEC	To enable Replicat to bypass the MySQL connection timeout, configure the following command in a SQLEXEC statement in the Replicat parameter file. SQLEXEC "select CURRENT_TIME();" EVERY n MINUTES Where: n is the maximum interval after which you want Replicat to reconnect. The recommended connection timeout 31536000 seconds (365 days).

See Oracle GoldenGate Parameters in Reference for Oracle GoldenGate.

See Introduction to Oracle GoldenGate in Administering Oracle GoldenGate.

Prepare Tables for Processing

This section describes how to prepare the tables for processing. Table preparation requires these tasks:

Position Extract to a Specific Start Point

You can position the ADD EXTRACT and ALTER EXTRACT commands to a specific start point in the transaction logs with the following command.

{ADD | ALTER EXTRACT} group, VAM, LOGNUM log_num, LOGPOS log_pos

• group is the name of the Oracle GoldenGate Extract group for which the start position is required.

• log_num is the log file number. For example, if the required log file name is test.000034, this value is 34. Extract will search for this log file.

• log_pos is an event offset value within the log file that identifies a specific transaction record. Event offset values are stored in the header section of a log record. To position at the beginning of a binlog file, set the log_pos as 4. The log_pos 0 or 1 are not valid offsets to start reading and processing.

In MySQL logs, an event offset value can be unique only within a given binary file. The combination of the position value and a log number will uniquely identify a transaction record and cannot exceed a length of 37. Transactional records available after this position within the specified log will be captured by Extract. In addition, you can position an Extract using a timestamp.

Change the Log-Bin Location

Modifying the binary log location by using the log-bin variable in the MySQL configuration file might result in two different path entries inside the index file, which could result in errors. To avoid any potential errors, change the log-bin location by doing the following:

1. Stop any new DML operations.
2. Let the extract finish processing all of the existing binary logs. You can verify this by noting when the checkpoint position reaches the offset of the last log.
3. After Extract finishes processing the data, stop the Extract group and, if necessary, back up the binary logs.
4. Stop the MySQL database.
5. Modify the log-bin path for the new location.
6. Start the MySQL database.
7. To clean the old log name entries from index file, use flush master or reset master (based on your MySQL version).
8. Start Extract.

Configure GoldenGate for Big Data Targets

This procedure helps you to configure and run Oracle GoldenGate for Big Data to extend the capabilities of Oracle GoldenGate instances. Oracle GoldenGate for Big Data supports specific Big Data handler configurations. It details how each of the Oracle GoldenGate for Big Data Handlers are compatible with the various data collections including distributions, database releases, and drivers.

See the following table for more information.

Topic	Description
Introduction to GoldenGate for Big Data	This chapter provides an introduction to Oracle GoldenGate for Big Data concepts and features. It includes how to verify and set up the environment, use it with Replicat, logging data, and other configuration details.
Using the Cassandra Handler	This chapter explains the Cassandra Handler and includes examples so that you can understand this functionality.
Using the Elasticsearch Handler	This chapter explains the Elasticsearch Handler and includes examples so that you can understand this functionality.
Using the Flume Handler	This chapter explains the Flume Handler and includes examples so that you can understand this functionality.
Using the HBase Handler	The HBase Handler allows you to populate HBase tables from existing Oracle GoldenGate supported sources.
Using the HDFS Handler	This chapter explains the HDFS Handler, which is designed to stream change capture data into the Hadoop Distributed File System (HDFS).
Using the Java Database Connectivity Handler	The Generic Java Database Connectivity (JDBC) is a handler that lets you replicate source transactional data to a target system or database. This chapter explains the Java Database Connectivity (JDBC) Handler and includes examples so that you can understand this functionality.
Using the Kafka Handler	This chapter explains the Kafka Handler and includes examples so that you can understand this functionality.
Using the Kafka Connect Handler	This chapter explains the Kafka Connect Handler and includes examples so that you can understand this functionality.
Using the Kinesis Streams Handler	This chapter explains the Kinesis Streams Handler and includes examples so that you can understand this functionality.
Using the MongoDB Handler	This chapter explains the MongoDB Handler and includes examples so that you can understand this functionality.
Using the Metadata Provider	This chapter explains the Metadata Provider functionality, different types of Metadata Providers, and examples that can be used to understand the functionality.
Using the Pluggable Formatters	Formatters provide the functionality to convert operations from the Oracle GoldenGate trail file info formatted messages that can then be sent to Big Data targets by one of the Oracle GoldenGate for Big Data Handlers.
Cassandra Handler Client Dependencies	This appendix lists the Cassandra client dependencies for Apache Cassandra.
Elasticsearch Handler Client Dependencies	This appendix lists the Elasticsearch transport client dependencies.
Flume Handler Client Dependencies	This appendix lists the Flume client dependencies for Apache Flume.
HBase Handler Client Dependencies	This appendix lists the HBase client dependencies for Apache HBase. The hbase-client-x.x.x.jar is not distributed with Apache HBase nor is it mandatory to be in the classpath. The hbase-client-x.x.x.jar is an empty maven project with the purpose of aggregating all of the HBase client dependencies.
HDFS Handler Client Dependencies	This appendix lists the HDFS client dependencies for Apache Hadoop. The hadoop-client-x.x.x.jar is not distributed with Apache Hadoop nor is it mandatory to be in the classpath. The hadoop-client-x.x.x.jar is an empty maven project with the purpose of aggregating all of the Hadoop client dependencies.
Kafka Handler Client Dependencies	This appendix lists the Kafka client dependencies for Apache Kafka.
Kafka Connect Handler Client Dependencies	This appendix lists the Kafka Connect client dependencies for Apache Kafka.
MongoDB Handler Client Dependencies	Oracle GoldenGate recommends that you use the 3.2.2 MongoDB Java Driver integration with MongoDB using mongo-java-driver-3.2.2.jar. You can download this driver from: http://mongodb.github.io/mongo-java-driver/
Understanding the Java Adapter and Oracle GoldenGate for Big Data	The Oracle GoldenGate Java Adapter is the overall framework. It allows you to implement custom code to handle Oracle GoldenGate trail records, according to their specific requirements. It comes built-in with Oracle GoldenGate File Writer module that can be used for flat file integration purposes.