TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

MariaDB から TiDB へのデータの移行

このドキュメントでは、MariaDBサーバーインストールから TiDB クラスターにデータを移行する方法について説明します。

前提条件

適切な移行戦略を選択してください。

これら 2 つの戦略の他に、状況に応じて利用できる他の戦略があるかもしれません。たとえば、次のようになります。

  • オブジェクト リレーショナル マッピング (ORM) の機能を使用して、データを再デプロイおよび移行します。
  • 移行の進行中に MariaDB と TiDB の両方から書き込むようにアプリケーションを変更します。

このドキュメントでは、最初の 2 つの戦略についてのみ説明します。

選択した戦略に基づいて、次のものを準備します。

  • ダンプと復元の戦略の場合:
    • DumplingとTiDB Lightningインストールします。
    • Dumpling がデータをエクスポートするには、MariaDBサーバーに必要な権限あることを確認してください。
  • データ複製戦略については、 データ移行 (DM)設定します。

互換性を確認する

TiDB はMySQLと互換性ありであり、MySQL と MariaDB には多くの共通機能があります。ただし、移行前に知っておくべき、TiDB と互換性がない MariaDB 固有の機能がある可能性があります。

このセクションの項目を確認するだけでなく、MariaDB ドキュメントの互換性と相違点も確認することをお勧めします。

認証

MySQL とのSecurity互換性ドキュメントには、TiDB がサポートする認証方法がリストされています。TiDB は MariaDB のいくつかの認証方法をサポートしていません。つまり、アカウントに新しいパスワード ハッシュを作成するか、その他の特定の対策を講じる必要がある場合があります。

使用されている認証方法を確認するには、次のステートメントを実行します。

SELECT
  plugin,
  COUNT(*)
FROM
  mysql.user
GROUP BY
  plugin;

+-----------------------+----------+
| plugin                | COUNT(*) |
+-----------------------+----------+
| mysql_native_password |       11 |
+-----------------------+----------+
1 row in set (0.002 sec)

システムバージョン管理されたテーブル

TiDB はシステムバージョン管理されたテーブルサポートしていません。ただし、TiDB はAS OF TIMESTAMPサポートしており、システム バージョン管理されたテーブルの使用例の一部を置き換える可能性があります。

次のステートメントを使用して、影響を受けるテーブルを確認できます。

SELECT
  TABLE_SCHEMA,
  TABLE_NAME
FROM
  information_schema.tables
WHERE
  TABLE_TYPE='SYSTEM VERSIONED';

+--------------+------------+
| TABLE_SCHEMA | TABLE_NAME |
+--------------+------------+
| test         | t          |
+--------------+------------+
1 row in set (0.005 sec)

システムのバージョン管理を削除するには、次のALTER TABLEステートメントを実行します。

MariaDB [test]> ALTER TABLE t DROP SYSTEM VERSIONING;
Query OK, 0 rows affected (0.071 sec)
Records: 0  Duplicates: 0  Warnings: 0

シーケンス

MariaDB と TiDB はどちらもCREATE SEQUENCEサポートしています。ただし、現在 DM ではサポートされていません。移行中にシーケンスを作成、変更、または削除せず、移行後にこれを特にテストすることをお勧めします。

シーケンスを使用しているかどうかを確認するには、次のステートメントを実行します。

SELECT
  TABLE_SCHEMA,
  TABLE_NAME
FROM
  information_schema.tables
WHERE
  TABLE_TYPE='SEQUENCE';

+--------------+------------+
| TABLE_SCHEMA | TABLE_NAME |
+--------------+------------+
| test         | s1         |
+--------------+------------+
1 row in set (0.016 sec)

ストレージエンジン

MariaDB は、 InnoDB 、 MyISAM 、 Ariaなどのローカル データ用のstorageエンジンを提供しています。データ形式は TiDB では直接サポートされていませんが、これらの移行は問題なく機能します。ただし、 CONNECTstorageエンジンやSpiderなど、一部のエンジンはサーバーの外部にデータを配置します。このようなテーブルを TiDB に移行することはできますが、TiDB は TiDB クラスターの外部にデータを保存する機能を提供していません。

使用しているstorageエンジンを確認するには、次のステートメントを実行します。

SELECT
  ENGINE,
  COUNT(*)
FROM
  information_schema.tables
GROUP BY
  ENGINE;

+--------------------+----------+
| ENGINE             | COUNT(*) |
+--------------------+----------+
| NULL               |      101 |
| Aria               |       38 |
| CSV                |        2 |
| InnoDB             |        6 |
| MEMORY             |       67 |
| MyISAM             |        1 |
| PERFORMANCE_SCHEMA |       81 |
+--------------------+----------+
7 rows in set (0.009 sec)

