IssueTracker

Your feature request was forwarded to the Cloud SQL engineering team to be evaluated. However, there is no ETA or guarantee of implementation. All future updates should occur here.

+1, we would also really like to see this feature so we can leverage the export/import functionality to quickly duplicate databases.

+1, we have a multi-tenant system with each tenant in their own schema.  We are trying to use export/import to 'clone' a tenant but instead of creating a new instance the import overwrite the existing.

We are using the REST API

+1

+1

+!

+1

+1

+1

+1

Hello.
This is not a difficult feature to implement . It's just a switch added or ignored. It will move the platform to new levels of speed and efficiency. At the moment, export a DB with the Gcloud command make it useless for lower environments. It is bound to the environment . Imagine a project that uses DB names as "acme-live" for the Production environment, "acme-uat" for UAT, "acme-qa1" for QA1 and so on and so forth.
The Cloud Engineering team could argue that using different database schema names for different environments should be an easy fix, just align all your DB Schema names to "acme".
That would be a sane choice for new "joiners" . For projects that are using the GCP platform for years and they have already configured these, it's not as easy. Especially when production has "acme-live" . Either all the environments need to use the "-live" extension or re-import the Moving DB from a Production environment (downtime - unacceptable). Schema Name "acme-live" on non production environments, Security team' nightmare.
Adding the option "--no-create-db" in your code, wouldn't be a task lasting more than a few hours.
I would suggest to add it as soon as possible and offer it as an ALPHA feature. If the users keep having issues, by all means, please trash it and give us a serious life lesson, instead of us waiting for features and arguing if somethings needs to be implemented or not.
Apologies for the long comment. had I believed this feature doesn't deserve your attention, I would have never replied on the thread. I believe it's a valid and very helpful request. An option that the other providers does not have it yet.
Best regards.

+1

I am also requesting this!

Following along, it'd be great if a variety of mysqldump type flags could be passed.

+1

+1

+1

+100

This would be an awesome feature to have especially because there is the option on import to set the db name you want to import too.... Though only as long as it is not mention in the sql import files :(

+101

We are still wasting a comical amount of working hours because of this thing.

Hi folks! Any update about this request?

+1 any update here

+1

+1

Exporting data only without creating objects is a necessary feature. An important use case is exporting a production database to a testing database for doing an integration test of a new feature in an application.
Vice versa, it is dangerous to automatically recreate a database instance from an import, because this overwrites an existing instance, which might be a production instance. This is even more worse since there is an option to choose a target database in the Cloud Console, which is silently overridden. Not really clever.

Hello can you add the --no-create-db arg to gcloud sql export ?

This would be very usefull