🗂

TiDB Dedicated の Dural Region Backup

2024/12/17に公開

この記事はTiDB Adventcalender 2024 12月17日の記事です。
https://www.pingcap.com/blog/tidb-dual-region-backup-cost-effective-disaster-recovery/

TiDB Dedicated Cluster に Dural Region Backupが出ました。大規模なRegion障害に備えて別リージョンでリアルタイム同期をおこないながらバックアップを別リージョンで取得する仕組みのようです。

さっそくやってみる

まずはBackup元のDedicated Cluster を東京リージョンで起動します。
[Resume中]

[起動完了]

クラスターの詳細画面に行きBackupをクリックします。

Backup Settingをクリックします。

Dual Region Backupのトグルをオンにします。

Backup先にVirginiaを選択してConfirmをクリックします。
2024年12月16日 の記事執筆現在、Osakaリージョンは選べるようになっているものの、TiDB Dedicated Cluster の基盤が存在しておらず処理が進められません。国内に閉じたDual Region Backupが必要な場合はPingCapに相談してみましょう!

確認画面で再度Confirmをクリックします。

設定が出来たら再度Backup Settingsをクリックすると次回のバックアップスケジュールが表示されます。

Schedulerで30分単位で時間を変更できます。(この画面だと夜19時30分です)ただし、1日1回の様で、翌日にその時間がセットされます。

Backupが取得されるまで待ちましょう。なおBackup元には少しテストテーブルとデータを以下のように入れてあります。

ti:root@172.30.88.127:4000=> use test;
USE
ti:root@172.30.88.127:4000=> show tables;
 Tables_in_test
----------------
 users
(1 row)

ti:root@172.30.88.127:4000=> select * from users;
 user_id | name  | email             | age
---------+-------+-------------------+-----
 1       | Alice | alice@example.com | 30
 2       | Bob   | bob@example.com   | 25
(2 rows)

Backup 取得成功とリストア

無事Backupが取得されました。以下のようにap-northeast-1us-east-1と2つのRegionが取得されています。

ActionRestoreを選択します。

us-east-1を選択してリストアを行います。

us-east-1で初めてDedicated Cluster を起動する場合The CIDR is not set for the region and the cluster cannot be createdとエラーが出ます。この場合以下の手順で先にNetworkを作成しておきます。
左ペインからProject Settingをクリックします。

Project CIDRをクリックします。

作成された直後は以下の通り最初はInactiveになりますが、Clusterを起動すると自動でActiveに代わります。

以下の通りRestore中はクラスターがcreatingRestoringのステータスとなるのでしばらく待ちます。


おおよそ30分程度(データ量に勿論依存しますが、私の環境は最小の環境でテストしています)で復元しました。

RTO と RPO

データベースの災害対策設計として一番大事なのはビジネス要件としてのRTOとRPOです。

RTO(Recovery Time Objective)
システムやサービスの障害が発生した後、復旧するまでに許容できる最大の時間を示します。つまり、サービス停止から復旧完了までの時間の目標です。

RPO(Recovery Point Objective)
システムの障害が発生した時点までに失われることを許容できるデータの量を示します。具体的には、最後にバックアップが取られた時点からどれくらい遡って復旧する必要があるかの目標です。

Dural Region Backupでは、RTOがデータ量に依存しますが最小構成で約30分、RPO(バックアップ取得間隔)が1日1回が最短サイクルとなります。

TiDBに限らずこの2つは短くすればするほどコストが上がる強い相関性を持っています。ほぼリアルタイムでの別リージョンバックアップが必要な場合、今回のコールド型ではなく以下の機能を用いてレプリケーションを張ることを合わせて検討するのがよさそうです。
https://zenn.dev/kameping/articles/8ac97a06ce3de8

Discussion