MySQL

Versions

Version	Status	Notes
8.4	Available	Recommended
8.0	Available

Connecting

Parameter	Value
Host	{name}.db.foundrydb.com
Port	3306
Default database	defaultdb
TLS	Required

mysql -h HOST -u USER -pPASS defaultdb --ssl-mode=REQUIRED

Full connection string examples: Connection Strings →

High Availability

A highly available MySQL service runs one source (the primary, read-write) and one or more replicas (read-only). The source streams its binary log to every replica using GTID-based replication, completed binlogs are archived continuously for point-in-time recovery, and ProxySQL sits in front to split reads from writes and to follow the primary across a failover.

MySQL GTID replication & automatic failover

Steady state · GTID replication to replicas

ProxySQL:6033writes →Sourceprimary R/W⇢ GTIDReplicasread-only⇢ binlogArchivePITR

ProxySQL :6033Source (primary)Replica (read-only)writesbinlog archive (PITR)GTID / binlog (dashed)

How the pieces fit together:

• GTID replication. Every transaction is tagged with a globally unique identifier, so replicas track exactly which transactions they have applied. Because position tracking is transaction-based rather than file-and-offset based, a replica can be promoted, or re-pointed at a new source, without manually reconciling binlog coordinates.
• Row-based binary log. The source records committed changes to its binary log and ships them to each replica, which replays them to stay in sync.
• ProxySQL routing. Writes go to the source; reads are distributed across the replicas. ProxySQL multiplexes client connections and tracks which node is the current primary, so applications keep using a single endpoint.
• Binlog archiving. Completed binlogs are uploaded to object storage so the service can be restored to any point in time, independent of the replicas.

Connection Pooling (ProxySQL)

ProxySQL is available on port 6033. Enable it:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/pooler \
  -H "Content-Type: application/json" \
  -d '{"pool_size": 25}'

ProxySQL handles connection multiplexing and query routing: it sends writes to the source and reads to the replicas, and it reconnects clients to the new primary automatically after a failover. Because the routing follows the primary, applications connect to a single stable endpoint and do not have to be reconfigured when the topology changes.

Read Replicas

Add a replica:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/nodes \
  -H "Content-Type: application/json" \
  -d '{"role": "replica"}'

Replicas are read-only and attach to the source over GTID replication. They serve two purposes: scaling read traffic (ProxySQL routes reads to them) and acting as promotion candidates for high availability. Because replication uses GTID mode, failover is position-free: a replica already knows the set of transactions it has applied, so it can be promoted or re-pointed without reconciling binlog file-and-offset coordinates. Track how far behind a replica is with the replication_lag_seconds metric (see Metrics).

Failover

Promote a replica to primary:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/nodes/{node_id}/failover

Automatic failover triggers when the source becomes unreachable (requires at least one replica). During failover:

1. The unreachable source is fenced, and a healthy replica is promoted to the new source (read-write).
2. The stable endpoint re-points writes to the new source; if ProxySQL is enabled it updates routing automatically, so writes follow the new source with no client reconfiguration.
3. The remaining replicas re-point their GTID replication at the new source. GTID makes this safe: each node tracks applied transactions by identifier, so re-pointing needs no manual binlog coordinates.
4. The lost node is replaced automatically: a fresh VM is provisioned and GTID-syncs from the new source as a replica, so the cluster self-heals back to its full node count instead of running degraded.
5. If the old source later comes back online, it rejoins as a replica. Any transactions it committed but never replicated (errant GTIDs) are reconciled against the new source before it follows, so the timeline stays consistent.

Failover and node replacement are automatic. Losing the source with no healthy replica left to promote (for example a single-node service) has no failover target, so the service alerts for manual intervention rather than self-healing.

Point-in-Time Recovery

The source archives its completed binary logs continuously to object storage, on top of full backups. Together these let you restore to any timestamp within the retention window, not just to the moment a backup was taken. A restore replays the archived binlogs forward from a base backup up to the requested restore_point, into a brand-new service so the original is left untouched.

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups/restore \
  -H "Content-Type: application/json" \
  -d '{
    "restore_point": "2026-03-15T14:30:00Z",
    "target_service_name": "my-mysql-restored"
  }'

Configuration

curl -u admin:password -X PATCH \
  https://api.foundrydb.com/managed-services/{id}/configuration \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "innodb_buffer_pool_size": "2G",
      "max_connections": "500",
      "slow_query_log": "ON",
      "long_query_time": "1"
    }
  }'

Common parameters:

Parameter	Default	Description
innodb_buffer_pool_size	128MB	InnoDB cache, set to 70-80% of RAM
max_connections	151	Max simultaneous connections
slow_query_log	OFF	Enable slow query logging
long_query_time	10	Threshold in seconds for slow query log
innodb_flush_log_at_trx_commit	1	Durability vs performance (1=full, 2=fast)
max_allowed_packet	64MB	Max packet/BLOB size

Metrics

curl -u admin:password \
  "https://api.foundrydb.com/managed-services/{id}/metrics?metric=connections&period=1h"

Key metrics: connections, queries_per_second, innodb_buffer_pool_hit_rate, replication_lag_seconds.

Backups

# List backups
curl -u admin:password \
  https://api.foundrydb.com/managed-services/{id}/backups

# Trigger manual backup
curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups \
  -H "Content-Type: application/json" \
  -d '{"backup_type": "manual"}'

Version Notes

MySQL 8.4: mysql_native_password authentication plugin is disabled by default. Use caching_sha2_password (the default) or sha256_password. Most modern drivers support this. If you see authentication errors, upgrade your driver.