ユーザーは、HADB 履歴ファイル、管理エージェント設定ファイル、ログファイルとリポジトリ、およびインストールパスの外部にあるすべてのデータデバイスを保管するようにしてください。この作業がまだ完了していない場合は、アップグレードの前に実行してください。管理リポジトリと設定ファイルを移動するには、次の手順に従います。
すべての古い管理エージェントを停止し、HADB ノードは動作したままにします。
各ホスト上で、リポジトリディレクトリを新しい場所に移動します。
各ホスト上で、dbconfig ディレクトリを新しい場所にコピーします。
各ホスト上で、mgt.cfg ファイルをアップデートし、dbconfig とリポジトリディレクトリの正しいパスを設定します。
アップデートされた mgt.cfg ファイルを使用して管理エージェントを起動します。
HADB Version 4.4.x から Version 4.4.2-7 にアップグレードするには、次の手順を実行します。
必要に応じて、上で説明したアップグレード前の作業を実行します。
HADB Version 4.4.2-7 をすべての HADB ホストにインストールします。パスは Version 4.4.x とは別のパス、たとえば /opt/SUNWhadb/4.4.2-7 にします。
HADB Version 4.4.2-7 を、HADB ホストとは別の hadbm クライアントホストにインストールします。
すべての HADB ホスト上で実行されているすべての管理エージェントを停止します。
新しいバージョンのソフトウェアを使用して (ただし、設定ファイルは古いまま)、管理エージェントプロセスを起動します。残りの手順では、新しいバージョンの bin ディレクトリにある hadbm コマンドを使用してください。
管理ドメインでパッケージを登録します。デフォルトのパッケージ名が V4.4 になるので、同じ名前を持つ既存のパッケージとの競合を避けるために別のパッケージ名が必要になる場合があります。
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-7 V4.4.2-7 |
hadbm listpackages コマンドを実行し、ドメインに新しいパッケージが登録されていることを確認します。
新しい hadbm Version 4.4.2-7 を使用してデータベースを再起動します。デバイスと履歴ファイルを移動する必要がある場合は、オンラインアップグレードを、デバイスと履歴ファイル用の新しいパスの設定とともに 1 回の操作で実行します。
hadbm set packagename=V4.4.2-7,devicepath=new_devpath, historypath=new_histpath |
そうでない場合、つまりデバイスと履歴ファイルがすでにインストールディレクトリの外にある場合は、ノードの順次再起動のみを行う次のコマンドを実行します。
hadbm set packagename=V4.4.2-7 database name |
データベースが「実行中」の状態にあり (hadbm status コマンドを使用して確認)、かつ正常に動作してクライアントトランザクションを処理していることを確認します。
すべてが正常に動作している場合は、あとで古いインストールを削除することができます。古いパッケージの登録を解除する前に、古いパッケージへのすべての参照を ma リポジトリから削除します。そうしないと、「使用中のパッケージ」のために hadbm unregisterpackage が失敗します。たとえば、ダミーの再設定操作 hadbm set connectiontrace=same as previous value によって、古いパッケージへのすべての参照が削除されます。ここで、古いパッケージの登録を解除します。
hadbm unregisterpackage [--hosts=host-list] old pacakge name |
ファイルシステムから古いインストールを削除します。
Solaris で、アップグレードの成功をテストするには、アップグレードが正常に実行されたことを確認します。
動作中のプロセスが新しいバイナリを使用していることを確認してください。すべての HADB ノードで、次のことを確認します。
new path/bin/ma -v new path/bin/hadbm -v |
データベースが動作中かどうかを確認します。次のコマンドによって、すべての HADB ノードが「実行中」の状態にあることが表示されます。
new path/bin/hadbm status -n |
HADB を使用している製品のポインタが、新しい HADB パスを指すように変更されていることを確認します。
HADB を使用している製品では、独自のアップグレードテストを実行して、HADB アップグレードも動作していることを確認できます。
オンラインアップグレードの後、新しいバージョンが正常に動作しない場合は、以前の HADB バージョンの使用に戻してください。ただし、管理エージェントリポジトリが変更されている場合は、HADB 自体はダウングレードできますが、新しい管理エージェントを引き続き動作させる必要があります。
ここでは、HADB の配備とアップグレードに関する追加情報を示します。
デバイス、ログ、および履歴ファイルはローカルディスクにのみ格納するようにし、リモートマウントのファイルシステムは使用しないでください。
ホストに複数のノードが配置されている場合は、各ノードに所属するデバイスを別のディスクに保管することをお勧めします。そうしないと、ディスクの競合によってパフォーマンスが低下します。この問題の症状は、「BEWARE - last flush/fputs took too long」などのメッセージによって履歴ファイルで確認できます。1 つのノードに複数のデータデバイスファイルがある場合は、これらのデバイスファイルに別々のディスクを使用することをお勧めします。
ローカルディスク (可能であれば、データデバイスに使用されているものとは別のディスク) を使用して、HADB ホストに HADB バイナリをインストールしてください。NFS の遅延またはディスクの競合によって、履歴ファイルに「Process blocked for nnn, max block time is nnn」という警告が出力され、ノードが再起動される可能性があります。
HADB デバイス、履歴ファイル、管理エージェントディレクトリ、およびエージェント設定ファイルを HADB パッケージのパスには配置しないでください。これを行うと、新しいバージョンにアップグレードし、古いパッケージのパスを削除したときに問題が発生します。
このリリースの HADB では、最大 28 ノード (24 のアクティブデータノード、および 4 つのスペア) が正式にサポートされています。
JDBC ドライバおよび HADB サーバーには同じバージョンを使用することをお勧めします。
IPv6 はサポートしていません。IPv4 のみです。
Windows でのコマンド行の長さは、2048 バイトに制限されています。
UDP マルチキャスト用にネットワークを設定する必要がある。
RedHat Enterprise Linux 3.0 Update 1 〜 3 は、過剰なスワッピングが見られるため、配備プラットフォームとしてはお勧めできません。この問題は、RedHat Enterprise Linux 3.0 Update 4 では修正されています。
NSUP をリアルタイム優先度を使用して実行する可能性は次のとおりです。
ノードスーパーバイザー (NSUP) のプロセス (clu_nsup_srv) は、タイムリーな方法による「ハートビート」メッセージ交換を利用して、HADB の高可用性を保証します。NSUP がほかのプロセスと同じ場所に配置されていると、このタイミングが影響を受け、リソースの枯渇が発生します。その結果、誤ったネットワークパーティションが発生し、ノードが再起動します (その前に、履歴ファイルに「Process blocked for n seconds」という警告が出力される)。それにより、トランザクションの中止やその他の例外が発生します。
この問題を解決するには、clu_nsup_srv (installpath/lib/server に格納されている) の suid ビットを設定し、そのファイルをルートが所有するようにする必要があります。これを手動で行うには、次のコマンドを実行します。
# chown root clu_nsup_srv # chmod u+s clu_nsup_srv |
これにより、clu_nsup_srv プロセスは、起動されると、ユーザー root として実行されます。さらに、起動後、自分自身にリアルタイム優先度を自動的に与えることができるようになります。setuid を使用することによるセキュリティーへの影響を避けるために、リアルタイム優先度は最初の間だけ設定され、優先度が変更されたらプロセスは有効な uid に戻ります。ほかの HADB プロセスは、優先度をタイムシェアするために自分の優先度を低くします。
NSUP がリアルタイム優先度を設定できない場合は、「Could not set realtime priority」(unix: errno will be set to EPERM) という警告を出力します。この警告は ma.log ファイルに書き込まれ、リアルタイム優先度を使用しないで処理が継続されます。
リアルタイム優先度を設定できない例として、次のような場合があります。
Solaris 10 の非大域ゾーンにインストールされている場合
Solaris 10 で、PRIV_PROC_LOCK_MEMORY (プロセスが物理メモリー内のページをロックできる) または PRIV_PROC_PRIOCNTL 特権、あるいはその両方が無効になっている場合
ユーザーが setuid 権限を無効にしている場合
ユーザーがソフトウェアを tar ファイルとしてインストールしている場合 (App.server 用のルート以外のインストールオプション)
clu_nsup_srv プロセスは CPU の消費が少なく、フットプリントも小さいため、リアルタイム優先度を使用して実行してもパフォーマンスには影響しません。
Solaris での HADB 用の IP ネットワークマルチパスの設定 (Solaris 9 でのみテスト済み)
可能な範囲で最高のネットワーク可用性を保証するために、HADB を実行している Solaris ホストをネットワークマルチパスを使用して設定することをお勧めします。ネットワークマルチパスの設定は、『IP Network Multipathing Administration Guide』で詳細に説明されています。HADB でマルチパスを使用することにした場合は、後述されている HADB 用のマルチパス設定への対応に進む前に、『IP Network Multipathing Administration Guide』の「Administering Network Multipathing」の節を参照してマルチパスを設定してください。『IP Network Multipathing Administration Guide』は、Solaris 9 の『System Administrator Collection』に含まれており、http://docs.sun.com からダウンロードできます。
ネットワークインタフェース障害検出時間の設定
HADB でマルチパスのフェイルオーバーを適切にサポートするには、/etc/default/mpathd 内の FAILURE_DETECTION_TIME パラメータで指定されているネットワークインタフェース障害検出時間が 1000 ミリ秒を超えないようにする必要があります。元の値がこの値を超えている場合は、このファイルを編集して、このパラメータの値を 1000 に変更します。
FAILURE_DETECTION_TIME=1000 |
変更を有効にするために、次のコマンドを実行します。
pkill -HUP in.mpathd |
HADB で使用する IP アドレス
『Solaris IP Network Multipathing Administration Guide』で説明されているように、マルチパスを使用するには、物理ネットワークインタフェースをマルチパスインタフェースグループにグループ化する必要があります。このようなグループ内の各物理インタフェースには、物理インタフェースアドレスとテストアドレスの 2 つの IP アドレスが関連付けられます。データの送信に使用できるのは物理インタフェースアドレスのみであり、テストアドレスは Solaris 内部の使用のためにのみ用意されています。hadbm create --hosts が実行されると、各ホストは、マルチパスグループの 1 つの物理インタフェースアドレスによってのみ指定されます。
例
ホスト 1 とホスト 2 のそれぞれに、2 つの物理ネットワークインタフェースが含まれていると仮定します。各ホスト上で、これらの 2 つのインタフェースをマルチパスグループとして設定し、ifconfig -a を実行すると次の出力が得られます。
ホスト 1
bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000 broadcast 129.159.115.255 |
ホスト 2
bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000 broadcast 129.159.115.255 |
ここで、両方のホスト上の物理ネットワークインタフェースは、bge0 および bge1 として表示されています。『IP Network Multipathing Administration Guide』で説明されているように、bge0:1 および bge1:1 として表示されているのはマルチパステストインタフェースです (そのため、ifconfig 出力ではこれらのインタフェースが「非推奨」としてマークされている)。
この環境で HADB を設定するには、各ホストから 1 つの物理インタフェースアドレスを選択します。この例では、ホスト 1 からは 129.159.115.10 を、ホスト 2 からは 129.159.115.20 を選択します。ホストあたり 1 つのデータベースノードを含むデータベースを作成するには、hadbm create に次の引数を使用します。
--host 129.159.115.10,129.159.115.20 |
ホストあたり 2 つのデータベースノードを含むデータベースを作成するには、次の引数を使用します。
--host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20 |
どちらの場合も、両方のホストの ma.server.mainternal.interfaces 変数を 129.159.115.0/24 に設定してください。
オンラインで 4.2 または 4.3 から 4.4 にアップグレードすることはできません。ただし、4.4 の将来のバージョンではオンラインアップグレードがサポートされます。4.4.1 から 4.4.2 にアップグレードするには、次の手順を実行します。
すべての HADB ホストに 4.4.2 をインストールします。パスは 4.4.1 とは別のパス、たとえば /opt/SUNWhadb/4.4.2-6 にします。
hadbm クライアントホストに新しいバージョンをインストールします。
HADB ホスト上で実行されているすべての管理エージェントを停止します。
新しいバージョンのソフトウェアを使用して (ただし、設定ファイルは古いまま)、管理エージェントプロセスを起動します。残りの手順では、新しいバージョンの bin ディレクトリにある hadbm コマンドを使用してください。
管理ドメインでパッケージを登録します。ここで、デフォルトのパッケージ名が V4.4 になるため、同じ名前を持つ既存のパッケージとの競合を避けるために別のパッケージ名が必要になる場合があります。
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2 |
新しいバージョンを使用してデータベースを再起動します。次のコマンドでは、ノードの順次再起動が実行されます。
hadbm set packagename=V4.4.2 database_name |
データベースが「実行中」の状態にあり (hadbm status コマンドを使用して確認)、かつ正常に動作してクライアントトランザクションを処理していることを確認します。
すべてが正常に動作している場合は、あとで古いインストールを削除することができます。
古いパッケージの登録を解除する前に、古いパッケージへのすべての参照を ma リポジトリから削除します。そうしないと、「使用中のパッケージ」のために hadbm unregisterpackage が失敗します。たとえば、ダミーの再設定操作 hadbm set connectiontrace=<same_as_previous_value> によって、古いパッケージへのすべての参照が削除されます。ここで、古いパッケージの登録を解除します。
hadbm unregisterpackage [--hosts=<host_list>] <old_package_name> |
HADB のインストール手順で説明されているように、ファイルシステムから古いインストールを削除します。