寺田　佳央 – Yoshio Terada

HADBの両ノード障害発生時の復旧方法

HADBの両ノード障害発生時の復旧方法


前回、HADBノードの再起動と状態確認方法で説明しましたが、

HADBを構成するノードの再起動が必要な場合は、片ノードづつ

リブートをして頂くか、“hadbm stop HADB_NAME”を実行した後、

再起移動してください。


仮に、HADBを構成するノードがお互いに通信できなくなった場合、

もしくは、両ノードが同時に停止してしまったような場合

データベースの整合性が取れなくなりHADBサービスを提供できなくなります。

そのような場合、データベースを再構築しなくてはなりません。



今回は、両ノードが同時に停止してしまった場合、もしくはステータスが

不正な状態になった場合のHADBの復旧方法について説明します。


復旧手順は下記の２ステップを実行してください。



手順１: HADBを初期化(“hadbm clear”)する。

手順２: “asadmin configure-ha-cluster”を実行する。



両ノード障害の発生（疑似）


DBの不整合が発生する状態を作成する為、HADBが稼働している状態で、

両ノードを同時にリブートして下さい。

appserver1 > sync appserver1 > reboot appserver2 > sync appserver2 > reboot

不正な状態に陥っている事の確認


次に、両ノードをリブートした後、それぞれのシステム上でHADBの

管理エージェント(ma)を起動して下さい。

その後、“hadbm status HADB_NAME”を実行して見ましょう。

上記で、１台づつマシンをリブートした時と比べ、いつまで経っても

状態がHAFaultTolerant,FaultTolerantに変わりません。


さらには、状態は“NonOperational”として表示されています。

この状態は、HADBとしてサービスを提供できていない状態を表しています。

appserver1 > /sun/SUNWappserver91/hadb/4/bin/ma-initd start appserver2 > /sun/SUNWappserver91/hadb/4/bin/ma-initd start appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** 2007-09-12 14:38:44.813 INFO hadbm status –nodes=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Database Status app-cluster1 NonOperational

HADBデバイスのクリーンアップ


上記のように、”NonOperational”の状態から”HAFaultTolerant,FaultTolerant”の

状態に戻すためには、下記の手順に従い修復を行います。



HADBの修復を行うために、“hadbm clear HADB_NAME”を実行して下さい。

“hadbm clear”を実行した後、“hadbm status HADB_NAME”を実行すると

HADBの状態が”NonOperational”から“FaultTolerant”に変わる事を確認できます。

appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm clear app-cluster1 Please enter the password for the database system user:[***********] Please retype the password for database system user:[***********] WARNING: The –dbpassword option is deprecated since it is insecure. Using this option can compromise your password. Please use either the command prompt or the –dbpasswordfile option. Please enter the password for the admin system user:[***********] 2007-09-12 14:42:32.552 INFO hadbm clear –fast=false –quiet=false –version=false –yes=false –force=false –echo=false –dbpassword=****** app-cluster1 This command will clear database app-cluster1. Type “yes” or “y” to confirm this operation, anything else to cancel: y 2007-09-12 14:42:38.555 INFO Node app-cluster1:0 is currently starting at config version 3, stopping node in order to stop database 2007-09-12 14:43:19.240 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.nilog.0 for node app-cluster1:0 2007-09-12 14:43:19.244 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.relalg.0 for node app-cluster1:0 2007-09-12 14:43:19.247 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.noman.0 for node app-cluster1:0 2007-09-12 14:43:19.249 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.data-0.0 for node app-cluster1:0 2007-09-12 14:44:16.059 INFO Starting node app-cluster1:0 at level firststart, config version 5, in order to start database 2007-09-12 14:44:16.255 INFO n:0 NSUP INF 2007-09-12 14:44:16.248 p:685 Legal realtime priorities are 0 (lowest) to 59 (highest) set it to:29 Database app-cluster1 successfully cleared. appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user: [***********] 2007-09-12 14:46:50.316 INFO hadbm status –nodes=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Database Status app-cluster1 FaultTolerant appserver1 >

