This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(236.8, 85%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EEJ%3C/text%3E%3C/svg%3E)
Hello,
We operate an Azure Database for MySQL Flexible Server running MySQL 5.7. Around November/December 2024, we observed a significant increase in our database costs. Our 500 MB database has accumulated up to 4 TB of backup data, primarily due to extensive binary logs. This aligns with our workload, which involves frequent updates to one of the tables.
However, we haven't made any significant changes to our configuration or workload, and the load has remained consistent throughout the year. We're seeking insights into why our costs escalated during this period without any modifications on our end.
Thank you for your assistance.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(249.60000000000002, 51%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAP%3C/text%3E%3C/svg%3E)
Hi Even Johansen,
Just checking in to see if the below answer provided by Andreas Baumgarten
If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.
Hello @Adithya Prasad K
Andreas was helpful, but it did not answer my questions about the significant increase in cost.
Please read through my comments to help me understand what is going on with the never ending increase of "Backup Storage Used" (and the cost increasing with it).
Here's a quote from one of my comments:
One particularly confusing aspect of our previous MySQL Flexible Server instance is that, despite the retention period being set to seven days, the "Backup Storage Used" continued to grow over a span of two months. Additionally, the amount of "binary logs" increased alongside it. We verified the binary log count using
SHOW BINARY LOGS;. The current database has been running for 6 days, so it will take a few more days to determine if it behaves the same way.
Hi @Even Johansen ,
unfortunately I haven't an answer on your question "why the the "Backup Storage Used" continued to grow". Sorry.
I hope someone who is able to give you an answer will join the thread.
(If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)
Regards
Andreas Baumgarten
UPDATE:
The new "Azure Database for MySQL flexible server" has now been running for around 10 days.
This is another screenshot of the backup settings:
All the following metrics are from 27th of February, to 10th of March (today).
This is how "Backup Storage Used" looks:
"Binlog Storage Used" is consistent throughout the same period:
"Data Storage Used" is also pretty consistent:
Why does "Backup Storage Used" continue to grow after 10 days, when we have "backup retention" set to 7 days?
To clarify: "binlog_expire_logs_seconds" is set to 0. (default)
Also: Previously we've been able to create a ticket for our issues where we got contacted by Microsoft Support to help with our issues directly. Now i don't seem to be able to create such a ticket. Do you have any information about this? Is it still possible to contact Microsoft Support?
Thanks!
UPDATE: The new "Azure Database for MySQL flexible server" has now been running for around 10 days. This is another screenshot of the backup settings: All the following metrics are from 27th of February, to 10th of March (today).
This is how "Backup Storage Used" looks: "Binlog Storage Used" is consistent throughout the same period:
"Data Storage Used" is also pretty consistent:
Why does "Backup Storage Used" continue to grow after 10 days, when we have "backup retention" set to 7 days?
To clarify: "binlog_expire_logs_seconds" is set to 0. (default)
Also: Previously we've been able to create a ticket for our issues where we got contacted by Microsoft Support to help with our issues directly. Now i don't seem to be able to create such a ticket. Do you have any information about this? Is it still possible to contact Microsoft Support?
Thanks!
Hi @Even Johansen ,
did you try the Cost analysis already to figure out what is causing the costs?
Using the View section in Cost analysis might help to track the costs down by service.
(If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)
Regards
Andreas Baumgarten
Hi @Andreas Baumgarten ,
Yes we have identified the resource.
It is "Storage Data Used" for one of our "Azure Database for MySQL Flexible Server".
Please note that the original database was migrated to a new MySQL Flexible Server recently, to eliminate any potential configuration issues. The following screenshots are from the new replacement database which have only been running since February 19th. Therefore the accumulated storage is not that large, but let's have a look at the trend.
Looking at the metrics we see that the "Data Storage Used" in the database itself is relativly small:
While the "Backup Storage Used" is a lot higher and keeps increasing:
"Bin Log Storage" looks like this:
And "Storage Used" looks like this:
The backup retention is set to 7 days, with no Geo-redundancy and only locally redundant.
We belive the culprit is a combination of frequent changes to the database and the "point-in-time" restoration feature. Please correct us if we're wrong.
Ideally we would like just a snapshot once a day without the option to select a specific point during that day, but we will look into other backup options at a later time.
We are looking into some software changes what will help decrease the frequency of updates to the table, to help with the accumulation of binary logs, but we are still looking for an answer as to why this changed in November/December.
Thanks!
Hi @Even Johansen ,
decreasing the data retention time isn't an option?
(If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)
Regards
Andreas Baumgarten
Hi!
If I understand correctly, reducing the retention period would shorten the time available to detect potential issues. For example, if we set it to one day but don’t realize there's a problem until several days later, the restore point from when everything was working would no longer be available.
One particularly confusing aspect of our previous MySQL Flexible Server instance is that, despite the retention period being set to seven days, the "Backup Storage Used" continued to grow over a span of two months. Additionally, the amount of "binary logs" increased alongside it. We verified the binary log count using SHOW BINARY LOGS;.
The current database has been running for 6 days, so it will take a few more days to determine if it behaves the same way.
FYI the default parameters for binlog is as follows (which was configured the same for the previous MySQL Flexible Server:
According to the documentation for "binlog_expire_logs_seconds", the value 0 should make the binlog expire ASAP.
https://docs.microsoft.com/en-us/azure/mysql/flexible-server/concepts-server-parameters#binlog_expire_logs_seconds
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(220.8, 4%, 31%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESM%3C/text%3E%3C/svg%3E)
Hi @Even Johansen ,
The binary log is used mainly for two purposes: replication and data recovery operations.
Usually, the binary logs are deleted as soon as the handle is free from the service, backup, or replica set. If there are multiple replicas, the binary logs wait for the slowest replica to read the changes before they're deleted.
Could you please check if these operations are not performed on your server which causes increase in logs?
You may try use new feature of Accelerated Logs https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-accelerated-logs if that helps.
If you want to persist binary logs for a longer duration, you can configure the binlog_expire_logs_seconds parameter. If binlog_expire_logs_seconds is set to the default value of 0, a binary log is deleted as soon as the handle to it's freed. If the value of binlog_expire_logs_seconds is greater than 0, the binary log is deleted after the configured number of seconds.
Azure Database for MySQL - Flexible Server handles managed features, like backup and read replica deletion of binary files, internally.
When you replicate the data-out from Azure Database for MySQL - Flexible Server, this parameter needs to be set in the primary to avoid deletion of binary logs before the replica reads from the changes in the primary.
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.
Thanks
Hi @Even Johansen ,
Just checking if you got a chance to look at the above reply and tried suggested steps.
Please let us know so that we can assist further.
Thanks
Hi @Even Johansen ,
If I understand correctly, reducing the retention period would shorten the time available to detect potential issues. For example, if we set it to one day but don’t realize there's a problem until several days later, the restore point from when everything was working would no longer be available.
Yes. That's the tradeoff you will get: low retention time = less data but less days the backup might be available.----------
(If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)
Regards
Andreas Baumgarten