転生じゃなかった・・・移行したら「TiDB Cloud Dedicated」だった件

本記事は TiDB Advent Calendar 2024 23日目の記事です。

あらすじ

「データってさ、分散とかしなくても意外とイケるっしょ？」
データの管理？それくらい俺に任せとけと豪語していた平凡なデータベースサーバーだったが、突如現れた謎の鬼強ブラッククエリ軍団に押し潰されてあえなくクラッシュ。。。

「俺の人生、SQLに捧げただけだったな……」と思ったその瞬間、謎の声が響く。

「あなたの新しい人生、TiDBの世界で頑張ってみませんか？」

次に目覚めると、なんと「TiDB Cloud Dedicated」に移行していた！！

あれ。。。体はクラスタ構成、心は水平スケーリング、え？？
なぜか全身が分散システムでできていて、色々とチート級のスキルを持つ俺。

しかもNewSQLだし「俺って、強くね？」とこれは夢か・・・いやいや夢ではないこれは現実だ！！と気づくと同時に自信に満ち溢れていった。・・・続く

はじめに

どうも！！urachoooooooです！！！

あらすじはさておきTiDB Cloud Dedicatedへ移行するための簡単な手順を載せていきますーー！！
（今回はサクッと書くのみです）

転生・・・ではなく移行の手順

今回使用するCloudプロバイダは「AWS」です！！

TiUP環境を作る

まずはお馴染みの「tiup」をインストールしてから、「dumpling」や「sync_diff_inspector」をインストールしていきます。
尚、今回「tidb-lightning」はマネージドを使用するのでインストールしないです。
（MySQLクライアントはインストールしておくと便利ですー）

やること

移行に必要なツールをインストール

手順で必要なもの

• tiup
• dumpling
• sync_diff_inspector

手順

• tiup

  インストール

  curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
  source /home/ec2-user/.bash_profile
  

• dumpling

  インストール

  tiup install dumpling
  

• sync_diff_inspector

  パラメータ（環境に合わせてください）

  TIDB_VERSION="v8.1.1"
  ARCH="amd64"
  

  インストール

  wget https://download.pingcap.org/tidb-community-toolkit-${TIDB_VERSION}-linux-${ARCH}.tar.gz
  tar zxvf tidb-community-toolkit-${TIDB_VERSION}-linux-${ARCH}.tar.gz
  
  echo "export PATH=$PATH:/home/ec2-user/.tiup/tidb-community-toolkit-${TIDB_VERSION}-linux-${ARCH}" >> ~/.bash_profile
  source ~/.bash_profile
  
  sync_diff_inspector --version
  

  • TIDB_VERSION：使用しているTiDB Cloud Dedicatedのバージョンに合わせる
  • ARCH：使用環境に合わせる

PrivateLinkでVPCと繋げる

TiDB Cloud Dedicatedへの接続はVPCピアリングとPrivateLinkの接続が可能になりますが、今回は「PrivateLink」で接続していきます

やること

AWSとTiDBのVPCの接続の確立

手順で必要なもの

• TiDB
  • service-name
• AWS
  • VPC ID
  • サブネットID
  • セキュリティグループID
  • VPCエンドポイントID

手順

【①TiDBでの作業】

1. TiDB Cloudコンソールを使用して対象のClusterの接続設定へ移動

• TiDB Cloudコンソールを開き、対象のClusterを選択する
• 「Connect」ボタンを押下する
• 表示された接続オプションから「Private Endpoint」を選択し、「Create Private Endpoint Connection」ボタンを押下する

2. TiDBのサービス生成を待機

• 「Private Endpoint Connection」の作成処理が開始
  • 「TiDBのサービス」が生成されるまで待機する

3. PrivateLinkの準備が完了したらAWS情報を入力

• PrivateLinkの準備が整ったら、AWSの「VPC ID」と「サブネットID」を入力する
• 入力した情報を基に、AWS CLIで使用するコマンドが生成されます

4. サービス名を控える

• 生成されたサービス名が以下の形式で表示されます
  • 「com.amazonaws.vpce.xx-xxxx-x.vpce-svc-xxxxxxxxxxxxxxxxx」の様な形式です

【②AWSでの作業】

5. AWSマネジメントコンソールを使用してVPCエンドポイント作成へ移動

• AWSマネジメントコンソールを開き、「VPC」を選択する
• メニューから「エンドポイント」を選択し、「エンドポイントを作成」ボタンを押下する

6. TiDBのサービス名を使用して検証

• TiDB Cloudで控えた「service-name」を使用して、サービスの検証を行う

7. ネットワークの設定

• 使用する「VPC ID」、「サブネットID」と「セキュリティグループID」を設定する

• 必要な項目を入力後、「エンドポイントを作成」ボタンを押下する

  TiDB Cloud Serverlessとは異なり、追加設定でDNSの有効化はここではしない。有効化すると作成時にエラーになります

8. VPCエンドポイントIDを控える

• 作成されたVPCエンドポイントのIDを控える（このIDは次に行うTiDBの設定で必要になります）

【③TiDBでの作業】

9. AWSのプライベートエンドポイントへの接続

