基本からわかる！高性能×高可用性データベースシステムの作り方 indexページ
Oracle Databaseのレプリケーション機能にはいくつかありますが、障害に備えるためレプリケーション機能としてはData Guardフィジカル・スタンバイおよびその拡張であるActive Data Guardが第一選択肢です。手作業でData Guardを構成する場合、最初にデータベースの複製を作成する工程が最も手間がかかります。Oracle Database 18c以降ではdbcaコマンドを使用するとこの複製工程を大幅に簡略化することができます。Data Guardを構成するには最低限何を設定すればよいかを解説します。
Data Guardフィジカル・スタンバイの動作原理
Data Guardフィジカル・スタンバイは物理バックアップ・リカバリの応用でデータベースのレプリカを作成します。
Data Guardの前にまず、物理バックアップ・リカバリの仕組みをおさらいしましょう。
データベースに更新が発生すると、その情報はREDOログの形でオンラインREDOログ・ファイルに記録されます。これはデータ・ブロックにどのような変更が行われたかの記録です。データベースのフル・バックアップ、つまり全データ・ブロックのバックアップが取得してあれば、それを書き戻して(リストア)、REDOログを適用(リカバリ)すれば、REDOログが存在する時点までのデータベースの状態を復元することができます。
Data Guardフィジカル・スタンバイは、レプリケーション元のデータベース(プライマリ・データベース)のフル・バックアップを別のサーバーにリストアし、そこでプライマリ・データベースで生成されたREDOログを適用し続けることでプライマリ・データベースとデータ・ブロックの中身の構造まで全く同じになるデータベースを複製することができます。Data Guard用語では複製したレプリケーション先のデータベースをスタンバイ・データベースと呼びます。
Data Guardでは、プライマリ・データベースでREDOログ情報がSystem Global AreaのREDOログ・バッファに書き込まれるとスタンバイ・データベースに転送しようとします。そのため、いくつかあるレプリケーション機能の中でも、Data Guardが最も転送遅延が小さくなります。転送遅延が小さいため、レプリケーション先に更新が伝搬したことが確認できるまでCOMMITが確定しないという同期転送モードを持っているのもData Guardだけです。
Data Guardの仕組みをもう少し詳細に見ていきましょう。Data Guardは大別すると2つの機能に分解できます。1つはREDOログの送受信(REDO転送サービス)で、もう1つは受信したREDOログの適用(適用サービス)です。Data Guardの構成とは、これら2つの機能を設定することです。
1つ目の設定はREDOログの送受信に関する設定です。プライマリ・データベースではREDOログ送信に関する設定を行います。スタンバイ・データベースではREDOログ受信に関する設定を行います。受信したREDOログ情報はスタンバイREDOログ・ファイルに格納されます。CREATE DATABASEで作成したプライマリ・データベースではREDOログ情報はオンラインREDOログ・ファイルに格納されますが、スタンバイREDOログ・ファイルはデータベース作成時点では存在していないのでこれを作成する必要があります。スタンバイREDOログ・ファイルもオンラインREDOログ・ファイルと同様に固定長固定数のファイル群で、循環して上書きされます。スタンバイREDOログ・ファイルの内容も上書きされる前にアーカイブREDOログ・ファイルに書き出されていきます。
2つ目の設定はリカバリです。スタンバイREDOログ・ファイルおよびアーカイブREDOログ・ファイルに記録されたREDOログ情報をデータファイルに適用します。REDOログの送受信とリカバリは独立して動作します。つまり、リカバリ・プロセスを停止している場合でもREDOログの送受信は継続しています。
Active Data GuardというのはData Guardフィジカル・スタンバイの発展形で、スタンバイ・データベースをリカバリしながらもREAD ONLYでオープンすることができる機能です。
Data Guardフィジカル・スタンバイを手作業で構成
Oracle Enterprise Manager Cloud Controlが構成されているオンプレミス環境や、Oracle Cloud InfrastructureのDatabase Cloud ServiceではWebのGUIからData Guardが簡単に構成できるようになっていますが、ここでは手作業でコマンド操作して構成する方法を解説します。Data Guard環境の構築で最も手間がかかる工程は、最初にプライマリ・データベースの複製を作る(違う名前でデータベースをリストアする)ところです。Oracle Database 18c以降のDatabase Configuration Assistant(dbcaコマンド)を使用すると、Data Guardスタンバイ・データベース用の複製を簡単に作成できるようになっています。
Data Guardの構築は大別すると3つの工程になります。
1. プライマリ・データベースでの設定
プライマリ・データベースからスタンバイ・データベースを複製するにあたり、スタンバイ・データベースに設定が引き継がれる項目をプライマリ・データベースで設定しておきます。
2. スタンバイ・データベースでの設定
プライマリ・データベースからスタンバイ・データベースの複製を作成します。その後、プライマリ・データベースの設定を引き継がない項目をスタンバイ・データベースで設定します。
3. REDO転送サービスの設定とリカバリ開始
Data GuardのREDOログ送受信の設定を双方に行います(REDO転送サービスの開始)。そして、スタンバイ・データベースでリカバリを開始します(リカバリ・サービスの開始)。
それでは各工程を見ていきましょう。
1. プライマリ・データベースでの設定
1.1. アーカイブ・ログ・モード
Data Guardはアーカイブ・ログ・モードである必要があります。アーカイブ・ログ・モードへの変更はData Guard構築でプライマリ・データベースの停止が発生する唯一の工程です。しかし本番運用されているデータベースならばすでにアーカイブ・ログ・モードになっていることが想定されるので、Data Guardは実質的に無停止で構成することが可能です。
$ srvctl stop database -db ... $ sqlplus / as sysdba SQL> startup mount SQL> alter database archivelog; SQL> select LOG_MODE from v$database; LOG_MODE ------------------------------------ ARCHIVELOG SQL> exit $ srvctl start database -db ...
1.2. FORCE LOGGING
Data GuardはREDOログ情報に乗らない変更は伝搬しません。そのため、NO LOGGINGが指定されている操作でもREDOログを生成するFORCE LOGGINGモードにします。
SQL> alter database force logging; SQL> select force_logging from v$database; FORCE_LOGGING -------------------- YES
1.3. STANDBY_FILE_MANAGEMENT
プライマリ・データベースで新しいデータファイルが生成されたとき、それをスタンバイ・データベースでも自動生成する設定を行います。
SQL> alter system set STANDBY_FILE_MANAGEMENT='AUTO' scope=both sid='*';
1.4. スタンバイREDOログ・ファイル
スタンバイ・データベースで受信されたREDOログ情報はスタンバイREDOログ・ファイルに格納されます。スタンバイREDOログ・ファイルはスタンバイ・データベースにあればよいのですが、Data Guardを構成する場合はいずれプライマリとスタンバイの役割を入れ替える(スイッチオーバー)ことになるので、あらかじめプライマリ・データベースにも作成します。プライマリ・データベースで作成したスタンバイREDOログ・ファイルは、dbcaで複製するとスタンバイ・データベースにもその構成が引き継がれます。
Oracleインスタンスは自分が書き込む専用のREDOログのストリームを持っており、これをREDOスレッドと呼びます。RAC構成では複数のOracleインスタンスがあるので、REDOスレッドはOracleインスタンスの数だけあります(V$LOG.THREAD#)。
スタンバイREDOログ・ファイルの構成はオンラインREDOログ・ファイルの構成から導出しますので、まずオンラインREDOログ・ファイルの構成を調べます。CDB$ROOTにログインしてV$LOGビューからREDOスレッドとメンバーの構成、そしてファイルのサイズを調べます。
SQL> select thread#,group#,bytes from v$log; THREAD# GROUP# BYTES ---------- ---------- ---------- 1 1 1073741824 1 2 1073741824 2 3 1073741824 2 4 1073741824
作成するスタンバイREDOログ・ファイルは、各REDOスレッドにオンラインREDOログのメンバー数+1個のメンバーを作成します。各ファイル・サイズはオンラインREDOログ・ファイルと同じにします。GROUP番号はオンラインREDOログおよびスタンバイREDOログあわせて一意な番号を指定します。
SQL> alter database add standby logfile thread 1 group 5 size 1073741824, group 6 size 1073741824, group 7 size 1073741824; SQL> alter database add standby logfile thread 2 group 8 size 1073741824, group 9 size 1073741824, group 10 size 1073741824;
2. スタンバイ・データベースでの設定
2.1. dbcaでプライマリ・データベースをオンライン複製
Data Guardの構築で最も手間がかかる工程は、データベースを違う名前(DB_UNIQUE_NAME)で複製を作るところです。
Oracle Databaseはデータベースの名前が3階層あります。CDBおよびnon-CDBの名前で2階層(DB_NAMEとDB_UNIQUE_NAME)、そしてPluggable Databaseの名前で1階層(PDB_NAME)です。Data Guardを構成するデータベース群は、それぞれDB_UNIQUE_NAMEが一意になっています。DB_NAMEとPDB_NAMEは共通です。DB_UNIQUE_NAMEが管理操作上のデータベースを区別する識別子です。データベースのファイル・パスに含まれる「データベースの名前」や、srvctlコマンドの-dbオプションで指定する「データベースの名前」というのはDB_UNIQUE_NAMEを指しています。そのため、複製を作る前にDB_UNIQUE_NAMEを決めておく必要があります。
手作業でデータベースを複製するには、DB_UNIQUE_NAMEを変えてOracleインスタンスを起動するための初期化パラメータファイルの用意や各種ログ・ファイルが生成されるディレクトリの作成などが必要です。これらをdbcaで大幅に簡略化します。
dbcaにプライマリ・データベースへの接続情報を指定し、内部的にはRMANを使用してオンライン・フル・バックアップを取得し直接スタンバイ・データベース用のストレージにリストアします。スタンバイ・データベース用のOracleインスタンスの初期化パラメータは基本的にはプライマリ・データベースのものを継承します。変更のあるパラメータはdbcaのオプションで指定します。
$ export LANG=C $ export NLS_LANG=American_America.US7ASCII $ dbca -silent -createDuplicateDB -createAsStandby -gdbName DB_NAME.DB_DOMAIN -sysPassword SYSユーザーのパスワード -primaryDBConnectionString scan-host-name:port/SERVICE_NAMES -dbUniqueName DB_UNIQUE_NAME -sid ORACLE_SID接頭辞 -initParams db_create_file_dest=+DATA, db_recovery_file_dest=+RECO -databaseConfigType RAC -adminManaged -nodelist node3,node4
| 分類 |
dbcaのオプション |
意味 |
| プライマリ・データベースへの接続情報 |
-gdbName |
グローバル・データベース名 |
| -sysPassword |
SYSユーザーのパスワード |
|
| -primaryDBConnectionString |
Oracle Netの接続情報 CDB$ROOTに接続するのでサービス名はDB_UNIQUE_NAME.DB_DOMAIN |
|
| スタンバイ・データベース側の識別子の指定 |
-dbUniqueName |
DB_UNIQUE_NAME |
| -sid |
ORACLE_SID接頭辞 |
|
| -initParams |
プライマリ・データベースの初期化パラメータから変更するもの |
|
| RAC構成 |
-databaseConfigType |
RAC/RAC One Node構成の指定 |
| -adminManaged |
RACのクラスタ・タイプの指定 |
|
| -nodelist |
RACインスタンスを起動するノードの指定 |
dbcaで複製が完了するとスタンバイ・データベースになれる状態(V$DATABASE.DATABASE_ROLE=PHYSICAL_STANDBY)になっておりOPEN READ ONLYでアクセスできる状態になっています。また、Oracle Grid Infrastructure上に構成されている環境ではdbcaの完了でクラスタのリソース登録まで行われるので、srvctlコマンドでOracleインスタンスの操作ができるようになっています。
SQL> select OPEN_MODE,DATABASE_ROLE from v$database; OPEN_MODE DATABASE_ROLE --------------- -------------------- READ ONLY PHYSICAL STANDBY
2.2. BCTファイル(Optional)
Data Guardフィジカル・スタンバイはスタンバイ・データベースでもデータファイルのバックアップを取得することができます。Block Change Trackingファイルを設定しておけば高速増分バックアップも可能です。これはプライマリ・データベースで設定されていてもスタンバイ・データベースには引き継がれないので、必要であればスタンバイ・データベースであらためて設定が必要です。
SQL> alter database enable block change tracking; SQL> select status from V$BLOCK_CHANGE_TRACKING; STATUS ---------- ENABLED
2.3. FLASHBACK ON(Optionalただし実質的に必須)
Data GuardのREDO転送およびリカバリ自体はFlashback Databaseが設定されていなくても動作します。ただし、スタンバイ・データベースへのフェイルオーバーのテストや、スタンバイ・データベースを切り離してアプリケーションのテストなどに使用すると、プライマリ・データベースとはREDOログの内容がずれているのでそのままではREDOログ適用の再同期ができなくなります。これをFlashback Databaseを使用せずに再同期させるには、REDOログがずれる前に取得したフル・バックアップをリストアするか、現在のプライマリ・データベースから複製しなければなりません。つまりスタンバイ・データベースの再構築が必要になります。これを簡単に再同期できるようにするためには、Flashback Databaseの機能を使用しREDOログの内容がずれる前の時刻まで戻します。そのため、Data Guardをまともに運用しようとするならばFlashback Databaseの設定は実質的に必須です。
SQL> alter database flashback on; SQL> select flashback_on from v$database; FLASHBACK_ON -------------------- YES
3. REDO転送サービスの設定とリカバリ開始
3.1. tnsnames.ora
REDOログの転送先の情報はtnsnames.oraファイルのエントリを使用します。書式はアプリケーションが接続するときの書き方と同じで、Oracleリスナーのアドレスとサービス名を指定します。REDO転送の宛先のサービス名はCDB$ROOTのサービス、つまりデータベースのデフォルト・サービス名であるDB_UNIQUE_NAME.DB_DOMAINになります。
スタンバイ・データベース側にもプライマリ・データベースへの接続情報を作成しておきます。つまり、Data Guardを構成する全データベースへの接続情報をあらかじめ全ノードのtnsnames.oraに記述しておきます。
primary_database_net_alias = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = scan-host-name-primary)(PORT = scan-port)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = primary_SERVICE_NAMES) ) ) standby_database_net_alias = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = scan-host-name-standby)(PORT = scan-port)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = standby_SERVICE_NAMES) ) )
3.2. REDOログ転送サービスの初期化パラメータ
REDOログ送受信の設定はOracleインスタンスの初期化パラメータに設定します。プライマリとスタンバイの役割で設定するパラメータが異なりますが、プライマリとスタンバイの役割はいつか入れ替わるので、あらかじめすべての初期化パラメータをプライマリとスタンバイの両方に設定しておきます。Data Guardに関連する初期化パラメータはすべてALTER SYSTEM SET … SCOPE=BOTHで動的に設定できます。
3.2.1. アーカイブREDOログ・ファイルの出力先
プライマリとスタンバイ両方でLOG_ARCHIVE_DEST_1を設定しておきます。ここに指定するDB_UNIQUE_NAMEは自データベースの名前です。出力先はDB_RECOVERY_FILE_DESTを使用します。
SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=195G scope=spfile sid='*'; SQL> alter system set DB_RECOVERY_FILE_DEST='+RECO' scope=spfile sid='*'; SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db_unique_name' scope=spfile sid='*'; SQL> alter system set LOG_ARCHIVE_DEST_STATE_1='ENABLE' scope=spfile sid='*';
3.2.2. スタンバイ・データベース
REDOログ送受信の許可と、アーカイブREDOログ・ファイルをリモートから取得する場合の接続先を指定します。LOG_ARCHIVE_CONFIGのDG_CONFIGにはData Guardを構成するすべてのデータベースのDB_UNIQUE_NAMEを列挙します。FAL_SERVERはリモートのデータベース、つまりプライマリ・データベースへ接続するtnsnames.oraのエントリを指定します。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_DB_UNIQUE_NAME,standby_DB_UNIQUE_NAME)' scope=spfile sid='*'; SQL> ALTER SYSTEM SET FAL_SERVER='primary_alias' scope=spfile sid='*';
プライマリとスタンバイの役割はいつか入れ替わるので、あらかじめプライマリ・データベースにもFAL_SERVERは設定しておきます。
3.2.3. プライマリ・データベース
REDOログ送受信の許可と、REDOログ送信先を指定します。REDOログ送信先の指定にはアーカイブREDOログ・ファイルの出力先の指定と同様にLOG_ARCHIVE_DEST_nを使用します。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_DB_UNIQUE_NAME,standby_DB_UNIQUE_NAME)' scope=spfile sid='*'; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_database_net_alias ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_DB_UNIQUE_NAME' scope=spfile sid='*'; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2='ENABLE' scope=spfile sid='*';
LOG_ARCHIVE_DEST_nの指定でREDOログ転送サービスの動作モードが変わります。これは設定の一例です。詳しくはOracle Databaseのマニュアル「Data Guard概要および管理」を参照してください。
スタンバイとプライマリの役割はいつか入れ替わるので、スタンバイ・データベースにもあらかじめLOG_ARCHIVE_DEST_ｎを設定しておきます。
ALTER SYSTEM SETで設定が完了した瞬間に、REDOログの送受信が開始されます。
3.3. リカバリ開始
スタンバイ・データベースでリカバリを開始します。dbcaで複製が完了するとREAD ONLYでOPENした状態になっていました。これでリカバリを開始するとActive Data Guardになります。OPEN_MODEがREAD ONLY WITH APPLYになります。
SQL> select OPEN_MODE,DATABASE_ROLE from v$database; OPEN_MODE DATABASE_ROLE -------------------- -------------------- READ ONLY PHYSICAL STANDBY SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT; SQL> select OPEN_MODE,DATABASE_ROLE from v$database; OPEN_MODE DATABASE_ROLE -------------------- -------------------- READ ONLY WITH APPLY PHYSICAL STANDBY
3.4. スタンバイ・データベースの状態遷移
スタンバイ・データベースをREAD ONLY WITH APPLY状態にするActive Data GuardはEnterprise Editionの有償ライセンス・オプションです。READ ONLYでOPENせずにMOUNT状態にするData Guardフィジカル・スタンバイとの状態遷移はコマンドで操作します。
通常はData Guard(MOUNT)かActive Data Guard(OPEN READ ONLY)のどちらか片方に決め打ちして運用するので、起動手順としてはどちらもOracleインスタンス起動 → リカバリ開始になります。Oracleインスタンスの起動オプションが異なります。
まとめ
今回はData Guardフィジカル・スタンバイとその拡張であるActive Data Guardの動作原理と、手作業の場合に最低限なにを設定すればData Guardが構築できるかまでを解説しました。REDO転送モードの設定は要件に応じてマニュアルを参照してください。
Data GuardはREDO転送サービスと適用サービスの設定を行えば終わりというわけにはいきません。プライマリとスタンバイの役割の切り替え(ロール変換)などの運用を検討する必要があります。ですが今回は構築まで！
基本からわかる！高性能×高可用性データベースシステムの作り方 indexページ