Go to Qiita Advent Calendar 2024 Top
LoginSignup
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@sugimount(sugi mount)

[Oracle Cloud] DBCS リージョン間の高可用性構成をしてみた

Posted at

はじめに

Oracle Cloud Infrastructure(以下OCI)では、Oracle DB のマネージドサービス である、Database Cloud Service (略して DBCS) が提供されています。DBCS では簡単にマルチリージョンの可用性構成が組めます。
東京リージョンと大阪リージョンで災害対策したいときに、マルチリージョン構成が出来ます。この構成は、Oracle DB の Data Guard と呼ばれる機能で実現されています。

今回の記事では、マルチリージョン構成を試したので、その設定方法を忘れないように残しておきます。

リモートピアリング設定

東京リージョンと大阪リージョン間で、Data Guard を構成するために、リモートピアリング設定が必要です。次のURLを参照して設定していくとよいでしょう。リージョン間の疎通確認のために、Compute Instance をたてて Ping を実行していくのが良いと思います。

システム構成図

こんなかんじの構成を作っていきます。Tokyo が Primary で、Osaka が Standby です。

1593090298570.png

Network Security List

東京リージョンと大阪リージョン間で、互いに疎通するための Security List の設定を行います。上のシステム構成図と見比べると、理解しやすいと思います。
今回は、次の3種類を開放します。

  • ICMP (Ping)
  • SSH (TCP 22)
  • Oracle DB (TCP 1521)

Tokyo Region 側の設定

1593064726309.png

Osaka Region側の設定

1593064790998.png

Tokyo DBCS Create

Tokyo 側の DBCS を適当に作成します。

1593064862706.png

パラメータも適当に入れます。

1593064922835.png

パラメータも適当に入れたのちに、Create DB System を押します。

1593064996871.png

Provisioning されました。

1593065022622.png

一定時間後に Available になります。

1593071219536.png

Data Guard 構成

DBCS の管理画面上で、Data Guard を構成します。先ほど作成した Tokyo 側の DBCS をクリックします。

1593071261513.png

更に詳細画面に進みます。

1593071369536.png

Enable Data Guard を押します。

1593071400679.png

Osaka 側のパラメータを入れて、Enable ボタンを押します。

  • リモートピアリングを構成した VCN を指定
  • Password は Tokyo と同一のものを指定

1593071442609.png

Updating 状態となり、Osaka 側が作成されます。自分の環境では、1時間50分ほど完了までに時間が掛かりました。データ量によっても時間は変わってくるはずです。

1593071485273.png

一定時間後、Tokyo Region 側の画面に何やら変化があります。

1593071944566.png

Work Requests にも、Create Data Guard のジョブが表示されています。

1593071979725.png

Osaka Region 側を見ると、DBCS メニューで Provisioning 中の物が見えます。

1593072003428.png

Osaka 側 DBCS の詳細画面はこんな感じです。

1593072034954.png

完了後の Tokyo Region 側の画面の状態です。

1593085781433.png

Data Guard 設定確認

Tokyo Region 側の DBCS にログインして各種確認をします。
oracle user へスイッチします。

[opc@tokyodb03 ~]$ sudo su - oracle
Last login: Thu Jun 25 11:51:52 UTC 2020
[oracle@tokyodb03 ~]$

dgmgrl コマンドを起動

[oracle@tokyodb03 ~]$ dgmgrl /
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Thu Jun 25 11:53:02 2020
Version 19.7.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected to "tokyodb_nrt1m4"
Connected as SYSDG.
DGMGRL>

Data Guard 構成の詳細を確認。Tokyo と Osaka 側の DBCS が見えています。また、MaxPerformance Mode が Default となっていることもわかります。

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - tokyodb_nrt1m4_tokyodb_kix12q

  Protection Mode: MaxPerformance
  Members:
  tokyodb_nrt1m4 - Primary database             <== 1台目 : Tokyo
    tokyodb_kix12q - Physical standby database  <== 2台目 : Osaka

  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    TraceLevel                      = 'USER'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'
    ConfigurationWideServiceName    = 'tokyodb_CFG'

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS

