Provisioning datastores

ZopDay provisions and adopts cloud-managed datastores on all three clouds. Create provisions a new datastore; Adopt wires an existing one into ZopDay without modifying it. Either way, you get a resource that deployments can attach to, and ZopDay never changes it on its own afterwards.

Before you start

• A cloud account connected with the datastore permissions (on AWS: RDS, ElastiCache, and Secrets Manager; on GCP: roles/cloudsql.admin, roles/redis.admin, roles/secretmanager.admin, and roles/storage.admin for the Cloud SQL copy staging bucket; on Azure: the ZopDay Infrastructure Access custom role, which carries the flexible server, Redis, and Key Vault secret permissions). See Cloud permissions.
• The provisioning:create policy. See RBAC.
• A network: a cluster whose VPC the datastore should join, or a VPC you pick.
• To copy a database between instances, an admin role.

How it works

Create provisions only these engines. Adopt is for datastores you already run; check with support before relying on it for other engines. A service uses a datastore through a database attached from the service’s Databases tab; see Connecting services.

Where credentials live

Create and Adopt handle credentials the same way:

ZopDay stores only the secret reference (ARN / URI), not the password. ZopDay generates the password at create time and resolves it from the secret manager when it needs it, but never stores it. If you regenerate the password directly in the secret manager, ZopDay’s reference still works, because it points to the secret, not the value.

What ZopDay changes on a database, and what it doesn’t

Once a datastore exists, ZopDay never changes its tier, replica count, or backup policy on its own, even if ZopDay created it. No schedule, recommendation, or remediation does it. Managed databases are not on the provisioner’s pause list either, so nothing pauses them.

ZopDay acts on a database in three cases, and only when you ask:

• Teardown of a datastore ZopDay created. Deleting its provisioning job deletes the datastore. See Teardown. Adopted datastores are never deleted.
• Copying a database between Cloud SQL instances. The source is only read. On MySQL, the copy replaces an existing target database only when you choose to overwrite it. See Copying a database between instances.
• An update you request. Changes you submit for an existing datastore run as an update job, the same in-place update job that clusters and VMs use. Adopted datastores are never modified.

For sizing recommendations on a database, attach it to a ZopNight event readiness plan as a monitor-only target. ZopNight computes a suggested tier (including connection-pool math and headroom) and shows it to you. You apply it through your DBA workflow.

Create a datastore

Go to Infrastructure → Provision and choose MySQL Database, PostgreSQL Database, or Redis Cache. The drawer takes you through these steps:

1. Resource type + engine

   Choose MySQL, PostgreSQL, or Redis, then pick an engine version. The dropdown defaults to the latest supported major version available on the cloud.

2. Cloud account + region + network

   Pick the connected cloud account and region. If you select a cluster, ZopDay places the datastore in the private subnet of that cluster’s VPC. Otherwise, pick a VPC yourself.

3. Sizing

   Pick the instance type from the cloud’s list and set the storage in GB (at least 20 GB, or 32 GB for PostgreSQL). Redis takes a node type instead of storage.

   Advanced settings, collapsed at the bottom of the form, holds the rest, including High Availability (a Multi-AZ standby replica), Public Access (VPC-only unless you turn it on), Deletion Protection, and Automated Backups (on by default, with the cloud’s default retention). High Availability, Deletion Protection, and Automated Backups are not offered for Redis. There are no presets and no IOPS or retention fields.

4. Credentials

   ZopDay generates a strong root password and writes it to your cloud’s secret manager (AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault). ZopDay never stores the password itself. It keeps only the secret reference (ARN / URI).

   The drawer has no username field, and the password is always auto-generated.

5. Provision

   Click Provision. The job runs in the background. Follow its progress in Activity → Provisioning Jobs.

Create takes 5–15 minutes, depending on the cloud and tier. Most of that time is the cloud provisioning the instance: the RDS, Cloud SQL, and Azure DB create calls block until the engine is ready.

