BinLog Storage has reached huge proportions and still growing

Question

BinLog Storage has reached huge proportions and still growing

Simu Dreamproduction 0

Hello,

Since 04th of April BinLog Storage for our Azure Database for MySQL flexible server has reached 70 GB and still growing rapidly.

I have tried several things found online but lack permission for almost everything.
Is there anything we can do to reduce the Binlog or check what is causing this issue?

Best Regards

Simu

Vijayalaxmi Kattimani 2,225 Reputation points Microsoft External Staff

2025-04-14T15:59:24.2233333+00:00
Hi Simu Dreamproduction,

Greetings!

We apologize for the inconvenience caused.

To manage the growing BinLog storage in your Azure Database for MySQL, Here are some steps and considerations to help you manage and reduce the BinLog storage:

BinLog Expiry Configuration: The binlog_expire_logs_seconds parameter specifies the number of seconds that the service waits before deleting the binary log file. By default, this is set to 0, meaning logs are deleted as soon as they are no longer needed. Increasing this value can delay deletion and increase storage usage. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-server-parameters Ensure that binlog_expire_logs_seconds is set appropriately to balance between data retention for replication and storage usage.

Replication and Data Recovery: Binary logs are used for replication and data recovery. If you have multiple replicas, the logs will wait for the slowest replica to read the changes before deletion. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-server-parameters If you are using read replicas, ensure that they are functioning correctly and not causing delays in log deletion. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-read-replicas

Monitoring and Alerts: Use Azure Monitor to track the storage usage of your BinLogs. Set up alerts to notify you when storage usage exceeds a certain threshold. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-backup-restore Regularly review the storage metrics and adjust the binlog_expire_logs_seconds parameter as needed to manage storage efficiently. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-server-parameters

Permissions and Access: Ensure you have the necessary permissions to modify server parameters. If you lack permissions, you may need to contact your Azure administrator or support team to make the necessary changes. https://eng.ms/docs/cloud-ai-platform/azure-data/azure-data-azure-databases/mysqlmariadb/azure-database-for-mysql-flexible-server/mysql-flexible-server-tsgs/sop/network-billing-entraid-errorlog-triage

Steps to Reduce BinLog Storage:

Check Current BinLog Settings: Verify the current value of binlog_expire_logs_seconds and adjust it if necessary. For example, setting it to a lower value can help reduce storage usage.

Purge Old BinLogs: Manually purge old BinLogs if they are no longer needed. This can be done by setting the binlog_expire_logs_seconds to a lower value temporarily and then reverting it back.

Review Replication Setup: Ensure that your replication setup is optimized and that there are no delays in log processing by replicas.

Here are links to several parallel threads that may be helpful to you:

https://learn.microsoft.com/en-us/answers/questions/2074307/azure-mysql-flexible-server-reduce-storage-size-by

I hope this information helps. Please do let us know if you have any further queries.
Simu Dreamproduction 0 Reputation points

2025-04-15T06:58:30.51+00:00

Hello,

Unfortunately we tried all those steps.

binlog_expire_logs_seconds was already set to 0. We tried yesterday to set it to 120 and waited couple of hours, did not help, set it for 1 day to see what happens over night, still the same. Binlog still growing, is now at 82GB out of 100GB.

Restart of the SQL server is also not helping.

Our database has no replication and no read replicas.
Vijayalaxmi Kattimani 2,225 Reputation points Microsoft External Staff

2025-04-15T08:35:44.98+00:00

Hi @Simu Dreamproduction,

Thank you for the update.

Could you please provide the server details via private message as it will help us conduct a more thorough investigation.
Simu Dreamproduction 0 Reputation points

2025-04-15T09:21:40.2633333+00:00

How do I send private messages? :)
Vijayalaxmi Kattimani 2,225 Reputation points Microsoft External Staff

2025-04-15T09:25:38.04+00:00

Hi @Simu Dreamproduction,

We have already initiated a private message, and you may have received an email notification regarding the same. please check and share the requested details through the private message.
Vijayalaxmi Kattimani 2,225 Reputation points Microsoft External Staff

2025-04-15T10:02:29.8233333+00:00
Hi @Simu Dreamproduction,

Based on your update, we would like to add the following information. If you set binlog_expire_logs_seconds to a higher value, the binary logs won't be deleted soon enough. That delay can lead to an increase in the storage billing.

