Skip to main content

oceanbase_mysql_to_datahub

---
sidebar_position: 3
---
# OceanBase MySQL Migration Synchronization to Datahub

NineData data replication supports the efficient migration or real-time synchronization of OceanBase MySQL data to DataHub, ensuring seamless data integration and enabling data consolidation and analysis across multiple scenarios.

### Prerequisites

- The source and target data sources have been added to NineData. For instructions on how to add data sources, see [Add Data Source](/configuration/datasource.md).
- The source database type is OceanBase MySQL.
- The target data source type is Datahub.

### Usage Limitations

* Before performing data synchronization, it is necessary to assess the performance of the source and target data sources, and it is recommended to perform data synchronization during off-peak business hours. Otherwise, the full data initialization will occupy a certain amount of read and write resources of the source and target data sources, leading to increased database load.
* It is necessary to ensure that each table in the synchronization object has a primary key or unique constraint, and the column names are unique; otherwise, the same data may be synchronized repeatedly.

### Operation Steps

import Content from '../../ref/_ref-replic-mysql-datahub.md';

<Content />

### View Synchronization Results

import Content1 from '../../ref/_ref-result.md';

<Content1 />

### Appendix 1: Data Type Mapping Table

<table>
<thead>
<tr>
<th width="200">Type</th>
<th width="400">OceanBase MySQL Data Type</th>
<th width="400">Datahub Default Mapping Data Type</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="10">Numeric Types</td>
<td>BOOL, BOOLEAN</td>
<td>BOOLEAN</td>
</tr>
<tr>
<td>TINYINT</td>
<td>TINYINT</td>
</tr>
<tr>
<td>SMALLINT</td>
<td>SMALLINT</td>
</tr>
<tr>
<td>MEDIUMINT</td>
<td>MEDIUMINT</td>
</tr>
<tr>
<td>INT</td>
<td>INT</td>
</tr>
<tr>
<td>BIGINT</td>
<td>BIGINT</td>
</tr>
<tr>
<td>DECIMAL, DOUBLE</td>
<td>DECIMAL</td>
</tr>
<tr>
<td>FLOAT</td>
<td>FLOAT</td>
</tr>
<tr>
<td>DOUBLE</td>
<td>DOUBLE</td>
</tr>
<tr>
<td>BIT</td>
<td>STRING</td>
</tr>
<tr>
<td rowspan="4">Date Types</td>
<td>DATETIME (without time zone), TIMESTAMP (with time zone)</td>
<td>TIMESTAMP</td>
</tr>
<tr>
<td>DATE</td>
<td>STRING</td>
</tr>
<tr>
<td>TIME</td>
<td>STRING</td>
</tr>
<tr>
<td>YEAR</td>
<td>INT</td>
</tr>
<tr>
<td>Character Types</td>
<td>CHAR (up to 256), VARCHAR (up to 262144), BINARY (up to 256), VARBINARY (up to 1048576), ENUM, SET</td>
<td>STRING</td>
</tr>
<tr>
<td>Large Objects</td>
<td>TINYBLOB (up to 255), BLOB (up to 65535), MEDIUMBLOB (up to 16777215), LARGEBLOB (up to 536870910), TINYTEXT (up to 255), TEXT (up to 65535), MEDIUMTEXT (up to 16777215), LARGETEXT (up to 536870910)</td>
<td>STRING</td>
</tr>
<tr>
<td>JSON Type</td>
<td>JSON</td>
<td>STRING</td>
</tr>
<tr>
<td>Spatial Types</td>
<td>GEOMETRY, POINT, LINESTRING, POLYGON, MULTIPOINT, MULTISTRING, MULTIPOLYGON, GEOMETRYCOLLECTION</td>
<td>STRING</td>
</tr>
</tbody>
</table>

### Appendix 2: Pre-Check Item List

| Check Item | Check Content |
| ------------------------ | ----------------------------------------------------------- |
| Source Data Source Check | Check the gateway status of the source data source, instance reachability, and accuracy of username and password |
| Target Data Source Check | Check the gateway status of the target data source, instance reachability, and accuracy of username and password |
| Source Database Permission Check | Check if the account permissions of the source database meet the requirements |
| Target Database Data Existence Check | Check if there is existing data for the objects to be replicated in the target database |

### Appendix 3: System Parameter Description{#appendix4}

To implement incremental data storage in **DataHub**, NineData provides a set of default system parameters and metadata fields to identify data characteristics. Here are the specific meanings and usage scenarios of the system parameters.

| **Parameter Name** | **Meaning and Usage** |
| ------------------------- | ------------------------------------------------------------ |
| ${nd_record_id} | The unique ID for each data record (Record). In UPDATE operations, the record_id must remain the same before and after the update to achieve change association. |
| ${nd_exec_timestamp} | The execution time of the Record operation. |
| ${nd_database_name} | The name of the database to which the table belongs, facilitating data source differentiation. |
| ${nd_table_name} | The name of the table corresponding to the Record, used for precise location of change records. |
| ${nd_operation_type} | The type of Record change operation, with the following values: <ul><li>I: Insert</li><li>U: Update</li><li>D: Delete</li></ul>For full synchronization, all are I. |
| ${nd_before_image} | The before-image identifier, indicating that the target Record status is **before the change occurs**, i.e., the current data has been changed. Values: <ul><li>Y: Before-image.</li><li>N: Not a before-image.</li></ul>For example: INSERT operation is N; DELETE operation is Y; UPDATE operation before is Y, after is N. |
| ${nd_after_image} | The after-image identifier, indicating that the target Record status is **after the change occurs**, i.e., the current data is the latest state. Values: <ul><li>Y: After-image.</li><li>N: Not an after-image.</li></ul>For example: INSERT operation is Y; DELETE operation is N; UPDATE operation before is N, after is Y. |
| ${nd_datasource} | **Data source information**: The IP and port number of the data source, in the format `ip:port`. |

### Related Documentation

[Data Replication Introduction](/replication/intro_repli.md)