上記でHADBでバイスのクリーンアップ行った後、HADBの状態が

“FaultTolerant”に変わりました。

そこで、HADBのサービスが上記で使用可能になったのではないかと

思われるかもしれません。


しかし、実際は上記を行っただけではApplication Serverから

HADBに対して接続できません。


理由は、“hadbm clear”を実行するとHADBのデバイスの初期化が

行われるため、Application Serverから接続する為に必要なテーブルや

スキーマ等、全て初期化されてしまうからです。


これを、clusqlコマンドを使用し確認しましょう。



hadbm clear実行直後のHADBのテーブル一覧

appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 system+adminadmin SQL: select * from sysroot.alltables ; schemaid tableid schemaname tablename 0 302 sysroot systbldsc 0 303 sysroot systbldef 0 304 sysroot systbt 0 308 sysroot syslnk 0 309 sysroot syshgh 0 310 sysroot sysacc 0 104 sysroot krnprocedures 0 105 sysroot krnnodes 0 109 sysroot krnnodegroupnodes 0 301 sysroot systbl 0 305 sysroot systbtatt 0 306 sysroot systbtdef 0 307 sysroot sysusr 0 311 sysroot sysnix 0 312 sysroot sysviw 0 313 sysroot sysviwcol 0 101 sysroot krntables 0 102 sysroot krnfragments 0 103 sysroot krnreplicas 0 106 sysroot krnredundancyunits 0 107 sysroot krnsites 0 108 sysroot krnnodegroups HADB-I-11930: Selected 22 row(s) SQL: quit ; appserver1 >

HADBが正常に動作している時のテーブル一覧

appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 system+adminadmin SQL: select * from sysroot.alltables ; schemaid tableid schemaname tablename 0 301 sysroot systbl 0 305 sysroot systbtatt 0 306 sysroot systbtdef 0 307 sysroot sysusr 0 311 sysroot sysnix 0 312 sysroot sysviw 0 313 sysroot sysviwcol 0 101 sysroot krntables 0 102 sysroot krnfragments 0 103 sysroot krnreplicasv 0 106 sysroot krnredundancyunits 0 107 sysroot krnsites 0 108 sysroot krnnodegroups 10078 10082 haschema sessionattribute 10078 10084 haschema singlesignon 10078 10085 haschema statefulsessionbean 0 302 sysroot systbldsc 0 303 sysroot systbldef 0 304 sysroot systbt 0 308 sysroot syslnk 0 309 sysroot syshgh 0 310 sysroot sysacc 0 104 sysroot krnprocedures 0 105 sysroot krnnodes 0 109 sysroot krnnodegroupnodes 10078 10079 haschema blobsessions 10078 10081 haschema sessionheader HADB-I-11930: Selected 27 row(s)

上記２つのテーブル一覧を御確認ください。

確認すると、「hadbm clear実行直後のHADBのテーブル一覧」には

下記の5つのテーブルが存在していない事が確認できます。



●　sessionattribute

●　singlesignon

●　statefulsessionbean

●　blobsessions

●　sessionheader




また、“hadbm clear HADB_NAME”を実行した直後、Application Serverから

HADBに接続する際に使用するユーザ(admin)でHADBに接続しようとした際、

ユーザが存在していないため、下記のエラーが出力されます。

appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 admin+adminadmin HADB-E-11601: Invalid user name or password

asadmin configure-ha-clusterの実行


そこで、HADBデバイスの初期化（”hadbm clear”）の後で、

HADBのテーブル、スキーマそしてユーザを再度構築する為に、

asadmin configure-ha-clusterコマンドを実行して下さい。

appserver1 > asadmin configure-ha-cluster –devicesize 1024 –hosts appserver01,appserver02 –user admin app-cluster1 HADBMGMT008:The database, app-cluster1, already exists Command configure-ha-cluster executed successfully. appserver1 >

