|
| 1 | +# Migrate from MySQL |
| 2 | + |
| 3 | +This document will guide you through the migration process from MySQL to GreptimeDB. |
| 4 | + |
| 5 | +## Before you start the migration |
| 6 | + |
| 7 | +Please be aware that though GreptimeDB supports the wire protocol of MySQL, it does not mean GreptimeDB implements all |
| 8 | +MySQL's features. You may refer to the "[ANSI Compatibility](/reference/sql/compatibility.md)" to see the |
| 9 | +constraints regarding using SQL in GreptimeDB. |
| 10 | + |
| 11 | +## Migration steps |
| 12 | + |
| 13 | +### Create the databases and tables in GreptimeDB |
| 14 | + |
| 15 | +Before migrating the data from MySQL, you first need to create the corresponding databases and tables in GreptimeDB. |
| 16 | +GreptimeDB has its own SQL syntax for creating tables, so you cannot directly reuse the table creation SQLs that are produced |
| 17 | +by MySQL. |
| 18 | + |
| 19 | +When you write the table creation SQL for GreptimeDB, it's important to understand |
| 20 | +its "[data model](/user-guide/concepts/data-model.md)" first. Then, please take the following considerations in |
| 21 | +your create table SQL: |
| 22 | + |
| 23 | +1. Since the time index column cannot be changed after the table is created, you need to choose the time index column |
| 24 | + carefully. The time index is best set to the natural timestamp when the data is generated, as it provides the most |
| 25 | + intuitive way to query the data, and the best query performance. For example, in the IOT scenes, you can use the |
| 26 | + collection time of sensor data as the time index; or the occurrence time of an event in the observability scenes. |
| 27 | +2. In this migration process, it's not recommend to create another synthetic timestamp, such as a new column created |
| 28 | + with `DEFAULT current_timestamp()` as the time index column. It's not recommend to use the random timestamp as the |
| 29 | + time index either. |
| 30 | +3. It's vital to set the most fit timestamp precision for your time index column, too. Like the chosen of time index |
| 31 | + column, the precision of it cannot be changed as well. Find the most fit timestamp type for your |
| 32 | + data set [here](/reference/sql/data-types#data-types-compatible-with-mysql-and-postgresql). |
| 33 | +4. Choose the most fit tag columns based on your query patterns. The tag columns store the metadata that is |
| 34 | + commonly queried. The values in the tag columns are labels attached to the collected sources, generally used to |
| 35 | + describe a particular characteristic of these sources. The tag columns are indexed, making queries on them |
| 36 | + performant. |
| 37 | + |
| 38 | +Finally please refer to "[CREATE](/reference/sql/create.md)" SQL document for more details for choosing the |
| 39 | +right data types and "ttl" or "compaction" options, etc. |
| 40 | + |
| 41 | +### Write data to both GreptimeDB and MySQL simultaneously |
| 42 | + |
| 43 | +Writing data to both GreptimeDB and MySQL simultaneously is a practical strategy to avoid data loss during migration. By |
| 44 | +utilizing MySQL's client libraries (JDBC + a MySQL driver), you can set up two client instances - one for GreptimeDB |
| 45 | +and another for MySQL. For guidance on writing data to GreptimeDB using SQL, please refer to the [Ingest Data](/user-guide/ingest-data/for-iot/sql.md) section. |
| 46 | + |
| 47 | +If retaining all historical data isn't necessary, you can simultaneously write data to both GreptimeDB and MySQL for a |
| 48 | +specific period to accumulate the required recent data. Subsequently, cease writing to MySQL and continue exclusively |
| 49 | +with GreptimeDB. If a complete migration of all historical data is needed, please proceed with the following steps. |
| 50 | + |
| 51 | +### Export data from MySQL |
| 52 | + |
| 53 | +[mysqldump](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html) is a commonly used tool to export data from MySQL. |
| 54 | +Using it, we can export the data that can be later imported into GreptimeDB directly. For example, if we want to export |
| 55 | +two databases, `db1` and `db2` from MySQL, we can use the following command: |
| 56 | + |
| 57 | +```bash |
| 58 | +mysqldump -h127.0.0.1 -P3306 -umysql_user -p --compact -cnt --skip-extended-insert --databases db1 db2 > /path/to/output.sql |
| 59 | +``` |
| 60 | + |
| 61 | +Replace the `-h`, `-P` and `-u` flags with the appropriate values for your MySQL server. The `--databases` flag is used |
| 62 | +to specify the databases to be exported. The output will be written to the `/path/to/output.sql` file. |
| 63 | + |
| 64 | +The content in the `/path/to/output.sql` file should be like this: |
| 65 | + |
| 66 | +```plaintext |
| 67 | +~ ❯ cat /path/to/output.sql |
| 68 | +
|
| 69 | +USE `db1`; |
| 70 | +INSERT INTO `foo` (`ts`, `a`, `b`) VALUES (1,'hello',1); |
| 71 | +INSERT INTO ... |
| 72 | +
|
| 73 | +USE `db2`; |
| 74 | +INSERT INTO `foo` (`ts`, `a`, `b`) VALUES (2,'greptime',2); |
| 75 | +INSERT INTO ... |
| 76 | +``` |
| 77 | + |
| 78 | +### Import data into GreptimeDB |
| 79 | + |
| 80 | +The [MySQL Command-Line Client](https://dev.mysql.com/doc/refman/8.4/en/mysql.html) can be used to import data into |
| 81 | +GreptimeDB. Continuing the above example, say the data is exported to file `/path/to/output.sql`, then we can use the |
| 82 | +following command to import the data into GreptimeDB: |
| 83 | + |
| 84 | +```bash |
| 85 | +mysql -h127.0.0.1 -P4002 -ugreptime_user -p -e "source /path/to/output.sql" |
| 86 | +``` |
| 87 | + |
| 88 | +Replace the `-h`, `-P` and `-u` flags with the appropriate values for your GreptimeDB server. The `source` command is |
| 89 | +used to execute the SQL commands in the `/path/to/output.sql` file. Add `-vvv` to see the detailed execution results for |
| 90 | +debugging purpose. |
| 91 | + |
| 92 | +To summarize, data migration steps can be illustrate as follows: |
| 93 | + |
| 94 | + |
| 95 | + |
| 96 | +After the data migration is completed, you can stop writing data to MySQL and continue using GreptimeDB exclusively! |
0 commit comments