Oracle導入に関する留意事項

Oracle導入に関する留意事項

   Active-Standby構成の両系のサーバでデータ領域が共有されることが前提となるため、インストールの際には両系でストレージ領域をマウントして上書きをする形で導入を行う。

   インストール時に初期のデータ領域を作成するかどうかは任意で選択できるが、今回はインストールの手順でデータ領域を作成せず、インストール終了後 に手動でデータ領域を作成することで作業時間を圧縮することが可能となる。また、共有ストレージ上のデータに両系からアクセスするためには、Oracle 管理ユーザのUIDが両系で同一であるように配慮しなければならない。

   またOracle ARKでは、Listenerのダウンを切り替えのトリガとはしていない。動作の仕様としては、監視対象として定義しておき、Listenerのダウン時に再度立ち上げることになる。

   この動作を期待する場合、Listenerに使用するVIPがLifeKeeperの保護対象リソースとして定義されており、Listener定義ファイルのHOSTにそのVIPが指定されている必要がある。

   Listenerファイルの定義方法については割愛するが、設定にあたりSteelEye社のWebページからダウンロード可能なOracle ARKのドキュメントを一読しておくことをお薦めする。

Oracle ARKによるHAクラスタ化

   OracleのHAクラスタ化に関しては、MySQLの構築手順で解説している事項については重複を避け必要な設定項目のみを紹介していく。

GUIからの設定

   MySQLの組み込み時と同様に、Oracleをプライマリサーバ上で起動した状態で、GUI画面から以下の操作を行って、をLifeKeeperのリソースとして組み込むことになる。

   まずGUI画面メニューバーから、「Edit → Resource → Create Resource Hierarchy 」を選択する。次にGUIの各画面から表7の項目を入力する。


画面名選択・入力内容
SelectRecoveryKITOracle Database(※7)
SwitchbackTypeIntelligent
ServerDBのプライマリサーバ
Oracle_SID for Databasethinkit(※8)
ORACLE_HOME for Database/opt/oracle/product/10.2.0(※9)
Database TagThinkIT(※10)
表7:Oracle ARKの設定項目

※注7: Oracleが選択肢にない場合は、Oracle ARKのパッケージ(SteelEye-lkORA-5.1.0-2)のインストールとライセンスの組み込みをする必要がある。
※注8、注9: oratabファイル内でORCALE_SIDとORACLE_HOMEを紐づけておく。
※注10: LifeKeeperの管理上の任意の名称を付ける。今回はThinkITとしたが、SIDと関連付けなくとも動作上に影響はない。

   以上の項目を入力後「Create」をクリックすることでプライマリサーバ側のORACLEリソースが作成される。

   MySQLの場合と同様に、これに続くリソース情報の拡張(Extend)のための手順は割愛する。今回はGUIからのOracleリソースのHA クラスタ化に関しては入力項目の紹介のみとなるが、MySQLと同様にGUI上からシンプルに構築を行うことができる。

   続いてMySQLのリソースを例に、LifeKeeperの主要な機能の確認手法について紹介する。

HAクラスタ化後の動作確認

   LifeKeeperの機能として最低限確認したい事項は以下の3点である。


  • 切り替え操作時の動作
  • ローカルリカバリの動作(障害時に現用系サーバ上でサービスの再起動を試行する)
  • フェイルオーバーの動作(ローカルリカバリに失敗した場合に待機系に自動的に切り替わる)
表8:確認するLifeKeeperの機能

   切り替え操作についてはGUI画面上から切り替わりを確認するだけであり、また本連載の「第3回:LifeKeeper for Linuxの操作」においても紹介をしているので割愛する。今回は残る2点の動作確認についてMySQLを例に紹介する。

ローカルリカバリの確認

   今回は、プロセスにKILLシグナルを送った場合の挙動でローカルリカバリが正常に動作することを確認していく。まずは、作業前の状態を確認する。

[root@ylk1 root]#lcdstatus -e
BACKUPTAGIDSTATEPRIO
ylk2.example.comMysql-ThinkITmysql7712ISP1
ylk2.example.comip-192.168.44.134IP-192.168.44.134ISP1
(以下出力略)

   表示の確認上、一部出力を割愛している点はあるが、アクティブ側のサーバ上でlcdstatus -eコマンドを打つと作成したMysql-ThinkITリソースのステートがISPとなっている。さらにpsコマンドとnetstatコマンドにより MySQLが起動していることを確認しておく。

[root@ylk1 root]# ps auxwww | grep mysql
root74320.00.05204156tty1SDec110:00
/bin/sh /usr/local/bin/mysqld_safe
(出力略)
mysql74970.04.710546412096tty1SDec110:02
/usr/local/libexec/mysqld
(以下出力略)
 
[root@ylk1 root]# netstat -anp | grep 3306
tcp000.0.0.0:33060.0.0.0:*LISTEN7497/mysqld

   上記のようにMySQLが正常に起動していることを確認できたら、これらのプロセスにKILLシグナルを送り擬似障害を発生させる。

[root@ylk1 root]# kill -9 7432 7497
[root@ylk1 root]# netstat -anp | grep 3306
[root@ylk1 root]#


   この時点で、MySQLが停止していることがわかる。LifeKeeperの障害検出のための監視は、初期設定であれば2分ごとに行われるため2分程度間隔をおいた後に再度起動状態を確認する。

[root@ylk1 root]# netstat -anp | grep 3306
tcp0 0 0.0.0.0:33060.0.0.0:*LISTEN17623/mysqld

   停止前と異なるPIDで3306番ポートをListenしていることがわかる。これにより、LifeKeeperのローカルリカバリによりMySQLが再度起動されたことを確認することができる。

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30