I have a Google Cloud SQL MySQL 2nd Gen 5.7 instance with 70GB of unused storage. I want to reduce the unused storage of my instance as this is one of the major hosting costs.
The only way that I'm seeing as a possibility is dumping all the database to a new Google Cloud SQL instance created with the right storage capacity. However this approach has several pitfalls:
It would require a lot of time to dump and load the database (this would require severe downtime in the websites that are using the db)
I would have to change all the websites that use that database because the database's IP would change
What alternatives do I have?
As it is indicated in the official documentation, it is not possible to reduce the storage capacity of a Cloud SQL instance. You can give more capacity to an instance if needed, but the change is permanent and cannot be rolled back.
The best option for you right now would be to create a SQL dump file and export your current data into it. Then, in a new Cloud SQL instance with the desired capacity, import the SQL dump file so that all your data is stored in the new instance. To reduce time and costs for this process, please follow these best practices, including the use of the appropriate flags, compressing your data and other tips available for faster and less expensive imports and exports.
However, the possibility of reducing the capacity of a Cloud SQL instance has been requested as a new feature and is currently being worked on. Head to the link and click on the star icon on the top left corner to get email notifications on any progress made on this request.
There are no alternatives to reduce Instance size(Storage capacity) except one way which you mentioned in your question.
So, the way is first, export data from your old db instance:
Then, import the data into your new db instance which you newly created with reduced Instance size:
And as you know, it's impossible to reduce Instance size for all PostgreSQL, MySQL and SQL Server on Cloud SQL and only increasing Instance size is possible after creating your db instance.
Related
I identified an issue with an infrastructure I created on the Google Cloud Platform and would like to ask the community for help.
A charge was made that I did not expect, as theoretically it would be almost impossible for me to pass the limits of the free tier. But I noticed that my database is huge, with 1gb and growing, and there are some very heavy buckets.
My database is managed by a Django APP, and accessing the tool's admin panel there are only 2 records in production. There were several backups and things like that, but it wasn't me.
Can anyone give me a guide on how to solve this?
I would assume that you manage the database yourself, i.e. it is not Cloud SQL. Databases pre-allocate files in larger chunks in order to be efficient on writes. You can check this yourself - write additional 100k records, most likely size will not change.
Go to Cloud SQL and it will say how many sql instances you have. If you see the "create instance" window that means that you don't have any Google managed SQL instances and the one we're talking about is a standalone one.
You can also check Deployment Manger to see if you deployed one from the marketplace or it's a standalone VM with MySQL installed manually.
I made a simple experiment and deployed (from Marketplace) a MySQL 5.6 on top of Ubuntu 14.04 LTS. Initial DB size was over 110MB - but there are some records in it initially (schema, permissions etc) so it's not "empty" at all.
It is still weird that your DB is 1GB already. Try to deploy new one (if your use case permits that). Maybe this is some old DB that was used for some purpose and all the content deleted afterwards but some "trash" still remains and takes a lot of space.
Or - it may well be exactly as NeatNerd said - that DB will allocate some space due to performance issues and optimisation.
If I have more details I can give you better explanation.
I want to use a small mysql database in order to store some data that i going to calculate on a VM of GCE (by using Talend).
After store the data on the mysql i want to connect to it by using Excel, and update some registries.
What should be the best approach, install mysql on the VM or use Google Cloud SQL?
Kind Regards
Only you can decide what better fits your needs, but you may consider the following:
Local Mysql Pros:
Faster performances. This could be important if generating a lot of queries you would need a bigger Cloud SQL instance to have similar speed.
Minor costs
Cloud SQL Pros:
High reliability. Data is backed-up without the need of taking snapshots.
Possibility to stop or delete GCE instance and keep database active.
Easier and faster to scale if required
Easily add a read replica.
Less load on the GCE
Sincerely,
Paolo
For better performance you can run your MySQL server on a virtual machine. I have tried that with the same server specifications (1 CPU, 3.75 GB memory) and it runs much better.
We are testing the Google Cloud SQL service and we have a problem when importing our database.
Imported file include this command:
DROP DATABASE $my_db
But Google Cloud SQL dashboard still shows a storage size as if nothing was deleted.
Is it the right method for deleting a database without removing the supporting VM?
I don't want to delete the whole VM as instance names seem to be reserved for two months.
InnoDB will hold onto the data that it has allocated itself, so when you create a database and delete it, the storage usage remains the same. This means you can't reduce the maximum storage you have used, but InnoDB will recycle the space it has reserved if you import new data.
Not sure how to ask this question, but as I understand google cloud SQL supports the idea of instances, which are located throughout their global infrastructure...so I can have a single database spread across multiple instances all over the world.
I have a a few geographic regions our app serves...the data doesn't really need to be aggregated as a whole and could be stored individually on separate databases in regions accordingly.
Does it make sense to serve all regions off one database/multiple instances? Or should I segregate each region into it's own database and host the data the old fashion way?
If by “scaling” you mean memory size, then you can start with a smaller instance (less RAM) and move up to a more powerful instance (more RAM) later.
But if you mean more operations per second, there is a certain max size and max number of operations that one Cloud SQL instance can support. You cannot infinitely scale one instance. Internally the data for one instance is indeed stored over multiples machines, but that is more related to reliability and durability, and it does not scale the throughput beyond a certain limit.
If you really need more throughput than what one Cloud SQL instance can provide, and you do need a SQL based storage, you’ll have to use multiple instances (i.e. completely separate databases) but your app will have to manage them.
Note that the advantages of Cloud go beyond just scalability. Cloud SQL instances are managed for you (e.g. failover, backups, etc. are taken care of). And you get billing based on usage.
(Cloud SQL team)
First, regarding the overall architecture: An "instance" in Google Cloud SQL is essentially one MySQL database server. There is no concept of "one database/multiple instances". Think of your Cloud SQL "instance" as the database itself. At any point in time, the data from a Cloud SQL instance is served out from one location -- namely where your instance happens to be running at that time. Now, if your app is running in Google App Engine or Google Compute Engine, then you can configure your Cloud SQL instance so that it is located close to your app.
Regarding your question of one database vs. multiple databases: If your database is logically one database and is served by one logical app, then you should probably have one Cloud SQL instance. (Again, think of one Cloud SQL instance as one database). If you create multiple Cloud SQL instances, they will be siloed from one another, and your app will have to do all the complex logic of managing them as completely different databases.
(Google Cloud SQL team)
I am creating a WP8 App.
I have a created a sqlite database in the isolated storage.
Now my data keeps updating and I want to regularly download the latest data from the server database and update the local database.
The database in the WP8 cannot be changed at the client side so there will be only 1 side data merging.
Which is the best way and service to use?
If you do not work with a large database, you might prefer to replace the device database and not worry about merging. This can be as simple as making an export of the server database, transferring it to the device and then importing it into the device database. The appropriate method of dumping the database on the server side is dependent on the type of database (e.g. mysqldump in the case of MySQL).
If you do work with a large database, or if you are struggling with bandwidth issues on the device, you might want to use a technique to detect differences. One of the easiest methods is change tracking on the database. All modifications can then be logged with an change_at timestamp. The device can then remember which is the last modification it contains, get the new entries, and replicate the changes locally (For in-depth detailed explanation, please provide more information of the server environment and data structure).