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 は、TiDB がサポートしていない一部のデータ型 ( UUID 、 INET4 、およびINET6など) をサポートします。

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

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 Lightningの構成方法と実行方法の詳細については、 TiDB Lightningを始めましょうを参照してください。

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

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

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

DMを使用してデータをレプリケートする

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

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

注記：

これを本番で実行する前に、まずアプリケーションのテスト インスタンスまたは開発インスタンスでこれを実行することを強くお勧めします。これは、互換性の問題の可能性を確認することと、移行にかかる時間を把握することの両方を目的としています。

ステップ 1. 準備する

MariaDB でバイナリログが有効になっていて、 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 ツールキットの一部です。

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

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

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

データの検証

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

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