MySQL

This page contains the setup guide and reference information for MySQL.

The destination-mysql connector supports both SSL and non SSL connections.

Clean Runtime MySQL destination: The independently packaged MySQL destination has completed isolated full-path acceptance. It writes _daspire_raw_<connection prefix><stream> lower-cased, preserves the raw-table output contract documented below, and supports append, top-level-primary-key append_dedup with a nullable integer cursor, and explicitly enabled overwrite. Existing ssl=false settings are preserved as an explicit non-TLS choice; TLS-enabled connections are never silently downgraded. It does not use LOAD DATA LOCAL INFILE, does not yet support SSH tunneling or cross-database namespaces. Normal MySQL targets must honor autocommit=false so cancellation and failed checkpoints can roll back. An internal, explicit AnalyticDB for MySQL compatibility mode instead uses primary-key-idempotent autocommit, per-target-table writer fencing, staged INSERT OVERWRITE, and write readback before acknowledging state. The guarded image and a private/default-off definition are registered, but the connector remains fail-closed for unsupported primary-key, cursor, raw-table, or server capability shapes.

Prerequisites

For the Clean Runtime, use a separately validated transactional MySQL target (the local compatibility fixtures cover MySQL 5.7 and 8.0), or an explicitly admitted AnalyticDB compatibility target. MySQL protocol support alone does not prove transactional, DDL, locking or overwrite compatibility. Normalization is not executed by this writer; it requires a separately configured and validated downstream processor. Legacy-engine version requirements are not Clean Runtime acceptance evidence.

• Host
• Port
• Database
• Username
• Password

Permission

You will need a MySQL user with CREATE, INSERT, SELECT, DROP permissions. We highly recommend creating a Daspire-specific user for this purpose.

The default target contract requires transactional InnoDB writes and must allow the session to disable autocommit. The private AnalyticDB compatibility mode is the only exception: it requires @@autocommit = 1, primary-key duplicate suppression, CREATE TABLE ... LIKE, INSERT OVERWRITE, and an exact connector-owned writer-lock table. This mode is enabled only for a prevalidated existing destination; it is not inferred from a hostname and does not create a second destination. After that compatibility contract has been accepted, ordinary connection checks are metadata-only by default and do not create _daspire_check_% tables. A write-capability check is an explicit offline operator probe, not a routine product check.

That metadata-only default applies only to the accepted AnalyticDB mode. Ordinary transactional MySQL and legacy-raw MySQL checks still perform a bounded temporary-table write-capability probe. Their concurrent_safe_check default is false; setting it true does not turn their checks into read-only checks. Omit the field to preserve the selected mode's default, rather than copying an AnalyticDB setting into another mode.

For settings served by a qualified Clean MySQL capability publication, the form's check switch displays the selected mode's default when no value has been saved. Changing the mode does not overwrite an explicitly saved true or false. Viewing a default does not insert it into configuration. Available mode choices continue to come from the product spec; runtime support does not automatically make an additional mode selectable. An older unqualified form must not be used as proof that this behavior has been deployed.

Network Access

Make sure your MySQL database can be accessed by Daspire. If your database is within a VPC, you may need to allow access from the IP you're using to expose Daspire.

Target Database

MySQL doesn't differentiate between a database and schema. A database is essentially a schema where all the tables live in. You will need to choose an existing database or create a new database. This will act as a default database/schema where the tables will be created if the source doesn't provide a namespace.

For Native execution with the clean MySQL destination, the selected destination database is the only target database. Control preserves source namespaces for source reads and checkpoints, but maps a different, non-empty source namespace to the selected database in newly assembled destination catalogs. It does not change stream names, table prefixes, sync modes, or existing immutable snapshots. Streams whose names collide after case-insensitive namespace mapping are rejected before submission. This does not enable cross-database writes.

Features

Clean Runtime capability matrix

Capability	transactional_mysql_v1 (default)	legacy_mysql_airbyte_raw_v1	analyticdb_airbyte_raw_v1
Database writes	Transactional InnoDB; autocommit=false	Same transactional guarantee, legacy raw layout	Explicitly admitted idempotent autocommit and table fencing
Append	Yes	Yes, legacy raw rows	Yes, compatible raw rows
Overwrite	Explicitly enabled, transactional/staged path	Explicitly enabled, legacy layout	Explicitly admitted staged INSERT OVERWRITE
append_dedup	Top-level keys and nullable integer cursor; writer deduplicates	Raw history only; downstream normalization is separate	Raw history only; downstream normalization is separate
Default metadata-only check	No	No	Yes, after target capability acceptance
Namespace	Selected database only	Selected database only	Selected database only
SSH tunnel	Not supported	Not supported	Not supported
Arbitrary JDBC URL parameters	Not supported	Not supported	Not supported
Normalization/dbt execution	Separate processor, not this writer	Separate processor, not this writer	Separate processor, not this writer

All three writers use the same 8 MiB retained serialized-payload flush threshold in the common-buffer release. It is not a process RSS limit: a single incoming record and Python/driver overhead require additional memory. Byte flushes do not replace STATE, transaction commit, target attribution or usage acknowledgement. The original per-stream row-count limit still applies. Only a qualified deployed image and mode-specific consumer evidence establish support for a connection; this matrix is not permission to change its mode or replay an old job.

