There are two articles on the existing Support portal that cover this topic:
These are not documented in the documentation as they are not required for all customer installations. The former article should only be used if an existing implementation is auditing excessively and the use of the Internal Audit Sink Policy is not currently in place. It is recommended that customers and administrators consider using alternative storage methodologies if their auditing requirements are strict. The API Gateway is not a storage appliance and is not the best solution for long-term storage of audit data that may be necessary for regulatory or compliance purposes.
The latter item is more broadly applicable but excessive binary log generation is not considered a concern unless audit generation is also high. Binary log files are generated by the MySQL server when queries are replicated between hosts. There is a binary log that consists of queries that leave the master and were sent to the slave. There are also relay logs that were received on a slave by the master. These two log sets can generate a large amount of data if queries between the API Gateways is disproportionately high. The largest user of bandwidth, throughput, and storage in MySQL queries between two Gateway databases is audit data. That storage burden is increased substantially if audited request and response messages are stored in the API Gateway database.
As such--if proper implementation methodologies are followed then neither of these scripts should be necessary. If audited data is sent out via the Internal Audit Sink Policy and audits are not stored on the local API Gateway databases then binary log and audit record usage is considered minimal.