DGMGRL>

なお、先ほどのコマンドの名前は、Unique Name が表示されています

1593086213249.png

Tokyo 側 DBCS の詳細です

DGMGRL> SHOW DATABASE VERBOSE tokyodb_nrt1m4;

Database - tokyodb_nrt1m4

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    tokyodb

  Properties:
    DGConnectIdentifier             = 'tokyodb_nrt1m4'
    ObserverConnectIdentifier       = ''
    FastStartFailoverTarget         = ''
    PreferredObserverHosts          = ''
    LogShipping                     = 'ON'
    RedoRoutes                      = ''
    LogXptMode                      = 'ASYNC'
    DelayMins                       = '0'
    Binding                         = 'optional'
    MaxFailure                      = '0'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyLagThreshold               = '30'
    TransportLagThreshold           = '30'
    TransportDisconnectedThreshold  = '30'
    ApplyParallel                   = 'AUTO'
    ApplyInstances                  = '0'
    StandbyFileManagement           = ''
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '0'
    LogArchiveMinSucceedDest        = '0'
    DataGuardSyncLatency            = '0'
    LogArchiveTrace                 = '0'
    LogArchiveFormat                = ''
    DbFileNameConvert               = ''
    LogFileNameConvert              = ''
    ArchiveLocation                 = ''
    AlternateLocation               = ''
    StandbyArchiveLocation          = ''
    StandbyAlternateLocation        = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    LogXptStatus                    = '(monitor)'
    SendQEntries                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    HostName                        = 'tokyodb03'
    StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=tokyodb03)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=tokyodb_nrt1m4_DGMGRL.tokyosubnet01.tokyovcn.oraclevcn.com)(INSTANCE_NAME=tokyodb)(SERVER=DEDICATED)))'
    TopWaitEvents                   = '(monitor)'
    SidName                         = '(monitor)'

  Log file locations:
    Alert log               : /u01/app/oracle/diag/rdbms/tokyodb_nrt1m4/tokyodb/trace/alert_tokyodb.log
    Data Guard Broker log   : /u01/app/oracle/diag/rdbms/tokyodb_nrt1m4/tokyodb/trace/drctokyodb.log

Database Status:
SUCCESS

DGMGRL>

Osaka 側 DBCS の詳細です

DGMGRL> SHOW DATABASE VERBOSE tokyodb_kix12q;

Database - tokyodb_kix12q

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 1.00 KByte/s
  Active Apply Rate:  516.00 KByte/s
  Maximum Apply Rate: 516.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    tokyodb

  Properties:
    DGConnectIdentifier             = 'tokyodb_kix12q'
    ObserverConnectIdentifier       = ''
    FastStartFailoverTarget         = ''
    PreferredObserverHosts          = ''
    LogShipping                     = 'ON'
    RedoRoutes                      = ''
    LogXptMode                      = 'ASYNC'
    DelayMins                       = '0'
    Binding                         = 'optional'
    MaxFailure                      = '0'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyLagThreshold               = '30'
    TransportLagThreshold           = '30'
    TransportDisconnectedThreshold  = '30'
    ApplyParallel                   = 'AUTO'
    ApplyInstances                  = '0'
    StandbyFileManagement           = ''
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '0'
    LogArchiveMinSucceedDest        = '0'
    DataGuardSyncLatency            = '0'
    LogArchiveTrace                 = '0'
    LogArchiveFormat                = ''
    DbFileNameConvert               = ''
    LogFileNameConvert              = ''
    ArchiveLocation                 = ''
    AlternateLocation               = ''
    StandbyArchiveLocation          = ''
    StandbyAlternateLocation        = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    LogXptStatus                    = '(monitor)'
    SendQEntries                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    HostName                        = 'osakadb03'
    StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=osakadb03)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=tokyodb_kix12q_DGMGRL.osakasubnet01.osakavcn.oraclevcn.com)(INSTANCE_NAME=tokyodb)(SERVER=DEDICATED)))'
    TopWaitEvents                   = '(monitor)'
    SidName                         = '(monitor)'

  Log file locations:
    Alert log               : /u01/app/oracle/diag/rdbms/tokyodb_kix12q/tokyodb/trace/alert_tokyodb.log
    Data Guard Broker log   : /u01/app/oracle/diag/rdbms/tokyodb_kix12q/tokyodb/trace/drctokyodb.log

