Remove an unwanted application database from an existing managed MySQL instance. This permanently removes the selected database and its data; it is different from terminating the entire instance.

Open the intended service

Sign in to the client area, open the intended MySQL service and choose Manage. Use that service’s module tabs for the sections below. Confirm the service and resource before making a change. Enable the corresponding client feature on the intended offering. If a section is missing or unavailable, review that service’s configuration rather than trying a different service.

Prepare before removal

Open Databases, or Manage databases from the overview. Identify the exact database and every application using it. Stop or redirect those applications through your normal maintenance process before removal.

Confirm that any required backup or export exists and can support the recovery you need. Do not assume the module has created a suitable backup, or that this interface offers a restore control. If recovery is uncertain, establish the available recovery method before deleting data.

Remove only the intended database

1. Check the selected service, database name and intended maintenance action again.
2. Choose Remove on that database’s row.
3. Read the confirmation that all data in the database will be permanently deleted.
4. Confirm only when removal is intended. Wait for the provider operation to complete and reload the database list.
5. Verify the database is gone while the intended remaining databases and applications still work.

Reserved system databases are excluded from this customer list. A missing entry after a read failure is not deletion proof. Use the provider-confirmed outcome when the result is uncertain, rather than repeatedly submitting deletion.

Removing one application database does not terminate the Cloud SQL instance or stop its provider charges. It also does not automatically remove every database login that previously used it.

Check the outcome

Wait for the provider operation to settle, then reload the relevant section and verify the actual result. A success notice or Done activity row can precede final provider completion. If an operation is already in progress, wait rather than repeatedly submitting it.

An empty list can also result from a failed read; it does not establish that the resource has no entries. For an uncertain result, reconcile the service and provider state before repeating a change. Do not include passwords, provider keys or full customer records.

See the PD Google Cloud MySQL Blesta guide for related setup, or explore PD Google Cloud MySQL.