ここでは、Application Server 8.1 に含まれている HADB 実装に関する重要な追加情報を示します。
データベース管理に使用するパスワードの変更を可能にするために、新しい管理コマンド hadbm setadminpassword が実装されました。このコマンドは、使用する管理エージェントを示すオプションと、古いパスワードおよび新しいパスワードを取ります。詳細は、hadbm setadminpassword のマニュアルページを参照してください。
既存の管理コマンド hadbm listpackages が変更されています。以前、このコマンドはオペランドを取らず、関連する管理ドメイン内のすべてのパッケージを表示していました。変更によって、オプションのパッケージ名オペランドが導入され、その名前を持つパッケージのみが表示されます。そのオペランドが指定されない場合は、すべてのパッケージが表示されます。詳細は、hadbm listpackages のマニュアルページを参照してください。
既存の管理コマンド hadbm createdomain が変更されています。hostlist オペランドが、管理エージェントのポート番号も指定できるように拡張されました。この方法により、hostlist オペランドのみを使用してドメインが完全に指定されます。下位互換性のために、以前の動作も引き続きサポートされています。詳細は、hadbm createdomain のマニュアルページを参照してください。
管理システムからのエラーメッセージの一部が変更されています。これらの変更は、エラーメッセージのわかりやすさ、一貫性、および正確性を向上させることを目的にしています。実際の変更は、このリリースノートには示されていません。
インストールとアンインストールの動作が若干変更されています。HADB のインストールまたはアンインストールでは、ソフトリンク /opt/SUNWhadb/4 が常に保持されるべきですが、必ずしもそのとおりにはなっていません。
コマンド行でパスワードをコマンドオプションとして入力する場合がありますが、この方法は推奨されません。これは、コマンド行オプションとしてパスワードを取るすべての hadbm コマンドに当てはまります。hadbm コマンドでは、従来より、パスワードを次の方法で入力できるようになっています。
パスワードファイル
コマンド行オプション
対話型の入力
2 つ目の方法のコマンド行オプションは安全でないと見なされるため、推奨されません。この方法でパスワードが入力されると、警告メッセージが表示されます。代わりに、1 つ目の方法のパスワードファイルか、または 3 つ目の方法の対話型の入力を使用してください。コマンド行でのパスワードの使用は、次のリリースでは廃止される予定です。これは、コマンド行のパスワードオプションを取るすべての hadbm コマンドに適用されることに注意してください。
HADB は、JGroups Version 2.2 を使用するようにアップグレードされており、そのソースコードは HADB とともに配布されます。以前の HADB バージョンからのオンラインアップグレードをサポートするために、JGroups 2.1 および 2.2 の両方が HADB とともに提供されます。JGroups 2.1 の場合は、バイトコードのみが提供されます。
次のファイルシステムを使用するよう HADB を設定する場合には、重要な考慮事項がいくつかあります。
ext2 および ext3— HADB は、Red Hat Application Server 3.0 用に ext2 および ext3 ファイルシステムをサポートしている。Red Hat Application Server 2.1 については、HADB は ext2 ファイルシステムしかサポートしていない。
Veritas– Solaris プラットフォームで Veritas File System を使用すると、「WRN: Direct disk I/O mapping failed」というメッセージが履歴ファイルに書き込まれる。このメッセージは、データデバイスおよびログデバイスについて HADB が直接入出力を有効にできないことを示している。直接入出力は、ディスクページに書き込むための CPU コストを節減することによってパフォーマンスを向上させる。また、「ダーティー」なデータページを管理するためのオペレーティングシステムのオーバーヘッドを減らす。
Veritas File System で直接入出力を利用するには、次の方法の 1 つを使います。
オプション mincache=direct でマウントされたファイルシステム上に、データデバイスとログデバイスを作成します。このオプションは、このファイルシステムで作成されたすべてのファイルに適用されます。詳細は、mount_vxfs(1M) コマンドを参照してください。
Veritas Quick 入出力ユーティリティーを使用して、ファイルシステムファイルに対する raw 入出力を行います。詳細は、『VERITAS File System 4.0 Administrator's Guide for Solaris』を参照してください。
これらの設定は、Application Server 8.1 2005Q2 Update 2 ではテストされていないことに注意してください。
Application Server ソフトウェアでの HADB のインストールと設定については、『Application Server Enterprise Edition 高可用性 (HA) 管理ガイド』を参照してください。
ユーザーは、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 のインストール手順で説明されているように、ファイルシステムから古いインストールを削除します。
テーブルに UNIQUE 二次インデックスを作成することはできません。
式 (DISTINCT 列) は、これが選択された唯一の式でないかぎり、収集式では許可されません。
すべてのテーブルを、主キーを指定して作成する必要があります。つまり、主キーのないテーブルはサポートされていません。
FULL OUTER JOIN はサポートされていません。
テーブルサブクエリーである IN サブクエリーはサポートされていません。次に例を示します。
SELECT SNAME FROM S WHERE (S1#,S2#) IN (SELECT S1#,S2# FROM SP WHERE P#='P2') |
NOT NULL と PRIMARY KEY 以外の制約はサポートされていません。
リソースに新しい所有者を割り当てることができます。ただし、これを行う場合、現在の所有者に付与されている特権は新しい所有者に付与されません。
2 つ以上の入れ子の NOT EXISTS サブクエリーで、各サブクエリーがクエリーの外側のレベルに (直接) 関連付けられていないものはサポートされていません。
列の特権はサポートされていません。
行の値コンストラクタは、VALUES 句でのみ許可されています。
行の値コンストラクタでは、サブクエリーは値式とは見なされません。
主キーを作成するとき、次のデータ型は使用できません。
REAL
FLOAT
DOUBLE PRECISION
DECIMAL
NUMERIC
Application Server には、HTTP、IIOP、および JMS クライアント向けの負荷分散、HTTP セッションのフェイルオーバーのサポート、EJB クラスタリングおよびフェイルオーバーのサポート、高可用性 EJB タイマー、分散トランザクションリカバリ、アプリケーションのローリングアップグレードのサポート、および J2EE アプリケーションの一時的な状態を保存するための高可用性データベースが組み込まれています。
可用性により、クラスタ内の Application Server インスタンスのフェイルオーバー保護が可能になります。ある Application Server インスタンスがダウンすると、そのサーバーに割り当てられていたセッションを別の Application Server インスタンスが引き継ぎます。セッション情報は、HADB に格納されます。HADB は、HTTP セッションの持続性、ステートフルセッション Bean、およびシングルサインオン資格をサポートします。