Database Status:
SUCCESS

DGMGRL>

データの書き込み

Tokyo 側にテストデータを書き込みます。説明は省略して、コマンドだけ羅列します。

sqlplus / as sysdba

User Create

CREATE USER sugi IDENTIFIED BY Sug1_Passw0rd_dayo; 
GRANT CONNECT, RESOURCE TO sugi;
ALTER USER sugi quota unlimited on USERS; 
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

tnsnames 編集

vim $ORACLE_HOME/network/admin/tnsnames.ora

追記

pdbname=
(DESCRIPTION=
  (LOAD_BALANCE=off) 
  (ADDRESS=
    (PROTOCOL=tcp)  
    (HOST=10.0.0.9)  
    (PORT=1521)
  ) 
  (CONNECT_DATA=
    (SERVICE_NAME=pdb01.tokyosubnet01.tokyovcn.oraclevcn.com) 
    (FAILOVER_MODE=
      (TYPE=select) 
      (METHOD=basic)
    )
  )
)

PDB 接続

sqlplus sugi/Sug1_Passw0rd_dayo@pdbname

CREATE TABLE

CREATE TABLE emp 
 (
 empno VARCHAR2(10) NOT NULL,
 empname VARCHAR2(50),
 gender_f NUMBER(1,0)
 ) 
;

INSERT INTO

INSERT INTO emp VALUES (1, 2, 1);
INSERT INTO emp VALUES (2, 3, 1);
INSERT INTO emp VALUES (3, 2, 1);
COMMIT;

SELECT *

SELECT * FROM emp;

Result

SQL> SELECT * FROM emp;

EMPNO      EMPNAME                                              GENDER_F
---------- -------------------------------------------------- ----------
1          2                                                           1
2          3                                                           1
3          2                                                           1

Data Guard のデータ保護モードをMaxAvailabilityに変更

Data Guard には、コスト・可用性・パフォーマンス・データ保護のバランスをとるために、データ保護モードが3種類用意されています。下の表は3種類の特徴と概要を示したものです

参考元 : https://www.oracle.com/technetwork/jp/content/twp-dataguard-11gr2-134591-ja.pdf

モード データ損失のリスク 転送 スタンバイ・データベースからの確認がない場合の処理
最大保護 データ損失ゼロ 二重障害保護 SYNC トランザクションのREDOがディスクに書き込まれたことを示すスタンバイ・データベースからの確認を受信してから、コミットの成功をアプリケーションに通知します。
最大可用性 ハイブリッド 損失の可能性あり SYNC スタンバイ・データベースからの確認を受信するか、または NET_TIMEOUT しきい値に指定された期間が過ぎたら、いずれの場合もコミットの成功をアプリケーションに通知します。
最大パフォーマンス 最小限のデータ保護 損失の可能性あり ASYNC プライマリはスタンバイからの確認を待つことなく、コミットの成功をアプリケーションに通知します。

今回は検証の一環で、データ保護モードを変更してみます。
DGMGRL(Data Guard Brokerのコマンド・ユーティリティ)を使用して、最大可用性(MaxAvailability) モードに変更します

edit database tokyodb_nrt1m4 set property 'logXptMode'='SYNC';
edit database tokyodb_kix12q set property 'logXptMode'='SYNC';
edit configuration set protection mode as maxavailability;

実行例

DGMGRL> edit database tokyodb_nrt1m4 set property 'logXptMode'='SYNC';
Property "logXptMode" updated
DGMGRL> edit database tokyodb_kix12q set property 'logXptMode'='SYNC';
Property "logXptMode" updated
DGMGRL> edit configuration set protection mode as maxavailability;
Succeeded.
DGMGRL>

