MySQL source

Daspire uses one MySQL source connector for self-managed MySQL and the supported managed providers. Choose the provider-specific endpoint, network, and CA settings described below; do not create duplicate connectors for each cloud.

Clean source rollout status

The independent clean MySQL source is packaged in its own image and is the default runtime for the single MySQL source definition as of July 20, 2026. The legacy runtime and image fallback are retired. Disabling the clean route, supplying an invalid image, or using an unsupported legacy-only configuration now fails closed instead of starting the old image. This does not copy or bulk-migrate source configurations, catalogs, state, destinations, or customer data.

Capability	Clean source status
Full Refresh	Validated for Generic MySQL, Amazon RDS for MySQL, Aurora Provisioned, Aurora Serverless v2, Azure Flexible Server, and Google Cloud SQL
Standard incremental	Validated for the same six environments
Binlog CDC	Validated for Generic MySQL 5.7/8.0, Amazon RDS for MySQL, Aurora Provisioned, Aurora Serverless v2, Azure Flexible Server, and Google Cloud SQL
Direct TLS	Supported; verify_identity is recommended
Delete capture	Supported only by the validated clean binlog CDC path
SSH tunnel	Not supported by the clean source

Older saved configurations may contain legacy CDC, ssl=false, or SSH tunnel options. Those options are not available through a fallback connector. Before reactivating such a Source, reconfigure it to the clean contract; Daspire does not silently downgrade TLS or emulate SSH tunneling.

Aurora Serverless v1 is end-of-life and is excluded from new validation. Migrate to Aurora Serverless v2.

Connection fields

Provide these values for every mode:

• host: the exact DNS hostname described for your platform. Do not include a scheme, port, path, or user information.
• port: normally 3306.
• database: the one database/namespace to discover.
• username and password, or an approved managed credential handle.
• ssl_mode: use verify_identity for CA and hostname verification.
• ssl_ca: the complete PEM CA bundle from the database operator or cloud provider. When supplied, this bundle replaces the system trust store for the connection; include every provider root needed during an announced rotation.
• Optional ssl_cert and ssl_key when the server requires mutual TLS.
• replication_method: Standard or, only in a validated environment, CDC.
• stream_allowlist: optional exact table names to limit discovery.

verify_ca verifies the chain without checking the hostname. require encrypts the connection without authenticating the server certificate and is not recommended for production. prefer may fall back only for a loopback compatibility target; it does not permit a public cleartext connection. TLS 1.2 is the minimum.

Network, endpoint, and CA by platform

Generic MySQL 5.7 or 8.0

• Allow TCP from the Daspire egress address or private runtime network to the MySQL listener. Restrict the firewall to the exact source and port; do not expose 3306 to the internet.
• Use the stable writer hostname whose certificate contains that DNS name. Avoid an IP address when verify_identity is enabled.
• Obtain the issuing CA chain from the server operator. Keep hostname verification enabled and rotate the CA bundle before the server certificate chain changes.
• Full Refresh needs readable tables or views. Standard incremental and CDC need base tables; the additional requirements are listed below.

Amazon RDS for MySQL

• In the DB security group, allow inbound MySQL traffic only from the Daspire security group, private network, or exact egress CIDR. Public accessibility alone does not grant access; the route table, network ACL, and security group must all permit the path.
• Use the RDS DB instance endpoint for the writer. Do not use an IP address or a transient resolved address.
• Download the current regional/global RDS CA bundle from AWS and use the RDS endpoint with verify_identity.
• Keep automated backup retention above zero so RDS binary logging remains enabled. CDC also requires the parameter and retention settings below.

Aurora MySQL Provisioned

• Permit port 3306 in the cluster security group from the approved Daspire network only.
• Use the Aurora cluster writer endpoint for CDC. Binary logs are available from the primary instance, not reader instances. Do not use a reader endpoint for a resumable CDC source.
• Use the AWS RDS CA bundle and verify the exact cluster endpoint hostname.
• Apply CDC binlog parameters in a dedicated DB cluster parameter group. A binlog_format change requires the writer to be rebooted before validation.

Aurora Serverless v2

• Use the same security-group, writer-endpoint, CA, and cluster-parameter rules as Aurora Provisioned.
• The host must be the Serverless v2 cluster writer endpoint, not a Data API endpoint or reader endpoint.
• If the cluster can auto-pause to 0 ACU, allow enough connection/read timeout for wake-up and reconnect. A wake-up is not a state reset; the committed CDC state must still resume on the same accepted server identity.
• Aurora Serverless v1 is EOL and must be migrated to Serverless v2.

