🙆

TiDB Serverless のブランチ機能について

2024/08/06に公開

今日はTiDB Serverlessにあるブランチを触っていきます。
https://docs.pingcap.com/ja/tidbcloud/branch-overview

ブランチ

クラスターのブランチは、元のクラスターから分岐したデータのコピーを含む別のインスタンスと定義されています。つまり、検証用にデータが分離された環境が提供されるため、元のクラスターへの影響を考慮不要で開発やデバッグが行える機能です。

2023年7月5日以降に作成されたServerlessクラスターであれば、現在のベータ版の間は無償でこの機能を使うことができますが、ストレージは無償版でクラスター単位で10GiB、有償版で100GiBに制限されています。これ以上のストレージが必要な場合はサポートヘの問い合わせが必要なようです。

コピーオンライト

ブランチの作成自体は数分で完了するようです。ただし実際のデータコピー自体が数分で完了するわけではもちろんありません。データの射影をコピーオンライトという方式で作成しています。
https://ja.wikipedia.org/wiki/コピーオンライト#:~:text=コピーオンライト (Copy%2DOn,%E5%89%B2%E3%82%8A%E5%BD%93%E3%81%A6%E3%80%81%E3%82%B3%E3%83%94%E3%83%BC%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%99%E3%82%8B%E3%80%82

単純には、コピーコマンドが発せられたとき(ブランチの作成が指示されたき)実際にはデータはコピーされていません。オリジナルのデータを見ています。その後オリジナルのインスタンスかブランチのインスタンスへデータ書き込み(Insert、Update、DeleteのDML等)が行われた時点でデータはコピーされることになります。これは多くのクラウド型データベースでもサポートされている技術であり、データコピーを高速性とストレージコストの圧縮を実現できます。

さっそくやってみる

まずTiDB Serverless クラスターになにがしかのテーブルやデータがある状態から始めます。

環境がない場合、シンプルにこちらをやってみて下さい。
https://zenn.dev/kameping/articles/2248cb2833785e
任意のクラスターを選択してBranchesを選択します。

画面右上のCreate Branchをクリックします。

適当な名前を入力しCreateを押します。

作成中です。

数分待つと以下のように作成完了となります。

ストレージが割り当てられていることがわかります。
1.02MiBは同じ領域が確保されていますが、前述の通りコピーオンライトとなっており実際はデータは書き込まれていません。この辺りは全てミドルウェアが抽象化して管理しますので今後は意識不要です。

双方のエンドポイントを見ると以下になっています。
[オリジナル]
End Point: gateway01.ap-northeast-1.prod.aws.tidbcloud.com
USERNAME: 24Vt4u5yz6bN68P.root
[ブランチ]
End Point: gateway01.ap-northeast-1.prod.aws.tidbcloud.com
USERNAME: 3zgbybya8kkhhbd.root

元クラスターとブランチは同じエンドポイントを共有し、USERNAMEが異なっておりここで判別されています。TiDB Serverlessリージョンが同じであれば全てエンドポイントが同じとなります。つまり、それが別クラスターなのかブランチなのかはエンドポイントだけでは違いが判りませんが、逆に言えば別として取り扱えると理解して問題ないでしょう。ただしテストで便利なSQL EditorChat2QueryData API等はブランチではつかえないようになっています。

ブランチ側で

delete  from test.user;

を実行して元クラスター側で

select * from test.user;

を実行するとデータが正しく出てくることで、別扱いとなっていることがわかります。
一度作成されたブランチは元クラスターとはデータが論理上完全に別扱いとなっておりGitHubのブランチなどと異なりマージすることはできません。

このブランチ機能はGitHub統合させることでプルリクエスト単位で自動で新しいブランチの作成をトリガーさせることが出来ます。次回の記事ではそれについては触れていきます。

Discussion