TiDB CloudでDedicatedクラスタからServerlessクラスタにレプリケーションしてみた（Changefeed機能）
2024.09.25こんにちは、ゲームソリューション部のsoraです。
今回は、TiDB CloudでDedicatedクラスタからServerlessクラスタにレプリケーションしてみた（Changefeed機能）ことについて書いていきます。
手順は以下を参考に進めていきます。
構成
今回の構成は以下です。
レプリケーション元のDedicatedクラスタからServerlessクラスタへレプリケーションします。
レプリケーション前にEC2インスタンス経由でデータエクスポートを行い、S3からデータインポートを行います。
その後に、DedicatedクラスタでChangefeedを作成することでレプリケーションします。
TiDB Cloudのクラスタ間のChangefeedを作成する上での主な注意点は以下です。
・Sink to TiDB Cloud機能は、次の AWS リージョンにあり、2022 年 11 月 9 日以降に作成されたTiDB Cloud Dedicated クラスターでのみ使用できます。
・AWS オレゴン (us-west-2)
・AWS フランクフルト (eu-central-1)
・AWS シンガポール (ap-southeast-1)
・AWS 東京 (ap-northeast-1)
・AWS サンパウロ (sa-east-1)
・ソースTiDB Cloud Dedicated クラスターと宛先TiDB Cloud Serverless クラスターは、同じプロジェクトと同じリージョンに存在する必要があります。
また、クラスタ間のレプリケーションはDedicatedクラスタからServerlessクラスタへのみ可能であり、逆方向のレプリケーションやServerless間、Dedicated間でのレプリケーションはできません。
データエクスポート・インポートの準備（AWS）
データエクスポート・インポートに利用するEC2インスタンスとS3を準備します。
データエクスポートにはEC2インスタンスにインストールしたDumpling、インポートにはS3を使用します。
EC2インスタンスにDumplingをインストールします。
TiDB CloudのDedicatedクラスタに接続して設定する場面があるため、MySQLクライアントもインストールしておきます。
# tiupのインストール
$ curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
$ echo 'export PATH=$PATH:~/.tiup/bin' >> ~/.bashrc
$ source ~/.bashrc
$ tiup --version
1.16.0 v1.16.0-nightly-18
Go Version: go1.21.13
Git Ref: master
GitHash: c1a14a55118b5c2076497cca7d7b28741ad8ab80
# Dumplingのインストール
$ tiup install dumpling
$ tiup dumpling -V
Starting component dumpling: /home/ec2-user/.tiup/components/dumpling/v8.3.0/dumpling -V
Release version: v8.3.0
Git commit hash: 1a0c3ac3292fff7742faa0c00a662ccb66ba40db
Git branch: HEAD
Build timestamp: 2024-08-20 10:13:00Z
Go version: go version go1.21.10 linux/amd64
# MySQLのインストール（TiDB Cloudに接続して設定するため）
$ sudo dnf -y localinstall https://dev.mysql.com/get/mysql84-community-release-el9-1.noarch.rpm
$ sudo dnf -y install mysql-community-client
EC2インスタンスにてS3を宛先をS3としてエクスポートするため、インスタンスプロファイルとしてS3にアクセス可能な権限を付与しておきます。
S3バケットやエンドポイントも準備しておいてください。
テストデータの登録（Dedicatedクラスタ）
レプリケーションを設定する上では不要ですが、エクスポート・インポートの確認のため、テストデータを入れておきます。
TiDB CloudのDedicatedクラスタにて、SQL Editorから以下SQLでデータを作成します。
CREATE DATABASE prefecture_db;
USE prefecture_db;
CREATE TABLE prefecture (
id INT AUTO_INCREMENT PRIMARY KEY,
prefecture VARCHAR(255) NOT NULL,
prefectural_capital VARCHAR(255) NOT NULL,
area VARCHAR(255) NOT NULL
);
INSERT INTO prefecture (prefecture, prefectural_capital, area) VALUES
('Hokkaido', 'Sapporo', 'Hokkaido'),
('Aomori', 'Aomori', 'Tohoku'),
('Iwate', 'Morioka', 'Tohoku'),
('Miyagi', 'Sendai', 'Tohoku'),
('Akita', 'Akita', 'Tohoku'),
('Yamagata', 'Yamagata', 'Tohoku'),
('Fukushima', 'Fukushima', 'Tohoku'),
('Ibaraki', 'Mito', 'Kanto'),
('Tochigi', 'Utsunomiya', 'Kanto'),
('Gunma', 'Maebashi', 'Kanto'),
('Saitama', 'Saitama', 'Kanto'),
('Chiba', 'Chiba', 'Kanto'),
('Tokyo', 'Tokyo', 'Kanto'),
('Kanagawa', 'Yokohama', 'Kanto');
-- 登録したデータの確認
SELECT * FROM prefecture;
GCの設定変更（AWS→Dedicatedクラスタ）
データのエクスポート・インポート、Changefeedの作成をしている間に、入っているデータが変わってしまうとデータにずれが生じるため、DedicatedクラスタにてGCの設定を変更します。
EC2インスタンスからTiDB CloudのDedicatedクラスタに接続して設定します。
設定値については、最初に紹介した手順の中で以下の説明があります。
- その間、履歴データが TiDB によってガベージ コレクションされないように、 tidbgcライフタイム次の 2 つの操作の合計時間よりも長く延長します。
・既存のデータをエクスポートおよびインポートする時間
・Sink to TiDB Cloudを作成する時間
mysql --connect-timeout 15 -u <ユーザ名> -h <ホスト名> -P 4000 -D test -p<パスワード>
mysql> SET GLOBAL tidb_gc_life_time = '4h';
Query OK, 0 rows affected (0.04 sec)
レプリケーション元クラスタのデータエクスポート（AWS→Dedicatedクラスタ）
EC2インスタンスにてDumplingを使用して、TiDB CloudのDedicatedクラスタのデータをエクスポートします。
このとき、エクスポート先としてS3を指定します。
$ tiup dumpling -u <ユーザ名> -P 4000 -h <ホスト名> --filetype sql -t 2 -o s3://xxxxxxxxxx/changefeed-test/ -r 200 -F 4MiB -p <パスワード>
上記コマンド実行後にS3を確認すると、データがエクスポートされていることが確認できます。
エクスポートされたファイルのmetadataをダウンロードして、TSO（Posの値）を確認します。
このTSOはChangefeed作成時に必要になります。
Started dump at: 2024-09-25 04:59:20
SHOW MASTER STATUS:
Log: tidb-binlog
Pos: 452785697019133953
GTID:
Finished dump at: 2024-09-25 04:59:20
レプリケーション先クラスタへデータインポート（Serverlessクラスタ）
先ほどエクスポートしたデータをServerlessクラスタにインポートします。
今回はTiDB CloudのGUI上で使用可能なImport機能を使用して、S3経由でインポートします。
インポートができたため、SQL Editorで確認してみるとインポートしたデータが入っていることがわかります。
Changefeedの作成（Dedicatedクラスタ）
同期前のデータのエクスポート・インポートが完了したため、DedicatedクラスタにてChangefeedを作成してレプリケーションします。
GUI上のChangefeed＞Create Changefeedから作成します。
宛先をTiDB Serverlessにして、対象のクラスタとそのユーザ・パスワードを入力します。
テーブルフィルタやイベントフィルタを設定することも可能ですが、今回はデフォルトのままとします。
Start Replication Positionには、エクスポートしたデータのmetadataに記載されていたTSOを入力します。
作成したChangefeedのステータスがCreatingからRunningに変わると作成完了です。
GCの設定戻し（AWS→Dedicatedクラスタ）
Changefeedの作成が完了したため、EC2インスタンスからDedicatedクラスタに接続して、GC設定をデフォルトの値に戻します。
$ mysql --connect-timeout 15 -u <ユーザ名> -h <ホスト名> -P 4000 -D test -p<パスワード>
$ SET GLOBAL tidb_gc_life_time = '10m';
レプリケーションの確認
レプリケーションのための設定が完了したため、Dedicatedクラスタに追加のデータを入れて、Serverlessクラスタにて同様のデータが追加されていることを確認してみます。
まず、DedicatedクラスタのSQL Editorから以下でデータを追加します。
USE prefecture_db;
INSERT INTO prefecture (prefecture, prefectural_capital, area) VALUES
('Niigata', 'Niigata', 'Chubu'),
('Toyama', 'Toyama', 'Chubu'),
('Ishikawa', 'Kanazawa', 'Chubu'),
('Fukui', 'Fukui', 'Chubu'),
('Yamanashi', 'Kofu', 'Chubu'),
('Nagano', 'Nagano', 'Chubu'),
('Gifu', 'Gifu', 'Chubu'),
('Shizuoka', 'Shizuoka', 'Chubu'),
('Aichi', 'Nagoya', 'Chubu'),
('Mie', 'Tsu', 'Kinki'),
('Shiga', 'Otsu', 'Kinki'),
('Kyoto', 'Kyoto', 'Kinki'),
('Osaka', 'Osaka', 'Kinki'),
('Hyogo', 'Kobe', 'Kinki');
その後、レプリケーション先のServerlessクラスタにてデータを確認してみると、データが追加されていることが確認できました。
Dedicatedクラスタにて、Changefeedを確認するとメトリクスも確認することができました。
最後に
今回は、TiDB CloudでDedicatedクラスタからServerlessクラスタにレプリケーションしてみた（Changefeed機能）ことを記事にしました。
どなたかの参考になると幸いです。
