Oracle RAC環境へのノード追加
Grid Infrastructure（クラスタ環境）へのノード追加
事前準備
SSH接続構成
SSH接続構成（概要）
前回の作業でひとまず2ノードRACの構築が終わり、今回は新DBサーバ#3を3台目のノードとしてRACに追加します。
一口にRACのノード追加といっても中身は「Grid Infrastructure（クラスタ環境）へのノードの追加」、「Oracle Databaseホームの拡張」、「DBインスタンスの追加」に分かれておりまして、まずは「Grid Infrastructure（クラスタ環境）へのノードの追加」です。この作業にはいろいろトラップが仕込まれていますんで先にその辺のところを書いておきたいと思います。
「Oracle Clusterware管理およびデプロイメント・ガイド 26ai」にはGrid Infrastructureのクラスタ環境にノードを追加するための必須ステップとしての4つの準備作業が記載されています。
- 物理的な接続を確立
- オペレーティング・システムをインストール
- Oracleユーザーを作成
- ノード構成を検証、および指定ノード追加前のクラスタ整合性検証を行う場合、cluvfy stage -pre nodeaddコマンドを実行
新DBサーバは3台まとめてOSやデバイスを設定しているので1から3は既に終わっています。で、ここでデプロイメント・ガイド通りに4のcluvfy stage -pre nodeaddを実行すると必ず失敗*1するのでこの手順はスキップです。
デプロイメント・ガイドでは上の4つの準備作業を終えたらOracle Grid Infrastructureインストーラ（gridSetup.sh）を使ってノードを追加します。が、それを信じてgridSetup.shを実行するとSSH構成でコケてこれまた失敗*2します。
Grid Infrastructureの各ノードはパスワードなしの透過的なSSH接続（鍵交換）の構成が必須です。gridSetup.shで新規クラスタ構築を構築する場合、「クラスタ・ノードの情報」画面にあるSSH接続の「設定」ボタンをクリックすると自動でこの構成してくれます。
gridSetup.shのノード追加にもこれと似たようなボタンはあります。しかしこちらはクリックしても「[INS-06003] 次のノードとのパスワードなしのSSH接続の設定に失敗しました」というメッセージ*3を表示するだけのボタンで透過的なSSH接続の構成はやってくれません。SSHが構成できなければノードの追加はできずgridSetup.shの実行が失敗してしまうというという次第でございます。
この問題を回避するにはgridSetup.shに頼らず追加ノードのSSH構成をあらかじめ手動でやっておけばいいわけでして、そのための手順が「Grid Infrastructureインストレーションおよびアップグレード・ガイド 26ai for Linux」の「C インストール前のタスクの手動完了 – クラスタ・ノードでのSSHの構成」です。
が、ここにもまた問題があり、アップグレード・ガイドの手順通りに作業すると今度は既存ノードと追加ノード間の通信で別のアルゴリズムを使ってホスト認証する*4ようになってしまいます。
以下は既存ノードでgridユーザのSSH構成がどうなっているかを確認した結果です。
【新DBサーバ・prsdb01、prsdb02で実行】
-----------------------------------------------------------------------------
# gridユーザにスイッチ
su - grid
# gridユーザの.sshにあるファイルを確認
ls -a .ssh/
# known_hostsに登録されたサーバとホスト鍵アルゴリズムを確認
awk '{print $1" "$2}' .ssh/known_hosts
#--------------- 実機での実行結果 ---------------
# (prsdb01)
#-----------------------------
[root@prsdb01 ~]# su - grid
[grid@prsdb01 ~]$ ls -a .ssh/
. .. authorized_keys id_rsa id_rsa.pub known_hosts
[grid@prsdb01 ~]$
[grid@prsdb01 ~]$ awk '{print $1" "$2}' .ssh/known_hosts
prsdb02 ssh-rsa
prsdb01 ssh-rsa
[grid@prsdb01 ~]$
#-----------------------------
# (prsdb02)
#-----------------------------
[root@prsdb02 ~]# su - grid
[grid@prsdb02 ~]$ ls -a .ssh/
. .. authorized_keys id_rsa id_rsa.pub known_hosts
[grid@prsdb02 ~]$
[grid@prsdb02 ~]$ awk '{print $1" "$2}' .ssh/known_hosts
prsdb02 ssh-rsa
prsdb01 ssh-rsa
[grid@prsdb02 ~]$
この結果からわかることは3点。
- gridSetup.shは2ノードRAC構築時のSSH構成でRSAを指定してgridユーザの鍵ペアを生成
- ノード間のSSH接続にはパブリック・ネットワークのホスト名（ショートネーム形式）のみ使用
- ホスト鍵タイプはデフォルトのssh-ed25519ではなくssh-rsaを明示的に指定
「Grid Infrastructureインストレーションおよびアップグレード・ガイド 26ai for Linux」のSSH構成手順には1、2についての記述はありますが3については何も書いてありません。もしドキュメントの手順そのまま1、２だけ実行してしまうとRACノード間のホスト認証はこんな状態になってしまいます。
| ホスト認証 | 接続方向 | ホスト鍵タイプ |
| 既存ノードから既存ノード | prsdb01 -> prsdb02 prsdb02 -> prsdb01 | ssh-rsa |
| 既存ノードから追加ノード | prsdb01 -> prsdb03 prsdb02 -> prsdb03 | ssh-ed25519 |
| 追加ノードからすべてのノード | prsdb03 -> prsdb01 prsdb03 -> prsdb02 | ssh-ed25519 |
gridユーザ同士で鍵交換ができていればホスト鍵のタイプが何だろうと透過的なSSH接続は可能でしょうが、RACの構成上ノード間で設定差異があるのはよろしくありません。
なのでgridユーザの鍵交換を行う前にssh-keyscanを使ってRACノード間のホスト認証はすべてssh-rsaタイプのホスト鍵を使うように設定、それからgridユーザのSSH接続を構成を実行します。
*1：cluvfy stage -pre nodeaddを実行するとこんなエラーが返されます。
————————————————————————————————
「PRKN-1038 : ノード”prsdb01″で実行されるコマンド”/usr/bin/ssh -o FallBackToRsh=no -o PasswordAuthentication=no -o StrictHostKeyChecking=yes -o NumberOfPasswordPrompts=0 prsdb03 -n /bin/true”で予期しない出力が発生 しました」
「ED25519 host key is known for prsdb03 and you have requested strict checking.Host key verification failed.」
————————————————————————————————
このSSHコマンドが成功するには既存ノードのknown_hostsに追加ノードの情報が記録されており、さらにパスワードなしの透過的なSSH接続ができるように設定（鍵交換）されていなきゃなりません。でもデプロイメント・ガイドだとSSHの構成って次のフェーズ（gridSetup.shでノード追加）の話なんですよね。この時点では何の設定もないので当然cluvfyは失敗します。
ちなみにRHEL9のsshコマンド（OpenSSH_8.7p1）のmanページにはオプションにFallBackToRshはなく、Geminiさんによればとっくの昔に廃止されたオプションだとか。どうもこのへんのところは古いバージョンのGrid Infrastructureの仕組みそのままのような気がしますがそろそろ見直した方がよろしいんじゃなかろうか、というのが私の個人的な感想でございます。
*2：gridSetup.shのノード追加がSSH構成でしくじるのはOracle 21cでも同様でして私はこれを21cのgridSetup.shのバグだと思っておりました。ところがOracle 26aiでも相変わらずSSH構成がダメなんですよね。ということは、実はこれが仕様なんじゃなかろうかと今では思います。こんな仕様にしている理由は私のような無課金勢を振るい落とすため、というのは私の勝手な推測でまったく根拠はありません。
*3：メッセージの全文がコレ。
—————————————————-
[INS-06003] 次のノードとのパスワードなしのSSH接続の設定に失敗しました: [prsdb03]
原因 – 失敗したノードで異なるオペレーティング・システムが実行されているか、アクセスできない可能性があります。アクセス可能な場合、ローカル・マシンと同じオペレーティング・システムを実行している場合は、SSHデーモンが選択したノードで構成されていない可能性があります。
—————————————————-
原因に表示される内容はどれもぜんぜん的外れなんで実際には何のチェックもやらずに機械的にこのメッセージをだしているってことじゃなかろうかと思います。
*4：私がこの点に気づいたのはOracle 21cでのノード追加がきっかけです。ガイドの手順まんまに手動でSSHを構成してからgridSetup.shを実行したらなんかヘンなエラーが出たもんで、それでいろいろ環境をチェックしたら既存ノードと追加ノードでホスト鍵のアルゴリズムが食い違っていることに気づいた次第でございます。うかつにも私はこのときのエラー・メッセージを保存しておらずホスト鍵アルゴリズムの食い違いがエラーの原因だったかどうか、はっきりしたことは今となってはわかりまぜん。まあ、ホスト鍵アルゴリズムを統一した後でgridSetup.sh実行中にエラーは出ていないんでたぶんそうだったんじゃないかなぁとは思ってます。いずれにせよノード間の設定は極力同じにしておいた方が無難です。
SSH接続構成（設定）
ここから手動によるSSHの構成の作業です。
この作業では既存ノードのSSH構成も変更します。既存ノードでCRSが起動している場合は念のためCRSを停止しておきます。
【新DBサーバ・prsdb01、prsdb02 / rootユーザで実行】 ----------------------------------------------------------------------------- # prsdb02 -> prsdb01の順にCRSを停止 /opt/app/26.0.0/grid/bin/crsctl stop crs
まず追加ノード（新DBサーバ#3）のgridユーザで鍵ペア生成のついでに.sshディレクトリを作成します。
【新DBサーバ・prsdb03で実行】
-----------------------------------------------------------------------------
# gridユーザにスイッチ
su - grid
# RSAタイプの鍵ペアを生成
ssh-keygen -t rsa
# -> 入力要求には何も入力せず、すべてEnterキー押下
# .sshディレクトリが作成されたことを確認
ls -a
# .sshディレクトリにRSAタイプの鍵ペアが作成されたことを確認
ls .ssh/
既存ノード（新DBサーバ#1）のgridユーザで追加ノード（新DBサーバ#3）からssh-rsaタイプのホスト鍵を収集してknown_hostsに追記、このknown_hostsを既存ノード（新DBサーバ#2）と追加ノード（新DBサーバ#3）に配布します。また、鍵交換を行うため追加ノードにはauthorized_keysも送付します。
【新DBサーバ・prsdb01 / gridユーザで実行】
-----------------------------------------------------------------------------
# gridユーザの${HOME}/.sshに移動
cd .ssh
# known_hostsをバックアップ
cp known_hosts known_hosts.bk
# authorized_keysをバックアップ
cp authorized_keys authorized_keys.bk
# known_hostsに追加ノード（新DBサーバ#3）のエントリが存在する場合は削除
sed -i '/^prsdb03/d' known_hosts
# 追加ノード（新DBサーバ#3）からssh-rsaタイプのホスト鍵を収集してknown_hostsに追記
ssh-keyscan -t rsa prsdb03 >> known_hosts
# known_hostsに追加ノードのホスト鍵（ssh-rsaタイプ）が登録されていることを確認
cat known_hosts
# known_hostsを既存ノード（新DBサーバ#2）に転送
scp known_hosts prsdb03:~/.ssh/
# authorized_keysを追加ノード（新DBサーバ#3）に転送
scp authorized_keys prsdb03:~/.ssh/
# known_hostsを追加ノード（新DBサーバ#3）に転送
scp known_hosts prsdb03:~/.ssh/
追加ノード（新DBサーバ#3）でgridユーザの公開鍵をauthorized_keysに追記して既存ノード（新DBサーバ#1、新DBサーバ#2）に送付します。
【新DBサーバ・prsdb03 / gridユーザで実行】
-----------------------------------------------------------------------------
# authorized_keys、known_hostsが転送されていることを確認
ls
# 追加ノード（新DBサーバ#3）の公開鍵をauthorized_keysに追記
cat id_rsa.pub >> authorized_keys
# authorized_keysに既存、追加すべてのノードの公開鍵が記載されていることを確認
cat authorized_keys
# 最新のauthorized_keyを既存ノード（新DBサーバ#1、新DBサーバ#2）に転送
scp authorized_keys prsdb01:~/.ssh/
scp authorized_keys prsdb02:~/.ssh/
各ノードでSSHコマンドを実行して透過的にSSH接続ができることを確認します。
【新DBサーバ・prsdb01、prsdb02、prsdb03 / gridユーザで実行】
-----------------------------------------------------------------------------
# 自ノードから新DBサーバ#01への透過的SSH接続を確認
ssh prsdb01 date
# 自ノードから新DBサーバ#02への透過的SSH接続を確認
ssh prsdb02 date
# 自ノードから新DBサーバ#03への透過的SSH接続を確認
ssh prsdb03 date
どのノード宛のコマンドもパスワード要求なしに結果が返されるパスワード要求なしに結果が返されれば手動によるSSH接続の構成は完了です。
NOZEROCONFの設定
gridSetup.shによるGrid Infrastructureインストール及び構成の前提条件チェックにはZeroconf（OS側のmDNS）無効化という項目があります。
このチェックでgridSetup.shはOSのｍDNS関連サービスやソケットが無効化されていることを確認するとともに、/etc/sysconfig/networkファイルに”NOZEROCONF=yes”と自分で書き込んでから「ｍDNSを扱うOSのサービスは無効化されてるしネットワーク定義ファイルに”NOZEROCONF=yes”が設定されているんでチェックOK」というわけの分からないことをやっています*1。
【新DBサーバ・prsdb01の/etc/sysconfig/network（ノード追加前）】
-----------------------------------------------------------------------------
[root@prsdb01 ~]# cat /etc/sysconfig/network
# Created by anaconda
NOZEROCONF=yes <-- gridSetup.shが”NOZEROCONF=yes”を追加
[root@prsdb01 ~]#
-----------------------------------------------------------------------------
【新DBサーバ・prsdb02の/etc/sysconfig/network】
-----------------------------------------------------------------------------
[root@prsdb02 ~]# cat /etc/sysconfig/network
# Created by anaconda
NOZEROCONF=yes <-- gridSetup.shが”NOZEROCONF=yes”を追加
[root@prsdb02 ~]#
-----------------------------------------------------------------------------
【新DBサーバ・prsdb03の/etc/sysconfig/network】
-----------------------------------------------------------------------------
[root@prsdb03 ~]# cat /etc/sysconfig/network
# Created by anaconda <--ファイルの中身はコメントだけ
[root@prsdb03 ~]#
で、更にわけのわからないことにgridSetup.shはノード追加の場合、新しく追加するノードに対してこの/etc/sysconfig/networkファイルへの書き込みをやりません。それでも前提条件チェックの判定条件はインストール＆構成ときと同じなので、たとえ追加ノードのｍDNSが無効化されていたとしても「/etc/sysconfig/networkに”NOZEROCONF=yes”が設定されてないんでチェックNG」というふざけた判定を下します。
この判定は警告レベルなので無視してもどうってことはありません。しかしこのバカげた警告メッセージを読むのは（ムカついて）メンタル的には大いにマイナスなので、それを回避するためにgridSetup.shでノード追加を実行する前にあらかじめ既存ノードの/etc/sysconfig/networkを追加ノードに転送しておきます。
【新DBサーバ・prsdb01 / gridユーザで実行】
-----------------------------------------------------------------------------
# /etc/sysconfig/networkを追加ノードに転送
scp /etc/sysconfig/network prsdb03:/etc/sysconfig/
*1：RHEL9のネットワーク制御は/etc/sysconfig/networkをまったく使用していないのでこのファイルに何が書かれていてもガン無視です。gridSetup.shがこのファイルに”NOZEROCONF=yes”を書き込むのは単に自分がやっているZeroconf無効化チェックにOKを出すためという理由しかありません。gridSetup.shの前提条件チェックが古いLinuxバージョンでの判定ロジックをそのまま引き継いでしまっているのでこんな苦し紛れなことをしているんだろうとは思いますが、だったら判定ロジックの方を直せよと。
2：追加ノードでｍDNS関連サービスを無効化しているにもかかわらず、gridSetup.shによるノード追加の前提条件チェックでなぜこの警告メッセージが出てきたかを理解した瞬間、私は「マジ死ねよ」と思いました。
CRS起動
「透過的なSSH接続の手動構成」で停止した既存ノードのCRSを新DBサーバ#1 -> 新DBサーバ#2の順に起動します。
【新DBサーバ・prsdb01、prsdb02 / rootユーザで実行】
-----------------------------------------------------------------------------
# prsdb01 -> prsdb02の順にCRSを起動
/opt/app/26.0.0/grid/bin/crsctl start crs -wait
Grid Infrastructure（クラスタ環境）のノード追加
既存ノード（新DBサーバ#1）でgridSetup.shを実行してGrid Infrastructure（クラスタ環境）にノード（新DBサーバ#3）を追加します。
まずは新DBサーバ#1のgridユーザでVNC Serverを起動します。
【新DBサーバ・prsdb01 / gridユーザで実行】
-----------------------------------------------------------------------------
# VNC Server起動
vncserver :1
VNC Viewerで新DBサーバにログイン後、ターミナルからgridSetup.shを起動します。
【新DBサーバ・prsdb01 / VNC Viewerで実行】
-----------------------------------------------------------------------------
# gridSetup.sh起動
/opt/app/26.0.0/grid/gridSetup.sh
Grid Infrastructureインストーラ画面を操作して新DBサーバ#3をクラスタ・ノードに追加します。
【Grid Infrastructureインストーラ画面操作手順】
| No. | 画面 | 操作 |
| 1 | 構成オプションの選択 | 「クラスタに、さらにノードを追加してください」選択 |
| ２ | クラスタのノード追加情報 | ①「追加(A…)」クリック → 「クラスタ・ノードの情報の追加」画面表示 ② 以下の通り入力して「OK(O)」クリック —————————————————- パブリックホスト名(H)：prsdb03.exsample.lan 仮想ホスト名(V) ：prsdb03-vip.exsample.lan —————————————————- ③ 「SSH接続'(C…)」クリック ④ 「ユーザー・ホームに存在する…」にチェックが入っていることを確認 ⑤ 「次へ(N)」クリック ※「次へ(N)」で |
| 2′ | クラスタのノード追加情報 | 「[INS-40111] 指定されたOracleベースの場所が次のノードで空ではありません: [prsdb03]。続行しますか。」というメッセージが表示されたら「はい(Y)」をクリック*1 |
| 3 | 前提条件チェックの実行 | チェック中にエラーや警告が出力されないことを確認。 何も問題がなければ画面操作不要でサマリーに遷移 |
| 4 | サマリー | 設定内容に問題がなければ「送信(I)」クリック |
| 5 | 製品のインストール | 「構成スクリプトの実行」が表示されたら画面指示に従って新DBサーバ#3（prsdb03）のrootユーザで以下のスクリプトを実行 /opt/app/oraInventory/orainstRoot.sh /opt/app/26.0.0/grid/root.sh ※入力要求はすべてEnterキー押下 スクリプトの実行にエラーがなく正常終了メッセージ「CLSRSC-325: Oracle Grid Infrastructureをクラスタ用に設定します … 成功しました」が表示されたら「OK(O)」をクリックして「構成スクリプトの実行」画面終了 |
| 6 | 終了 | 正常終了メッセージ「クラスタ用のOracle Grid Infrastructureのノードの追加が成功しました」を確認して「閉じる(C)」クリック → インストーラが終了したらターミナルを閉じてVNC Viewerからログアウト |
新DBサーバ#3でgridユーザの .bash_profile に環境変数設定を追加します。
【新DBサーバ・prsdb03 / gridユーザの.bash_profileに追記】
-----------------------------------------------------------------------------
export ORACLE_BASE=/opt/app/grid
export ORACLE_HOME=/opt/app/21.0.0/grid
export LD_LIBRARY_PATH=${ORACLE_HOME}/lib
export ORACLE_SID=+ASM3
export PATH=${ORACLE_HOME}/bin:${PATH}
新DBサーバ#3のgridユーザが自ノードのASMインスタンスに接続できることを確認します。接続に問題がなければCRSの自動起動を無効化してクラスタ・リソース状態の確認を行います。
【新DBサーバ・prsdb03 / gridユーザで実行】
-----------------------------------------------------------------------------
# gridユーザからログアウト
exit
# gridユーザで再ログイン（スイッチ・ユーザ）
su - grid
# sqlplusを起動してASMインスタンスに接続
sqlplus / as sysasm
# 接続しているインスタンスが＋ASM3であることを確認
select instance_name from v$instance;
# sqlplus終了
exit
# gridユーザからログアウト（grid → rootにユーザ復帰）
exit
# CRS自動起動無効化
/opt/app/26.0.0/grid/bin/crsctl disable crs
# CRS自動起動無効確認
/opt/app/26.0.0/grid/bin/crsctl config crs
# クラスタ・リソース確認（リソース状態が確認できればOK）
/opt/app/26.0.0/grid/bin/crsctl status res -t
*1：追加ノードのOracleベース（/opt/app/grid）が元々カラだとしてもインストーラ画面を操作するうちにgridSetup.shが追加ノードのOracleベース（/opt/app/grid/）にcrsdataディレクトリ及びその下のゴミっぽい何かを勝手に作成してしまいます。で、ふざけたことに「Oracleベースがカラじゃないんすけどいいんすか？」ときます。いや、オマエがそこにゴミぶん投げたんだろうよと。
裏（teraterm）でこのcrsdataディレクトリを削除してからインストーラ画面を先に進めるか、ガン無視でそのまま先に進むか、どっちがいいかちょっと迷ってGeminiさんに相談したら「ノード追加が正常に終わればcrsdataはきれいな形で上書きされるだろうから削除いらんのでは」ということでメッセージはガン無視で先に進むことにしました。マジ疲れます。
Oracle Databaseホームの拡張
事前準備
透過的なSSH接続の手動構成
Oracle Databaseホームの拡張でもインストーラによる透過的SSH接続の構成がエラーとなるかどうかはわかりませんが、とりあえずoracleユーザのSSH接続も手動で構成しておきます。
まずは安全のため既存ノード（新DBサーバ#1）のoracleユーザでDB（PRDB）を停止、ついでにホスト鍵とoracleユーザの鍵ペアの暗号アルゴリズム（鍵タイプ）を確認します。
【新DBサーバ・prsdb01 で実行】
-----------------------------------------------------------------------------
# oracleユーザにスイッチ
su - oracle
# PDB(PRPDB）停止
srvctl stop pdb -db prdb -pdb prpdb
# DB(PRPDB）停止
srvctl stop database -db prdb
# 鍵ペアを確認
ls .ssh
authorized_keys id_rsa id_rsa.pub known_hosts
[oracle@prsdb01 .ssh]$
# oracleユーザのknown_hostsに登録された既存ノードのホスト鍵アルゴリズムを確認
awk '{print $1" "$2}' .ssh/known_hosts
prsdb02 ssh-rsa
prsdb01 ssh-rsa
[oracle@prsdb01 .ssh]$
追加ノード（新DBサーバ#3）のoracleユーザで鍵ペア生成のついでに.sshディレクトリを作成します。
【新DBサーバ・prsdb03 で実行】
-----------------------------------------------------------------------------
# oracleユーザにスイッチ
su - oracle
# RSAタイプの鍵ペアを生成
ssh-keygen -t rsa
# -> 入力要求には何も入力せず、すべてEnterキー押下
# .sshディレクトリが作成されたことを確認
ls -a
# .sshディレクトリにRSAタイプの鍵ペアが作成されたことを確認
ls .ssh/
既存ノード（新DBサーバ#1）のoracleユーザで追加ノード（新DBサーバ#3）からssh-rsaタイプのホスト鍵を収集してknown_hostsに追記、このknown_hostsを既存ノード（新DBサーバ#2）と追加ノード（新DBサーバ#3）に配布します。また、鍵交換を行うため追加ノードにはauthorized_keysも送付します。
【新DBサーバ・prsdb01 / oracleユーザで実行】
-----------------------------------------------------------------------------
# oracleユーザの${HOME}/.sshに移動
cd .ssh
# known_hostsをバックアップ
cp known_hosts known_hosts.bk
# authorized_keysをバックアップ
cp authorized_keys authorized_keys.bk
# known_hostsに追加ノード（新DBサーバ#3）のエントリが存在する場合は削除
sed -i '/^prsdb03/d' known_hosts
# 追加ノード（新DBサーバ#3）からssh-rsaタイプのホスト鍵を収集してknown_hostsに追記
ssh-keyscan -t rsa prsdb03 >> known_hosts
# known_hostsに追加ノードのホスト鍵（ssh-rsaタイプ）が登録されていることを確認
cat known_hosts
# known_hostsを既存ノード（新DBサーバ#2）に転送
scp known_hosts prsdb03:~/.ssh/
# authorized_keysを追加ノード（新DBサーバ#3）に転送
scp authorized_keys prsdb03:~/.ssh/
# known_hostsを追加ノード（新DBサーバ#3）に転送
scp known_hosts prsdb03:~/.ssh/
追加ノード（新DBサーバ#3）でoracleユーザの公開鍵をauthorized_keysに追記して既存ノード（新DBサーバ#1、新DBサーバ#2）に送付します。
【新DBサーバ・prsdb03 / oracleユーザで実行】
-----------------------------------------------------------------------------
# カレント・ディレクトリを.sshに移動
cd .ssh
# 既存ノード（新DBサーバ#1）からauthorized_keys、known_hostsが転送されていることを確認
ls
# authorized_keysに自身の公開鍵を追記
cat id_rsa.pub >> authorized_keys
# authorized_keysに自身の公開鍵が追記されたことを確認
cat authorized_keys
# authorized_keysを既存ノードに配布
scp authorized_keys prsdb01:~/.ssh/
scp authorized_keys prsdb02:~/.ssh/
各ノードでSSHコマンドを実行して透過的にSSH接続ができることを確認します。
【新DBサーバ・prsdb01、prsdb02、prsdb03 / gridユーザで実行】
-----------------------------------------------------------------------------
# 自ノードから新DBサーバ#01への透過的SSH接続を確認
ssh prsdb01 date
# 自ノードから新DBサーバ#02への透過的SSH接続を確認
ssh prsdb02 date
# 自ノードから新DBサーバ#03への透過的SSH接続を確認
ssh prsdb03 date
どのノード宛のコマンドもパスワード要求なしに結果が返されるパスワード要求なしに結果が返されれば手動によるSSHの構成は完了です。
ここまでの作業に問題がなければ既存ノード（新DBサーバ#1）のoracleユーザでDBを起動します。
【新DBサーバ・prsdb01 / oracleユーザで実行】
-----------------------------------------------------------------------------
# DB(PRPDB）起動
srvctl start database -db prdb
# DB(PRDB）起動確認
srvctl status database -db prdb
# PDB(PRPDB）起動確認
srvctl status pdb -db prdb
Oracle Databaseホームの拡張
既存ノードのoracleユーザでOracle Databaseインストーラ（runInstaller）を実行してOracle Databaseホームを拡張します*1。
まずは新DBサーバ#1のoracleユーザでVNC Serverを起動します。
【新DBサーバ・prsdb01 / oracleユーザで実行】
-----------------------------------------------------------------------------
# VNC Server起動
vncserver :1
VNC Viewerで新DBサーバにログインしてターミナルからrunInstallerを起動します。
【新DBサーバ・prsdb01 / oracleユーザ VNC Viewerで実行】
-----------------------------------------------------------------------------
# Oracle Databaseインストーラ起動
/opt/app/oracle/product/26.0.0/dbhome_1/runInstaller
Oracle Databaseインストーラ画面を以下のように操作してDBサーバ#3にOracle Databaseホームを拡張します。
【Oracle Databaseインストーラ画面操作手順】
| No. | 画面 | 操作 |
| 1 | 構成オプションの選択 | 「Oracle RACクラスタへのノードの追加」を選択 |
| 2 | ノードの選択 | 「prsdb03」チェック 「SSH接続(C)…」をクリックして「ユーザー・ホームに存在する…」にチェックが入っていることを確認 |
| 3 | 前提条件チェックの実行 | エラーが出力されないことを確認。 何も問題がなければ画面操作不要でサマリーに遷移 |
| 4 | サマリー | 設定内容に問題がなければ「送信(I)」クリック |
| 5 | 製品のインストール | 「構成スクリプトの実行」が表示されたら画面指示に従って新DBサーバ#3（prsdb03）のrootユーザで以下のスクリプトを実行 /opt/app/oracle/product/21.0.0/dbhome_1/root.sh ※入力要求はすべてEnterキー押下 スクリプトの実行にエラーがなければ「OK(O)」をクリックして「構成スクリプトの実行」画面終了 |
| 6 | 終了 | 正常終了メッセージ「Oracle Databaseのノードの追加が成功しました」を確認して「閉じる(C)」クリック |
Oracle Dataase環境の拡張が正常終了したらターミナルを閉じてDBサーバ#1（VNC Viewer）からログアウトします。
最後に新DBサーバ#3の${ORACLE_HOME}を確認してディレクトリやファイルが配置されていればひとまずOracle Databaseホームの拡張は完了です。
【新DBサーバ・prsdb03で実行】
-----------------------------------------------------------------------------
# ${ORACLE_HOME}にディレクトリやファイルが配置されていることを確認
ls /opt/app/oracle/product/26.0.0/dbhome_1
OPatch ctx instantclient nls plsql slax
QOpatch cv inventory odbc precomp sqlcl
R data javavm olap python sqlj
addnode dbs jdbc oml4py racg sqlpatch
admin deinstall jdk opmn rdbms sqlplus
assistants demo jlib oraInst.loc relnotes srvm
bin diagnostics ldap oracore root.sh suptools
cfgtoollogs dv lib ord root.sh.old ucp
clone env.ora log ords root.sh.old.1 usm
crs has md oss runInstaller utl
crypto hs mgw oui schagent.conf xdk
css install network perl sdk
[oracle@prsdb03 ~]$
少し長くなったというか、ここまで書いてだいぶメンタルすり減ったので一旦ここで切ります。次は追加ノードへのOracle RACデータベース・インスタンスの追加です。
*1：「Real Application Clusters管理およびデプロイメント・ガイド」にはこちらの環境のようにローカルなOracleホームの拡張（ノード追加）についてaddnode.shを-silentで実行する手順しか記述されておらずGUIでの実行手順がありません。Geminiさんによれば「最近の公式ドキュメントでは、構成の自動化やオペミス回避目的でノード追加・削除といった運用コマンドの解説をサイレント（CUI）モードに一本化の傾向」だそうでございます。でも、Grid Infrastructureの場合はデプロイメント・ガイドのノード追加手順がGUIなんですよね。どっちなんだよと。
他のドキュメントにもGUIによるOracleホームの拡張手順は載っていないとのことで、仕方がないからCLIでやってしまおうかとも思ったんですがOracle 21cでのOracleホーム拡張はGUIでやってますんでできればここでやり方を変えたくない。
で、addnode.shを-silentなしで叩いてみたら「このバージョンではaddnodeでのノード追加は非推奨。やるならDBインストーラを使え」といった感じのメッセージが出てきて最終的にrunInstallerでOracleホームの拡張を実行した次第です。まあ長々と書きましたけど何が言いたいかというと私がここに書いたrunInstallerをGUIで実行する手順は公式ドキュメントの通りではありません。つーても、ここまでの流れからいってその公式ドキュメントがまるでアテにならんからなぁ…
おまけ：addnode.sh -silentでOracle Databaseホームを拡張したらどうなるか
折角なのでrunInstallerで追加したノードを一旦削除して「Real Application Clusters管理およびデプロイメント・ガイド」に書かれたとおりにaddnode.sh -silentでOracle Databaseホームを拡張したらどうなるかも載せておこうと思います*1。
【新DBサーバ・prsdb01でaddnode.shをCLI実行した結果…】
-----------------------------------------------------------------------------
[root@prsdb01 ~]# su - oracle
[oracle@prsdb01 ~]$ cd /opt/app/oracle/product/26.0.0/dbhome_1/addnode/
[oracle@prsdb01 addnode]$ ./addnode.sh -silent "CLUSTER_NEW_NODES=prsdb03"
[INFO] [INS-35507] addnode.shまたはaddnode.batを使用したノードの追加はこのリリースでは非推奨です。かわりに、Oracle Databaseインストーラを使用してRACノードの追加を実行します。
構成の準備が進行中です。
構成の準備が正常に終了しました。
.................................................. 7% 完了しました。
リモート・ノードへのファイルのコピーが進行中です。
リモート・ノードへのファイルのコピーが正常に終了しました。
.................................................. 22% 完了しました。
このインストール・セッションのログは次の場所にあります:
/opt/app/oraInventory/logs/installActions2026-10-18_05-27-21PM.log
ファイルを初期化しますが進行中です。
ファイルを初期化しますが正常に終了しました。
.................................................. 52% 完了しました。
クラスタ・インベントリを保存していますが進行中です。
.................................................. 89% 完了しました。
クラスタ・インベントリを保存していますが正常に終了しました。
/opt/app/oracle/product/26.0.0/dbhome_1のクラスタ・ノードの追加が成功しました。
詳細は'/opt/app/oraInventory/logs/silentInstall2026-10-18_05-27-21PM.log'を確認 してください。
Oracleベースの設定が進行中です。
Oracleベースの設定が正常に終了しました。
.................................................. 96% 完了しました。
rootユーザーとして次のスクリプトを実行します:
1. /opt/app/oracle/product/26.0.0/dbhome_1/root.sh
次のノードで/opt/app/oracle/product/26.0.0/dbhome_1/root.shを実行してください:
[prsdb03]
Successfully Setup Software.
.................................................. 100% 完了しました。
[oracle@prsdb01 addnode]$
結局、runInstaller呼び出しているだけ…
*1：このあとaddnode.sh（CLI）でもう一度runInstaller（GUI）でOracle Databaseホームを拡張しています。
DBサーバ構築（Oracle 26ai）・関連ページ
DBサーバ構築、Oracle 26ai（１）概要
DBサーバ構築、Oracle 26ai（２）OS、N/W、ストレージ
DBサーバ構築、Oracle 26ai（３）Gridインストール１
DBサーバ構築、Oracle 26ai（４）Gridインストール２
DBサーバ構築、Oracle 26ai（５）DBインストール
DBサーバ構築、Oracle 26ai（６）2ノードRAC構築 1 （DB設計）
DBサーバ構築、Oracle 26ai（６）2ノードRAC構築 2 （DB構築）
DBサーバ構築、Oracle 26ai（６）2ノードRAC構築 3 （アーカイブログ、HugePages他）
DBサーバ構築、Oracle 26ai（7）RACノード追加 1（Gridノード追加、Oracleホーム拡張）
コメント