This section describes how to use data transmission DTS (hereinafter referred to as DTS) to complete the MySQL database data synchronization to configure the DataHub instance, so that data can flow into the real-time computing, big data products for real-time data analysis.
- Support through the line, VPN gateway or gateway access Ali intelligent cloud of self-built MySQL data synchronization to Datahub instance.
- ECS support of self-built MySQL data synchronization to Datahub instance.
- Support RDS for MySQL instance data under one account Ali cloud sync to DataHub instance.
- Support RDS for Ali cloud accounts under different MySQL instance data synchronization to DataHub instance.
Synchronization objects
- Synchronization only supports synchronous table, the table does not support other non-objects.
Synchronization area
Source MySQL instance Supported territory include:
East 1 (Hangzhou), East 2 (Shanghai), North China 1 (Qingdao), North China 2 (Beijing), North 3 (of the North), North 5 (Hohhot), South China 1 (Shenzhen) America West (Silicon Valley), the eastern United States, Asia Pacific (Singapore), Hong Kong, the Middle East and the eastern part 1 (Dubai), Asia-Pacific, Southeast 3 (Kuala Lumpur), Australia (Sydney), Indonesia (Jakarta), India (Mumbai), central Europe 1 ( Frankfurt)
target Datahub examples include geographical support:
East 1 (Hangzhou), 2 East China (Shanghai), North China 2 (Beijing)
Shown, MySQL-> DataHub data real-time synchronization above, the delta data is generated in real time synchronized to MySQL DataHub instance topic. Incremental log table name DataHub instance stored in the default MySQL table with the same name. topic names can be modified according to business needs, you can configure task, modify the table in the DataHub instances corresponding topic name.
In addition to storing the update data topic, it also stores some meta information structure is defined in the following topic:
| dts_record_id | dts_instance_id | dts_db_name | dts_table_name | dts_operation_flag | dts_utc_timestamp | dts_before_flag | dts_after_flag | dts_col1 | …. | dts_colN |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 234 | db1 | sbtest1 | I | 1476258462 | N | Y | 1 | ….. | JustInsert |
| 2 | 234 | db1 | sbtest1 | U | 1476258463 | Y | N | 1 | ….. | JustInsert |
| 2 | 234 | db1 | sbtest1 | U | 1476258463 | N | Y | 1 | ….. | JustUpdate |
| 3 | 234 | db1 | sbtest1 | D | 1476258464 | Y | N | 1 | ….. | JustUpdate |
其中：
dts_record_id: 这条增量日志的唯一标识，唯一递增。如果变更类型为 update，那么增量更新会被拆分成 2 条，一条 Insert，一条 Delete。这两条记录具有相同的 record_id。
dts_instance_id: 这条增量日志所对应的数据库的 server id。
dts_db_name: 这条增量更新日志更新的表所在的数据库库名。
dts_table_name:这条增量更新日志更新的表。
dts_operation_flag: 标示这条增量日志的操作类型。取值包括:
I : insert 操作
D : delete 操作
U : update 操作
dts_utc_timestamp: 这条增量日志的操作时间戳，为这个更新操作记录 binlog 的时间戳。这个时间戳为 UTC 时间。
dts_before_flag: 表示这条增量日志后面带的各个 column 值是否更新前的值。取值包括：Y 和 N。当后面的 column 为更新前的值时，dts_before_flag＝Y, 当后面的 column 值为更新后的值时，dts_before_flag=N.
dts_after_flag：表示这条增量日志后面带的各个 column 值是否更新后的值。取值包括：Y 和 N。 当后面的 column 为更新前的值时，dts_after_flag=N，当后面的 column 值为更新后的值时，dts_after_flag=Y.
对于不同的操作类型，增量日志中的 dts_before_flag 和 dts_after_flag 定义如下：
1) 操作类型为：insert
| dts_record_id | dts_instance_id | dts_db_name | dts_table_name | dts_operation_flag | dts_utc_timestamp | dts_before_flag | dts_after_flag | dts_col1 | …. | dts_colN |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 234 | db1 | sbtest1 | I | 1476258462 | N | Y | 1 | ….. | JustInsert |
当操作类型为 insert 时，后面的所有 column 值为新插入的记录值，即为更新后的值。所以 before_flag＝N, after_flag=Y
2) 操作类型为：update
| dts_record_id | dts_instance_id | dts_db_name | dts_table_name | dts_operation_flag | dts_utc_timestamp | dts_before_flag | dts_after_flag | dts_col1 | …. | dts_colN |
|---|---|---|---|---|---|---|---|---|---|---|
| 2 | 234 | db1 | sbtest1 | I | 1476258463 | Y | N | 1 | ….. | JustInsert |
| 2 | 234 | db1 | sbtest1 | I | 1476258463 | N | Y | 1 | ….. | JustUpdate |
当操作类型为 update 时，会将 update 操作拆为 2 条增量日志。这两条增量日志的 dts_record_id ,dts_operation_flag 及 dts_utc_timestamp 相同。
第一条日志记录了更新前的值，所以 dts_before_flag=Y, dts_after_flag=N
第二条日志记录了更新后的值，所以 dts_before_flag=N, dts_after_flag=Y
3) 操作类型为：delete
| dts_record_id | dts_instance_id | dts_db_name | dts_table_name | dts_operation_flag | dts_utc_timestamp | dts_before_flag | dts_after_flag | dts_col1 | …. | dts_colN |
|---|---|---|---|---|---|---|---|---|---|---|
| 3 | 234 | db1 | sbtest1 | D | 1476258464 | Y | N | 1 | ….. | JustUpdate |
当操作类型为 delete 时，后面的所有 column 值为被删除的记录值，即为更新前的值。所以 dts_before_flag＝Y, dts_after_flag=N
下面详细介绍MySQL数据库数据同步至DataHub实例的配置流程。
1.购买同步链路
进入 数据传输 DTS 控制台，进入数据同步页面，点击控制台右上角“创建同步作业” 开始作业配置。
在链路配置之前需要购买一个同步链路。同步链路目前支持包年包月及按量付费两种付费模式，可以根据需要选择不同的付费模式。
在购买页面需要配置的参数包括：
- 源实例
同步作业的源实例类型，目前只支持MySQL - 源地域
如果为本地自建MySQL，那么选择专线在阿里云上的接入点所在的地区。如果为ECS上的自建MySQL,那么选择ECS实例所在的地区。如果为RDS For MySQL,那么选择RDS实例所在的地区。 - 目标实例
目标实例为同步作业的目标实例类型，目前支持 MySQL、MaxCompute (原ODPS、，分析型数据库（AnalyticDB）、DataHub。配置 MySQL->DataHub 同步链路时，目标实例选择：Datahub 即可。 - 目标地域
由于 Datahub 目前暂时只在 华东1(杭州) 地区售卖，所以目标地域默认选择 华东1(杭州)。 - 实例规格
实例规格影响了链路的同步性能，可以根据业务性能选择合适的规格。对于数据同步链路规格的具体说明请参考：数据同步规格说明
当购买完同步实例，返回数据传输控制台，点击新购链路右侧的“配置同步作业” 开始链路配置。
2.同步链路连接信息配置。
在这一步主要配置：
同步作业名称
同步作业名称没有唯一性要求，主要为了更方便识别具体的作业，建议选择一个有业务意义的作业名称，方便后续的链路查找及管理。数据源连接信息配置
在这个步骤中需要配置源 MySQL 实例的连接信息及目标Datahub实例的 project。配置的 Datahub project 必须属于登录 DTS 所使用的阿里云账号的资源。
源实例可以支持：通过专线接入阿里云的自建数据库、ECS上的自建数据库、RDS。
如果源实例为通过专线接入阿里云的自建数据库，那么需要配置的连接信息如下：
- 实例类型：选择 通过专线接入阿里云的本地 DB
- 实例地区：选择 专线 接入阿里云的接入点，例如接入阿里云的北京，那么选择 华北2 即可。
- 对端专有网络：专线 接入的阿里云上的 专有网络的VPC ID
- 主机名或IP地址：配置本地 MySQL 数据库访问地址，这个地址为本地局域网访问地址
- 端口：本地 MySQL 实例监听端口
- 数据库账号：本地 MySQL 实例访问账号
- 数据库密码：上面指定的 MySQL 访问账号对应的密码
如果源实例为ECS上的自建数据库，那么需要配置的连接信息如下：
- 实例类型：选择 ECS上的自建数据库
- ECS实例ID: 配置ECS实例的实例ID
- 端口：自建 MySQL 实例监听端口
- 数据库账号：自建 MySQL 实例访问账号
- 数据库密码：上面指定的 MySQL 访问账号对应的密码
如果源实例为RDS，那么只需要配置RDS实例的实例ID。
当这些内容配置完成后，可以点击授权白名单并进入下一步。
2.选择同步对象
当连接信息配置完成后，即进入同步表及同步初始化的相关配置。
在这个步骤中，需要配置 同步初始化 和 同步表。其中:
(1)同步初始化
同步初始化选项包括： 结构初始化
结构初始化是指对于待同步的表，在目标Datahub实例中创建对应的 topic，完成 topic schema 定义。建议选择结构初始化。
(2) 同步表选择
同步表只能选择某些表，不能直接选择整个库。对于同步的表，可以修改 topic 名称，选择对应的 shard key。如需修改，可以点击右边已选择对象后面的编辑按钮，进入修改界面。
当配置完同步对象后，进入同步启动前的预检查阶段。
3.预检查
When all of the above options configuration is complete, that is, into the pre-inspection before the start. Check the specific items detailed in the final of this pre-check the contents of a
post-sync when the configuration is complete, the data transmission services will be limited pre-check, after the pre-check by, you can click on the OK button to start the sync.
When the sync job starts, that is, into sync list. At this point just started work in sync initialization state. Initialization time depends on the size of the sync number table. When initialization is complete synchronization link that is entering the synchronization of state, then the source synchronous link with the target instance of truly established.
When the synchronization task into the synchronization when a topic query can be synchronized in the corresponding table Datahub example:
This completes the MySQL database data synchronization to configure the DataHub instance.
After sync is established, the flow can be calculated in the register DataHub Topic, while creating streaming source table, real-time data for subsequent analysis of data synchronized to calculate DataHub instance.