@Blueberry's banner p

Blueberry


				

				

				
0 followers   follows 0 users  
joined 2022 September 04 19:13:44 UTC

				

User ID: 90

Blueberry


				
				
				

				
0 followers   follows 0 users   joined 2022 September 04 19:13:44 UTC

					

No bio...


					

User ID: 90

I copied your post into o4-mini ChatGPT, without the last two paragraphs and the PSC idea, and this was spit out after a minute:

—————————

Here’s a proven, zero-Downtime–capable way to copy your Cloud SQL for MySQL database from Project A into Project B without dumping to GCS or exposing it publicly: use Database Migration Service (DMS) in the destination project, treating the source instance as a “self-managed” MySQL endpoint. This leverages private connectivity (VPC peering) so data never traverses the public Internet.

  1. Prepare your source Cloud SQL instance • Enable binary logging & GTID, and use row-based replication on your source: set log_bin, binlog_format=ROW, gtid_mode=ON, and retain logs (expire_logs_days or binlog_expire_logs_seconds) for at least a week. • Create a replication user with REPLICATION SLAVE, REPLICATION CLIENT, SELECT, SHOW VIEW, EXECUTE, TRIGGER, etc., per your migration type .

  2. Enable DMS in the destination project • In Project B, enable the Database Migration Service API and grant yourself the Database Migration Admin role.  • Ensure the DMS service account has compute.networkAdmin so it can set up peering. 

  3. Set up private connectivity (VPC peering) • In Project B, create a Private Connectivity Configuration under DMS → Private connectivity. Select the VPC from Project A that holds your source instance’s private IP; DMS will automatically peer its service-network VPC into that network. 

  4. Create your Source Connection Profile • Still in Project B’s DMS UI, go to Connection Profiles → Create Profile → Source. • Engine: MySQL • Classification: “Self-managed MySQL” (even though it’s Cloud SQL)—this bypasses the same-project restriction . • Host: the private IP (or public IP + authorized network) of your Cloud SQL source. • Credentials: use the replication user you created. 

  5. Create & run the Migration Job • Go to Migration Jobs → Create Migration Job in Project B.

    1. Name your job.
    2. Source: select the connection profile from step 4.
    3. Destination: choose an existing or let DMS create a new Cloud SQL instance in Project B.
    4. Connectivity: pick Private IP and select the private connectivity config you made in step 3.
    5. Type: choose One-time (initial load only) or Continuous (CDC + initial load).
    6. Test, then Start the job. 

DMS will do an initial data copy over the peered VPC, then (if you chose Continuous) apply changes in near real-time.

  1. Cut over to the new instance • Once the initial load is complete and lag is minimal, stop writes on the source, then in the DMS job click Promote. This switches your application to the target instance in Project B. 

Why this works • No GCS buckets or manual dumps needed.
• Data never leaves Google’s private network—no public IP exposure.
• Cross-project works seamlessly by treating the source as self-managed and running DMS in the target project.
• Scales to multi-TB databases with minimal downtime (CDC mode)

———————————-

Is it wrong?