tencent cloud

Tencent Cloud DataBuddy

MySQL Data Source

Baixar
Modo Foco
Tamanho da Fonte
Última atualização: 2026-10-09 16:09:30
Traduzido por IA

Overview

MySQL is a widely used open-source relational database. DataBuddy data ingestion supports using MySQL as a source, covering various scenarios such as offline synchronization, real-time full-database synchronization, and sharded database and table synchronization. This document describes the connection configuration, supported capabilities, prerequisites, and common issues of MySQL data sources in DataBuddy.

Supported Versions

Type
Supported Version
Self-Built MySQL
5.6.x / 5.7.x / 8.0.x / 8.1.x / 8.2.x / 8.3.x / 8.4.x
TencentDB for MySQL (CDB)
5.6 / 5.7 / 8.0
JDBC Driver
8.0.21

Read Capability

Capability
Offline read
Real-time full database read
Sharded database and table read
Supported
✓
✓
✓
For a complete comparison of data source capabilities, see Supported Data Sources and Read Capabilities.

Use Limits

Real-Time Sync Limitations

Limit
Description
Binlog format
Only ROW format is supported.
binlog_row_image
Must be set to FULL
Binlog retention period
Retain for at least 72 hours; the larger the full data volume, the longer the retention period required.
Table without primary key
Tables without primary keys cannot guarantee exactly-once semantics, and data duplication may occur.
XA transaction
XA ROLLBACK is not supported, and related tables must be processed manually.
Read-only database
Read-only database instances earlier than version 5.6.x are not supported.
Functional Index
Tables containing Functional indexes are not supported (a new feature in MySQL 8.0).
Cascading deletion
Synchronizing cascading deletion of associated table records is not supported.
Stored procedures and materialized views
Reading is not supported.
SET data type
Real-time synchronization is not supported.
Online DDL tool
Only gh-ost is supported, and other online DDL change tools are not supported.

Offline Sync Limitations

Limit
Description
Concurrency for Sharded Table Synchronization
When multiple tables are split into a single table during synchronization, the task concurrency must be greater than the number of tables.
Stored Procedure
Reading is not supported.

Supported Field Types

For complete field types, see MySQL official documentation. The following table shows DataBuddy support across different links (excerpted from MySQL 8.0.x).
Field Type
Offline read
Real-time read
TINYINT / TINYINT UNSIGNED
✅
✅
SMALLINT / MEDIUMINT / INT / BIGINT (including UNSIGNED)
✅
✅
FLOAT / DOUBLE / DECIMAL / NUMERIC
✅
✅
REAL
❌
✅
CHAR / VARCHAR / TEXT Series
✅
✅
JSON
✅
✅
BINARY / VARBINARY / BLOB Series
✅
✅
DATE / TIME / DATETIME / TIMESTAMP / YEAR
✅
✅
BIT / BOOL / BOOLEAN / ENUM
✅
✅
SET
✅
❌
GEOMETRY / POINT
❌
✅
Spatial types such as LINESTRING / POLYGON / MULTIPOINT
❌
❌
Spatial types (GEOMETRY series) have limited support. Convert them to string types before synchronization.

Supported DML/DDL for Real-Time Sync

DML

Operation
Whether Supported
INSERT / DELETE / UPDATE
✅

DDL

Operation
Whether Supported
Supported syntax examples
Add column (ADD COLUMN)
✅
ALTER TABLE t ADD col TYPE [FIRST | AFTER col]
Drop column (DROP COLUMN)
✅
ALTER TABLE t DROP [COLUMN] col
Rename column (RENAME / CHANGE COLUMN)
✅
ALTER TABLE t CHANGE old new TYPE
Modify column type (MODIFY COLUMN)
✅
ALTER TABLE t MODIFY col TYPE
Add table (CREATE TABLE)
✅
CHECK and Temporary tables are not supported.
Rename table / Delete table / Clear table
❌

DDL change response takes effect only during the incremental phase. For high-risk operations such as dropping or renaming tables, the destination typically does not support automatic response. For detailed DDL change response policies (automatic change, ignore, and log alarm), see Real-time Full-Database Multi-Table Task Configuration.

Prerequisites

1. Configuring Account Permissions

Offline synchronization:
CREATE USER 'wedata_user'@'%' IDENTIFIED BY 'your_password';
GRANT SELECT ON your_database.* TO 'wedata_user'@'%';
FLUSH PRIVILEGES;
Real-time synchronization:
CREATE USER 'wedata_cdc_user'@'%' IDENTIFIED BY 'your_password';
GRANT SELECT, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT
ON *.* TO 'wedata_cdc_user'@'%';
FLUSH PRIVILEGES;
We recommend creating a dedicated account for sync tasks to avoid mixing it with business accounts.

2. Enabling Binlog (Real-Time Sync Only)

SHOW VARIABLES LIKE 'log_bin'; -- ON indicates that it is enabled.
Binlog is enabled by default for Tencent Cloud MySQL. For self-managed instances, configure it in my.cnf:
[mysqld]
log-bin=mysql-bin
server-id=1
binlog_format=ROW
binlog_row_image=FULL
Restart the database after the modification for the changes to take effect.

3. Setting Session Timeout (Recommended)

For full synchronization of large databases, we recommend increasing the session timeout:
SET GLOBAL interactive_timeout = 28800;
SET GLOBAL wait_timeout = 28800;

Creating a Data Source

Operation Steps

