Going off the beaten track and the most popular conferences in Western Europe lets you have a different prospective, meet very skilled DevOps and challenge your technical knowledge. Very glad to talk about “MySQL on the cloud, from virtual machines to serverless options” at the DevOpsConf Russia in Moscow.
Very happy that my post on RDS & MySQL minor versions (and how to speed up RDS MySQL upgrades) went live today on the Percona Community Blog. You can read the entire post here.
Vorerst sind Serverless-Datenbanken noch ein großes Fragezeichen is the (German) title of the interwiew I recently had with Jaxenter about relational databases and DevOps. You can find my answers here.
Last week I wrote a post on enabling KMS encryption for a running Amazon RDS instance for the Open Source Database Community Blog of Percona . Glad to share with the amazing Percona community how at Funambol we encrypted dozens of Amazon RDS instances without significant downtime. You can read the post here.
Here are the abstract and the slides of my talk “Do not press that Button: Operational Challenges of relational Databases on the Cloud” at the DevOps Conference 2018 in Berlin this week.
You can find the full interview on JAXenter.
According to the Amazon documentation, many users never pay for automated backups and DB Snapshots
There is no additional charge for backup storage, up to 100% of your total database storage for a region. (Based upon our experience as database administrators, the vast majority of databases require less raw storage for a backup than for the primary dataset, meaning that most customers will never pay for backup storage.)
But what if you are not one a lucky one? How do you know if you can increase the retention period of a RDS instance without ending up paying for extra storage? Or how much do you need to reduce your retention period to use only the (free) quota?
Here it gets tricky: there is no API to find out the total size of your backups or snapshots and there is nothing available in the console either.
As snapshots are incremental, it is really down to the activity of your database and it might be quite hard to predict the storage extra you are going to pay at the end of the month if you have a fixed retention or some business requirements on manual snapshots.
Sometime it might even be better to allocate more storage to the RDS instances in the region – and have access as well to higher IOPS on standard SSD storage – than simply pay for the extra storage of the snapshots.
But how can you figure out the best balance to take advantage of the free storage or forecast your backup storage? There is no direct way to find it out but you can estimate the cost – and so indirectly the size – by running a billing report.
Billing report and backup usage information
You can get a billing report from the console going to the Billing & Cost Management and:
- select “Reports”
- choose “AWS Usage Report”
- select “Amazon RDS Service”
- specify time period and granularity
- download report in XML or CVS format.
- open the report and check the “TotalBackupUsage” and “ChargedBackupUsage”
Knowing now the cost and the AWS S3 pricing for your region, you can now determine the storage.
How can I automate the process?
You can generate and have a Hourly Cost Allocation Report delivered automatically to a S3 bucket and process the information and create your alarms and logic accordingly.
For more information see the Monthly Cost Allocation Report page
I am very excited to attend this year the DevOps Conference in Berlin and present the session “Do not press that button: operational challenges of relational databases on the cloud”. You can find the abstract here. Looking forward to DevOpsCon in May!