Output Schema

Each stream will be output into its own table in MySQL. Each table will contain 3 columns:

• _daspire_ab_id: a uuid assigned by Daspire to each event that is processed. The column type in MySQL is VARCHAR(256).

• _daspire_emitted_at: a timestamp representing when the event was pulled from the data source. The column type in MySQL is TIMESTAMP(6).

• _daspire_data: a json blob representing with the event data. The column type in MySQL is JSON.

append_dedup tables also contain connector-owned _daspire_pk_hash and _daspire_cursor metadata columns. The writer keeps one row per configured primary key and replaces it only when the integer cursor advances, using emitted time and stable record identity as deterministic tie-breakers. A missing primary key, missing cursor field, nested field path, or non-integer cursor fails before state acknowledgement.

For an in-place migration of an existing AnalyticDB destination, the connector preserves legacy _airbyte_ab_id, _airbyte_data, and _airbyte_emitted_at raw tables and also recognizes already-created _daspire_* three-column raw tables. New raw tables use the legacy _airbyte_* layout so existing queries do not need to change. Writes are idempotent by raw-record primary key. Overwrite streams are promoted from a same-layout staging table; an empty snapshot uses TRUNCATE because AnalyticDB does not clear a table for an empty INSERT OVERWRITE ... SELECT.

Setup guide

For Clean Runtime, do not enable local_infile for this connector. It uses parameterized writes, not LOAD DATA LOCAL INFILE. Configure supported TLS fields through the selected connector spec; non-empty jdbc_url_params and non-NO_TUNNEL SSH configurations are rejected. Do not silently drop unsupported fields during migration or assume that a legacy UI option enables the corresponding clean path.

Historical legacy-engine setup (not Clean Runtime)

The following local-infile/JDBC settings document the old engine only. They do not apply to the independently packaged Clean Runtime described above.

Before setting up MySQL destination in Daspire, you need to set the local_infile system variable to true. You can do this by running the query SET GLOBAL local_infile = true with a user with SYSTEM_VARIABLES_ADMIN permission. This is required cause Daspire uses LOAD DATA LOCAL INFILE to load data into table.

Default JDBC URL Parameters

The following JDBC URL parameters are set by Daspire and cannot be overridden by the jdbc_url_params field:

• useSSL=true (unless ssl is set to false)
• requireSSL=true (unless ssl is set to false)
• verifyServerCertificate=false (unless ssl is set to false)
• zeroDateTimeBehavior=convertToNull

Limitations

Note that MySQL documentation discusses identifiers case sensitivity using the lower_case_table_names system variable. One of their recommendations is:

"It is best to adopt a consistent convention, such as always creating and referring to databases and tables using lowercase names.
This convention is recommended for maximum portability and ease of use."

Source: MySQL docs

As a result, Daspire MySQL destination forces all identifier (table, schema and columns) names to be lowercase.

Historical legacy-engine SSH tunnel reference

Not supported by Clean Runtime. Its product adapter rejects SSH tunneling with ssh_tunnel_unsupported; direct connections use NO_TUNNEL. These historical instructions must not be offered as a working clean-connector setup path.

Daspire has the ability to connect to a MySQL instance via an SSH Tunnel. The reason you might want to do this because it is not possible (or against security policy) to connect to the database directly (e.g. it does not have a public IP address).

When using an SSH tunnel, you are configuring Daspire to connect to an intermediate server (a.k.a. a bastion server) that does have direct access to the database. Daspire connects to the bastion and then asks the bastion to connect directly to the server.

Using this feature requires additional configuration, when creating the destination. We will talk through what each piece of configuration means.

1. Configure all fields for the destination as you normally would, except SSH Tunnel Method.

2. SSH Tunnel Method defaults to No Tunnel (meaning a direct connection). If you want to use an SSH Tunnel choose SSH Key Authentication or Password Authentication.

• Choose Key Authentication if you will be using an RSA private key as your secret for establishing the SSH Tunnel (see below for more information on generating this key).

• Choose Password Authentication if you will be using a password as your secret for establishing the SSH Tunnel.

3. SSH Tunnel Jump Server Host refers to the intermediate (bastion) server that Daspire will connect to. This should be a hostname or an IP Address.

4. SSH Connection Port is the port on the bastion server with which to make the SSH connection. The default port for SSH connections is 22, so unless you have explicitly changed something, go with the default.

5. SSH Login Username is the username that Daspire should use when connection to the bastion server. This is NOT the MySQL username.

6. If you are using Password Authentication, then SSH Login Username should be set to the password of the User from the previous step. If you are using SSH Key Authentication leave this blank. Again, this is not the MySQL password, but the password for the OS-user that Daspire is using to perform commands on the bastion.

7. If you are using SSH Key Authentication, then SSH Private Key should be set to the RSA Private Key that you are using to create the SSH connection. This should be the full contents of the key file starting with -----BEGIN RSA PRIVATE KEY----- and ending with -----END RSA PRIVATE KEY-----.