Azure Database for MySQL Flexible Server

• With public access, add only the Daspire egress IP/CIDR to the server firewall. With private access, provide VNet/Private Link routing and DNS from the Daspire runtime network. Do not combine private-only DNS with an unreachable public route.
• Use <server>.mysql.database.azure.com; Microsoft recommends the FQDN instead of an IP because the address can change.
• Keep require_secure_transport=ON. For full verification, provide the current DigiCert Global Root G2 and Microsoft RSA Root CA 2017 roots and use the Azure FQDN with verify_identity.
• Full Refresh, standard incremental, and clean binlog CDC are validated. For CDC, set binlog_row_image=FULL, binlog_row_metadata=FULL, leave binlog_row_value_options empty, and use binlog_expire_logs_seconds=604800 (7 days) or a longer monitored window. Query the effective global values after any required server restart.

Google Cloud SQL for MySQL

• For a public-IP connection, authorize only the Daspire egress CIDR. For a private-IP design, provide VPC connectivity and private DNS from the runtime.
• When Cloud SQL uses a Google-managed shared CA, copy the DNS name reported by Cloud SQL and configure it as an absolute FQDN matching *.sql.goog.. The terminal dot is required, for example example-id.us-central1.sql.goog.. Do not remove the final dot and do not replace the name with the public IP.
• Download the Cloud SQL server CA chain and use verify_identity. An IP or a hostname without the required terminal dot must fail certificate hostname verification.
• Full Refresh, standard incremental, and clean binlog CDC are validated. CDC requires automated backups and binary logging/PITR, plus binlog_row_image=FULL, binlog_row_metadata=FULL, and an empty binlog_row_value_options. Start with seven days of transaction-log and backup retention and monitor storage and maximum recovery time.

Least-privilege account

Create a dedicated account limited by network source and database. Replace the examples with your database and approved host pattern.

CREATE USER 'daspire'@'approved-host' IDENTIFIED BY 'use-a-secret-manager';
GRANT SELECT ON `your_database`.* TO 'daspire'@'approved-host';

Full Refresh and standard incremental need only SELECT on the selected objects. CDC additionally needs the MySQL replication protocol privileges:

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'daspire'@'approved-host';

The clean snapshot does not request RELOAD, global table locks, DDL, or write privileges. Do not grant SUPER, FILE, PROCESS, CREATE, ALTER, DROP, INSERT, UPDATE, or DELETE to the connector account.

Full Refresh

Select Standard and configure each selected stream as full_refresh.

• A cursor and primary key are not required.
• Base tables and readable views can be selected.
• Each run reads the selected objects again. It does not capture deletions between runs as change events.
• A full refresh has no resumable record position. If interrupted, rerun the stream from the beginning.

Standard incremental

Select Standard and configure the stream as incremental.

• The stream must be a base table with a source-defined primary key.
• Choose one non-null cursor with an exact integer, DECIMAL, NUMERIC, DATE, DATETIME, or TIMESTAMP type.
• Daspire orders and resumes by the cursor plus every remaining primary-key column. This avoids skipping rows that share the same cursor value.
• State version 1 is accepted only when its cursor and primary-key fields match the selected catalog. Unknown versions, malformed values, catalog drift, and changed primary keys fail closed before a read.
• Rows inserted later with a cursor at or before the committed position are not discovered automatically. Reset the stream when the cursor is not monotonic.
• Standard incremental does not capture DELETE operations.

Binlog CDC

Server parameters

CDC accepts the six environments listed in the support table only when all preconditions pass:

server_id                = a-unique-nonzero-value
log_bin                  = ON
binlog_format            = ROW
binlog_row_image         = FULL

For MySQL 8.0, also set:

binlog_row_metadata      = FULL
binlog_row_value_options =

The clean source supports gtid_mode=ON and gtid_mode=OFF. Transitional GTID modes (ON_PERMISSIVE or OFF_PERMISSIVE) fail closed. When GTID is enabled, also enable enforce_gtid_consistency.

For RDS for MySQL, use a dedicated DB parameter group, keep automated backups enabled, and verify the effective global values after applying the group. For Aurora Provisioned and Serverless v2, use a dedicated DB cluster parameter group and reboot the writer when a static parameter requires it. AWS defaults can report OFF_PERMISSIVE; explicitly set gtid-mode to OFF or complete the provider-supported transition to ON before enabling CDC.

