Static Oracle OpenLogReplicator mount options

Mount Options

To make Oracle OpenLogReplicator work, it is necessary to provide access to the Oracle database redo logs files. Specifically we need to provide access to the Oracle oradata folder (directory where the physical database files are stored, such redo log files) and the fra folder (fast recovery area folder). The gluesync agent supports three different ways to provide access to these resources:

  • Docker Volume (default)

  • NFS

  • SSHFS

In this page it will be shown how these three mounting solutions can be configured in our agent.

Folders

The location of the oracle folders in the filesystem of the database can be retrieved using the following queries:

The oradata location correspond to the value of the parameter: db_create_file_dest

SQL> SHOW PARAMETER db_create_file_dest;

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest		     string	 /opt/oracle/oradata

while the fra location correspond to the value of the parameter: db_recovery_file_dest

SQL> SHOW PARAMETER db_recovery_file_dest

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest		     string	 /opt/oracle/fra
db_recovery_file_dest_size	     big integer 50G

Docker Volume

This solution is the simplest one to setup since it does not need any additional component or external technologies. With this setup, the oracle database folders can be mounted directly on the gluesync agent container through docker volumes. To attach a volume to a container, use the volumes key within the service definition in the docker-compose.yml file. Specify the volume name followed by a colon and the container path where you want to mount the volume.

Here is an example used to mount the folders in the local directory to the path on the container. In this example the directories ./fra and ./oradata are made available to the container at the location /opt/fra and /opt/oradata respectively.

When using this setup the destination path in the container must be /opt/oradata for the oradata folder and /opt/fra for the fra folder. 
  gluesync-oracle-openlogreplicator-source:
    volumes:
	- ./gs-license.dat:/opt/gluesync/data/gs-license.dat
	- ./logback.xml:/opt/gluesync/data/logback.xml
	- ./security-config.json:/opt/gluesync/data/security-config.json
	- ./gluesync.com.jks:/opt/gluesync/data/gluesync.com.jks
	- ./gluesync-oracle-openlogreplicator-source:/opt/gluesync/data
	- ./gluesync-source-logs:/opt/gluesync/logs
	- ./fra:/opt/fra
	- ./oradata:/opt/oradata

Once the docker-compose file has been set up, the gluesync agent must be configured from the UI with the details that reflect this specific configuration. Here is an example:

Gluesync Openlogreplicator volume configuration

NFS

This solution consists of mounting NFS shares directly in the container and it requires the setup of an external NFS server exporting both the Oracle oradata and the fra folders.

Since the setup of the NFS server may vary on different operative systems and different options can be set, it will not be covered here.

Additionally, since the mount command requires admin privileges, additional permissions must be given to the gluesync-oracle-openlogreplicator container through the docker compose file. Here is an example:

  gluesync-oracle-openlogreplicator-source:
    cap_add:
    - SYS_ADMIN

the option cap_add is used to provide to the container the capability SYS_ADMIN. This capability is required to execute mount commands within the container, in fact the nfs shares within the container are mounted using the mount command with this syntax:

mount -t nfs -o [nfs options] SERVER_IP:ORADATA_EXPORTED_FOLDER /opt/oradata
mount -t nfs -o [nfs options] SERVER_IP:FRA_EXPORTED_FOLDER /opt/fra

Apart from the privileges permission no other change is required in the docker-compose file.

Once this has been done, the actual NFS settings must be passed to the agent through the ui as in the example below:

Gluesync Openlogreplicator nfs configuration

SSHFS

SSHFS can also be used to mount external folders on the container and similarly to NFS additional privileged permissions must be given to the container. The following example shows the permissions required to mount SSHFS shares withint the container.

  gluesync-oracle-openlogreplicator-source:
    cap_add:
    - SYS_ADMIN
    devices:
    - /dev/fuse:/dev/fuse
    volumes:
    - ./commons/oracle19-olr/sshkeys/id_rsa:/opt/gluesync/id_rsa:ro

The device /bin/fuse is required since SSHFS uses FUSE (a kernel module that allows non-privileged users to create and run their own filesystems without modifying kernel code), to communicate with the kernel.

Additionally in the volume section a ssh key must be passed to the container. The key is required to authenticate the user to the server and it must be configured on the server too.

Once this has been done, no further changes are necessary on the docker-compose file, but additional settings must be passed to gluesync through the UI as depicted in the image below:

Gluesync Openlogreplicator sshfs configuration
On the first attempt to mount the folders via SSHFS, it will ask to verify and accept the SSH fingerprint. This can cause a mounting issue and we suggest to add the following option to bypass this check: StrictHostKeyChecking=no.
Since mounting oracle folders directly on the container requires the container to have additional permissions, our suggestion is to mount the oracle folders on the server hosting gluesync and share them with the container through docker volumes. Keep in mind that the correct permissions must be set, the gluesync oracle openlogreplicator agent only needs read access to the directories. When the directories are mounted with sshfs, it may be necessary to add the user_allow_other options in /etc/fuse.conf.
When mounting the oracle folders on the docker container, files and directories permissions must be adjusted so that the gluesync user within the container has read access to those files.