[OCI]Autonomous Database の最新のバックアップからのクローンは使えるのか

はじめに

Autonomous Database にはクローン機能があり、フル・クローン / リフレッシュ可能クローン / メタデータ・クローンが作成できます。

また、フル・クローン / メタデータ・クローンの場合、データベース・インスタンス（実行中インスタンス）からのクローニング / バックアップからのクローニングを選択することができます。

さらに、バックアップからのクローニングの場合、過去60日以内のタイムスタンプを指定するポイント・イン・タイム・クローン / 自動バックアップのリストから選択するリストからのバックアップの選択 / 最新のバックアップ・タイムスタンプ を選択することができます。

「最新のバックアップ・タイムスタンプのバックアップからのクローニング」のユースケースとしては、データベースが使用できなくなった場合、または最新のバックアップに基づいてクローンを作成するなんらかの理由がある場合に使用します。
なお、クローンはソースと異なるExadata筐体上に作成されます。

Autonomous Database インスタンスとは別の環境に保管されているバックアップを使用するので、Autonomous Database インスタンスが障害等で使用不可になってしまった場合に有効なクローニングの手段です。

今回は、最新のバックアップ・タイムスタンプとはどれくらい最新なのか、ということを検証してみたいと思います。

検証方法

1. Autonomous Database インスタンスATP4Cloneを作成
2. 以下のようにSAMPLE表と、SERIALシーケンスを作成

   CREATE TABLE SAMPLE(ID int, time timestamp);
   
   CREATE SEQUENCE SERIAL MAXVALUE 200000;
   

3. SAMPLE表に1秒ごとに1行INSERTするスクリプト(check.sh)を実行
   check.sh

   #!/bin/bash
   
   sql_flg=/tmp/sql.flg
   touch $sql_flg
   
   (
   while [ -a ${sql_flg} ]
   do
    echo "insert into sample values(serial.nextval, systimestamp);"
    echo "commit;"
    sleep 1
   done
   
   echo "exit"
   
   )|sqlplus  -s  admin/Welcome12345#@ATP4Clone_tp
   exit
   

4. ある時点(3分後)で障害が発生しAutonomous Database が使用不可になったと仮定し、その2分後にDBを停止、停止後にクローン作成
5. クローン側に接続し、どの時点(T1)までINSERTされているか確認
   

結果

クローン側に接続し、以下のSQLでSAMPLE表のデータを確認してみます。

SELECT * FROM SAMPLE ORDER BY ID DESC;

 ID TIME                     
--- ------------------------ 
129 2023-04-25T15:38:40.211Z 
128 2023-04-25T15:38:39.210Z 
127 2023-04-25T15:38:38.209Z 
126 2023-04-25T15:38:37.208Z 
125 2023-04-25T15:38:36.207Z

スクリプト実行から2分後にDBを停止しました。停止までのラグがあり、実際DBが停止した2分9秒のデータまで残っていることが分かります。

結果としては、データ損失は0だったことになります。

今回の検証では、実際にDBに障害は起こしておらず、停止させただけのため、内部的にREDOログのバックアップは行われています。
Autonomous Database-Sharedでは、ログのバックアップ頻度は1分でクローン作成時間より短いため、データ損失が0という結果になったと考えられます。

なお、クローン側でDBA_PDBSディクショナリのLAST_RECOVER_TIME列を参照してみると、どの時点のデータまでクローン側に反映されているか分かります。

SELECT LAST_RECOVER_TIME FROM DBA_PDBS;

LAST_RECOVER_TIME 
----------------- 
2023/4/25 15:41:13

DB停止が15:38:40、クローン作成終了が15:43:20だったので、やはり内部的にREDOログのバックアップは取られ続けていることが分かります。

本検証からログのバックアップが直前まで取られていることが分かったので、ドキュメント通り障害発生時のRPOはバックアップ頻度同様最大1分と考えられます。

なお、クローン作成中はダウンタイム(RTO)となるため、ここを許容できるかがポイントになってくるかと思います。いくつかのパターンで検証した結果、クローン作成時間はデータ量に比例し、約25分/TBでした。

Autonomous Data Guard構成の場合、同一リージョン内ではRTOは数秒～2分、クロスリージョンでは15分となるので、クローン作成に伴うダウンタイムが許容できない場合は、Autonomous Data Guardをご検討いただくと良いかもしれません。

参考

バックアップからのAutonomous Databaseのクローニング