更新履歴
2016.05.13.追記: SPS12において、ストレージスナップショットとデルタバックアップの組み合わせのサポートを追記。
前回は、HANAの永続化の機能であるセーブポイントとスナップショットを説明しました。今回は、これらの機能を使っているバックアップについて説明します。具体的な手順やコマンドにはあまりこだわらずに、データバックアップのメカニズムを理解することを目的としたいと思います。
前回説明しましたが、HANAはインメモリーデータベースであること、加えて今のメモリーは揮発性であることから、セーブポイントというデータベース更新とは独立した永続化機能がその時点のデータベースの状態をデータボリュームに書きこんでいます。
HANAのバックアップの特徴はメモリー上のデータベース本体ではなく、このディスク上のデータボリュームを対象としていることです。つまり、ディスクベースのDBMSのバックアップがDB本体をコピーするのに対して、HANAはメモリー上のDB本体ではなくディスク上のデータボリュームをコピーしようとします。
しかし、このやり方には考慮すべき点が2つあります。
1番目はセーブポイントがデフォルトで5分ごとに実行されるので、バックアップの内容が最大5分は古いということです。これはログバックアップを行えば直近の状態までリカバリーできるので致命的ではないかもしれませんが、ユーザー感覚としては容認し難いレベルだと思います。
ですので、HANAはバックアップする前ににセーブポイントを実行するようになっています。
2番目の考慮点は、セーブポイントはバックアップ中でも更新されるからなのですが、データベースとしては致命的であるため、バックアップ開始直後のセーブポイント実行時にスナップショットを書き込みことにより対応しています。つまり、オンラインバックアップ中に内容が変わるかもしれないセーブポイント領域ではなく、セーブポイントのコピーであるスナップショット領域(静止点)をバックアップとすることにより、バックアップ処理中の更新の影響を受けないようにしているわけです。
HANAのバックアップ/リストアの基本的な考え方を説明します。
通常バックアップは、フルバックアップとしてのデータベース全体イメージのコピーと差分バックアップとしてのトランザクション・ログのコピーから構成されるケースが多いと思いますが、HANAの場合、フルと差分から成っていることは間違いないのですが、差分が2種類あり、1つは更新された物理ページの集合、もう1つはトランザクションログです。前者をデルタバックアップ、後者をログバックアップと呼びます。
リストアの際には、フルバックアップ→デルタバックアップ→ログバックアップの順に、つまり、ある時点の物理ページ全体→その後の差分物理ページ→その後の差分トランザクション、と適用するのが基本的な考え方ですが、RPOによっては使用しないバックアップもあります。
バックアップの種類をコマンドレベルでまとめました。
大別すると、HANA組み込みのファイルベースのバックアップと、外部のファイル複製機能を使うストレージスナップショットベースのバックアップがあります。
ファイルベースの場合、従来からあるフルに加えて、SPS10からデルタバックアップが使用可能になりました。デルタバックアップは、さらに、累積差分ページを取る増分バックアップと常に全開との差分ページだけを取る差分バックアップの2種類に分かれます。
ストレージスナップショットベースのバックアップは、HANAの外部のコピー機能を使います。cpコマンドでもtarコマンドでも機能はしますが、一般的には短時間で完了するストレージシステム付属のスナップショット機能を使用します。この場合、静止点を確保するためにBACKUP DATA CREATE SNAPSHOTコマンドを直前で実行します。バック終了後はBACKUP DATA CLOSE SNAPSHOTコマンドを使用してHANA内部のスナップショットの削除や後始末を行います。外部機能で取ったバックアップが有効(将来バックアップに使うという意味)な場合SUCCESSFULを、無効な(取ったが破棄することにした)場合や失敗した場合にはUNSUCCESSFULを指定します。
BackIntによるバックアップの説明は割愛します。動作は、ファイルベースのバックアップに準じると理解してください。
SPS12よりストレージスナップショットとHANAのデルタバックアップの組み合わせがサポートされました。(2016.05.13.追記)
前述の通り、フルバックアップ→デルタバックアップ→ログバックアップの順に、つまり、ある時点の物理ページ全体→その後の差分物理ページ→その後の差分トランザクション、と適用するのが基本的な考え方です。
従いまして、上図で障害発生の時点A、つまり直近の状態までリカバリーするときには、
という順位になります。
また、任意の時点(例えばB)に戻すときも考え方は同じですがどの時点かにより使わないものが出てきます。
この辺りの、どのバックアップを使うかは、リストアの初期の段階で”リカバリーストラテジーの決定”というフェーズでHANAが決めてくれます。
HANAがバックアップファイルの管理を行っている片鱗を見てみます。
以下は、インストール後、フル→増分→差分→差分というオペレーションを行った後のバックアップファイルの出力先です。
ちなみに、HANA Studioによる実行ですが、以下に相当するコマンドが発行されているはずです。
また、以下はM_BACKUP_CATALOGというシステムビューでバックアップの実行状況を参照できます。
ビュー中、ENTRY_TYPE_NAMEが”complete data backup”となっている行は1行しかありませんので、フルバックアップのBACKUP_IDは1460359737239であることがわかります。
デルタバックアップはネーミングルールで
ですから、1460359737239を先行とするのは6−8行目の増分バックアップと11-13行目の差分バックアップということになりますが、増分→差分の場合はこのようにはならないので、11-13行目→6−8行目ということがわかります。(図中、赤で示した部分)
さらに、14-16行目の先行が6−8業目となっています(図中、黄で示した部分)ので全体としては、
であり
ということになります。タイムスタンプを見ればわかるといえばそれまでですが、HANAがリカバリーストラテジー作成のための情報管理をしいてることはわかると思います。
ファイルベースのバックアップは、バックアップの書き込みまでをHANAが行います。機能的には、ローカルファイルシテムに書き出しますが、HANAアプライアンスハードウェアの障害に対応するために通常はNFSなどによりマウントされた外部ストレージに書き込むようにします。
データボリュームの仕様が公開されていないので説明しにくいのですが、丸ごとバックアップファイルにコピーするのではなく、ペイロードと言われるヘッダーなどを除いた部分のみコピーします。
また、データボリュームの読み込みの際、チェックサムによる誤り検出および訂正を行います。
ファイルベースのバックアップの処理フローは以下の通りです
ポイントは、以下の2点です。
個人的に面白いと思うのは、スナップショットの部分だけをバックアップしているのではなく、データボリューム全体をコピーしていることです。データボリュームの中には、バックアップ用に作った静止点であるスナップショットと直近のセーブポイントの少なくとも2つの状態が含まれていることになります。セーブポイントの方は、スナップショットと同じ内容なのか、次の世代なのかはわかりません。静止点以降の更新内容はスナップショット+Redoログでリカバリーされるのでわかる必要もありません。
リストアの時に(セーブポイントからではなく)スナップショットからデータベースが起動(メモリーロード)されさえすれば問題はないことになります。記憶の良い方は、前回のブログの最後のクイズを思い出すかもしれません。
ファイルベースのバックアップからのリストアは、バックアップファイルからデータボリュームへの戻しと、スナップショットからのメモリーロードが主なプロセスになります。通常のHANAのブート手順では、(シャットダウン時に作成された)セーブポイントからメモリーロードを行うのに対して、リストアにともなうデータベース起動ではスナップショットからメモリーロードが行われる、という点が違います。
具体的には、以下のようなプロセスになります。
最初のポイントはリストアのフェーズで、各プロセスはスナップショットの部分だけではなく、データボリューム全体をリカバリーします。つまり、先に述べたメモリーロードをセーブポイントから行うか、スナップショットから行うか、はまだ解決されていません。。
次のポイントは、ログリプレイのフェーズで、Redoログリプレイのためには、基になるテーブルが必要ですので、実際にリプレイが始まる前に対象テーブルのメモリーロードが行われます。重要なのはここで、通常のブートであればセーブポイントから行われるべきメモリーロードをスナップショットから行うことによりHANAはバックアップを取った静止点の時点へのリカバリーをしようとするわけです。
ファイルベースのバックアップはHANAインスタンスが、静止点状態の確保からデータボリュームのコピーまでの全てを管理実行しますが、データベースのサイズが大きくなるとコピーに要する時間が長期化します。この問題への対策としてストレージスナップショットベースのバックアップがあります。これは、データボリュームのコピーを文字通りストレージシステムのスナップショット機能に任せることにより時間短縮を図ろうとする機能です。
(紛らわしいので、以降では、HANAのスナップショットを内部スナップショット、ストレージによるスナップショットをストレージスナップショットと呼びます。)
HANAが行うのは、内部スナップショットの生成と削除のみです。内部スナップショット作成→ストレージスナップショット実行→内部スナップショット削除は一連の連続したオペレーションであるべきですが、機能の実装上、実行の主体がHANA→ストレージ→HANAと変わるため、データベース管理者(またはシステム運用管理ツールなど)が全体を管理する必要があります。
ストレージスナップショットベースのバックアップの手順は、下図の通りです。(クライアントとnameserverの間のindexserverは省略していますが、実際はファイルベースの場合と同様の動作となります。)
前述の内部スナップショットを作成する過程がPrepareフェーズ、削除する過程がConfirmフェーズです。PrepareとConfirmの間でストレージスナップショットが実行されます。
基本的な考え方は、ファイルベースの場合とほぼ同じで
2点です。
ファイルベースの時に行っている符号誤りのチェックは、ストレージスナップショットに依存することになりますので、チェックの有無や粒度には導入前に確認が必要です。
また、Confirmフェーズでは、スナップショットを削除するという重要な作業を行っています。スナップショットは、更新が多発するデータベースでは容量を圧迫することになる上、次のスナップショットを作るには現存のものを削除する必要があります。ストレージスナップショットを終えると速やかにConfirmフェーズを実行します。
スナップショットベースのリストアは、ストレージスナップショットのリストアとリカバリースクリプトの実行に分かれ、前者はストレージシステムに依存し、後者はHANAが行う処理です。
以上、バックアップ/リストアのメカニズムとセーブポイント、スナップショットがどのような役割を果たすかを説明しました。
次回は、システムレプリケーションの仕組みと、永続化、バックアップ、システムレプリケーションが内部的には似たような動きであり、いづれもスナップショットが重要な役割を果たしている、というお話をしたいと思います。
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
10 | |
10 | |
9 | |
8 | |
7 | |
7 | |
7 | |
7 | |
6 |