NTNX>日記

個人的な趣味による Nutanix Community Edition 日記。Japanese のみですみません。

Nutanix CE 上の Oracle を PD スナップショットから復旧してみる。(説明編)

Nutanix の Application Consistent Snapshots を利用して Oracle Database の復旧をしてみます。今回はシナリオの説明です。

すでに、下記のような方法でアプリケーション整合性をもつスナップショットを作成してあります。

これから、ためしに Oracle のデータファイルを壊してスナップショットから復旧してみます。この DB サーバの VM では、リストアのしやすさを意識していない構成でスナップショットを作成しているので、結構大変な感じになります。

今回の vDisk 構成とデータ配置

db02 という Linux ゲスト OS の VM を用意しました。

データ配置

vDisk 0(scsi.0)

OS 領域。Oracle Linux 7.4 をインストール。

vDisk 1(scsi.0)

パーティション作成して ext4 ファイルシステムでフォーマットし、/u01 にマウント。

  • Oracle Database 12c R2 のソフトウェア(ORACLE_HOME)
  • データベース構成ファイル すべて(DBF、Redo、制御ファイル)
  • アーカイブ Redo ログファイル

データと vDisk の関係

今回は、USERS 表領域のデータファイルを壊してみます。
対象のファイルはこれです。

SQL> select TABLESPACE_NAME,FILE_NAME from dba_data_files where TABLESPACE_NAME = 'USERS';

TABLESPACE_NAME FILE_NAME
--------------- --------------------------------------------------
USERS           /u01/app/oracle/oradata/testdb1/users01.dbf

ちなみに USERS 表領域には、TAB01 というテーブルがあります。

SQL> select TABLE_NAME,TABLESPACE_NAME from user_tables where TABLE_NAME = 'TAB01';

TABLE_NAME TABLESPACE_NAME
---------- ---------------
TAB01      USERS

このデータファイルの配置していあるファイルシステム /u01 は、2番目の vDisk(/dev/sdb)です。

[oracle@db02 ~]$ df -h /u01
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/sdb1         16G   12G  3.3G   79% /u01
[oracle@db02 ~]$ lsblk -f -l /dev/sdb1
NAME FSTYPE LABEL UUID                                 MOUNTPOINT
sdb1 ext4         1edb7fb0-a8f8-4d0b-9216-0c7804715efe /u01

Nutanix の CVM / AHV から見ると、この vDisk は scsi.1 として VM に接続されています。17179869184 = 16GB のディスクです。

nutanix@NTNX-2a0a73b3-A-CVM:192.168.1.192:~$ acli vm.disk_list db02
Device bus  Device index
scsi        0
scsi        1
nutanix@NTNX-2a0a73b3-A-CVM:192.168.1.192:~$ acli vm.disk_get db02 disk_addr=scsi.1
scsi.1 {
  addr {
    bus: "scsi"
    index: 1
  }
  container_id: 8488
  container_uuid: "928430ef-1887-48b2-974b-85db6a4421f5"
  source_vmdisk_uuid: "8b9d29bf-c66d-4582-8016-bb61750662cf"
  vmdisk_size: 17179869184
  vmdisk_uuid: "099dbb1c-0f76-457b-93de-47dc944520a5"
}

LVM や xfs を利用すると、UUID 重複になって大変(VM としてリストアして必要なファイルだけ転送するとかでも回避できますが)なので今回は基本パーティションで ext4フォーマットにしています。

今回のシナリオ

ここからのシナリオとしては、「とりあえずスナップショット作成」な DB サーバのデータファイルを一部消失した状態から復旧するような想定です。

破壊前の DB の状態です。

  • PD でのスナップショット(Application Consistent Snapshots が有効のもの)を作成ずみ。スナップショット取得時は、DBはバックアップモードにしてある。
  • アーカイブ Redo ログはすべて残っている。
  • データファイル、Redo ログファイルなど DB を構成するファイルすべて同じ vDisk に配置。

 Oracle Database のデータファイルを 1つだけ壊してみます。今回の構成ではデータファイル、Redo ログファイルが同じ vDisk に配置されていて、vDisk 全体をリストアすると DB としてはリカバリできなくなってしまいます。

f:id:gowatana:20170930000639p:plain

復旧手順の概要

Application Consistent Snapshots のベースとなる Protection Domain(PD)でのスナップショットのリストアは VM 単位(vDisk 単位ではなく)になるようです。そこで特定の vDisk だけを戻すため下記のように復旧してみました。

  1. PD スナップショットから、VM をリストア。
  2. リストアした VM の vDisk(vDisk 1)から、元の VM に vDisk を作成。
  3. 接続した vDisk から、データファイルを戻して、DB をリカバリ。

 ただしこれは一つの例であって、ディスク構成を工夫したりしておけば、復旧方法はもっと効率よくすることが可能かなと思います。

f:id:gowatana:20170930000652p:plain

つづく・・・