構文

MariaDB は、 DELETE 、 INSERT 、およびREPLACEステートメントに対してRETURNINGキーワードをサポートしています。TiDB はそれらをサポートしていません。アプリケーションとクエリのログを調べて、移行に影響があるかどうかを確認することをお勧めします。

データ型

MariaDB は、 UUID 、 INET4 、 INET6など、TiDB がサポートしていないいくつかのデータ型をサポートしています。

これらのデータ型を確認するには、次のステートメントを実行します。

SELECT
  TABLE_SCHEMA,
  TABLE_NAME,
  COLUMN_NAME,
  DATA_TYPE
FROM
  information_schema.columns
WHERE
  DATA_TYPE IN('INET4','INET6','UUID');

+--------------+------------+-------------+-----------+
| TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | DATA_TYPE |
+--------------+------------+-------------+-----------+
| test         | u1         | u           | uuid      |
| test         | u1         | i4          | inet4     |
| test         | u1         | i6          | inet6     |
+--------------+------------+-------------+-----------+
3 rows in set (0.026 sec)

文字セットと照合順序

TiDB は、MariaDB でよく使用されるlatin1_swedish_ci照合順序をサポートしていません。

TiDB がサポートする照合順序を確認するには、TiDB で次のステートメントを実行します。

SHOW COLLATION;

+--------------------+---------+-----+---------+----------+---------+
| Collation          | Charset | Id  | Default | Compiled | Sortlen |
+--------------------+---------+-----+---------+----------+---------+
| ascii_bin          | ascii   |  65 | Yes     | Yes      |       1 |
| binary             | binary  |  63 | Yes     | Yes      |       1 |
| gbk_bin            | gbk     |  87 |         | Yes      |       1 |
| gbk_chinese_ci     | gbk     |  28 | Yes     | Yes      |       1 |
| latin1_bin         | latin1  |  47 | Yes     | Yes      |       1 |
| utf8_bin           | utf8    |  83 | Yes     | Yes      |       1 |
| utf8_general_ci    | utf8    |  33 |         | Yes      |       1 |
| utf8_unicode_ci    | utf8    | 192 |         | Yes      |       1 |
| utf8mb4_0900_ai_ci | utf8mb4 | 255 |         | Yes      |       1 |
| utf8mb4_0900_bin   | utf8mb4 | 309 |         | Yes      |       1 |
| utf8mb4_bin        | utf8mb4 |  46 | Yes     | Yes      |       1 |
| utf8mb4_general_ci | utf8mb4 |  45 |         | Yes      |       1 |
| utf8mb4_unicode_ci | utf8mb4 | 224 |         | Yes      |       1 |
+--------------------+---------+-----+---------+----------+---------+
13 rows in set (0.0012 sec)

現在のテーブルの列が使用している照合順序を確認するには、次のステートメントを使用できます。

SELECT
  TABLE_SCHEMA,
  COLLATION_NAME,
  COUNT(*)
FROM
  information_schema.columns
GROUP BY
  TABLE_SCHEMA, COLLATION_NAME
ORDER BY
  COLLATION_NAME;

+--------------------+--------------------+----------+
| TABLE_SCHEMA       | COLLATION_NAME     | COUNT(*) |
+--------------------+--------------------+----------+
| sys                | NULL               |      562 |
| test               | NULL               |       14 |
| mysql              | NULL               |       84 |
| performance_schema | NULL               |      892 |
| information_schema | NULL               |      421 |
| mysql              | latin1_swedish_ci  |       34 |
| performance_schema | utf8mb3_bin        |       38 |
| mysql              | utf8mb3_bin        |       61 |
| sys                | utf8mb3_bin        |       40 |
| information_schema | utf8mb3_general_ci |      375 |
| performance_schema | utf8mb3_general_ci |      244 |
| sys                | utf8mb3_general_ci |      386 |
| mysql              | utf8mb3_general_ci |       67 |
| mysql              | utf8mb4_bin        |        8 |
+--------------------+--------------------+----------+
14 rows in set (0.045 sec)

文字セットと照合順序も参照してください。

Dumplingでデータをダンプし、 TiDB Lightningでデータを復元する

この方法では、アプリケーションをオフラインにしてデータを移行し、移行したデータを使用するようにアプリケーションを再構成することを前提としています。

注記：

これを本番で行う前に、まずアプリケーションのテストまたは開発インスタンスで実行することを強くお勧めします。これは、互換性の問題が発生する可能性をチェックするとともに、移行にかかる時間を把握するためです。

