Full GCP migration: Cloud SQL + Storage?

[rinse-dental]

I'm running a Windows Server VM + middle tier but suspect a full migration to Cloud SQL and Storage would be faster, cheaper and more scalable. Has anyone successfully made the move? Is it possible?

The AtoZ migration seems possible by creating the AtoZ filestore then mounting a drive using FUSE. https://cloud.google.com/storage/docs/g ... unt-bucket

As for Cloud SQL I suspect it's not possible because only MySQL is supported?

[saumilshah]

Not a full answer, but some field notes — we run in the same territory and made the opposite call, which might be useful.

On Cloud SQL: it does offer MySQL, so that is not the blocker you are expecting. What caught us out was further down — a managed tier decides some server settings for you, and the ones you cannot override are the ones that bite. Worth writing down the settings your current installation actually depends on and checking each one against what the managed tier exposes, before you commit to anything.

The thing I would measure before all of that is latency. You are moving a database that has always been on the same LAN out to a region, and that cost is paid per round trip rather than once — so it tends to surface as the application feeling slow rather than as an error, which makes it awkward to attribute after the fact. Before migrating anything, put realistic latency between a test client and a remote database and let someone who uses the software all day tell you whether it still feels right. That test is cheap and it will tell you more than any amount of reasoning about it.

On AtoZ: mounting a bucket with FUSE does work in the sense that the files appear. What we ended up caring about was the failure mode rather than the happy path — a mount that goes away mid-day behaves differently from a disk that goes away, and the software does not necessarily tell you which happened. Whatever you choose, decide up front what the office sees when the storage is briefly unreachable.

For what it is worth we looked hard at this and went the other way — we left the database where it was and worked around it instead of moving it. Different tradeoffs, not better ones, and it costs something to maintain. But it means the latency question never lands on the practice, and a bad network day degrades our side rather than stopping theirs.

Happy to go into more detail if any of that is useful.

[rinse-dental]

Thanks. This is useful. I went down the rabbit hole a fair amount myself... ChatGPT had to remind me of the issues I ran into

- Cloud SQL external-replica setup was blocked by GTID incompatibility.
- Cloud SQL for MySQL 8.x requires gtid_mode=ON.
- Open Dental’s MariaDB uses incompatible MariaDB GTIDs.
- Replication failed with Last_IO_Errno: 13117: source GTID mode off vs. Cloud SQL GTID mode on.
- The MySQL workaround (ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = LOCAL) could not be applied because Cloud SQL removes the required replication admin privileges.

[saumilshah]

That GTID mismatch is a wall, not a setting you are missing. MariaDB and MySQL GTIDs diverged into genuinely different formats, so a MariaDB source cannot act as a GTID replication source for a MySQL 8.x replica, and the MySQL-side workaround needs replication admin privileges a managed tier does not grant. Those two together close the native-replication path, and there is no flag that reconciles them.

Worth separating what that rules out, though. It closes replication-based cutover. It does not close the migration.

The blunt path is dump and load inside a maintenance window. Well understood, and the price is downtime you schedule deliberately.

The lower-downtime path is change data capture that reads the binlog by file and position rather than by GTID. That is the part I would look at hardest, precisely because GTID is the thing that broke and positional reading does not need it. You tail the source binlog into your own consumer, let the destination catch up while the practice keeps working, then stop writes, drain what is left and flip. The destination is never asked to be a replica, so its GTID mode and its missing privileges stop being part of the problem.

I should be straight about where my experience ends. We run that pipeline shape — binlog into a queue into a consumer — but we run it as a one-way mirror, with Open Dental staying authoritative on the office machine. Not as a cutover to a cloud-hosted database. So I can tell you the pipeline works and what it costs to own — you inherit ordering, replay when the consumer falls behind, and a decision about what happens to an event that fails to apply — but I have not done your cutover and will not pretend otherwise.

The other thing I would settle before choosing either: what Open Dental will support you running against. I would rather not guess on their behalf, and it is the answer most likely to decide this for you.