1. Log in to the DataBuddy console.
2. Switch to the target region and Workspace at the top.
3. Go to Data Integration > Task Management > Data Source Management (or Platform Management > Data Source Management).
4. Click Add Data Source and select MySQL.
5. Enter the connection configuration and authentication information. For details, see Parameter Description.
6. Click Test Connection (see Data Source Connectivity Test).
7. After the test passes, click Save or Save & Create Task.

Parameter Description

Parameter
Description
Required
Default Value
Data Source Name
Unique identifier of the data source within the workspace
Yes
-
Connection Method
String connection (JDBC URL) / Tencent Cloud instance
Yes
String concatenation
JDBC URL
Connection string in string connection mode, in the format jdbc:mysql://host:port/database
Required for string connection
—
Region and Instance
Select an instance in Tencent Cloud instance mode
Required for Tencent Cloud instance
—
Username.
Database connection account
Yes
—
Password
Database connection password (SSM credential hosting supported)
Yes
—
Data Source Version
5.6 / 5.7 / 8.0.x
Yes
—
Advanced Parameters
Connection-level extended parameters, such as useUnicode, characterEncoding, serverTimezone, and connectTimeout
No
—
Example JDBC URL:
jdbc:mysql://10.0.0.1:3306/mydb?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

Using in Data Ingestion Tasks

Real-Time Full-Database and Sharded Database/Table Sync

Configuration Item
Description
Source Table Scope
Specified tables (only selected tables are synchronized; new tables require a restart) / regex matching (specify database name + table name regex; new tables that match the rule are automatically added)
Read Mode
Full + incremental / Incremental only
Subscription Type
You can select INSERT / UPDATE / DELETE, and at least one must be retained.
gh-ost Synchronization
Whether to synchronize temporary tables generated by gh-ost online DDL.

Offline Single Table Sync

Configuration Item
Description
Data source.
Configured MySQL data source
Database / Table
Supports exact specification and regex matching. Table names support ranges such as table_[0-99]
Split Key
Supports integer fields only; primary key or indexed columns recommended; avoid COLLATE columns.
Filtering Condition
Standard WHERE syntax, supports time parameters (such as gmt_create > $bizdate).

Best Practices

Practice
Recommendation
Account Permission Minimization
Create a dedicated account for the synchronization task, grant only necessary permissions, and do not use root.
Binlog retention period
At least 72 hours; longer retention is recommended for full synchronization of large tables.
Split key selection
Primary key or index columns; avoid COLLATE columns to prevent data duplication.
Network connectivity establishment
Prioritize private network connections to improve transfer performance.

Handling Primary/Secondary Switchover (Real-Time Sync)

Whether a real-time synchronization task can recover smoothly during a MySQL primary/secondary switchover depends on the address type and whether GTID is enabled:
Scenario
Solution
TencentDB for MySQL (unchanged instance address)
The interruption lasts only seconds. The task automatically reconnects to the new primary and resumes from the latest snapshot position. failover is completed automatically without manual intervention.
Self-Built MySQL + VIP/DNS
After VIP/DNS drifts to the new primary, the task automatically reconnects. It is recommended to set the number of task retries to at least 3.
Self-Built MySQL + Fixed IP address
Pause the task before the switch, modify the data source IP address after the switch, and then resume running.
It is strongly recommended to enable GTID: In a primary/secondary switchover scenario, recovery based on GTID ensures no data duplication or loss. With asynchronous replication, a primary database failure may lose the last few unsynchronized transactions, which is a limitation of the MySQL replication layer itself. For zero data loss, use strong synchronous or semi-synchronous replication.

FAQs

Q: Why does the error A slave with the same server_uuid/server_id as this slave has connected to the master occur?

Multiple synchronization tasks used the same server-id. The system now generates server-id randomly. If an old task has explicitly configured server-id in its advanced parameters, delete this parameter.

Q: Why does the error Cannot replicate because the master purged required binary logs occur?

The Binlog files on MySQL have been cleaned up. Increase the Binlog retention period or optimize job concurrency to speed up consumption.

Q: Why does the error Connection reset by peer or a connection timeout occur?

A: Network issues or job backpressure cause idle timeout. You can increase slave_net_timeout (for example, 120) or optimize job parallelism and memory.

Q:JobManager OOM?

A: Large data volume or sparse primary key range distribution causes excessive splitting. You can:
Increase the JobManager CU.
Adjust the advanced parameter scan.incremental.snapshot.chunk.size (default: 8096).
Adjust split-key.even-distribution.factor.upper-bound.

Q: What happens if binlog_format is changed from ROW to STATEMENT for MySQL during real-time task execution?

A: A real-time task only validates binlog_format=ROW at startup and does not check it again during runtime. After binlog_format is switched to STATEMENT, all DML statements are treated as DDL by the parser, so the downstream cannot detect data changes, resulting in silent data loss. Do not modify binlog_format while the task is running.

Q: Why is some data duplicated when a COLLATE column is used as the split key?

A: COLLATE affects sorting, filtering, and grouping results. When setting a split key, select a non-COLLATE column.

Q: Is gh-ost Online DDL Supported?

A: Yes. After you enable the gh-ost synchronization switch, the system monitors and synchronizes changes to *_gho temporary tables. Prerequisites: gh-ost can access MySQL normally. For Tencent Cloud CDB, append the --aliyun-rds parameter to the gh-ost command.

References

Ajuda e Suporte

Esta página foi útil?

comentários