MariaDB から TiDB にデータを移行するには、次の手順を実行します。

  1. アプリケーションを停止します。アプリケーションをオフラインにします。これにより、移行中または移行後に MariaDB のデータが変更されないことが保証されます。

  2. tiup dumplingコマンドで MariaDB にデータをダンプします。

    tiup dumpling --port 3306 --host 127.0.0.1 --user root --password secret -F 256MB  -o /data/backup

  3. tiup tidb-lightningコマンドを使用してデータを復元します。TiDB TiDB Lightning の設定方法と実行方法の詳細については、 TiDB Lightningを使い始める参照してください。

  4. ユーザー アカウントと権限を移行します。ユーザーと権限を移行する方法の詳細については、 ユーザーと権限をエクスポートする参照してください。

  5. アプリケーションを再構成します。TiDBサーバーに接続できるように、アプリケーション構成を変更する必要があります。

  6. クリーンアップします。移行が成功したことを確認したら、MariaDB のデータの最終バックアップを作成し、サーバーを停止します。これは、 TiUP、 Dumpling、 TiDB Lightningなどのツールを削除できることも意味します。

DMでデータを複製する

この方法では、レプリケーションを設定し、アプリケーションを停止してレプリケーションが追いつくのを待ってから、TiDB を使用するようにアプリケーションを再構成することを前提としています。

DM を使用するには、 TiUPクラスターまたはTiDB Operatorを使用して DM サービスのセットを展開する必要があります。その後、 dmctl使用して DM サービスを構成します。

注記：

これを本番で行う前に、まずアプリケーションのテストまたは開発インスタンスで実行することを強くお勧めします。これは、互換性の問題が発生する可能性をチェックするとともに、移行にかかる時間を把握するためです。

ステップ1.準備

MariaDB で binlogs が有効になっており、 binlog_format ROWに設定されていることを確認してください。 binlog_annotate_row_events=OFFとlog_bin_compress=OFF設定することも推奨されます。

また、 SUPER権限またはBINLOG MONITORおよびREPLICATION MASTER ADMIN権限を持つアカウントも必要です。このアカウントには、移行するスキーマの読み取り権限も必要です。

SUPER権限を持つアカウントを使用していない場合、TiDB はまだ MariaDB 固有の権限を確認する方法を知らないため、DM 構成に以下を追加する必要がある可能性があります。

ignore-checking-items: ["replication_privilege"]

DMを使用して上流から下流にデータを移行する前に、事前チェックを行うことで上流のデータベース構成のエラーを検出し、移行がスムーズに進むようにします。詳細については、 移行タスクの事前チェック参照してください。

ステップ2. データを複製する

TiDB データ移行のクイック スタート ガイドに従って、MariaDB から TiDB にデータを複製します。

MariaDB から MariaDB へのレプリケーションの場合のように、最初に初期データをコピーする必要はなく、DM がこれを実行します。

ステップ3. ユーザーアカウントと権限を移行する

ユーザーと権限を移行する方法については、 ユーザーと権限をエクスポートする参照してください。

ステップ4. データをテストする

データが複製されたら、読み取り専用クエリを実行して検証することができます。詳細については、 アプリケーションをテストする参照してください。

ステップ5. 切り替える

TiDB に切り替えるには、次の手順を実行する必要があります。

  1. アプリケーションを停止します。
  2. レプリケーションの遅延を監視します。遅延は 0 秒になるはずです。
  3. アプリケーションが TiDB に接続するように構成を変更し、再度起動します。

レプリケーションの遅延を確認するには、 query-status <taskname>からdmctlを実行し、 subTaskStatusで"synced: true"を確認します。

ステップ6. クリーンアップ

移行が成功したことを確認したら、MariaDB のデータの最終バックアップを作成し、サーバーを停止できます。また、DM クラスターを停止して削除することもできます。

ユーザーと権限をエクスポートする

pt-show-grants使用できます。これは、MariaDB からユーザーと権限をエクスポートし、TiDB にロードするための Percona Toolkit の一部です。

アプリケーションをテストする

テストにはsysbenchなどの汎用ツールを使用することもできますが、アプリケーションの特定の機能をテストすることを強くお勧めします。たとえば、データの一時コピーを使用して、アプリケーションのコピーを TiDB クラスターに対して実行します。

このようなテストにより、アプリケーションの互換性と TiDB とのパフォーマンスが検証されます。対処が必要な警告があるかどうかを確認するには、アプリケーションと TiDB のログ ファイルを監視する必要があります。アプリケーションが使用しているデータベース ドライバー ( Javaベースのアプリケーションの場合は MySQL Connector/J など) がテストされていることを確認してください。必要に応じて、JMeter などのアプリケーションを使用してアプリケーションに負荷をかけることもできます。

データを検証する

同期差分インスペクター使用して、MariaDB と TiDB のデータが同一であるかどうかを検証できます。

このページは役に立ちましたか？