TiDBのサービス名を控えた所から引き続き実施していきます

• AWSで控えた「VPCエンドポイントID」を設定してAWSのプライベートエンドポイントへの接続を作成する
  • 接続するとAWSで作成したエンドポイントのステータスが保留中に変更
• しばらくするとAWSのプライベートエンドポイントへの接続が完了する
  • TiDBへの様々な接続方法が表示される様になります

【④AWSでの作業】

10. エンドポイントの有効化

AWSで作成したエンドポイントのステータスが「保留中」から「使用可能」になったことを確認してください

• プライベートDNS名を変更するから「このエンドポイントで有効にする」にチェックを入れて変更を保存する
• ステータスが「保留中」から「使用可能」になったことを確認する

【⑤TiDBでの作業】

11. 接続確認

• 対象のClusterへ接続できることを確認する

  mysql --comments -u 'root' -h privatelink-xxxxxxxx.xxxxxxxxxxxx.clusters.tidb-cloud.com -P 4000 -D 'test' -p'<PASSWORD>'
  

TiDBからS3への接続許可設定

dumplingとTiDB Lightning（マネージド）を使用したデータ移行を行うためにdumplingを使用したインポートの許可とLightningを使用したエクスポートの許可を行う必要があるためその設定を行います

やること

TiDBからAWS S3へのアクセス許可設定

手順で必要なもの

• TiDB
  • TiDB Cloud Account ID
  • TiDB Cloud External ID
• AWS
  • S3のARN
  • S3ロールのARN

手順

事前にS3バケットとフォルダの作成を行なっておいてください

【①TiDBでの作業】

1. TiDB Cloud Dedicatedのクラスターを選択

• TiDB Cloudコンソールで対象のDedicatedクラスターを選択する
• 「Import」メニューを選択し、「S3からデータをインポート」を選択する

2. TiDB Cloudアカウント情報の取得

• TiDB Cloudから「TiDB Cloud Account ID」と「TiDB Cloud External ID」を取得する
• 取得した「TiDB Cloud Account ID」と「TiDB Cloud External ID」を控える

【②AWSでの作業】

3. S3のARNをコピー

• 対象のS3バケットのARNを確認し、コピーする

4. IAMポリシーを作成

• S3アクセス許可を設定するIAMポリシーを作成する
  • ActionにS3バケットへの必要なアクセス権限を設定
  • Resourceに「S3のARN」を設定

5. IAMロールを作成

• IAMロールを作成する
  • 作成時に、控えた「TiDB Cloud Account ID」と「TiDB Cloud External ID」を使用して設定
  • 作成したIAMポリシーをこのロールにアタッチする

6. IAMロールのARNをコピー

• 作成した「S3ロールのARN」を控える（このARNは次に行うTiDBの設定で必要になります）

TiDB Cloud Dedicatedへデータ移行

上記手順でデータを移行する事前準備が整ったためデータを移行していきます。

DumplingからS3へSQL形式でアップロードして、TiDB Clooud Dedicatedのインポート（TiDB Lightning：physical）を使用してデータ移行を行います。

データ移行の対象はTiDBとの互換性のあるMySQLやAuroraのデータベースから移行する想定です

やること

TiDBとの互換性のあるデータベースからTiDB Cloud Dedicatedへのデータ移行

手順で必要なもの

• TiDBへ移行するためのテーブル定義
• S3へアクセスするための捨てのアクセスキー
• S3のURL
• S3ロールのARN
• dumplingの移行対象マッピング

手順

• TiDB Cloud Dedicatedを使用するには事前にクレジットカードの登録或いは、AWSマーケットプレイスへの設定を行なう必要があります

1. TiDB Cloud Dedicated作成

• TiDB Cloud Dedicatedの設定
  • Choose a Tier：Dedicated
  • Cloud Provider：AWS
  • Region：環境に合わせて設定
  • ストレージ：環境に合わせて設定
  • Cluster Size
    • TiDB Node：環境に合わせて設定
    • TiKV Node：環境に合わせて設定（3台1グループでスケール）
• 作成する
  • 上記設定を確認後、TiDB Cloud Dedicatedクラスターを作成する

2. TiDB用テーブル定義作成

• mysqldumpやdumplingを使用してテーブル定義を取得する
• AUTO_INCREMENTをAUTO_RANDOMに変更するなどTiDBのホットスポットを回避する設定を事前に行う

3. TiDBへテーブル定義をリストア

• データベースを作成する
• 作成したテーブル定義をリストアする

4. 移行元のデータをエクスポート

• 「xxx」を環境に合わせて設定してください
• FILE_TYPEは「sql」で設定していますが「csv」でもどちらでもOKです
• CONSISTENCYは「auto」にしていますが必要に応じて設定してください
• OUTPUTは「S3のURL」を設定してください

• 捨てのアクセスキーを環境変数へ登録する

  export　AWS_ACCESS_KEY_ID=xxx
  export AWS_SECRET_ACCESS_KEY=xxx
  export AWS_REGION=xxx
  

