Topics:
Parent topic: Installing the Oracle GoldenGate Classic Architecture
Assign free disk space according to the following instructions.
To determine the size of the Oracle GoldenGate download file, view the Size column before downloading your selected build from Oracle Software Delivery Cloud. The value shown is the size of the files in compressed form. The size of the expanded Oracle GoldenGate installation directory will be significantly larger on disk.
To install Oracle GoldenGate into a cluster environment, install the Oracle GoldenGate binaries and files as the Oracle user on a shared file system that is available to all cluster nodes, see Setting up for MySQL Cluster H.
Allocate an additional 1 GB of disk space on any system that hosts Oracle GoldenGate trails, which are files that contain the working data. You may need more or less than this amount, because the space that is consumed by the trails depends on the volume of data that will be processed. See the guidelines for sizing trails in Administering Oracle GoldenGate.
Parent topic: Installing with MySQL Databases
By default, Oracle GoldenGate maintains data that it swaps to disk in the dirtmp sub-directory of the Oracle GoldenGate installation directory. The cache manager assumes that all of the free space on the file system is available. This directory can fill up quickly if there is a large transaction volume with large transaction sizes. To prevent I/O contention and possible disk-related Extract failures, dedicate a disk to this directory. You can assign a name and size to this directory with the CACHEDIRECTORY option of the CACHEMGR parameter. The CACHESIZE option of CACHEMGR sets a soft limit for the amount of virtual memory (cache size) that is available for caching transaction data. See Reference for Oracle GoldenGate for the default values of these options and detailed explanations, in case system adjustments need to be made.
Parent topic: Disk Requirements for MySQL Database
MySQL provides a facility that allows users to specify different character sets at different levels.
| Level | Example |
|---|---|
|
Database |
create database test charset utf8; |
|
Table |
create table test( id int, name char(100)) charset utf8; |
|
Column |
create table test ( id int, name1 char(100) charset gbk, name2 char(100) charset utf8)); |
Limitations of Support
When you specify the character set of your database as utf8mb4/utf8, the default collation is utf8mb4_unicode_ci/utf8_general_ci. If you specify collation_server=utf8mb4_bin, the database interprets the data as binary. For example, specifying the CHAR column length as four means that the byte length returned is 16 (for utf8mb4) though when you try to insert data more than four bytes the target database warns that the data is too long. This is the limitation of database so Oracle GoldenGate does not support binary collation. To overcome this issue, specify collation_server=utf8mb4_bin when the character set is utf8mb4 and collation_server=utf8_bin for UTF-8.
The following character sets are not supported:
armscii8keybcs2utf16legeostd8Parent topic: Installing with MySQL Databases
Requirements for the database storage engine are as follows:
Oracle GoldenGate supports the InnoDB storage engine for a source MySQL database.
On a target MySQL database, the Oracle GoldenGate Replicat process connects to the database through the MySQL native API.
The NDB cluster engine is supported.
Parent topic: Installing with MySQL Databases
Oracle GoldenGate for MySQL supports MySQL, 5.5, 5.6, and 5.7, as well as Delivery to Amazon Aurora MySQL 5.6 and greater. The DDL feature is supported on MySQL 5.7.10 and later.
Parent topic: Installing with MySQL Databases
Requirements for the database user for Oracle GoldenGate processes are as follows:
Create a database user that is dedicated to Oracle GoldenGate. It can be the same user for all of the Oracle GoldenGate processes that must connect to a database:
Extract (source database)
Replicat (target database)
DEFGEN (source or target database)
To use DDL the MySQL user must have privileges to install the database plugins. Additionally, the user requires insert privileges on the source user.
To preserve the security of your data, and to monitor Oracle GoldenGate processing accurately, do not permit other users, applications, or processes to log on as, or operate as, the Oracle GoldenGate database user.
Keep a record of the database users. They must be specified in the Oracle GoldenGate parameter files with the USERID parameter.
The Oracle GoldenGate user requires read access to the INFORMATION_SCHEMA database.
The Oracle GoldenGate user requires the following user privileges.
Table 9-1 Oracle GoldenGate database user privileges for MySQL
| Privilege | Extract | Replicat |
|---|---|---|
|
|
X |
|
|
|
||
|
|
||
|
or
|
X |
X |
Footnote 1
If using the checkpoint table feature (recommended)
Footnote 2
To execute stored procedures
To capture binary log events, an Administrator must provide the following privileges to the Extract user:
Read and Execute permissions for the directory where the MySQL configuration file (my.cnf) is located
Read permission for the MySQL configuration file (my.cnf)
Read and Execute permissions for the directory where the binary logs are located
Read and Execute permission for the tmp directory
Parent topic: Installing with MySQL Databases
Oracle GoldenGate can be used with the NDB Cluster distributed database system underlying the MySQL Cluster or any cluster-management solution that has the ability to automate failover.
You will need to install at least some Oracle GoldenGate objects on shared storage. Select cluster-aware shared storage that is independent of, but available to, all nodes of the cluster.
The best practice is the install Oracle GoldenGate entirely on shared storage. This allows you to start the Oracle GoldenGate processes from any of the nodes without having to make changes to the parameter files. If the active node fails, the processes can be started quickly on another node, using the processing checkpoints that are preserved in the installation directory.
If you decide to install the Oracle GoldenGate binaries and files on each node, rather than on shared storage, the following must be true:
The Oracle GoldenGate installation must have the same location path on every node
At minimum, install the following directories on the shared storage to support Oracle GoldenGate recovery requirements. You can create symbolic links to them from the installation directory on each node.
dirchk
dirdat
These directories are among those created when you issue CREATE SUBDIRS during installation.
The parameter files in the dirprm directory, if not placed on the shared drive, must be identical on all nodes. To resolve environment settings that must be different from one node to the other, you can set environment settings so they are inherited from the local Manager process or reference a node-specific Oracle GoldenGate macro file. Because this scenario can be difficult to enforce, the inherent concerns can be avoided by storing the parameter files on the shared drive.
See Integrating into a Cluster after you install Oracle GoldenGate.
Parent topic: Installing with MySQL Databases
The following procedures show how you can set up Oracle GoldenGate to work for MySQL cluster.
Parent topic: Installing with MySQL Databases
These instructions apply generically and may not be applicable to your specific cluster system.
You must meet the following requirements when integration Oracle GoldenGate into a cluster:
Register the Oracle GoldenGate Manager process (and only Manager) as a cluster-managed resource as you would any other application. Manager must be the only Oracle GoldenGate process that the cluster-management software starts and stops, because it is the parent process that manages all other processes.
If the cluster uses a virtual IP address, you may need to obtain an available fixed IP address for the Manager process. The VIP must be an available IP address on the public subnet and cannot be determined through DHCP. In the parameter files of the Extract data pumps, specify the VIP of the remote Manager as the input value of the RMTHOST parameter. Other Oracle GoldenGate products that access Manager also should use the VIP.
Make certain that all nodes in the cluster have synchronized system clocks. The clocks must be synchronized with the clock on the system where Extract is executed. Oracle GoldenGate compares the time of the local system to the commit timestamps to make critical decisions. For information about synchronizing system clocks, consult your system administrator.
When you configure Manager, add the AUTOSTART and AUTORESTART parameters so that Manager starts the replication processes automatically. You can, when needed, control Extract, Replicat, and other Oracle GoldenGate processes from within the Oracle GoldenGate user interfaces.
Mount the shared drive on one node only. This prevents processes from being started on another node. Use the same mount point on all nodes.
Configure Oracle GoldenGate as appropriate for your environment.
Parent topic: Setting up for MySQL Cluster
Install MySQL Cluster as described in the MySQL document Installing MySQL Cluster on Linux at:
https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-install-linux.html
Note:
Oracle GoldenGate now supports MySQL Cluster/NDB storage mode only. Therefore, the following setup is needed in the configuration file (for example, my.cnf):
default-storage-engine=ndbcluster
After you create MySQL database and tables, you can check the status to make sure correct engine and data type is used as in this example:
show table status where Name='te';
Parent topic: Setting up for MySQL Cluster
To use Oracle GoldenGate for MySQL Cluster, you need to disable the NDB-LOG-UPDATE-AS-WRITE and NDB-LOG-UPDATED-ONLY parameters inside their respective MySQL database configuration files (my.cnf/my.ini) or by using the mysqld command. Extract must be positioned to a point in time where the disabled options are already in effect; for example:
mysqld --default-file=/rdbms/mysql/myssqlcluster/my_cluster/conf/my.cnf -uroot --datadir=/rdbms/mysql/myssqlcluster/my_cluster/mysqld_data--ndbcluster --ndb-log-update-as-write=0 --ndb-log-updated-only=0 --default-storage-engine=ndbcluster --max_allowed_packet=1G
The --ndb-log-updated-only option for MySQL does the following:
Logs complete rows.
Logs only column data that has been updated; that is, column data whose value has been set, regardless of whether or not the value was actually changed. This is the default behavior. If you need to log full rows, you can do so by setting --ndb-log-updated-only to 0 or OFF.
The --ndb-log-update-as-write option logs changed data as UPDATE operations.
Parent topic: Setting up for MySQL Cluster
Install Oracle GoldenGate, see Installing on all Platforms.
To support the cluster environment, install Oracle GoldenGate on a shared file system that can be accessed by all of the cluster nodes.
Parent topic: Setting up for MySQL Cluster