For Azure Flexible Server, binary logging and ROW format are provider-managed; set the two full-row flags and empty partial-JSON option above, configure binlog_expire_logs_seconds, and verify the effective values after restart. For Google Cloud SQL, enable automated backups and binary logging/PITR, set the two full-row flags, and verify that the partial-JSON option is empty. The clean source supports both the Azure-validated GTID OFF state and the Cloud SQL-validated GTID ON state.

Configure a unique cdc_server_id from 1 through 4294967295 for each concurrent CDC client. It is the replication client identity, not the server's own server_id.

Retention

Retention must exceed the maximum planned outage plus operational recovery time. Monitor binlog storage growth.

• Generic MySQL 8.0: start with binlog_expire_logs_seconds=864000 (10 days).
• Generic MySQL 5.7: start with expire_logs_days=10.
• RDS for MySQL: use CALL mysql.rds_set_configuration('binlog retention hours', 168);. AWS limits RDS for MySQL to 168 hours (7 days).
• Aurora MySQL: start with CALL mysql.rds_set_configuration('binlog retention hours', 240); and adjust after monitoring storage. Aurora MySQL v2.11+ and v3 allow up to 2160 hours.
• Azure Flexible Server: start with binlog_expire_logs_seconds=604800 (7 days) and increase it when the maximum outage plus recovery window is longer.
• Google Cloud SQL: enable automated backups and binary logging/PITR and start with seven days of transaction-log retention. Retention is provider-managed; size it together with backup retention and available storage.

If a file/position no longer exists, or GTID purging created a gap not contained in committed state, the connector returns cdc_position_expired. Recovery is deterministic: stop the source, reset its CDC state, rediscover the catalog, and run a new initial snapshot. The connector never guesses a newer position.

Initial snapshot, records, and state

• Every CDC stream must be an InnoDB base table with a source-defined primary key. Views, tables without a primary key, and non-InnoDB tables fail closed.
• The first run captures a binlog/GTID position and reads an InnoDB repeatable- read consistent snapshot without a global table lock. State is not emitted until the entire snapshot is complete.
• Changes committed between the captured start position and the snapshot can appear once in the snapshot and again as a binlog event. This is the expected initial at-least-once duplicate boundary; consumers must upsert by primary key.
• INSERT emits the after image, UPDATE emits the full after image, and DELETE emits the full before image. Every record includes _daspire_cdc_event, _daspire_cdc_deleted_at, _daspire_cdc_log_file, _daspire_cdc_log_pos, and _daspire_cdc_gtid.
• Checkpoints are emitted only after transaction commit. If a process stops after records were delivered but before their checkpoint was committed, the whole uncheckpointed transaction can be delivered again after restart. No exactly-once guarantee is made.
• CDC state version 1 binds the database, selected stream order, catalog fingerprint, server identity, GTID mode, and committed GTID or file/position. Unknown or malformed state is rejected.

Schema changes

Automatic CDC schema evolution is not supported in this release. CREATE, ALTER, DROP, RENAME, or TRUNCATE in the consumed interval fails closed without advancing state beyond the DDL. Stop writes, update the source schema, rediscover and accept the catalog, reset CDC state, and take a new snapshot. Partial JSON row images are also rejected.

Explicitly unsupported clean-source configurations

• SSH tunnel configuration. Use approved direct private networking, VPN, or Private Link/Private Service Connect patterns instead.
• Aurora Serverless v1.
• CDC tables without a primary key, non-InnoDB CDC snapshots, partial row images, partial JSON updates, and automatic schema evolution.
• Bulk customer migration. The clean image is now the definition default, but Daspire does not rewrite existing source configurations, catalogs, state, or customer data as a batch operation.

Troubleshooting

• tls_verification_failed: verify the CA chain and exact hostname. For Cloud SQL shared CA, confirm the *.sql.goog. name includes the terminal dot.
• authentication_failed: verify the managed credential and MySQL host pattern; do not weaken TLS to work around password authentication.
• permission_denied: confirm SELECT; for CDC also confirm REPLICATION SLAVE and REPLICATION CLIENT.
• cdc_precondition_failed: inspect effective global binlog parameters on the writer, not only the parameter-group desired values.
• cdc_position_expired: do not edit state manually. Reset and resnapshot after confirming retention and catalog readiness.
• schema_changed: stop the source, rediscover, review the new catalog, reset CDC state, and resnapshot.

For provider details, use the official AWS RDS certificate bundle, AWS RDS binlog retention, Aurora binary logging, Azure Flexible Server networking, Azure TLS guidance, and Cloud SQL server identity verification.