設定変更後の状態を確認します

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - tokyodb_nrt1m4_tokyodb_kix12q

  Protection Mode: MaxAvailability   <============== MaxAvailabilityになっている
  Members:
  tokyodb_nrt1m4 - Primary database
    tokyodb_kix12q - Physical standby database

  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    TraceLevel                      = 'USER'
    FastStartFailoverLagLimit       = '0'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'
    ConfigurationWideServiceName    = 'tokyodb_CFG'

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS

DGMGRL>

Tokyo側

DGMGRL> SHOW DATABASE VERBOSE tokyodb_nrt1m4;

Database - tokyodb_nrt1m4

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    tokyodb

  Properties:
    DGConnectIdentifier             = 'tokyodb_nrt1m4'
    ObserverConnectIdentifier       = ''
    FastStartFailoverTarget         = ''
    PreferredObserverHosts          = ''
    LogShipping                     = 'ON'
    RedoRoutes                      = ''
    LogXptMode                      = 'SYNC'　<============== SYNCになっている
    DelayMins                       = '0'
    Binding                         = 'optional'
省略

Osaka側

DGMGRL> SHOW DATABASE VERBOSE tokyodb_kix12q;

Database - tokyodb_kix12q

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 2.00 KByte/s
  Active Apply Rate:  574.00 KByte/s
  Maximum Apply Rate: 580.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    tokyodb

  Properties:
    DGConnectIdentifier             = 'tokyodb_kix12q'
    ObserverConnectIdentifier       = ''
    FastStartFailoverTarget         = ''
    PreferredObserverHosts          = ''
    LogShipping                     = 'ON'
    RedoRoutes                      = ''
    LogXptMode                      = 'SYNC'        <============== SYNCになっている
省略

スイッチオーバーのテスト

DGMGRL(Data Guard Brokerのコマンド・ユーティリティ)からスイッチオーバーの操作が出来ますが、OCI のコンソール画面上からも実行が可能です。
Switchover ボタンをクリックします

1593092629310.png

Password

1593092652770.png

Updating

1593092683858.png

約3分30秒ほど待つと、Tokyo と Osaka が入れ替わっています

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - tokyodb_nrt1m4_tokyodb_kix12q

  Protection Mode: MaxAvailability
  Members:
  tokyodb_kix12q - Primary database
    tokyodb_nrt1m4 - Physical standby database

Work Requests で開始と終了時刻が見えます

1593092981588.png

データの確認

フェールオーバーを実施したため、Osaka 側のテストデータを確認して、正常にスイッチオーバー出来たか見ます。Oracle ユーザーにスイッチします。

[opc@osakadb03 ~]$ sudo su - oracle
Last login: Thu Jun 25 13:51:09 UTC 2020
[oracle@osakadb03 ~]$

tnsnames 編集

vim $ORACLE_HOME/network/admin/tnsnames.ora

追記

pdbname=
(DESCRIPTION=
  (LOAD_BALANCE=off) 
  (ADDRESS=
    (PROTOCOL=tcp)  
    (HOST=172.16.0.6)  
    (PORT=1521)
  ) 
  (CONNECT_DATA=
    (SERVICE_NAME=pdb01.osakasubnet01.osakavcn.oraclevcn.com) 
    (FAILOVER_MODE=
      (TYPE=select) 
      (METHOD=basic)
    )
  )
)

PDB 接続

sqlplus sugi/Sug1_Passw0rd_dayo@pdbname

SELECT *

SELECT * FROM EMP;

Result
Osaka 側でも正常にデータを確認できました。リージョン間の Data Guard 構成が正常に出来ました。

SQL> SELECT * FROM emp;

EMPNO      EMPNAME                                              GENDER_F
---------- -------------------------------------------------- ----------
1          2                                                           1
2          3                                                           1
3          2                                                           1

参考URL

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?