A MySQL database server uses binary logs and relay logs that are used to manage changes between Gateway database instances in a Gateway cluster. The binary logs contain the queries and instructions originating from a master database that are awaiting transmission to its slave database.
The relay logs contain the queries and instructions originating from a master database that are awaiting execution on the slave database. If replication fails or is delayed for a period then one or both types of logs may start to accrue on the file system of the Gateway appliance. Unchecked growth of these files can result in over-utilization of the storage allocated to a Gateway appliance. This allows for excess disk space consumption which could cause a MySQL service outage and thus a Gateway application outage too.
The binary log management script will periodically verify the current running state of replication on the local Gateway database. If replication is functional and not delayed extensively then it will remove old binary and relay log files from the file system. This ensures that no data is lost (by verifying the state of replication) and that no excessive storage utilization occurs.
The audit record maintenance script should be stored in a central location. Traditionally, the script is located in /usr/local/bin/ or /opt/SecureSpan/Appliance/bin/. The invocation of this script is typically handled by the Gateway appliance's default scheduled task handler--crond. It is expected that this script will be configured to run via crontab. If you need assistance with configuring the Gateway appliance to run this script via cron then please open a new Support request.
Note: The values for "SLAVE" and "ROOTDBPWD" should be set to the hostname of the other Gateway database node and the password for the privileged MySQL user.
It may be necessary or preferable to configure the Gateway to transmit emails or other types of messages when the replication state is not in a good condition. If this process is required or desired then do the following:
This script will send an email notification if it is unable to manage the binary log files and if email has been configured for use. This serves as a helpful notification for a replication failure as this process should only fail if replication is not running or is not configured. The following procedure is optional and can be run in any environment where this script is being deployed for the first time.
Both the manage_binlogs.sh script and replication_email_service.xml policy example are included in the ZIP file attached to this article.
By using the manage_binlogs.sh script allows to resolve disk space issues without outage or interruptions.