上記、asadmin configure-ha-clusterコマンドを実行すると、

Appplication ServerからHADBのサービスを利用する為に必要な、

DBスキーマ、テーブル、ユーザ等が作成されます。

そこで、Application Serverから接続するユーザ(admin)で接続が可能となります。

clusqlでHADBに接続した後、作成されたテーブルの内容をそれぞれ確認してみましょう。

appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 admin+adminadmin SQL: SELECT schemaname, tablename, tableid FROM sysroot.alltables ; schemaname tablename tableid haschema sessionattribute 10082 haschema singlesignon 10084 haschema statefulsessionbean 10085 haschema blobsessions 10079 haschema sessionheader 10081 HADB-I-11930: Selected 5 row(s) SQL: show table sessionattribute ; table haschema.sessionattribute( lsn# special not null, rowid varchar(200) not null, sessattrdata blob not clustered, id varchar(100) not null, attributename varchar(100), appid varchar(100) not null, checksum# special not null, primary key(rowid,appid)); SQL: show table singlesignon; table haschema.singlesignon( lsn# special not null, ssoid varchar(100) not null primary key, lastaccess double integer, authtype varchar(100), username varchar(100), checksum# special not null); SQL: show table blobsessions ; table haschema.blobsessions( lsn# special not null, id varchar(100) not null, valid character(1) not null, maxinactive integer not null, lastaccess double integer, appid varchar(100) not null, sessdata blob not clustered, username varchar(100), ssoid varchar(100), checksum# special not null, primary key(id,appid)); SQL: show table sessionheader ; table haschema.sessionheader( lsn# special not null, id varchar(100) not null, valid character(1) not null, maxinactive integer not null, lastaccess double integer, appid varchar(100) not null, username varchar(100), ssoid varchar(100), checksum# special not null, primary key(id,appid)); SQL: show table statefulsessionbean ; table haschema.statefulsessionbean( lsn# special not null, id varchar(100) not null primary key, clusterid varchar(100), lastaccess double integer, beandata blob not clustered, containerid varchar(100), checksum# special not null); SQL: quit ;

備考：


clusqlで接続する際に、(system , admin)というユーザで接続しています。

systemはHADBのシステム管理用に使用するユーザで、adminユーザは

Application Serverから接続する際に使用するユーザ名です。



Application Serverから接続する際に使用するユーザ名、パスワード、

接続するHADBのノード名、ノードのポート番号はApplication Serverの

管理画面よりHADBのコネクションプールの設定情報(下記御参照)より確認

する事もできます。




以上で、HADBの両ノード障害が発生した場合の復旧方法について説明しましたが、

如何でしょうか。



実は、私もHADBを触り始めた当初、両ノードの同時リブートを行ってはいけない事を

知らず、やってしまい驚いてしまった事があります。


仮に同様の事をしてしまった場合には、上記を試してください。

そして、それでも駄目な場合は、弊社サポートセンターに御問い合わせください。

2007年9月12日 at 6:49 午前

HADBノードの再起動と状態確認方法

さて本日は、HADBノードの再起動と状態確認方法について説明します。



１. HADBを構成するノードの再起動方法について



前回の説明で、HADBを構成するノード(appserver01,appserver02)を

再起動する際は、両ノード同時にリブートする事は避けて頂きたいと説明しました。

そこで、今回まずは片ノードづつリブートした際における、HADBの状態変化について

説明したいと思います。

片ノードをリブートした際にHADBの状態としてどのように変化するか

下記より確認してみましょう。



正常時のステータス

appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:[***********] Database Status app-cluster1 FaultTolerant

正常時に“hadbm status”を実行するとDatabaseのステータスとして、

“HAFaultTolerant”（スペアノード付き）もしくは”FaultTolerant”

（スペアノード無し）が表示されます。


この状態で、片ノードに何らかの障害が発生したとします。

するとHADBは単一ノードでしかサービスを提供していませんので、

ステータスは下記のように”Operational”にかわります。


片ノードで起動している時のステータス

appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 Operational

実際に、ステータスが変更するかを実際に確認してみましょう。


手順；

1. 初めに片ノード(appserver02)をリブートします。

2. リブートが完了した後、appserver02にログインします。

3. HADBの管理エージェントプロセス(ma)を起動します。

4. 状態の変更を確認します。

appserver2 > sync appserver2 > reboot

上記の状態で、起動しているノード(appserver01)で

HADBのステータスを確認してみて下さい。

すると下記のようにステータスが変更されている事を確認できます。

appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 Operational

次に、システムのリブートが完了した後、システムにログインし、

HADBの管理エージェントプロセス(ma)を起動して下さい。

> ssh -l root 192.168.0.2 パスワード: [********] Last login: Wed Sep 12 11:17:51 2007 from 192.168.0.10 Sun Microsystems Inc. SunOS 5.10 Generic January 2005 You have new mail. # tcsh appserver2 > /sun/SUNWappserver91/hadb/4/bin/ma-initd start appserver2 > Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting Logging to /sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-12 14:03:43.938 INFO Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting 2007-09-12 14:03:43.956 INFO Using property: ma.server.type=jmxmp 2007-09-12 14:03:43.960 INFO Using property: ma.server.mainternal.interfaces=192.168.0.2 2007-09-12 14:03:43.962 INFO Using property: ma.server.dbhistorypath=/sun/SUNWappserver91/hadb/4.4.3-6/history 2007-09-12 14:03:43.966 INFO Using property: ma.server.dbconfigpath=/sun/SUNWappserver91/config/hadb 2007-09-12 14:03:43.968 INFO Using property: console.loglevel=INFO 2007-09-12 14:03:43.969 INFO Using property: logfile.name=/sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-12 14:03:43.971 INFO Using property: ma.server.jmxmp.port=1862 2007-09-12 14:03:43.972 INFO Using property: logfile.loglevel=INFO 2007-09-12 14:03:43.974 INFO Using property: ma.server.dbdevicepath=/sun/SUNWappserver91/hadb/4.4.3-6/device 2007-09-12 14:03:43.975 INFO Using property: repository.dr.path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-12 14:03:45.108 INFO Listening for client connections on port 1862 2007-09-12 14:03:45.398 INFO Repository REP:-54e808d5_114ee5e4be0_-8000: Multicast address=228.8.8.8, Port=1862, Bind address=192.168.0.2, Path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-12 14:05:14.959 INFO Starting node app-cluster1:1 at level auto, config version 3 2007-09-12 14:05:15.520 INFO n:1 NSUP INF 2007-09-12 14:05:15.518 p:606 Legal realtime priorities are 0 (lowest) to 59 (highest) set it to:29

HADBの管理エージェントプロセスが起動すると、上記のように

メッセージが表示されます。ここで、注意して頂きたいのは

上記のメッセージが表示された直後はまだ、HADBとして

正常な状態には戻っていないという事です。

上記メッセージが出力された直後にステータスを確認してください。

すると、まだ”Operational”の状態になっている事を確認できます。

理由は、前回「High Availability Session Store(HADB)の概要」

でも説明致しましたが、appserver01のテーブルの内容と同期を取る

作業等を行っているためです。

そこで、作業完了までしばらく待った後、再度コマンドを実行して下さい。

すると、ステータスが“HAFaultTolerant”/”FaultTolerant”に変わる事が

確認できるかと思います。

appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 Operational …..しばらく時間を経過した後（テーブルの同期が完了した後） appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 FaultTolerant

このように、HADBノードを再起動する際は、片ノードづつ実行して頂き、

片ノードが完全に立ち上がって、HADBのステータスが

“HAFaultTolerant”/”FaultTolerant”の状態に戻った事を確認した後

もう一台のHADBノードを再起動するようにして下さい。

2007年9月12日 at 4:30 午前