これはアーカイブされた TiDB のドキュメントであり、更新は行われていません。最新の LTS バージョンのドキュメントを表示する ↗
TiDB Self-Managed

MySQL にシンク

このドキュメントでは、 Sink to MySQL changefeed を使用してTiDB Cloudから MySQL にデータをストリーミングする方法について説明します。

ノート：

Changefeed 機能を使用するには、TiDB クラスターのバージョンが v6.4.0 以降であり、TiKV ノードのサイズが少なくとも 8 vCPU および 16 GiB であることを確認してください。

現在、 TiDB Cloudでは、クラスターごとに最大 10 個の変更フィードしか許可されていません。

サーバーレス階層クラスターの場合、変更フィード機能は使用できません。

前提条件

通信網

TiDBクラスタが MySQL サービスに接続できることを確認してください。

MySQL サービスがパブリック インターネット アクセスのない AWS VPC にある場合は、次の手順を実行します。

  1. MySQL サービスの VPC と TiDB クラスターの間のVPC ピアリング接続を設定する 。

  2. MySQL サービスが関連付けられているセキュリティ グループの受信ルールを変更します。

    インバウンド規則にTiDB Cloudクラスターが配置されているリージョンの CIDRを追加する必要があります。そうすることで、トラフィックが TiDBクラスタから MySQL インスタンスに流れるようになります。

  3. MySQL URL にホスト名が含まれている場合、 TiDB Cloudが MySQL サービスの DNS ホスト名を解決できるようにする必要があります。

    1. VPC ピアリング接続の DNS 解決を有効にするの手順に従います。
    2. Accepter DNS 解決オプションを有効にします。

MySQL サービスがパブリック インターネット アクセスのない GCP VPC にある場合は、次の手順を実行します。

  1. MySQL サービスが Google Cloud SQL の場合、Google Cloud SQL インスタンスの関連付けられた VPC で MySQL エンドポイントを公開する必要があります。 Google が開発したCloud SQL 認証プロキシを使用する必要がある場合があります。

  2. MySQL サービスの VPC と TiDB クラスターの間のVPC ピアリング接続を設定する 。

  3. MySQL が配置されている VPC のイングレス ファイアウォール ルールを変更します。

    イングレス ファイアウォール ルールにTiDB Cloudクラスターが配置されているリージョンの CIDRを追加する必要があります。そうすることで、トラフィックが TiDBクラスタから MySQL エンドポイントに流れるようになります。

全負荷データ

Sink to MySQLコネクタは、特定のタイムスタンプの後にのみ、TiDB クラスターから MySQL に増分データをシンクできます。 TiDB クラスターに既にデータがある場合は、 Sink to MySQLを有効にする前に、TiDB クラスターの全ロード データをエクスポートして MySQL にロードする必要があります。

  1. 次の 2 つの操作の合計時間よりも長くなるようにtidb_gc_life_timeを拡張して、その間の履歴データが TiDB によってガベージ コレクションされないようにします。

    • 全負荷データをエクスポートおよびインポートする時間
    • Sink to MySQLを作成する時間

    例えば：

    SET GLOBAL tidb_gc_life_time = '720h';

  2. Dumplingを使用して TiDB クラスターからデータをエクスポートし、 マイダンパー/マイローダーなどのコミュニティ ツールを使用してデータを MySQL サービスにロードします。

  3. Dumplingのエクスポートファイルから、メタデータ ファイルから MySQL シンクの開始位置を取得します。

    以下は、メタデータ ファイルの例の一部です。 Pos of SHOW MASTER STATUSは全ロード データの TSO であり、MySQL シンクの開始位置でもあります。

    Started dump at: 2020-11-10 10:40:19
SHOW MASTER STATUS:
        Log: tidb-binlog
        Pos: 420747102018863124
Finished dump at: 2020-11-10 10:40:20

MySQL シンクを作成する

前提条件を完了したら、データを MySQL にシンクできます。

  1. TiDB クラスターのChangefeedタブに移動します。

  2. Create Changefeedをクリックし、ターゲット タイプとしてMySQLを選択します。

  3. MySQL Connectionに MySQL エンドポイント、ユーザー名、およびパスワードを入力します。

  4. [次へ] をクリックして、TiDB が MySQL に正常に接続できるかどうかをテストします。

    • はいの場合、構成の次のステップに進みます。
    • そうでない場合は、接続エラーが表示され、エラーを処理する必要があります。エラーが解決したら、もう一度 [次へ] をクリックします。

  5. テーブル フィルタをカスタマイズして、複製するテーブルをフィルタリングします。ルールの構文については、 テーブル フィルター規則を参照してください。

    • フィルター ルールの追加: この列でフィルター ルールを設定できます。デフォルトでは、すべてのテーブルをレプリケートすることを表すルール*. *があります。新しいルールを追加すると、 TiDB Cloudは TiDB 内のすべてのテーブルに対してクエリを実行し、右側のボックスのルールに一致するテーブルのみを表示します。
    • レプリケートされるテーブル: この列は、レプリケートされるテーブルを示します。ただし、将来レプリケートされる新しいテーブルや、完全にレプリケートされるスキーマは表示されません。
    • 有効なキーのないテーブル : この列には、一意キーと主キーのないテーブルが表示されます。これらのテーブルでは、重複イベントを処理するためにダウンストリーム システムで一意の識別子を使用できないため、レプリケーション中にデータの一貫性が失われる可能性があります。このような問題を回避するには、レプリケーションの前にこれらのテーブルに一意のキーまたは主キーを追加するか、これらのテーブルを除外するフィルター ルールを設定することをお勧めします。たとえば、「!test.tbl1」を使用してテーブルtest.tbl1を除外できます。

  6. [開始位置]で、MySQL シンクの開始位置を構成します。

    • Dumplingを使用して全負荷データを実行した場合は、[**特定の TSO からレプリケーションを開始する] を**選択し、エクスポートされたDumplingメタデータ ファイルから取得した TSO を入力します。
    • 上流の TiDB クラスターにデータがない場合は、[**今からレプリケーションを開始する] を選択し**ます。
    • それ以外の場合は、 [Start replication from a specific time]を選択して開始時点をカスタマイズできます。

  7. [次へ] をクリックして、Changefeed 構成を確認します。

    すべての構成が正しいことを確認したら、クロスリージョン レプリケーションのコンプライアンスを確認し、 [作成] をクリックします。

    一部の構成を変更する場合は、[前へ] をクリックして前の構成ページに戻ります。

  8. シンクはすぐに開始され、シンクのステータスが「作成中」から「実行中」に変化することがわかります。

    [ Sink to MySQL ] カードをクリックすると、チェックポイント、レプリケーションレイテンシー、およびその他のメトリックを含む、Changfeed の実行ステータスがポップアップ ウィンドウに表示されます。

  9. Dumplingを使用して全負荷データを実行した場合は、シンクの作成後に GC 時間を元の値 (デフォルト値は10m ) に戻す必要があります。

SET GLOBAL tidb_gc_life_time = '10m';

制限

  • TiDB Cloudクラスターごとに、最大 10 個の変更フィードを作成できます。
  • TiDB Cloudは TiCDC を使用して変更フィードを確立するため、同じTiCDCとしての制限を持ちます。