Binlog Purging Process: The binlog_expire_logs_seconds parameter governs the automatic expiration of binary logs; however, it does not delete them immediately. Binary logs are purged only as new logs are generated. Therefore, if the server is not actively generating new binary logs, the existing logs will remain until new ones are created.

You can manually force a purge by issuing a command:

PURGE BINARY LOGS BEFORE NOW();

Storage Size Reporting Delay: Please note that even after purging the binary logs, it may take some time for Azure's storage reporting to reflect the changes. Storage metrics are not updated in real time and may exhibit a delay of several hours.

In certain cases, restarting the MySQL server can help initiate the purging process and refresh the storage usage reporting.

If the storage size remains unchanged after performing these steps, please share the server details as requested via private message.

I hope this information helps. Please do let us know if you have any further queries.
Simu Dreamproduction 0 Reputation points

2025-04-15T10:43:38.5933333+00:00

Hello,

Just to point out that we set binlog_expire_logs_seconds to 120 seconds, Binlog messages were growing with more than 1GB so there were messages written, yet Binlog was not going down and still increasing. We waited with this configuration for several hours yet nothing changed.

I will check out private.
Simu Dreamproduction 0 Reputation points

2025-04-16T06:38:13.9766667+00:00

Hello,

In 2 days we got like 25GB of Binlog messages. STOP-START of the sql server did not help either

1 answer

Your answer

Simu Dreamproduction 0 Reputation points

2025-04-15T06:58:30.51+00:00

Hello,

Unfortunately we tried all those steps.

binlog_expire_logs_seconds was already set to 0. We tried yesterday to set it to 120 and waited couple of hours, did not help, set it for 1 day to see what happens over night, still the same. Binlog still growing, is now at 82GB out of 100GB.

Restart of the SQL server is also not helping.

Our database has no replication and no read replicas.
Vijayalaxmi Kattimani 2,225 Reputation points Microsoft External Staff

2025-04-15T08:35:44.98+00:00

Hi @Simu Dreamproduction,

Thank you for the update.

Could you please provide the server details via private message as it will help us conduct a more thorough investigation.
Simu Dreamproduction 0 Reputation points

2025-04-15T09:21:40.2633333+00:00

How do I send private messages? :)
Vijayalaxmi Kattimani 2,225 Reputation points Microsoft External Staff

2025-04-15T09:25:38.04+00:00

Hi @Simu Dreamproduction,

We have already initiated a private message, and you may have received an email notification regarding the same. please check and share the requested details through the private message.
Vijayalaxmi Kattimani 2,225 Reputation points Microsoft External Staff

2025-04-15T10:02:29.8233333+00:00

Hi @Simu Dreamproduction,

Based on your update, we would like to add the following information. If you set binlog_expire_logs_seconds to a higher value, the binary logs won't be deleted soon enough. That delay can lead to an increase in the storage billing.

Binlog Purging Process: The binlog_expire_logs_seconds parameter governs the automatic expiration of binary logs; however, it does not delete them immediately. Binary logs are purged only as new logs are generated. Therefore, if the server is not actively generating new binary logs, the existing logs will remain until new ones are created.

You can manually force a purge by issuing a command:

PURGE BINARY LOGS BEFORE NOW();

Storage Size Reporting Delay: Please note that even after purging the binary logs, it may take some time for Azure's storage reporting to reflect the changes. Storage metrics are not updated in real time and may exhibit a delay of several hours.

In certain cases, restarting the MySQL server can help initiate the purging process and refresh the storage usage reporting.

If the storage size remains unchanged after performing these steps, please share the server details as requested via private message.

I hope this information helps. Please do let us know if you have any further queries.
Simu Dreamproduction 0 Reputation points

2025-04-15T10:43:38.5933333+00:00

Hello,

Just to point out that we set binlog_expire_logs_seconds to 120 seconds, Binlog messages were growing with more than 1GB so there were messages written, yet Binlog was not going down and still increasing. We waited with this configuration for several hours yet nothing changed.

I will check out private.
Simu Dreamproduction 0 Reputation points

2025-04-16T06:38:13.9766667+00:00

Hello,

In 2 days we got like 25GB of Binlog messages. STOP-START of the sql server did not help either

Answer 1

Simu Dreamproduction 0

No response after all. we probably need to create a new SQL server and migrate there.

I was hoping for some help though with the current issue. I am hoping we will not have the same issue on the SQL server

Share via

BinLog Storage has reached huge proportions and still growing

1 answer

Your answer