Adopt an existing datastore

Use Adopt for datastores you already own and want to wire into ZopDay without changing anything on the cloud side. Adopting happens outside the Provision drawer, which only creates new resources.

1. Pick the existing instance

   ZopDay lists every datastore visible to the connected cloud account in the chosen region. Pick the one you want to adopt.

2. Provide credentials

   Paste the connection URI, or the hostname, port, and username. ZopDay stores only a secret reference for the credentials, never the credentials themselves.

3. Confirm metadata

   ZopDay shows what it discovered about the datastore (engine, version, tier, network) and asks you to confirm. This step only reads: it makes no changes through the cloud API.

4. Apply

   The adopted datastore appears in your inventory.

For adopted datastores:

• Teardown is a no-op. Disconnecting an adopted datastore removes only ZopDay’s pointer. The datastore itself keeps running, untouched.
• You can update credentials through the same credential flow, which re-stores the secret reference.
• Sizing changes are out of scope. ZopDay never modifies adopted datastores. Resize them through your normal cloud workflow.

Copying a database between instances

ZopDay can copy a single database from one Cloud SQL instance to another. It exports from the source, stages the dump in a bucket, and imports into the target. Use it to stand up a staging copy from production, or to move a database onto an instance of a different size. Copying is available on GCP Cloud SQL today. AWS and Azure engines will be added later behind the same interface.

Cloud SQL’s managed export produces a different dump format for each engine, so MySQL and PostgreSQL support different cases. The wizard offers only the options that will work, and explains why when one won’t:

MySQL dumps carry their own routing. They can replace a database in place but cannot land under a different name. PostgreSQL dumps contain tables only. They can land under a new name but cannot overwrite an existing database.

How a copy behaves:

• The source is only ever read. Only the import you started writes to the target.
• Credentials are never stored for the copy. The job holds only instance identifiers and resolves credentials at runtime.
• One operation per instance. If a copy shares a source or target instance with a copy that is already running, ZopDay rejects it instead of queuing it.
• Overwriting is explicit. To replace an existing database, you must choose to overwrite. ZopDay never infers it.
• Retry resumes from the step that failed. Cancelling is best-effort. ZopDay refuses to cancel once the import has started, because a half-imported database is worse than a finished one.

Only admins can start or cancel a copy. Viewing copies needs the same permission as viewing any provisioning job.

Connecting datastores to clusters

Once a datastore is in your inventory (created or adopted), connect it to the cluster that uses it. Database connections belong to the provisioning job that created or adopted the datastore:

GET    /provisioning-jobs/{jobID}/databases/{dbID}/connections
POST   /provisioning-jobs/{jobID}/databases/{dbID}/connections
DELETE /provisioning-jobs/{jobID}/databases/{dbID}/connections/{connID}

On Infrastructure, each datastore-to-cluster connection shows a live status: Live, Drift, or Unverified. ZopDay also detects connections it didn’t create, by reading your apps’ ConfigMaps for database host and name settings (it never reads Secrets).

Teardown

DELETE /provisioning-jobs/{id} on a created datastore starts a deletion job that:

1. Submits the cloud delete call. No final snapshot is taken on any cloud, and on AWS the RDS instance’s automated backups are deleted with it (deletion protection is cleared first). If you need the data, take a manual snapshot or export in your cloud console before you delete the job.
2. Deletes the secret in the cloud secret manager.
3. Removes the inventory entry.

For adopted datastores, teardown is a no-op.

Reference

What “create” does on each cloud

Encryption and TLS settings follow the options the drawer applies and each cloud’s defaults. Check the instance in your cloud console if you have specific requirements.

Cost preview

Any cost figure shown before you provision is an estimate. Actual cost varies with storage growth, IOPS bursts, backups, and inter-AZ traffic, none of which can be predicted from the provisioning config alone.

Troubleshooting

Next steps