Cloud SQL Databases & Users

Beyond the instance itself, applications need their own databases and users with limited access. ZopDay adds them to a Cloud SQL instance it created, as a separate database job. You can change databases and access after the instance exists, without touching the instance settings.

What does a Cloud SQL database job create

One database on an existing Cloud SQL for MySQL or PostgreSQL instance, and two users limited to it. Both users are named after the database. A database called orders gets orders_user and orders_rduser.

• The editor user (ending in _user) has all privileges on that database. On PostgreSQL, it also has them on the database’s public schema.
• The read-only user (ending in _rduser) has SELECT on the database. On PostgreSQL, this covers the tables and sequences that already exist in public.

Databases and users are not separate resource types in ZopDay. The job creates no new cloud resource: the database lives on the instance you already run. Memorystore is not supported. The job works only with MySQL and PostgreSQL instances.

What do you fill in for a Cloud SQL database job

Cloud SQL instance  the provisioning job that created the instance (required)
Database name       starts with a letter; letters, digits and underscores; up to 63 characters (required)
Cluster             the cluster that runs the job; it must already be connected to the instance (required)
Cloud account       the cloud account
Description         optional

ZopDay rejects names the database engines reserve: mysql, information_schema, performance_schema, sys, postgres, template0 and template1.

How does a Cloud SQL database job run

The job has five steps:

1. Check that the instance is ready.
2. Check that the instance is connected to the chosen cluster.
3. Start the database setup job in the cluster.
4. Wait for it to finish.
5. Save the application logins as Kubernetes secrets.

The connection matters because the setup job reads the instance’s admin login from the Kubernetes secret that the connection created. If the instance is not connected to that cluster, ZopDay rejects the request and asks you to connect it first. The job checks this again when it runs.

The SQL comes from fixed templates. It runs as a Kubernetes Job in the cluster’s zop-system namespace. Running it again is safe. MySQL uses CREATE DATABASE IF NOT EXISTS and CREATE USER IF NOT EXISTS. PostgreSQL checks for the database and users before creating them. On both engines, a re-run resets the two passwords to newly generated values.

Where do the Cloud SQL app users’ passwords go

ZopDay generates both passwords, 24 characters each. Nobody chooses or types one. When the setup job succeeds, ZopDay writes two Kubernetes secrets in zop-system: one for the editor and one for the read-only user. Each holds the endpoint, port, database name, username and password.

ZopDay then deletes the passwords from its own record of the job. It also deletes them when a step fails. Applications read their logins from the two secrets. An application and a reporting tool can use different users, and revoking one does not affect the other.

What happens when you delete a Cloud SQL database job

Deleting the job removes what it created:

• On MySQL, ZopDay drops both users and then the database.
• On PostgreSQL, ZopDay ends open connections, drops objects owned by the two users, drops the database and then drops the users.

The two application secrets are removed afterwards. Running the delete again is safe, so a half-created database can still be cleaned up. Export the data first if you need it.

What a Cloud SQL database job never changes

• It does not change the instance’s tier, storage, flags or backups.
• It does not create users with custom names or custom permissions.
• It does not copy these logins to Secret Manager. They live only in the cluster’s zop-system secrets.