障害復旧のための SAP HANA スケールアップマルチターゲットシステムレプリケーションの設定
概要
多様性を受け入れるオープンソースの強化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat では、コード、ドキュメントにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。多様性を受け入れる用語に変更する取り組みの詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
Jira からのフィードバック送信 (アカウントが必要)
第1章 概要 リンクのコピーリンクがクリップボードにコピーされました!
可用性に対する要求が高まっているため、データのコピーは 1 つだけでは十分ではありません。
ビジネスの継続性を確保するには、信頼性と可用性の高いアーキテクチャーを使用し、複数のシステム間でデータをレプリケートする必要があります。マルチターゲットシステムレプリケーションを使用すると、プライマリーシステムのデータ変更を複数のセカンダリーシステムにレプリケートできます。詳細は、SAP HANA Multitarget System Replication を参照してください。
このドキュメントでは、RHEL HA Add-On を使用した SAP HANA Scale-Up System Replication の自動化 の説明に従って、インストールされた 2 ノードクラスター上の SAP HANA Multitarget System Replication を使用して、障害復旧用にレプリケーションサイトを設定する方法を説明します。
設定の例を以下に示します。
初期設定は次のとおりです。
- プライマリーサイト 1 (DC1) をセカンダリーサイト 2 (DC2) にレプリケート
- プライマリーサイト 1 (DC1) をセカンダリーサイト 3 (DC3) にレプリケート
プライマリーに障害が発生した場合、プライマリーはセカンダリーサイト 2 (DC2) に切り替わり、以前のプライマリーサイト 1 (DC1) がセカンダリーサイトになります。
フェイルオーバーが発生すると、このソリューションにより、設定されたプライマリーサイトが 3 番目の DR サイトでも確実に切り替えられます。フェイルオーバー後の設定は次のとおりです。
- プライマリーが DC2 で稼働
- セカンダリーが DC1 で稼働 (DC2 から同期)
- セカンダリーが DC3 で稼働 (DC2 から同期)
このインスタンスがフェイルオーバー中に稼働している限り、remotehost3 上の SAP HANA インスタンスは、新しいプライマリーに自動的に再登録されます。
このドキュメントでは、プライマリーデータベースを 3 番目のサイトに切り替える例も説明します。
クライアントをデータベースに接続するには、さらにネットワーク設定が必要であることに注意してください。ネットワーク設定はこのドキュメントの範囲外です。
詳細は、以下を参照してください。
第2章 パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存の 2 ノードクラスターの次のパラメーターが、3 番目のサイトのセットアップに使用されます。
| パラメーター | 例 | 説明 |
|---|---|---|
| SID | RH2 | HANA データベースのシステム ID |
| First SITE | DC1 | 1 番目のデータセンター/サイトの名前 |
| Second SITE | DC2 | 2 番目のデータセンター/サイトの名前 |
| Third SITE | DC3 | 3 番目のデータセンター/サイトの名前 |
| InstanceNr | 02 | HANA インスタンス番号 |
| <sid>adm uid | 1000 | sidadm ユーザーのユーザー ID |
| sapsys gid | 980 | sapsys のグループ ID |
3 つの HANA インスタンスすべてで、以下に対して同じ値を使用する必要があります。
- SID
- InstanceNr
- <sid>adm uid
- sapsys gid
第3章 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
ソリューションが機能するには、次の要件を満たす必要があります。
次のものがすべてのノードで同じである必要があります。
- CPU と RAM の数
- ソフトウェア設定
- RHEL リリース
- ファイアウォールの設定
- SAP HANA リリース (SAP HANA 2.0 SPS04 以降)
Pacemaker パッケージはクラスターノードにのみインストールされ、同じバージョンの resource-agents-sap-hana (0.162.1 以降) を使用する必要があります。
SAP HANA Multitarget System Replication をサポートできるようにするには、SAP HANA Multitarget System Replication の自動登録サポートの追加 を参照してください。また、以下を設定してください。
-
register_secondaries_on_takeover=trueの使用 -
log_mode=normalの使用
初期設定は、インストールガイド RHEL HA Add-On を使用した SAP HANA Scale-Up System Replication の自動化 に基づいています。
すべての SAP HANA インスタンスのシステムレプリケーション設定は、SAP 要件に基づいています。詳細は、SAP HANA Administration Guide に基づく SAP のガイドラインを参照してください。
第4章 インストール リンクのコピーリンクがクリップボードにコピーされました!
この章では、追加の SAP HANA インスタンスのインストールを説明します。
4.1. フェイルオーバーテストで 2 ノードの基本インストールを確認する リンクのコピーリンクがクリップボードにコピーされました!
RHEL HA Add-On を使用した SAP HANA Scale-Up System Replication の自動化 に基づいてインストールを行ったことを確認します。
SAP HANA Multitarget System Replication を使用できるようにするには、resource-agents-sap-hana のバージョンが 0.162.1 以降である必要があります。これは、以下のコマンドで確認できます。
rpm -q resource-agents-sap-hana resource-agents-sap-hana-0.162.1-0.el8_6.1.noarch
# rpm -q resource-agents-sap-hana
resource-agents-sap-hana-0.162.1-0.el8_6.1.noarch
フェイルオーバーテストを実行すると、環境が機能していることを確認できます。SAPHana リソースを移動することもできます。これは、move を使用した SAPHana リソースのフェイルオーバー でも説明されています。
4.2. 3 番目のサイトに SAP HANA をインストールする リンクのコピーリンクがクリップボードにコピーされました!
3 番目のサイトでは、次に示すように、2 ノード Pacemaker クラスター上の SAP HANA インスタンスと同じバージョンとパラメーターを使用して、SAP HANA をインストールする必要もあります。
| パラメーター | 値 |
|---|---|
| SID | RH2 |
| InstanceNumber | 02 |
| <sid>adm user ID | rh2adm 999 |
| sapsys group ID | sapsys 999 |
SAP HANA のインストールは hdblcm を使用して行います。詳細は、hdbclm を使用した SAP HANA のインストール を参照してください。必要に応じて、Ansible を使用してインストールを実行することもできます。
この章の例では、以下を使用しています。
- ホスト: DC1 サイトの clusternode1、DC2 サイトの clusternode2、および DC3 サイトの remotehost3
- SID RH2
- adminuser rh2adm
4.3. 3 番目のノードで SAP HANA System Replication をセットアップする リンクのコピーリンクがクリップボードにコピーされました!
既存のインストールでは、2 ノードクラスター内のプライマリー SAP HANA インスタンスとセカンダリー SAP HANA インスタンスの間にすでに SAP HANA System Replication が設定されています。SAP HANA System Replication は、稼働中のプライマリー SAP HANA データベースインスタンスで有効になります。
この章では、3 番目の SAP HANA インスタンスを、DC3 サイトのノード remotehost3 上にある追加のセカンダリー HANA System Replication サイトとして登録する方法を説明します。この手順は、ノード clusternode2 上の元のセカンダリー HANA インスタンス (DC2) の登録に似ています。詳細は、以降の章で説明します。さらに詳しい情報が必要な場合は、General Prerequisites for Configuring SAP HANA System Replication も参照してください。
4.3.1. プライマリーデータベースの確認 リンクのコピーリンクがクリップボードにコピーされました!
他のデータベースが実行中であり、システムのレプリケーションが適切に動作していることを確認する必要があります。以下を参照してください。
次の方法でプライマリー HANA インスタンスを検出できます。
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode" mode: primary
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
mode: primary
4.3.2. データベースキーのコピー リンクのコピーリンクがクリップボードにコピーされました!
新しいセカンダリー HANA インスタンスを登録する前に、プライマリー HANA インスタンスのデータベースキーを新しい追加の HANA レプリケーションサイトにコピーする必要があります。この例では、3 番目のサイトのホスト名は、remotehost3 です。
たとえば、プライマリーノード clusternode1 で次を実行します。
clusternode1:rh2adm> scp -rp
/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp
/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
clusternode1:rh2adm> scp -rp
/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp
/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
4.3.3. 3 番目のサイトをセカンダリーとして登録する リンクのコピーリンクがクリップボードにコピーされました!
プライマリーデータベース を実行しているノードの名前を確認する必要があります。
登録を監視するには、プライマリーノードの別のターミナルで次のコマンドを実行します。
clusternode1:rh2adm> watch python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/python_support/systemReplicationStatus.py
clusternode1:rh2adm> watch python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/python_support/systemReplicationStatus.py
これにより、進行状況とエラー (発生した場合) が表示されます。
3 番目のサイト (DC3) の HANA インスタンスを追加のセカンダリー SAP HANA インスタンスとして登録するには、3 番目のサイトのホスト (remotehost3) で次のコマンドを実行します。
remotehost3:rh2adm> hdbnsutil -sr_register --name=DC3
--remoteHost=clusternode1 --remoteInstance=${TINSTANCE}
--replicationMode=async --operationMode=logreplay --online
remotehost3:rh2adm> hdbnsutil -sr_register --name=DC3
--remoteHost=clusternode1 --remoteInstance=${TINSTANCE}
--replicationMode=async --operationMode=logreplay --online
この例では、DC3 は 3 番目のサイトの名前、clusternode1 はプライマリーノードの名前です。
データベースインスタンスがすでに実行されている場合は、停止する必要はありません。オプション --online を使用すると、オンライン中にインスタンスが登録されます。インスタンスの必要な再起動 (停止と起動) は、hdbnsutil 自体によって開始されます。
--online オプションは、HANA インスタンスがオンラインでもオフラインでも、どのような場合でも機能します (このオプションは SAP HANA 2.0 SPS04 以降で使用できます)。
HANA インスタンスがオフラインの場合は、3 番目のノードが登録された後に起動する必要があります。詳細は、SAP HANA System Replication を参照してください。
4.3.4. SAP HANA Multitarget System Replication の自動登録サポートの追加 リンクのコピーリンクがクリップボードにコピーされました!
register_secondaries_on_takeover = true という SAP HANA System Replication オプションを使用しています。これにより、以前のプライマリーサイトと他のセカンダリーサイトの間でフェイルオーバーが発生した場合に、新しいプライマリーサイトが自動的に再登録されます。このオプションは、すべての潜在的なプライマリーサイトの global.ini ファイルに追加する必要があります。
すべての HANA インスタンスの global.ini に、このエントリーが含まれている必要があります。
[system_replication] register_secondaries_on_takeover = true
[system_replication]
register_secondaries_on_takeover = true
次の 2 つの章では、global.ini 設定の詳細を説明します。
このパラメーターが設定されていても、フェイルオーバーの開始時に 3 番目のデータベースが 停止 してした場合、3 番目のインスタンスを手動で再登録する必要があります。
4.3.5. Pacemaker ノードでの global.ini の設定 リンクのコピーリンクがクリップボードにコピーされました!
Pacemaker クラスターによって管理されるサイト 1 およびサイト 2 の SAP HANA ノードの global.ini の [system_replication] セクションに、register_secondaries_on_takeover = true オプションを追加する必要があります。ファイル global.ini は、常にそれぞれのノードで編集し、別のノードからファイルをコピーしないでください。
global.ini ファイルは、サイトの HANA インスタンスが処理を停止した場合にのみ編集してください。
rh2adm ユーザーとして global.ini を編集します。
clusternode1:rh2adm> vim
/usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
clusternode1:rh2adm> vim
/usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
以下に例を示します。
このオプションは、SAP HANA データベースインスタンスが開始されるとすぐにアクティブになります。
4.3.6. remotehost3 で global.ini を設定する リンクのコピーリンクがクリップボードにコピーされました!
<sid>adm ユーザーとして global.ini を編集します。
% vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
% vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
remotehost3 では、ha_dr_provider_SAPhanaSR セクションは使用されません。
remotehost3 上の global.ini の例:
4.3.7. インストールの検証 リンクのコピーリンクがクリップボードにコピーされました!
インストール後、すべての HANA インスタンスが稼働しているか、およびそれらの間で HANA System Replication が機能しているかを確認する必要があります。最も簡単な方法は、systemReplicationStatus を確認することです。詳細は、System Replication ステータスの確認 を参照してください。詳細は、データベースの確認 も参照してください。
HANA System Replication が正しく機能するには、“log_mode” パラメーターが “normal” に設定されていることを確認してください。詳細は、SAP HANA データベースの log_mode の確認 を参照してください。
セットアップが期待どおりに機能していることを確認するには、次の章で説明されているように、テストケース を実行してください。
第5章 テストケース リンクのコピーリンクがクリップボードにコピーされました!
インストールの完了後、いくつかの基本テストを実行してインストールを確認し、SAP HANA Multitarget System Replication がどのように動作するか、および障害からどのように復旧するかを検証することを推奨します。実稼働を開始する前に、このようなテストケースを実行することを常に推奨します。可能であれば、実稼働環境に適用する前に、変更を検証するためのテスト環境を準備することもできます。
すべてのケースで、次の項目が説明されています。
- テストの内容
- テストの前提条件
- テストの手順
- テストのモニタリング
- テストの開始
- 期待される結果
- 初期状態に戻す方法
以前のプライマリー HANA レプリケーションサイトを、クラスターによって管理される HANA インスタンス上の新しいセカンダリー HANA レプリケーションサイトとして自動的に登録するには、SAPHana リソースでオプションの AUTOMATED_REGISTER=true を使用できます。詳細は、AUTOMATED_REGISTER を参照してください。
例で使用されている HA クラスターノードと HANA レプリケーションサイト (括弧内) の名前は次のとおりです。
- clusternode1 (DC1)
- clusternode2 (DC2)
- remotehost3 (DC3)
次のパラメーターは、HANA インスタンスとクラスターの設定に使用されます。
- SID=RH2
- INSTANCENUMBER=02
- CLUSTERNAME=cluster1
テスト環境の /etc/hosts で、clusternode1-2、remotehost3 をエイリアスとしても使用できます。
例や前提条件の追加チェックなど、テストの詳細を説明します。最後には、さらなるテストに備えて、環境をクリーンアップする方法の例が示されています。
場合によっては、clusternode1-2 と remotehost3 の間の距離が長すぎる場合は、–replicationMode=syncmem の代わりに –replcationMode=async を使用する必要があります。適切なオプションを選択する前に、SAP HANA 管理者にも問い合わせてください。
5.1. テストの準備 リンクのコピーリンクがクリップボードにコピーされました!
テストを実行する前に、環境全体が正常で健全な状態である必要があります。次のコマンドで、クラスターとデータベースを確認する必要があります。
-
pcs status --full -
python systemReplicationStatus.py -
df -h
pcs status --full の例は、pcs status を使用したクラスターのステータスの確認 にあります。"Migration Summary" に警告または以前の失敗がある場合は、テストを開始する前にクラスターをクリーンアップする必要があります。
pcs resource clear SAPHana_RH2_02-clone
[root@clusternode1]# pcs resource clear SAPHana_RH2_02-clone
クラスターのクリーンアップ で、クリーンアップを実行するその他の方法を説明しています。重要なのは、クラスターとすべてのリソースが起動していることです。
クラスターのほかに、データベースも稼働しており、同期している必要があります。データベースのステータスが適切であることを確認する最も簡単な方法は、システムのレプリケーションステータスを確認することです。レプリケーションステータス も参照してください。これはプライマリーデータベースで確認する必要があります。
プライマリーノードを検出するには、プライマリーデータベースの検出 をオンにするか、次のコマンドを使用します。
-
pcs status | grep -E "Promoted|Master" -
hdbnsutil -sr_stateConfiguration
次のコマンドを実行して、ファイルシステムに十分なスペースがあるかどうかを確認します。
df -h
# df -h
続行する前に、システムチェック のガイドラインにも従ってください。環境がクリーンであれば、テストを実行する準備ができています。テスト中、モニタリングは進行状況を確認するのに役立ちます。
5.2. 環境のモニタリング リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、テスト中の環境のモニタリングに焦点を当てます。このセクションでは、変更を確認するために必要なモニターのみを説明します。モニターは専用のターミナルから実行することを推奨します。テスト中に変化を検出できるように、テストを開始する前にモニタリングを開始することを推奨します。
便利なコマンド セクションで、さらに多くの例を紹介しています。
5.2.1. プライマリーノードの検出 リンクのコピーリンクがクリップボードにコピーされました!
プライマリーノードを検出してフェイルオーバーを監視するか、プライマリーノードで実行したときにレプリケーションステータスに関する情報のみを提供する特定のコマンドを実行する必要があります。
プライマリーノードを検出するには、<sid>adm ユーザーとして次のコマンドを実行します。
clusternode1:rh2adm> watch -n 5 'hdbnsutil -sr_stateConfiguration | egrep -e "primary masters|^mode"'
clusternode1:rh2adm> watch -n 5 'hdbnsutil -sr_stateConfiguration | egrep -e "primary masters|^mode"'
出力例 (clusternode2 がプライマリーデータベースの場合):
mode: syncmem primary masters: clusternode2
mode: syncmem
primary masters: clusternode2
プライマリーノードを特定する 2 つ目の方法は、クラスターノード上で root として次のコマンドを実行することです。
watch -n 5 'pcs status --full'
# watch -n 5 'pcs status --full'
プライマリーデータベースを実行するノードの出力は次のとおりです。
mode: primary
mode: primary
5.2.2. レプリケーションステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
レプリケーションのステータスは、プライマリーデータベースノードとセカンダリーデータベースノード間の関係と、レプリケーションの現在のステータスを示します。
レプリケーションのステータスを確認するには、<sid>adm ユーザーとして次のコマンドを実行します。
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration
システムレプリケーションステータスの変更を永続的に監視したい場合は、次のコマンドを実行してください。
clusternode1:rh2adm> watch -n 5 'python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
clusternode1:rh2adm> watch -n 5 'python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'
この例では、レプリケーションのステータスを繰り返し取得します。また、現在の戻りコードを確認します。
戻りコード (ステータス) が 15 である限り、レプリケーションのステータスは正常です。他の戻りコードは次のとおりです。
- 10: NoHSR
- 11: Error
- 12: Unknown
- 13: Initializing
- 14: Syncing
- 15: Active
新しいセカンダリーを登録する場合は、プライマリーノード上の別のウィンドウでコマンドを実行し、レプリケーションの進行状況を確認できます。フェイルオーバーを監視する場合は、前のプライマリーデータベースサーバーと新しいプライマリーデータベースサーバーで並行してコマンドを実行できます。詳細は、SAP HANA System Replication のステータスの確認 を参照してください。
5.2.3. /var/log/messages のエントリーの確認 リンクのコピーリンクがクリップボードにコピーされました!
Pacemaker は、/var/log/messages ファイルに多くの情報を書き込みます。フェイルオーバー中に、大量のメッセージがこのメッセージファイルに書き込まれます。SAP HANA リソースエージェントに応じて重要なメッセージのみを追跡できるようにするには、Pacemaker SAP リソースの詳細なアクティビティーをフィルターすると便利です。これは、単一のクラスターノード上のメッセージファイルを確認する場合に十分です。
たとえば、次のエイリアスを使用できます。
tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_${SAPSYSTEMNAME}_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
# tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_${SAPSYSTEMNAME}_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
このエイリアスを別のウィンドウで実行して、テストの進行状況を監視します。フェイルオーバーと同期状態の監視 の例も参照してください。
5.2.4. クラスターの状態 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのステータスを確認するにはいくつかの方法があります。
クラスターが実行中かどうかを確認します。
-
pcs cluster status
-
クラスターとすべてのリソースを確認します。
-
pcs status
-
クラスター、すべてのリソース、およびすべてのノード属性を確認します。
-
pcs status --full
-
リソースのみを確認します。
-
pcs resource
-
pcs status --full コマンドを使用すると、必要な情報がすべて得られます。変更を監視するには、このコマンドを watch と一緒に実行できます。
pcs status --full
# pcs status --full
変更を確認する場合は、別のウィンドウで watch コマンドを実行できます。
watch pcs status --full
# watch pcs status --full
出力例とその他のオプションは、クラスターのステータスの確認 を参照してください。
5.2.5. 残留物の検出 リンクのコピーリンクがクリップボードにコピーされました!
環境が次のテストを実行できる状態にあることを確認するには、以前のテストで残ったものを修正または削除する必要があります。
stonithは、クラスター内のノードをフェンスするために使用します。-
検出:
[root@clusternode1]# pcs stonith history -
修正:
[root@clusternode1]# pcs stonith cleanup
-
検出:
複数のプライマリーデータベース:
検出:
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration | grep -i primary同じプライマリーを持つすべてのノードを識別する必要があります。
-
修正: clusternode1:rh2adm> は、
--force_full_replicaオプションを使用して間違ったプライマリーを再登録します。
移動により発生した場所の制約:
検出:
[root@clusternode1]# pcs constraint location警告セクションを確認します。
-
修正:
[root@clusternode1]# pcs resource clear <clone-resource-which was moved>
セカンダリーレプリケーション関係:
-
検出: プライマリーデータベースで
clusternode1:rh2adm> python ${DIR_EXECUTABLES}/python_support/systemReplicationStatus.pyを実行します。 - 修正: セカンダリーデータベースを登録解除して再登録します。
-
検出: プライマリーデータベースで
siteReplicationMode を確認します (すべての SAP HANA ノードで同じ出力が表示されます)
-
clusternode1:rh2adm> hdbnsutil -sr_state --sapcontrol=1 |grep site.*Mode
-
Pcs プロパティー:
-
検出:
[root@clusternode1]# pcs property config -
修正:
[root@clusternode1]# pcs property set <key=value> -
maintenance_modeをクリア -
[root@clusternode1]# pcs property set maintenance-mode=false
-
検出:
log_mode:検出:
clusternode1:rh2adm> python systemReplicationStatus.py通常は
log_modeが必要であるという応答がレプリケーションのステータスで返されます。log_modeは、hdbsqlを使用したInifileの内容の確認 で説明されている方法で検出できます。-
修正:
log_modeを normal に変更し、プライマリーデータベースを再起動します。
CIB エントリー:
検出: クラスター情報ベース内の SFAIL エントリー。
CIB エントリーを検索して削除するには、クラスターの整合性の確認 を参照してください。
クリーンアップ/クリア:
検出:
[root@clusternode1]# pcs status --full場合によっては、エラーや警告が表示されることがあります。リソースをクリーンアップ/クリアしても、すべてが正常であれば何も起こりません。次のテストを実行する前に、環境をクリーンアップできます。
修正の例:
[root@clusternode1]# pcs resource clear <name-of-the-clone-resource>[root@clusternode1]# pcs resource cleanup <name-of-the-clone-resource>
これは、既存の環境に問題があるか確認する場合にも役立ちます。詳細は、便利なコマンド を参照してください。
5.3. テスト 1: プライマリーノードをアクティブな 3 番目のサイトを使用してフェイルオーバーする リンクのコピーリンクがクリップボードにコピーされました!
| テストの内容 | 3 番目のサイトの自動再登録。 クリア後に同期状態が SOK に変わる。 |
| テストの前提条件 |
|
| テストの手順 |
|
| テストのモニタリング |
3 番目のサイトで、
セカンダリーノードで root として |
| テストの開始 | クラスターコマンドを実行します。
|
| 期待される結果 | サイト 3 の monitor コマンドでは、プライマリーマスターが clusternode1 から clusternode2 に変更されます。
リソースをクリアすると、同期状態が |
| 初期状態に戻す方法 | テストを 2 回実行します。 |
(*)
remotehost3:rh2adm> watch hdbnsutil -sr_state [root@clusternode1]# tail -1000f /var/log/messages |egrep -e ‘SOK|SWAIT|SFAIL’
remotehost3:rh2adm>
watch hdbnsutil -sr_state
[root@clusternode1]# tail -1000f /var/log/messages |egrep -e ‘SOK|SWAIT|SFAIL’
詳細な説明:
clusternode1 または clusternode2 で root としてクラスターの初期状態を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力は、HANA がプライマリー SAP HANA サーバーである clusternode1 上で昇格されていること、およびクローンリソースの名前が SAPHana_RH2_02-clone であり、昇格可能であることを示しています。
テスト中にこれを別のウィンドウで実行して、変更を確認できます。
watch pcs status --full
[root@clusternode1]# watch pcs status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow SAP HANA クローンリソースの名前を識別する別の方法は次のとおりです。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プライマリーサーバーの変更を確認するには、テストを開始する前に、別のターミナルウィンドウで remotehost3 のモニタリングを開始します。
remotehost3:rh2adm> watch 'hdbnsutil -sr_state | grep "primary masters"
remotehost3:rh2adm> watch 'hdbnsutil -sr_state | grep "primary masters"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は次のようになります。
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:47:21 2023 primary masters: clusternode1
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:47:21 2023 primary masters: clusternode1Copy to Clipboard Copied! Toggle word wrap Toggle overflow テスト中に、予想される出力は clusternode2 に変わります。
上記で検出したクローンリソースを clusternode2 に移動してテストを開始します。
pcs resource move SAPhana_RH2_02-clone clusternode2
[root@clusternode1]# pcs resource move SAPhana_RH2_02-clone clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 上のモニターの出力は次のように変わります。
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:50:31 2023 primary masters: clusternode2
Every 2.0s: hdbnsutil -sr_state | grep "primary masters" remotehost3: Mon Sep 4 08:50:31 2023 primary masters: clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pacemaker は、クローンリソースを移動するための場所の制約を作成します。これは手動で削除する必要があります。以下を使用して制約を確認できます。
pcs constraint location
[root@clusternode1]# pcs constraint locationCopy to Clipboard Copied! Toggle word wrap Toggle overflow この制約は、次の手順を実行して削除する必要があります。
クローンリソースをクリアして、場所の制約を削除します。
pcs resource clear SAPhana_RH2_02-clone Removing constraint: cli-prefer-SAPHana_RH2_02-clone
[root@clusternode1]# pcs resource clear SAPhana_RH2_02-clone Removing constraint: cli-prefer-SAPHana_RH2_02-cloneCopy to Clipboard Copied! Toggle word wrap Toggle overflow リソースをクリーンアップします。
pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)
[root@clusternode1]# pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
テスト結果
- remotehost3 上の “プライマリーマスター” モニターには、新しいプライマリーノードへの即時切り替えが表示されるはずです。
-
クラスターのステータスを確認すると、元のセカンダリーがプロモートされ、元のプライマリーが再登録されて、
Clone_StateがPromotedからUndefined、WAITINGFORLPA、DEMOTEDに変わります。 -
セカンダリーは、フェイルオーバー後に初めて
SAPHanaモニターが起動するときに、sync_stateをSFAILに変更します。既存の場所の制約のため、リソースをクリアする必要があります。しばらくするとセカンダリーのsync_stateが再びSOKに変わります。 - セカンダリーがプロモートされます。
初期状態に戻すには、次のテストを実行します。テストが終了したら、クラスターのクリーンアップ を実行してください。
5.4. テスト 2: プライマリーノードをパッシブな 3 番目のサイトを使用してフェイルオーバーする リンクのコピーリンクがクリップボードにコピーされました!
| テストの内容 | 3 番目のサイトの登録なし。 3 番目のサイトが停止している場合でも、フェイルオーバーが機能する。 |
| テストの前提条件 |
|
| テストの手順 |
|
| テストの開始 | クラスターコマンドを実行します。
|
| テストのモニタリング |
3 番目のサイトで
クラスターノード上で root として |
| 期待される結果 | DC3 には何も変化がありません。レプリケーションは古い関係を維持します。 |
| 初期状態に戻す方法 | 新しいプライマリーに DC3 を再登録し、SAP HANA を起動します。 |
詳細な説明:
clusternode1 または clusternode2 で root としてクラスターの初期状態を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例のこの出力は、HANA がプライマリー SAP HANA サーバーである clusternode1 上でプロモートされていること、およびクローンリソースの名前が
SAPHana_RH2_02-cloneであり、プロモート可能であることを示しています。HANA の前にテスト 3 を実行すると、clusternode2 でテスト 3 がプロモートされる可能性があります。remotehost3 上のデータベースを停止します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 上のプライマリーデータベースを確認します。
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i "primary masters" primary masters: clusternode2
remotehost3:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i "primary masters" primary masters: clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターノード上のクラスター内の現在のプライマリーを確認します。
pcs resource | grep Masters * Masters: [ clusternode2 ][root@clusternode1]# pcs resource | grep Masters * Masters: [ clusternode2 ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow sr_stateを確認して、SAP HANA System Replication 関係を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SAP HANA System Replication 関係には、依然として 1 つのプライマリー (DC1) があり、DC2 と DC3 にレプリケートされます。
ダウンしている remotehost3 上のレプリケーション関係は、次のコマンドを使用して表示できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オフラインの remotehost3 上のデータベースは、
global.iniファイル内のエントリーをチェックします。テストの開始: クラスター内でフェイルオーバーを開始し、
SAPHana-clone-resourceの例を移動します。pcs resource move SAPHana_RH2_02-clone clusternode2
[root@clusternode1]# pcs resource move SAPHana_RH2_02-clone clusternode2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SAPHana が clusternode2 でプロモートされている場合は、クローンリソースを clusternode1 に移動する必要があります。この例では、SAPHana が clusternode1 でプロモートされることを想定しています。
出力はありません。前のテストと同様に、場所の制約が作成され、次のように表示できます。
pcs constraint location Location Constraints: Resource: SAPHana_RH2_02-clone Enabled on: Node: clusternode1 (score:INFINITY) (role:Started)[root@clusternode1]# pcs constraint location Location Constraints: Resource: SAPHana_RH2_02-clone Enabled on: Node: clusternode1 (score:INFINITY) (role:Started)Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターが再び正常に見える場合でも、この制約により、制約が削除されない限り、別のフェイルオーバーが回避されます。1 つの方法は、リソースをクリアすることです。
リソースをクリアします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リソースをクリーンアップします。
pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)
[root@clusternode1]# pcs resource cleanup SAPHana_RH2_02-clone Cleaned up SAPHana_RH2_02:0 on clusternode2 Cleaned up SAPHana_RH2_02:1 on clusternode1 Waiting for 1 reply from the controller ... got reply (done)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 現在のステータスを確認します。
レプリケーションのステータスを表示するには 3 つの方法があり、同期している必要があります。まずは remotehost3 のプライマリーから始めます。
remotehost3clusternode2:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i primary active primary site: 1 primary masters: clusternode1
remotehost3clusternode2:rh2adm> hdbnsutil -sr_stateConfiguration| grep -i primary active primary site: 1 primary masters: clusternode1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には、サイト 1 または clusternode1 が表示されます。これは、プライマリーを clusternode2 に移動するテストを開始する前はプライマリーでした。
次に、新しいプライマリーのシステムレプリケーションステータスを確認します。
まず新しいプライマリーを検出します。
pcs resource | grep Master * Masters: [ clusternode2 ][root@clusternode1]# pcs resource | grep Master * Masters: [ clusternode2 ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは不整合が発生しているため、remotehost3 を再登録する必要があります。テストを再度実行すると、プライマリーを元の clusternode1 に戻すのではないかと思うかもしれません。この場合、システムレプリケーションが機能しているかどうかを確認する 3 番目の方法があります。プライマリーノードで次のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力に remotehost3 が表示されない場合は、remotehost3 を再登録する必要があります。登録する前に、プライマリーノードで次のコマンドを実行して、登録の進行状況を確認してください。
clusternode2:rh2adm> watch python ${DIR_EXECUTABLES}/python_support/systemReplicationStatus.pyclusternode2:rh2adm> watch python ${DIR_EXECUTABLES}/python_support/systemReplicationStatus.pyCopy to Clipboard Copied! Toggle word wrap Toggle overflow これで、このコマンドを使用して、remotehost3 を再登録できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 上のデータベースがまだ起動していない場合でも、システムレプリケーションステータスの出力で 3 番目のサイトを確認できます。登録は、remotehost3 でデータベースを起動することで完了できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記で開始されたモニターには、remotehost3 の同期がすぐに表示されます。
-
元に戻すには、テストを再度実行します。オプションのテストの 1 つは、プライマリーをノードに切り替えて、remotehost3 の
global.iniで設定してデータベースを起動することです。データベースが起動する場合もありますが、再登録しない限り、システムレプリケーションステータスの出力には表示されません。 - 欠落しているエントリーがすぐに作成され、SAP HANA データベースが起動するとすぐにシステムレプリケーションが開始されます。
これは、次を実行して確認できます。
sidadm@clusternode1% hdbnsutil -sr_state sidadm@clusternode1% python systemReplicationStatus.py ; echo $?
sidadm@clusternode1% hdbnsutil -sr_state sidadm@clusternode1% python systemReplicationStatus.py ; echo $?Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 詳細は、SAP HANA System Replication ステータスの確認 を参照してください。
5.5. テスト 3: プライマリーノードを 3 番目のサイトにフェイルオーバーする リンクのコピーリンクがクリップボードにコピーされました!
| テストの内容 | プライマリーを 3 番目のサイトにフェイルオーバーします..3 番目のサイトがプライマリーになる。 セカンダリーが 3 番目のサイトに再登録される。 |
| テストの前提条件 |
|
| テストの手順 |
回復できるようにクラスターを
|
| テストの開始 |
remotehost3:rh2adm> で SAP HANA コマンドを実行します: |
| テストのモニタリング |
3 番目のサイトで |
| 期待される結果 |
|
| 初期状態に戻す方法 |
詳細な説明:
データベースの確認 を使用して、データベースが実行されているか確認し、レプリケーションのステータスを確認します。
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は、たとえば次のようになります。
mode: syncmem primary masters: clusternode1
mode: syncmem primary masters: clusternode1Copy to Clipboard Copied! Toggle word wrap Toggle overflow この場合、プライマリーデータベースは clusternode1 です。このコマンドを clusternode1 で実行すると、次の結果が得られます。
mode: primary
mode: primaryCopy to Clipboard Copied! Toggle word wrap Toggle overflow このプライマリーノードでは、システムのレプリケーションステータスを表示することもできます。次のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで適切な環境が整い、3 つのノードすべてで、システムレプリケーションステータスのモニタリングを別のウィンドウで開始できるようになりました。テストを開始する前に、3 つのモニターを開始する必要があります。テストが実行されると出力が変更されます。したがって、テストが完了するまでは実行し続けてください。
古いプライマリーノードでは、テスト中、clusternode1 が別のウィンドウで実行されました。
clusternode1:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'clusternode1:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'Copy to Clipboard Copied! Toggle word wrap Toggle overflow clusternode1 の出力は次のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 で同じコマンドを実行します。
remotehost3:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'remotehost3:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果は次のようになります。
this system is either not running or is not primary system replication site
this system is either not running or is not primary system replication siteCopy to Clipboard Copied! Toggle word wrap Toggle overflow これは、テストでフェイルオーバーが開始された後に変更されます。出力は、テスト開始前のプライマリーノードの例と似ています。
2 番目のノードで、以下を開始します。
clusternode2:rh2adm> watch -n 10 'hdbnsutil -sr_state | grep masters'
clusternode2:rh2adm> watch -n 10 'hdbnsutil -sr_state | grep masters'Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、現在のマスターの clusternode1 が表示され、フェイルオーバーの開始直後に切り替わります。
-
すべてが正しく設定されていることを確認するには、
global.iniも確認します。 DC1、DC2、DC3 の
global.iniを確認します。3 つのノードすべてで、
global.iniに次の内容が含まれている必要があります。[persistent] log_mode=normal [system_replication] register_secondaries_on_takeover=true
[persistent] log_mode=normal [system_replication] register_secondaries_on_takeover=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下を使用して
global.iniを編集できます。clusternode1:rh2adm>vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.iniclusternode1:rh2adm>vim /usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.iniCopy to Clipboard Copied! Toggle word wrap Toggle overflow (オプション) クラスターを
maintenance-modeにします。pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow テスト中に、
maintenance-modeを設定してもしなくても、フェイルオーバーが機能することがわかります。したがって、最初のテストは設定なしで実行できます。回復中にこれを設定する必要があります。ここでは、この設定があってもなくても機能することを示しています。これは、プライマリーにアクセスできない場合のオプションです。テストを開始します: DC3 にフェイルオーバーします。remotehost3 で次を実行してください。
remotehost3:rh2adm> hdbnsutil -sr_takeover done.
remotehost3:rh2adm> hdbnsutil -sr_takeover done.Copy to Clipboard Copied! Toggle word wrap Toggle overflow テストが開始されました。以前に開始したモニターの出力を確認してください。clusternode1 では、システムレプリケーションステータスは remotehost3 および clusternode2 (DC2) との関係を失います。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターは、この動作をまだ把握していません。システムレプリケーションステータスの戻りコードを確認すると、戻りコード 11 はエラーを意味し、何か問題があることがわかります。アクセスできる場合は、今すぐ
maintenance-modeに入ることを推奨します。remotehost3 が新しいプライマリーになり、clusternode2 (DC2) が remotehost3 上の新しいプライマリーとして自動的に登録されます。
remotehost3 のシステムレプリケーション状態の出力例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 戻りコード 15 も、すべてが正常であることを示していますが、clusternode1 が見つかりません。これは手動で再登録する必要があります。以前のプライマリー clusternode1 はリスト表示されないため、レプリケーション関係は失われます。
maintenance-modeを設定します。まだ行っていない場合は、次のコマンドを使用して、クラスターの 1 つのノードでクラスターに
maintenance-modeを設定します。pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドを実行すると、
maintenance-modeがアクティブか確認できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow リソースは unmanaged を表示しています。これは、クラスターが
maintenance-mode=trueであることを示します。仮想 IP アドレスは引き続き clusternode1 で開始されます。この IP を別のノードで使用する場合は、maintanence-mode=true を設定する前にvip_RH2_02_MASTERを無効にしてください。pcs resource disable vip_RH2_02_MASTER
[root@clusternode1]# pcs resource disable vip_RH2_02_MASTERCopy to Clipboard Copied! Toggle word wrap Toggle overflow clusternode1 を再登録します。
clusternode1 の
sr_stateを確認すると、DC2 のみとの関係がわかります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow しかし、DC2 を確認すると、プライマリーデータベースサーバーは DC3 です。したがって、DC1 からの情報は正しくありません。
clusternode2:rh2adm> hdbnsutil -sr_state
clusternode2:rh2adm> hdbnsutil -sr_stateCopy to Clipboard Copied! Toggle word wrap Toggle overflow DC1 でシステムレプリケーションステータスを確認すると、リターンコードは 12 ですが、これは不明です。したがって、DC1 を再登録する必要があります。
このコマンドを使用すると、以前のプライマリー clusternode1 を remotehost3 の新しいセカンダリーとして登録できます。
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=asyncsyncmem --name=DC1 --remoteName=DC3 --operationMode=logreplay --onlineclusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=asyncsyncmem --name=DC1 --remoteName=DC3 --operationMode=logreplay --onlineCopy to Clipboard Copied! Toggle word wrap Toggle overflow 登録が完了すると、remotehost3 上で 3 つのサイトすべてが複製され、ステータス (戻りコード) が 15 に変わります。
これが失敗した場合は、DC1 と DC3 のレプリケーション関係を手動で削除する必要があります。セカンダリーの登録 に記載されている手順に従ってください。
たとえば、次のように既存の関係をリストします。
clusternode1:rh2adm> hdbnsutil -sr_state
clusternode1:rh2adm> hdbnsutil -sr_stateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 既存の関係を削除するには、次を使用できます。
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC2`
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC2`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通常、これは必要ないかもしれません。テスト 4 は、テスト 3 の後に実行することを想定したものです。回復手順は、テスト 4 を実行することです。
5.6. テスト 4: プライマリーノードを 1 番目のサイトにフェイルバックする リンクのコピーリンクがクリップボードにコピーされました!
| テストの内容 | プライマリーがクラスターノードに戻る。 フェイルバックしてクラスターを再度有効にする。 3 番目のサイトをセカンダリーとして再登録する。 |
| テストの前提条件 |
|
| テストの手順 | クラスターの予想されるプライマリーを確認します。 DC3 ノードから DC1 ノードにフェイルオーバーします。 以前のセカンダリーが新しいプライマリーに切り替わったか確認します。 新しいセカンダリーとして remotehost3 を再登録します。
クラスターを |
| テストのモニタリング | 新しいプライマリーの起動時に、次のコマンドを実行します。
セカンダリーの起動時:
|
| テストの開始 |
クラスターの予想されるプライマリーを確認します: VIP およびプロモートされた SAP HANA リソースを、新しい潜在的なプライマリーである同じノード上で実行する必要があります。
この潜在的なプライマリーでは、 以前のプライマリーを新しいセカンダリーとして再登録します。
|
| 期待される結果 | 新しいプライマリーが SAP HANA を起動します。 レプリケーションステータスで、3 つのサイトすべてがレプリケートされたことが示されます。 2 番目のクラスターサイトが、新しいプライマリーに自動的に再登録されます。 DR サイトがデータベースの追加レプリカになります。 |
| 初期状態に戻す方法 | テスト 3 を実行します。 |
詳細な説明:
クラスターが
maintenance-modeになっているか確認します。pcs property config maintenance-mode Cluster Properties: maintenance-mode: true
[root@clusternode1]# pcs property config maintenance-mode Cluster Properties: maintenance-mode: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow maintenance-modeが true でない場合は、以下で設定できます。pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow システムのレプリケーションステータスを確認し、すべてのノード上のプライマリーデータベースを検出します。
まず、次を使用してプライマリーデータベースを検出します。
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は、以下のようになります。
clusternode1 上
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: syncmem primary masters: remotehost3
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: syncmem primary masters: remotehost3Copy to Clipboard Copied! Toggle word wrap Toggle overflow clusternode2 上
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: syncmem primary masters: remotehost3
clusternode2:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: syncmem primary masters: remotehost3Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 上
remotehost3:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: primary
remotehost3:rh2adm> hdbnsutil -sr_state | egrep -e "^mode:|primary masters" mode: primaryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 3 つのノードすべてで、プライマリーデータベースは remotehost3 です。
このプライマリーデータベースでは、システムレプリケーションステータスが 3 つのノードすべてでアクティブであり、戻りコードが 15 であることを確認する必要があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 3 つの
sr_stateがすべて一貫しているか確認します。3 つのノードすべてで、
hdbnsutil -sr_state --sapcontrol=1 |grep site.*Modeを実行してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力はすべてのノードで同じになるはずです。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 別のウィンドウでモニタリングを開始します。
clusternode1 で、以下を開始します。
clusternode1:rh2adm> watch "python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"clusternode1:rh2adm> watch "python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 で、以下を開始します。
remotehost3:rh2adm>watch "python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"remotehost3:rh2adm>watch "python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo \$?"Copy to Clipboard Copied! Toggle word wrap Toggle overflow clusternode2 で、以下を開始します。
clusternode2:rh2adm> watch "hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode"
clusternode2:rh2adm> watch "hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode"Copy to Clipboard Copied! Toggle word wrap Toggle overflow テストを開始します。
clusternode1 にフェイルオーバーするには、clusternode1 で開始します。
clusternode1:rh2adm> hdbnsutil -sr_takeover done.
clusternode1:rh2adm> hdbnsutil -sr_takeover done.Copy to Clipboard Copied! Toggle word wrap Toggle overflow モニターの出力を確認してください。
clusternode1 のモニターは、次のように変更されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 戻りコード 15 も重要です。
clusternode2 のモニターは、次のように変更されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow DC3 は失われているため、再登録する必要があります。
remotehost3 では、
systemReplicationStatusがエラーを報告し、リターンコードが 11 に変更されます。クラスターノードが再登録されているか確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サイトマッピングには、clusternode2 (DC2) が再登録されたことが示されています。
vip リソースを確認または有効にします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow vip リソース
vip_RH2_02_MASTERが停止されています。再度開始するには、次のコマンドを実行します。
pcs resource enable vip_RH2_02_MASTER Warning: 'vip_RH2_02_MASTER' is unmanaged
[root@clusternode1]# pcs resource enable vip_RH2_02_MASTER Warning: 'vip_RH2_02_MASTER' is unmanagedCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターは、
maintenance-mode=falseでない限りリソースを開始しないため、この警告は正しいです。クラスター
maintenance-modeを停止します。maintenance-modeを停止する前に、別のウィンドウで 2 つのモニターを起動して、変更を確認する必要があります。clusternode2 で、次を実行します。
watch pcs status --full
[root@clusternode2]# watch pcs status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow clusternode1 で、次を実行します。
clusternode1:rh2adm> watch "python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo $?"clusternode1:rh2adm> watch "python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py; echo $?"Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで、次のコマンドを実行して、clusternode1 の
maintenance-modeの設定を解除できます。pcs property set maintenance-mode=false
[root@clusternode1]# pcs property set maintenance-mode=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow clusternode1 のモニターには、すべてが期待どおりに実行されていることが表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 手動操作の後は、クラスターのクリーンアップ で説明されているように、クラスターをクリーンアップすることを推奨します。
clusternode1 上の新しいプライマリーに remotehost3 を再登録します。
remotehost3 を再登録する必要があります。進行状況を監視するには、clusternode1 で開始してください。
con_cluster_cleanupclusternode1:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'con_cluster_cleanupclusternode1:rh2adm> watch -n 5 'python /usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py ; echo Status $?'Copy to Clipboard Copied! Toggle word wrap Toggle overflow remotehost3 で、以下を開始してください。
remotehost3:rh2adm> watch 'hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode'
remotehost3:rh2adm> watch 'hdbnsutil -sr_state --sapcontrol=1 |grep siteReplicationMode'Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで、このコマンドを使用して、remotehost3 を再登録できます。
remotehost3:rh2adm> hdbnsutil -sr_register --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC3 --remoteName=DC1 --operationMode=logreplay --onlineremotehost3:rh2adm> hdbnsutil -sr_register --remoteHost=clusternode1 --remoteInstance=${TINSTANCE} --replicationMode=async --name=DC3 --remoteName=DC1 --operationMode=logreplay --onlineCopy to Clipboard Copied! Toggle word wrap Toggle overflow clusternode1 のモニターは、次のように変更されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow そして、remotehost3 のモニターは次のように変更されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで再び 3 つのエントリーがあり、remotehost3 (DC3) が再び clusternode1 (DC1) から複製されたセカンダリーサイトになります。
すべてのノードが、clusternode1 上のシステムレプリケーションステータスの一部であるか確認します。
3 つのノードすべてで、
hdbnsutil -sr_state --sapcontrol=1 |grep site.*Modeを実行してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのノードで同じ出力が得られるはずです。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pcs ステータス --full および SOK を確認します。
以下を実行します。
pcs status --full| grep sync_state
[root@clusternode1]# pcs status --full| grep sync_stateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は PRIM または SOK のいずれかである必要があります。
* hana_rh2_sync_state : PRIM * hana_rh2_sync_state : SOK* hana_rh2_sync_state : PRIM * hana_rh2_sync_state : SOKCopy to Clipboard Copied! Toggle word wrap Toggle overflow 最後に、
sync_statePRIM と SOK を含むクラスターのステータスは次のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - すべてが再び正常に動作することを確認するには、クラスターのステータスの確認 および データベースの確認 を参照してください。
第6章 便利なコマンド リンクのコピーリンクがクリップボードにコピーされました!
以下の 3 つのセクションで、便利なコマンドを紹介します。ほとんどの場合、操作や設定の成功を確認するのに役立ちます。例を応答とともに記載しています。出力は、形式上の理由で調整されている場合があります。
-
このドキュメントにリストされているすべてのコマンドには、
<sid>admユーザーが実行するものである場合、先頭に>が付いています。 -
root userが実行するすべてのコマンドには、先頭に#が付いています。 -
コマンドを実行するには、接頭辞の
>または#を除きます。
6.1. SAP HANA コマンド リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA コマンドは、<sid>adm ユーザーによって実行されます。以下に例を示します。
6.1.1. hdbclm を使用した SAP HANA のインストール リンクのコピーリンクがクリップボードにコピーされました!
3 番目のサイトのインストールは、2 番目のサイトのインストールと似ています。インストールは、root ユーザーとして hdblcm を使用して実行できます。以前に何もインストールされていないことを確認するには、hdbuninst を実行して、このノードに SAP HANA がまだインストールされていないかどうかを確認します。
HANA アンインストールの出力例:
cd /software/DATA_UNITS/HDB_SERVER_LINUX_X86_64 root@DC3/software/DATA_UNITS/HDB_SERVER_LINUX_X86_64# ./hdbuninst Option 0 will remove an already existing HANA Installation No SAP HANA Installation found is the expected answer
[root@remotehost3]# cd /software/DATA_UNITS/HDB_SERVER_LINUX_X86_64
root@DC3/software/DATA_UNITS/HDB_SERVER_LINUX_X86_64# ./hdbuninst
Option 0 will remove an already existing HANA Installation
No SAP HANA Installation found is the expected answer
DC3 での HANA インストールの出力例:
インストールが開始される前に、概要がリスト表示されます。
y を入力してインストールを開始します。
6.1.2. hdbsql を使用した Inifile の内容の確認 リンクのコピーリンクがクリップボードにコピーされました!
6.1.3. データベースの確認 リンクのコピーリンクがクリップボードにコピーされました!
データベースが実行されているかどうかを確認し、現在のプライマリーノードを検出します。
データベースインスタンスのリスト表示
出力が緑色の場合、インスタンスは実行中です。
データベースプロセスのリスト表示
通常、すべてのデータベースプロセスのステータスは GREEN です。
SAP HANA プロセスのリスト表示
SAP HANA ランドスケープ設定の表示
戻りコード:
- 0: Fatal
- 1: Error
- 2: Warning
- 3: Info
- 4: OK
プライマリーデータベースの検出
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
セカンダリーでの確認の例:
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode" mode: syncmem primary masters: clusternode1
clusternode1:rh2adm> hdbnsutil -sr_state | egrep -e "primary masters|^mode"
mode: syncmem
primary masters: clusternode1
現在のプライマリーでの確認の例:
データベースのバージョンの表示
SQL クエリーを使用した例:
hdbsql RH2=> select * from m_database SYSTEM_ID,DATABASE_NAME,HOST,START_TIME,VERSION,USAGE "RH2","RH2","node1","2023-06-22 15:33:05.235000000","2.00.059.02.1647435895","CUSTOM" 1 row selected (overall time 29.107 msec; server time 927 usec)
hdbsql RH2=> select * from m_database
SYSTEM_ID,DATABASE_NAME,HOST,START_TIME,VERSION,USAGE
"RH2","RH2","node1","2023-06-22 15:33:05.235000000","2.00.059.02.1647435895","CUSTOM"
1 row selected (overall time 29.107 msec; server time 927 usec)
systemOverview.py を使用した例:
6.1.4. SAP HANA の起動と停止 リンクのコピーリンクがクリップボードにコピーされました!
オプション 1: HDB コマンド
clusternode1:rh2adm> HDB help
Usage: /usr/sap/RH2/HDB02/HDB { start|stop|reconf|restart|version|info|proc|admin|kill|kill-<sig>|term }
kill or kill-9 should never be used in a productive environment!
clusternode1:rh2adm> HDB help
Usage: /usr/sap/RH2/HDB02/HDB { start|stop|reconf|restart|version|info|proc|admin|kill|kill-<sig>|term }
kill or kill-9 should never be used in a productive environment!
データベースを起動します。
clusternode1:rh2adm> HDB start
clusternode1:rh2adm> HDB startCopy to Clipboard Copied! Toggle word wrap Toggle overflow データベースを停止します。
clusternode1:rh2adm> HDB stop
clusternode1:rh2adm> HDB stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション 2 (推奨): sapcontrol を使用
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StartSystem HDB
03.07.2023 14:08:30
StartSystem
OK
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StartSystem HDB
03.07.2023 14:08:30
StartSystem
OK
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StopSystem HDB
03.07.2023 14:09:33
StopSystem
OK
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function StopSystem HDB
03.07.2023 14:09:33
StopSystem
OK
GetProcessList を使用して、HANA サービスの起動と停止を監視します。
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function GetProcessList
clusternode1:rh2adm> sapcontrol -nr ${TINSTANCE} -function GetProcessList
6.1.5. SAP HANA System Replication のステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA System Replication のステータスを確認するには、さまざまな方法があります。
- プライマリーノードの `clusternode1:rh2adm> python systemReplicationStatus.py `
-
clusternode1:rh2adm> echo $? #(systemReplicationStatus の戻りコード) -
clusternode1:rh2adm> hdbnsutil -sr_state -
clusternode1:rh2adm> hdbnsutil -sr_stateConfiguration
モニターとして実行される systemReplicationStatus.py の出力例:
予想される戻りコードの結果は次のとおりです。
- 10: NoHSR
- 11: Error
- 12: Unknown
- 13: Initializing
- 14: Syncing
- 15: Active
ほとんどの場合、システムレプリケーションのチェックは戻りコード 15 を返します。別の表示オプションとして、-t (printLandscapeTree) を使用する方法があります。
現在のプライマリーでの出力の例:
clusternode1:rh2adm> python systemReplicationStatus.py -t
HANA System Replication landscape:
DC1 ( primary )
| --- DC3 ( syncmem )
| --- DC2 ( syncmem )
clusternode1:rh2adm> python systemReplicationStatus.py -t
HANA System Replication landscape:
DC1 ( primary )
| --- DC3 ( syncmem )
| --- DC2 ( syncmem )
hdbnsutil -sr_state の例:
プライマリーでの sr_stateConfiguation の例:
セカンダリーでの sr_stateConfiguration の例:
どのノードが現在のプライマリーであるかをセカンダリーデータベースで確認することもできます。フェイルオーバー中に 2 つのプライマリーデータベースが見つかった場合に、この情報は、どちらのプライマリーデータベースが間違っており、セカンダリーとして再登録する必要があるかを判断するために必要になります。
詳細は、Example: Checking the Status on the Primary and Secondary Systems を参照してください。
6.1.6. セカンダリーノードの登録 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA System Replication 環境のセカンダリーデータベースを登録するための前提条件:
登録例:
登録すると、global.ini ファイルが自動的に更新されます。
更新前:
更新後:
6.1.7. sapcontrol GetProcessList リンクのコピーリンクがクリップボードにコピーされました!
アクティブな SAP HANA データベースのプロセスの確認
6.1.8. sapcontrol GetInstanceList リンクのコピーリンクがクリップボードにコピーされました!
これにより、SAP HANA データベースのインスタンスのステータスがリスト表示されます。ポートも表示されます。3 つの異なるステータス名があります。
- GREEN (実行中)
- GRAY (停止)
- YELLOW (ステータスが現在変化中)
アクティブなインスタンスの例:
停止したインスタンスの例:
6.1.9. hdbcons の例 リンクのコピーリンクがクリップボードにコピーされました!
HDB コンソールを使用してデータベースに関する情報を表示することもできます。
-
hdbcons -e hdbindexserver 'replication info' -
その他のオプションは、
hdbcons -e hdbindexserver helpを参照
'replication info' の例:
help の例:
6.1.10. SAP HANA バックアップの作成 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA System Replication を使用する場合は、先にプライマリーシステムでバックアップを作成する必要があります。
ユーザー <sid>adm としてこれを実行する方法の例:
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d SYSTEMDB "BACKUP DATA USING FILE ('/hana/backup/')"
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d ${SAPSYSTEMNAME} "BACKUP DATA USING FILE ('/hana/backup/')"
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d SYSTEMDB "BACKUP DATA USING FILE ('/hana/backup/')"
clusternode1:rh2adm> hdbsql -i ${TINSTANCE} -u system -d ${SAPSYSTEMNAME} "BACKUP DATA USING FILE ('/hana/backup/')"
6.1.11. プライマリーノードでの SAP HANA System Replication の有効化 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA System Replication はプライマリーノードで有効にする必要があります。これを行うには、先にバックアップを実行する必要があります。
clusternode1:rh2adm> hdbnsutil -sr_enable --name=DC1 nameserver is active, proceeding ... successfully enabled system as system replication source site done.
clusternode1:rh2adm> hdbnsutil -sr_enable --name=DC1
nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.
6.1.12. セカンダリーノードへのデータベースキーのコピー リンクのコピーリンクがクリップボードにコピーされました!
セカンダリーデータベースをセカンダリーとして登録するには、データベースキーをプライマリーデータベースからセカンダリーデータベースにコピーする必要があります。
以下に例を示します。
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/data/SSFS_${SAPSYSTEMNAME}.DAT
clusternode1:rh2adm> scp -rp /usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY remotehost3:/usr/sap/${SAPSYSTEMNAME}/SYS/global/security/rsecssfs/key/SSFS_${SAPSYSTEMNAME}.KEY
6.1.13. SAP HANA System Replication のセカンダリーノードの登録 リンクのコピーリンクがクリップボードにコピーされました!
まず、データベースキーがセカンダリーノードにコピーされていることを確認してください。次に、登録コマンドを実行します。
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC1 --remoteName=DC3 --operationMode=logreplay --online
clusternode1:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC1 --remoteName=DC3 --operationMode=logreplay --online
パラメーターの説明:
-
remoteHost: ソース (プライマリー) データベースを実行しているアクティブノードのホスト名 -
remoteInstance: データベースのインスタンス番号 replicationMode: 次のオプションのいずれか-
sync: ハードディスク同期 -
async: 非同期レプリケーション -
syncmem: メモリー同期
-
-
name: このレプリケーションサイトのエイリアス -
remoteName: ソースデータベースのエイリアス名 operationMode: 次のオプションのいずれか-
delta_datashipping: データが定期的に送信されます。テイクオーバーに少し時間がかかります。 -
logreplay: ログがリモートサイトですぐに再実行されます。テイクオーバーが早くなります。 -
logreplay_readaccess: 2 番目のサイトへの追加の logreplay 読み取り専用アクセスが可能です。
-
6.1.14. SAP HANA データベースの log_mode の確認 リンクのコピーリンクがクリップボードにコピーされました!
log_mode の設定には 2 つのオプションがあります。
-
log_mode=overwrite -
log_mode=normal: これはデフォルト値であり、データベースインスタンスがプライマリーとして実行されている場合にも必要です。SAP HANA Multitarget System Replication を使用する場合は、log_mode=normalを使用する必要があります。log_modeを確認する最良の方法は、hdbsqlを使用することです。
間違った overwrite エントリーを含む例:
この場合、次の 2 つの global.ini ファイルがあります。
デフォルト-
/usr/sap/${SAPSYSTEMNAME}/SYS/global/hdb/custom/config/global.ini
-
HOST-
/hana/shared/${SAPSYSTEMNAME}/HDB${TINSTANCE}/${HOSTNAME}/global.iniHOST値はDEFAULT値を上書きします。データベースを起動する前に両方のファイルを確認してから、hdbsqlを再度使用して正しい設定を確認することもできます。log_modeは、global.iniファイルを編集することで変更できます。
-
以下に例を示します。
clusternode1:rh2adm> vim /hana/shared/${SAPSYSTEMNAME}/HDB${TINSTANCE}/${HOSTNAME}/global.ini
# global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver
[persistence]
log_mode = overwrite
clusternode1:rh2adm> vim /hana/shared/${SAPSYSTEMNAME}/HDB${TINSTANCE}/${HOSTNAME}/global.ini
# global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver
[persistence]
log_mode = overwrite
global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver [persistence] log_mode = normal
# global.ini last modified 2023-04-06 16:15:03.521715 by hdbnameserver
[persistence]
log_mode = normal
global.ini ファイルを確認または更新した後、log_mode 値を確認します。
また、このセクションからわかるように、このパラメーターは [persistence] セクションで設定する必要があります。ログモードを overwrite から normal に変更する場合は、データベースを確実に回復できるように、完全なデータバックアップを作成することを推奨します。
6.1.15. プライマリーデータベースの検出 リンクのコピーリンクがクリップボードにコピーされました!
プライマリーノードを識別するには、たとえば次の方法があります。
-
pcs status | grep Promoted -
hdbnsutil -sr_stateConfiguration -
systemReplicationStatus.py
オプション 1 - 次の systemReplicationStatus.py スクリプトとフィルターの例は、すべてのノード上のプライマリーデータベースの場所を返します。
clusternode1:rh2adm>
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/Python/bin/python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py --sapcontrol=1 | egrep -e
"3${TINSTANCE}01/HOST|PRIMARY_MASTERS"| head -1 | awk -F"=" '{ print $2 }'
clusternode1:rh2adm>
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/Python/bin/python
/usr/sap/${SAPSYSTEMNAME}/HDB${TINSTANCE}/exe/python_support/systemReplicationStatus.py --sapcontrol=1 | egrep -e
"3${TINSTANCE}01/HOST|PRIMARY_MASTERS"| head -1 | awk -F"=" '{ print $2 }'
出力:
clusternode2
clusternode2
オプション 2 - 次の例では、すべてのノードに対して同様の方法で systemReplicationStatus を表示します。
rh2adm>hdbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
rh2adm>hdbnsutil -sr_state --sapcontrol=1 | grep site.*Mode
出力:
6.1.16. プライマリーのテイクオーバー リンクのコピーリンクがクリップボードにコピーされました!
プライマリーノードとセカンダリーノードの確認は、レプリケーションステータスの確認 セクションを参照してください。また、以下の点にも注意してください。
-
クラスターを
maintenance-modeにします。 - セカンダリーノードでテイクオーバーを開始します。
クラスターの maintenance-mode を有効にする例:
pcs property set maintenance-mode=true
[root@clusternode1]# pcs property set maintenance-mode=true
新しいプライマリーとなるセカンダリーで、<sidadm> ユーザーとして次のコマンドを実行します。
clusternode1:rh2adm> hdbnsutil -sr_takeover
clusternode1:rh2adm> hdbnsutil -sr_takeover
このセカンダリーがプライマリーになり、他のアクティブなセカンダリーデータベースが、新しいプライマリーに再登録されます。前のプライマリーは、セカンダリーとして手動で再登録する必要があります。
6.1.17. 以前のプライマリーをセカンダリーとして再登録する リンクのコピーリンクがクリップボードにコピーされました!
クラスターが停止しているか、maintenance-mode になっていることを確認してください。以下に例を示します。
clusternode2:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC2 --online --remoteName=DC3 --operationMode=logreplay --force_full_replica --online
clusternode2:rh2adm> hdbnsutil -sr_register --remoteHost=remotehost3 --remoteInstance=${TINSTANCE} --replicationMode=syncmem --name=DC2 --online --remoteName=DC3 --operationMode=logreplay --force_full_replica --online
この例では、完全なレプリケーションを使用しています。SAP HANA システム管理者は、完全なレプリケーションが必要になる場合を理解しておく必要があります。
6.1.18. フェイルオーバーからの回復 リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA System Replication のステータスの確認 および プライマリーノードの検出 を参照してください。重要なのは、情報の整合性を確保することです。ノードが systemReplicationStatus.py の出力に含まれておらず、ノードのシステムレプリケーションの状態が異なる場合は、このノードを再登録する必要があるかどうかをデータベース管理者に確認してください。
これを解決する 1 つの方法は、このサイトを新しいセカンダリーとして 再登録 することです。
場合によっては、セカンダリーインスタンスがまだ起動していないことがあります。その後、もう一度再登録する前に、このサイトの登録を解除してください。セカンダリー DC1 の登録を解除する例:
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC1
clusternode1:rh2adm> hdbnsutil -sr_unregister --name=DC1
DC1 の再登録例:
clusternode1:rh2adm> hdbnsutil -sr_register --name=DC1 --remoteHost=node2 --remoteInstance=02 --replicationMode=sync --operationMode=logreplay --online
clusternode1:rh2adm> hdbnsutil -sr_register --name=DC1 --remoteHost=node2 --remoteInstance=02 --replicationMode=sync --operationMode=logreplay --online
データベースを 起動 し、実行中 かどうかを確認する必要があります。最後に レプリケーションステータスを確認 します。
6.2. Pacemaker コマンド リンクのコピーリンクがクリップボードにコピーされました!
6.2.1. クラスターの起動と停止 リンクのコピーリンクがクリップボードにコピーされました!
すべてのノードでクラスターを起動するには、次のコマンドを実行します。
pcs cluster start -all
# pcs cluster start -all
再起動後、サービスが有効になっている場合にのみ、クラスターが自動的に起動します。このコマンドは、クラスターが起動したかどうか、およびデーモンの自動起動が有効になっているかどうかを確認するのに役立ちます。
pcs cluster status
# pcs cluster status
クラスターの自動起動は次の方法で有効にできます。
pcs cluster enable --all
# pcs cluster enable --all
その他のオプションは以下のとおりです。
- クラスターを停止する
- ノードをスタンバイ状態にする
-
クラスターを
maintenance-modeにする
詳細は、pcs cluster のヘルプを参照してください。
pcs cluster stop --all pcs cluster help
# pcs cluster stop --all
# pcs cluster help
6.2.2. クラスターを maintenance-mode にする リンクのコピーリンクがクリップボードにコピーされました!
変更を加えるときに Pacemaker クラスターによる干渉を避けるには、クラスターを maintenance-mode にすることで、クラスターを "フリーズ" できます。
pcs property set maintenance-mode=true
# pcs property set maintenance-mode=true
maintenance-mode を確認する簡単な方法は、リソースが unmanaged かどうかを確認することです。
maintenance-mode のクラスターは、リソースステータスの変更を更新しません。その間に、クラスターリソースを更新してリソース状態を検出します。
pcs resource refresh
# pcs resource refresh
これにより、何か問題がある場合にその問題が示され、maintenance-mode が終了するとすぐに、クラスターによる修復アクションが実行されます。
次のコマンドを実行して maintenance-mode を解除します。
pcs property set maintenance-mode=false
# pcs property set maintenance-mode=false
これで、クラスターが引き続き動作します。設定に問題があった場合、クラスターはその問題にすぐに対処します。
6.2.3. クラスターのステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
以下に、クラスターのステータスを確認するいくつかの方法を示します。
クラスターが実行中かどうかを確認します。
pcs cluster status
# pcs cluster statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターとすべてのリソースを確認します。
pcs status
# pcs statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター、すべてのリソース、およびすべてのノード属性を確認します。
pcs status --full
# pcs status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow リソースのみを確認します。
pcs resource status --full
# pcs resource status --fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow Stonithの履歴を確認します。pcs stonith history
# pcs stonith historyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 場所の制約を確認します。
pcs constraint location
# pcs constraint locationCopy to Clipboard Copied! Toggle word wrap Toggle overflow
フェンシングを設定してテストする必要があります。可能な限り自動化されたソリューションを実現するには、クラスターを常にアクティブにする必要があります。そうすることで、再起動後にクラスターが自動的に起動できるようになります。実稼働環境では、再起動を無効にすると、クラッシュ後などに手動で介入できるようになります。デーモンのステータスも確認してください。
以下に例を示します。
6.2.4. リソースの状態の確認 リンクのコピーリンクがクリップボードにコピーされました!
pcs resource を使用して、すべてのリソースのステータスを確認します。これにより、リソースのリストと現在のステータスが出力されます。
以下に例を示します。
6.2.5. リソース設定の確認 リンクのコピーリンクがクリップボードにコピーされました!
次のコマンドで、現在のリソース設定が表示されます。
これには、インストールおよび設定されたリソースエージェントの設定に使用されるすべてのパラメーターがリスト表示されます。
6.2.6. SAPHana リソースオプションの AUTOMATED_REGISTER=true リンクのコピーリンクがクリップボードにコピーされました!
このオプションを SAPHana リソースで使用すると、Pacemaker はセカンダリーデータベースを自動的に再登録します。
最初のテストではこのオプションを使用することを推奨します。AUTOMATED_REGISTER=false を使用した場合、管理者はセカンダリーノードを手動で再登録する必要があります。
6.2.7. リソースの処理 リンクのコピーリンクがクリップボードにコピーされました!
リソース管理には複数のオプションがあります。詳細は、利用可能なヘルプを参照してください。
pcs resource help
# pcs resource help
使用されているリソースエージェントをリスト表示します。
pcs resource config | grep "type=" | awk -F"type=" '{ print $2 }' | sed -e "s/)//g"
# pcs resource config | grep "type=" | awk -F"type=" '{ print $2 }' | sed -e "s/)//g"
出力例:
IPaddr2 SAPHanaTopology SAPHana
IPaddr2
SAPHanaTopology
SAPHana
特定のリソースエージェントの説明と設定パラメーターを表示します。
pcs resource describe <resource agent>
# pcs resource describe <resource agent>
例 (出力なし):
pcs resource describe IPaddr2
# pcs resource describe IPaddr2
リソースエージェント IPaddr2 の例 (出力付き):
クラスターが停止すると、すべてのリソースも停止します。クラスターが maintenance-mode になると、すべてのリソースは現在のステータスのままになりますが、監視または管理されなくなります。
6.2.8. maintenance mode のクラスタープロパティーの処理 リンクのコピーリンクがクリップボードにコピーされました!
定義されているすべてのプロパティーをリスト表示します。
データベースを再設定するには、設定が完了するまで変更を無視するようにクラスターに指示する必要があります。以下を使用してクラスターを maintenance-mode にできます。
pcs property set maintenance-mode=true
# pcs property set maintenance-mode=true
maintenance-mode を確認します。
すべてのリソースが "unmanaged" であることを確認します。
maintenance-mode の設定を解除すると、リソースは managed に戻ります。
pcs property set maintenance-mode=false
# pcs property set maintenance-mode=false
6.2.9. move を使用した SAPHana リソースのフェイルオーバー リンクのコピーリンクがクリップボードにコピーされました!
SAP HANA データベースをフェイルオーバーする簡単な例は、pcs resource move コマンドを使用することです。以下に示すように、クローンリソース名を使用してリソースを移動する必要があります。
pcs resource move <SAPHana-clone-resource>
# pcs resource move <SAPHana-clone-resource>
この例では、クローンリソースは SAPHana_RH2_02-clone です。
リソースを移動します。
制約が残っているかどうかを確認します。
pcs constraint location
# pcs constraint location
リソースをクリアすることで、フェイルオーバー中に作成された場所の制約を削除できます。以下に例を示します。
pcs resource clear SAPHana_RH2_02-clone
[root@clusternode1]# pcs resource clear SAPHana_RH2_02-clone
"Migration Summary" に警告やエントリーが残っているかどうかを確認します。
pcs status --full
# pcs status --full
stonith の履歴を確認します。
pcs stonith history
# pcs stonith history
必要に応じて、stonith の履歴をクリアします。
pcs stonith history cleanup
# pcs stonith history cleanup
Pacemaker バージョン 2.1.5 より前のバージョンを使用している場合は、Is there a way to manage constraints when running pcs resource move? を参照し、残っている制約を確認してください。
6.2.10. フェイルオーバーと同期状態の監視 リンクのコピーリンクがクリップボードにコピーされました!
すべての Pacemaker のアクティビティーは、クラスターノードの /var/log/messages ファイルに記録されます。他にも多くのメッセージがあるため、SAP リソースエージェントに関連するメッセージを確認するのが難しい場合があります。SAP リソースエージェントに関連するメッセージのみをフィルターするコマンドエイリアスを設定できます。
エイリアスの例 tmsl:
alias tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_${SAPSYSTEMNAME}_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
# alias tmsl='tail -1000f /var/log/messages | egrep -s "Setting master-rsc_SAPHana_${SAPSYSTEMNAME}_HDB${TINSTANCE}|sr_register|WAITING4LPA|PROMOTED|DEMOTED|UNDEFINED|master_walk|SWAIT|WaitforStopped|FAILED|LPT"'
tsml の出力例:
フィルターを使用すると、どのようなステータス変化が発生しているかを理解しやすくなります。詳細がない場合は、メッセージファイル全体を開くと、すべての情報を確認できます。
フェイルオーバー後、リソースをクリアできます。場所の制約が残っていないことも確認してください。
6.2.11. クラスターの整合性の確認 リンクのコピーリンクがクリップボードにコピーされました!
インストール中、設定が最終的に完了する前にリソースが起動することがあります。これにより、Cluster Information Base (CIB) のエントリーが発生し、誤った動作が発生する可能性があります。これは簡単に確認でき、設定の完了後に手動で修正することもできます。
SAPHana リソースを起動すると、欠落しているエントリーが再作成されます。間違ったエントリーには pcs コマンドでは対処できないため、手動で削除する必要があります。
CIB エントリーを確認します。
cibadmin --query
# cibadmin --query
クラスターメンバーが DC1 と DC2 であり、ノード間の同期状態が SOK と報告される場合、DC3 と SFAIL のエントリーはクラスター情報ベースに存在しないはずです。
対応するエントリーを確認する例:
cibadmin --query |grep '"DC3"' cibadmin --query |grep '"SFAIL"'
# cibadmin --query |grep '"DC3"'
# cibadmin --query |grep '"SFAIL"'
このコマンドは、クラスター内の任意のノードで root ユーザーとして実行できます。通常、コマンドの出力は空です。設定にまだエラーがある場合、出力は次のようになります。
<nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>
<nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>
これらのエントリーは、次のコマンドを使用して削除できます。
cibadmin --delete --xml-text '<...>'
# cibadmin --delete --xml-text '<...>'
上の例のエントリーを削除するには、次のように入力する必要があります。出力には二重引用符が含まれるため、テキストを一重引用符で囲む必要があることに注意してください。
cibadmin --delete --xml-text ' <nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>'
# cibadmin --delete --xml-text ' <nvpair id="SAPHanaSR-hana_rh1_glob_sec" name="hana_rh1_glob_sec" value="DC3"/>'
削除された CIB エントリーがないことを確認します。返される出力は空である必要があります。
cibadmin --query |grep 'DC3"'
# cibadmin --query |grep 'DC3"'
6.2.12. クラスターのクリーンアップ リンクのコピーリンクがクリップボードにコピーされました!
フェイルオーバーテスト中に、以前のテストの制約やその他の残留物が残ることがあります。次のテストを開始する前に、クラスターからこれらをクリアする必要があります。
クラスターのステータスで障害イベントがないか確認します。
pcs status --full
# pcs status --full
"Migration Summary" にクラスターの警告またはエントリーが表示された場合は、リソースをクリアしてクリーンアップする必要があります。
pcs resource clear SAPHana_RH2_02-clone pcs resource cleanup SAPHana_RH2_02-clone
# pcs resource clear SAPHana_RH2_02-clone
# pcs resource cleanup SAPHana_RH2_02-clone
出力:
Cleaned up SAPHana_RH2_02:0 on clusternode1 Cleaned up SAPHana_RH2_02:1 on clusternode2
Cleaned up SAPHana_RH2_02:0 on clusternode1
Cleaned up SAPHana_RH2_02:1 on clusternode2
以前のフェイルオーバーなどで使用された不要な場所の制約があるかどうかを確認します。
pcs constraint location
# pcs constraint location
既存の制約をさらに詳しく確認します。
pcs constraint --full
# pcs constraint --full
リソース移動後の場所の制約の例:
Node: hana08 (score:-INFINITY) (role:Started) (id:cli-ban-SAPHana_RH2_02-clone-on-hana08)
Node: hana08 (score:-INFINITY) (role:Started) (id:cli-ban-SAPHana_RH2_02-clone-on-hana08)
この場所の制約をクリアします。
pcs resource clear SAPHana_RH2_02-clone
# pcs resource clear SAPHana_RH2_02-clone
制約が制約リストから消えていることを確認します。まだ残っている場合は、制約 ID を使用して明示的に削除します。
pcs constraint delete cli-ban-SAPHana_RH2_02-clone-on-hana08
# pcs constraint delete cli-ban-SAPHana_RH2_02-clone-on-hana08
フェンシングを使用して複数のテストを実行する場合は、stonith の履歴をクリアすることもできます。
pcs stonith history cleanup
# pcs stonith history cleanup
pcs コマンドはすべて root ユーザーとして実行します。残留物の検出 も参照してください。
6.2.13. その他のクラスターコマンド リンクのコピーリンクがクリップボードにコピーされました!
さまざまなクラスターコマンドの例
6.3. RHEL および一般的なコマンド リンクのコピーリンクがクリップボードにコピーされました!
6.3.1. 現在のステータスの検出 リンクのコピーリンクがクリップボードにコピーされました!
環境の現在のステータスを知るには、いくつかの手順に従う必要があります。環境の監視 を参照してください。また、次のことを行うことを推奨します。
-
/var/log/messagesを確認し、ログの確認を容易にするために モニタリング用のエイリアス を使用します。 - 場合によっては、適切な操作を継続するために、クラスターを以前のアクティビティーからクリーンアップする必要があります。残留物を検出 し、必要に応じてクリアします。
6.3.2. yum info リンクのコピーリンクがクリップボードにコピーされました!
6.3.3. RPM バージョン表示 リンクのコピーリンクがクリップボードにコピーされました!
rpm -q resource-agents-sap-hana resource-agents-sap-hana-0.162.1-2.el9_2.noarch
# rpm -q resource-agents-sap-hana
resource-agents-sap-hana-0.162.1-2.el9_2.noarch
6.3.4. モニタリング用のエイリアス リンクのコピーリンクがクリップボードにコピーされました!
これをシェルプロファイルに追加できます。この例では、root のエイリアスは <sid>adm のエイリアスに依存しているため、これもすでに定義されている必要があります。
root (
~/.bashrcに追加):Copy to Clipboard Copied! Toggle word wrap Toggle overflow <sid>adm(~/.customer.shに追加):Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第7章 参考資料 リンクのコピーリンクがクリップボードにコピーされました!
7.1. Red Hat リンクのコピーリンクがクリップボードにコピーされました!
7.2. SAP リンクのコピーリンクがクリップボードにコピーされました!
- SAP HANA Administration Guide for SAP HANA Platform
- Disaster Recovery Scenarios for Multitarget System Replication
- SAP HANA System Replication Configuration Parameter
- Example: Checking the Status on the Primary and Secondary Systems
- General Prerequisites for Configuring SAP HANA System Replication
- Change Log Modes
- Failed to re-register former primary site as new secondary site due to missing log
- Checking the Status with landscapeHostConfiguration.py
- How to Setup SAP HANA Multi-Target System Replication
- SAP HANA Multitarget System Replication