• パラメータ

  HOST_NAME="xxx"          # 移行元のホスト名
  USER="xxx"               # 移行元のユーザー名
  PASS="xxx"               # 移行元のパスワード
  PORT=3306                # 移行元のポート番号
  DATABASE="xxx"           # エクスポートするデータベース名
  FILE_TYPE="sql"          # ファイル形式 (SQL または CSV)
  THREADS=xxx              # スレッド数
  ROWS=xxx                 # テーブル内同時実行数
  CONSISTENCY="auto"       # 一貫性設定
  OUTPUT="s3://xxx"        # エクスポート先S3のURL
  

  • --no-schemas：テーブル定義なし
  • -t（--threads）：コア数に合わせる
  • -r（--rows）：テーブル内同時実行数（0無効、1以上は有効）
  • -B（--database）：指定されたデータベースをエクスポートする
    • 複数選択する場合は「--filter」を使用する
• コマンド

  time tiup dumpling --no-schemas -u${USER} -p${PASS} -P${PORT} -h${HOST_NAME} --database ${DATABASE} --filetype ${FILE_TYPE} --threads ${THREADS} --rows ${ROWS} --consistency ${CONSISTENCY} --output ${OUTPUT} -F256MiB
  

5. S3のデータをインポート

TiDBのデータが0件であることを確認する
（移行先のデータが存在する場合は削除する）

• TiDB Cloud Dedicatedのインポート設定を行いConnectボタンを押下する
  • インポート設定
    • スキーマ：なし
    • フォーマット：SQL
    • フォルダーURI：S3のURL
    • Role ARN：S3ロールのARN
• 移行対象のテーブルにチェックを入れ、「Start Import」を押下してインポートを開始する
• ステータスが「Completed」になることを確認する

移行データチェック

TiDB Cloud Dedicatedのインポート（Lightning）で移行した場合でもテーブル定義のチェックやデータの整合性は行うのですが、おまけとして「sync_diff_inspector」でもチェックを行なっていきます（通常はインポート時にエラーになった場合にどこでエラーになったのか？を特定する場合に使うと良いかと思います！！）

やること

データ移行元と移行先のテーブル定義とデータを比較

手順で必要なもの

• sync_diff_inspectorのTOML

手順

• 実行

  time sync_diff_inspector --config=sync_diff_inspector.toml
  

• TOMLサンプル（xxxを環境に合わせて設定する）
  sync_diff_inspector.toml

  # Diff Configuration.
  
  ######################### Global config #########################
  # The number of goroutines created to check data. 
  # The number of connections between sync-diff-inspector 
  # and upstream/downstream databases is slightly greater than this value.
  check-thread-count = xxx
  
  # If enabled, SQL statements is exported to fix inconsistent tables.
  # 有効にすると、矛盾したテーブルを修正するためにSQLステートメントがエクスポートされます。
  export-fix-sql = true
  
  # Only compares the table structure instead of the data.
  # データではなくテーブル構造のみを比較します。
  check-struct-only = false
  
  # If enabled, sync-diff-inspector skips checking tables that do not exist in the upstream or downstream.
  # 有効にすると、sync-diff-inspectorはアップストリームまたはダウンストリームに存在しないテーブルのチェックをスキップします。
  skip-non-existing-table = false
  
  ######################### Datasource config #########################
  [data-sources]
  [data-sources.mysql]
  host = "xxx"
  port = 3306
  user = "xxx"
  password = "xxx"
  
  [data-sources.tidb]
  host = "xxx"
  port = 4000
  user = "xxx"
  password = "xxx"
  
  ######################### task config #########################
  # Configures the tables of the target database that need to be compared.
  [task]
  # output-dir saves the following information:
  output-dir = "/var/tmp/sync_diff_inspector_output"
  
  # The upstream database. The value is the unique ID declared by data-sources.
  source-instances = ["mysql"]
  
  # The downstream database. The value is the unique ID declared by data-sources.
  target-instance = "tidb"
  
  # The tables of downstream databases to be compared. Each table needs to contain the schema name and the table name, separated by '.'
  # Use "?" to match any character and "*" to match characters of any length.
  # For detailed match rules, refer to golang regexp pkg: https://github.com/google/re2/wiki/Syntax.
  target-check-tables = ["database.*"]
  
  ######################### Table config #########################
  # Special configurations for specific tables. The tables to be configured must be in `task.target-check-tables`.
  # config1  is the only custom ID for this configuration. It is used for the above `task.target-configs` configuration.
  [table-configs.config1] 
  # The name of the target table, you can use regular expressions to match multiple tables, but one table is not allowed to be matched by multiple special configurations at the same time.
  target-tables = ["database.table"]
  
  # (optional) Specifies the column used to divide data into chunks. If you do not configure it,
  index-fields = ["id"]
  

まとめ

TiDB Cloud Dedicatedへ移行する簡単な手順を書きました！！

書いたのですが、やはりイメージがないと伝わりにくいかと思いますので、イメージを使用したもっと詳細な情報はいつかどこかで公開できれば💦

また、DumplingやTiDB Lightningは移行速度が本当に早いのでまたの機会で速度の計測なども載せられたら！！