JPH11167510A - レプリケーション方法、レプリケーションツール、および、レプリケーションサーバ - Google Patents
レプリケーション方法、レプリケーションツール、および、レプリケーションサーバInfo
- Publication number
- JPH11167510A JPH11167510A JP9334333A JP33433397A JPH11167510A JP H11167510 A JPH11167510 A JP H11167510A JP 9334333 A JP9334333 A JP 9334333A JP 33433397 A JP33433397 A JP 33433397A JP H11167510 A JPH11167510 A JP H11167510A
- Authority
- JP
- Japan
- Prior art keywords
- replication
- directory server
- directory
- request
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4523—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using lightweight directory access protocol [LDAP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4517—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using open systems interconnection [OSI] directories, e.g. X.500
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
- Y10S707/99945—Object-oriented database structure processing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99955—Archiving or backup
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】ディレクトリデータのレプリケーションを行う
ディレクトリシステムにおいて、コンシューマ側のディ
レクトリサーバが、任意の時点で取ってあるバックアッ
プを使用して、レプリカデータの再構築を行うことを可
能とする。 【解決手段】コンシューマ側のディレクトリサーバが管
理するレプリカデータ９ｃ中に、レプリケーションサー
ビス１０′が行ったレプリケーションによって最後に変
更されたエントリを特定するための情報１０ｃを記録す
るようにする。そこで、レプリケーションサービス１
０′は、この情報１０ｃに基づいて、次にレプリケーシ
ョンを行うべきエントリを知ることができるので、サプ
ライヤ側のディレクトリサーバが管理するマスタデータ
９ｓと、レプリカデータ９ｃとの差分を認識することが
でき、従って、バックアップを使用したレプリカデータ
９ｃの再構築時に、この差分についてのみレプリケーシ
ョンを行うことができる。
ディレクトリシステムにおいて、コンシューマ側のディ
レクトリサーバが、任意の時点で取ってあるバックアッ
プを使用して、レプリカデータの再構築を行うことを可
能とする。 【解決手段】コンシューマ側のディレクトリサーバが管
理するレプリカデータ９ｃ中に、レプリケーションサー
ビス１０′が行ったレプリケーションによって最後に変
更されたエントリを特定するための情報１０ｃを記録す
るようにする。そこで、レプリケーションサービス１
０′は、この情報１０ｃに基づいて、次にレプリケーシ
ョンを行うべきエントリを知ることができるので、サプ
ライヤ側のディレクトリサーバが管理するマスタデータ
９ｓと、レプリカデータ９ｃとの差分を認識することが
でき、従って、バックアップを使用したレプリカデータ
９ｃの再構築時に、この差分についてのみレプリケーシ
ョンを行うことができる。
Description
【０００１】
【発明の属する技術分野】本発明は、ディレクトリデー
タの複製管理において、運用性を向上させることを可能
とする技術に関する。
タの複製管理において、運用性を向上させることを可能
とする技術に関する。
【０００２】
【従来の技術】今日の企業内情報システムのように、メ
ールシステムやファイル共有システム等の独立した複数
のシステムが混在したＯＡ環境においては、ユーザは、
複数のメールアドレス，ログイン名，パスワード等のユ
ーザ識別情報を持つようになっている。そのため、管理
者は、ユーザの増減に際し、各システムで使用されるユ
ーザ識別情報を、別々に追加／削除する必要があり、管
理負担が大きい。
ールシステムやファイル共有システム等の独立した複数
のシステムが混在したＯＡ環境においては、ユーザは、
複数のメールアドレス，ログイン名，パスワード等のユ
ーザ識別情報を持つようになっている。そのため、管理
者は、ユーザの増減に際し、各システムで使用されるユ
ーザ識別情報を、別々に追加／削除する必要があり、管
理負担が大きい。
【０００３】そこで、複数の異種システムで用いられる
ユーザ識別情報、並びに、機器および資源に関する情報
を一元的に管理するディレクトリサービスを行うことを
可能としたディレクトリシステムが、管理者の管理負担
を軽減することができるとして期待されている。ディレ
クトリシステムを適用することで、ユーザが所望する情
報を検索して提供することが可能となる。
ユーザ識別情報、並びに、機器および資源に関する情報
を一元的に管理するディレクトリサービスを行うことを
可能としたディレクトリシステムが、管理者の管理負担
を軽減することができるとして期待されている。ディレ
クトリシステムを適用することで、ユーザが所望する情
報を検索して提供することが可能となる。
【０００４】上述した企業内情報システムは、これまで
は、比較的小規模な部署単位で構築されていた。しか
し、部署ごとに異なる企業内情報システムでは、部署間
の人の移動に伴う手続きやメールの交換を円滑に行うこ
とはできないことから、全社的に統一された大規模で広
域な企業内情報システムの構築が、急速に進められてい
る。
は、比較的小規模な部署単位で構築されていた。しか
し、部署ごとに異なる企業内情報システムでは、部署間
の人の移動に伴う手続きやメールの交換を円滑に行うこ
とはできないことから、全社的に統一された大規模で広
域な企業内情報システムの構築が、急速に進められてい
る。
【０００５】このような大規模で広域な企業内情報シス
テムの発展に伴い、ディレクトリシステムは、システム
規模に関わらず、アクセス性能を維持することが望まれ
ている。また、信頼性の面からも、単一箇所の障害によ
るサービスの中断を防ぐために、サービスの多重化が必
要である。
テムの発展に伴い、ディレクトリシステムは、システム
規模に関わらず、アクセス性能を維持することが望まれ
ている。また、信頼性の面からも、単一箇所の障害によ
るサービスの中断を防ぐために、サービスの多重化が必
要である。
【０００６】こうした要求に答えるためには、ディレク
トリデータの複製を複数箇所に配置することが有効であ
る。以降、ディレクトリデータの複製を「レプリカデー
タ」と呼び、ディレクトリデータの複製を行うことを
「レプリケーション」と呼ぶ。
トリデータの複製を複数箇所に配置することが有効であ
る。以降、ディレクトリデータの複製を「レプリカデー
タ」と呼び、ディレクトリデータの複製を行うことを
「レプリケーション」と呼ぶ。
【０００７】ディレクトリサービスにおけるレプリケー
ションに関する標準として、ＣＣＩＴＴの勧告である
Ｘ.５００が挙げられる。Ｘ.５００は、ディレクトリサ
ービスを、クライアント−サーバ型の分散システムアー
キテクチャとして規定し、クライアントとサーバとの間
のディレクトリアクセスプロトコルとして、ＤＡＰ（Di
rectory Access Protocol）を規定している。
ションに関する標準として、ＣＣＩＴＴの勧告である
Ｘ.５００が挙げられる。Ｘ.５００は、ディレクトリサ
ービスを、クライアント−サーバ型の分散システムアー
キテクチャとして規定し、クライアントとサーバとの間
のディレクトリアクセスプロトコルとして、ＤＡＰ（Di
rectory Access Protocol）を規定している。
【０００８】Ｘ.５００準拠のディレクトリサービス
は、木構造（ディレクトリツリー）として階層管理され
たデータモデルを有する。木の枝葉に相当する箇所に
は、ディレクトリエントリが配置される。各エントリ
は、同一の親エントリを有するエントリ間で一意である
相対識別名（ＲＤＮ：Relative Distinguished Name）
と、木構造の根（ルート）からの経路を示すＲＤＮの列
である識別名（ＤＮ：Distinguished Name）とによっ
て、一意に識別される。また、各エントリは、ユーザの
メールアドレスに加えて、姓名，電話番号，ＦＡＸ番
号，写真等の様々な情報を、属性として記憶可能であ
る。ここで、エントリは、１つ以上のオブジェクトクラ
スに属する。オブジェクトクラスとは、あるクラスに存
在しなければならない必須の属性、および、存在しても
よい任意の属性の集合を定義するものである。
は、木構造（ディレクトリツリー）として階層管理され
たデータモデルを有する。木の枝葉に相当する箇所に
は、ディレクトリエントリが配置される。各エントリ
は、同一の親エントリを有するエントリ間で一意である
相対識別名（ＲＤＮ：Relative Distinguished Name）
と、木構造の根（ルート）からの経路を示すＲＤＮの列
である識別名（ＤＮ：Distinguished Name）とによっ
て、一意に識別される。また、各エントリは、ユーザの
メールアドレスに加えて、姓名，電話番号，ＦＡＸ番
号，写真等の様々な情報を、属性として記憶可能であ
る。ここで、エントリは、１つ以上のオブジェクトクラ
スに属する。オブジェクトクラスとは、あるクラスに存
在しなければならない必須の属性、および、存在しても
よい任意の属性の集合を定義するものである。
【０００９】レプリケーションについては、複製元のデ
ィレクトリデータ（マスタデータ）を管理し、複製する
ディレクトリデータを提供するディレクトリサーバを、
サプライヤ側と定義し、レプリカデータを管理し、複製
するディレクトリデータを受け取るディレクトリサーバ
を、コンシューマ側と定義しており、サプライヤ側のデ
ィレクトリサーバとコンシューマ側のディレクトリサー
バとの間のレプリケーションプロトコルとして、ＤＩＳ
Ｐ（Directory Information Shadowing Protocol）を規
定している。
ィレクトリデータ（マスタデータ）を管理し、複製する
ディレクトリデータを提供するディレクトリサーバを、
サプライヤ側と定義し、レプリカデータを管理し、複製
するディレクトリデータを受け取るディレクトリサーバ
を、コンシューマ側と定義しており、サプライヤ側のデ
ィレクトリサーバとコンシューマ側のディレクトリサー
バとの間のレプリケーションプロトコルとして、ＤＩＳ
Ｐ（Directory Information Shadowing Protocol）を規
定している。
【００１０】また、オペレーションモデルとしては、サ
プライヤ側のディレクトリサーバからレプリケーション
を起動する「push」モデルと、コンシューマ側のディレ
クトリサーバがデータを要求してレプリケーションを起
動する「pull」モデルとがある。
プライヤ側のディレクトリサーバからレプリケーション
を起動する「push」モデルと、コンシューマ側のディレ
クトリサーバがデータを要求してレプリケーションを起
動する「pull」モデルとがある。
【００１１】一方、ＩＥＴＦ（Internet Engineering T
ask Force）は、ＴＣＰ／ＩＰスタック上で動作するＬ
ＤＡＰ（Light Weight Directory Access Protocol）
（ＲＦＣ１７７７）を、ディレクトリアクセスの標準プ
ロトコルとした。
ask Force）は、ＴＣＰ／ＩＰスタック上で動作するＬ
ＤＡＰ（Light Weight Directory Access Protocol）
（ＲＦＣ１７７７）を、ディレクトリアクセスの標準プ
ロトコルとした。
【００１２】ＬＤＡＰは、ＯＳＩスタック上で動作する
ＤＡＰに比べて軽量であることが大きな利点である。Ｉ
ＥＴＦでは、レプリケーションの標準プロトコルは決定
されていない。しかし、軽量であり、既存プロトコルを
再利用でき、ＡＰＩがシンプルで開発が簡単であるなど
の利点があり、ディレクトリサーバ間のレプリケーショ
ンにも、ＬＤＡＰが有効である。実際に、ＬＤＡＰをレ
プリケーションプロトコルとして用いたサーバ製品が市
場に出荷されている。
ＤＡＰに比べて軽量であることが大きな利点である。Ｉ
ＥＴＦでは、レプリケーションの標準プロトコルは決定
されていない。しかし、軽量であり、既存プロトコルを
再利用でき、ＡＰＩがシンプルで開発が簡単であるなど
の利点があり、ディレクトリサーバ間のレプリケーショ
ンにも、ＬＤＡＰが有効である。実際に、ＬＤＡＰをレ
プリケーションプロトコルとして用いたサーバ製品が市
場に出荷されている。
【００１３】以下、ＬＤＡＰをレプリケーションプロト
コルとして用いた従来のレプリケーションについて説明
する。
コルとして用いた従来のレプリケーションについて説明
する。
【００１４】なお、以下の説明では、マスタデータを管
理するディレクトリサーバを「サプライヤ・ディレクト
リサーバ」と呼び、レプリカデータを管理するディレク
トリサーバを「コンシューマ・ディレクトリサーバ」と
呼ぶ。そして、サプライヤ・ディレクトリサーバで行わ
れた変更操作を、コンシューマ・ディレクトリサーバへ
と伝播するサーバを「レプリケーションサーバ」と呼
ぶ。
理するディレクトリサーバを「サプライヤ・ディレクト
リサーバ」と呼び、レプリカデータを管理するディレク
トリサーバを「コンシューマ・ディレクトリサーバ」と
呼ぶ。そして、サプライヤ・ディレクトリサーバで行わ
れた変更操作を、コンシューマ・ディレクトリサーバへ
と伝播するサーバを「レプリケーションサーバ」と呼
ぶ。
【００１５】本従来例では、レプリケーションサーバを
独立した１つのサーバとして説明するが、サプライヤ・
ディレクトリサーバまたはコンシューマ・ディレクトリ
サーバの１機能として実現するようにしてもよい。
独立した１つのサーバとして説明するが、サプライヤ・
ディレクトリサーバまたはコンシューマ・ディレクトリ
サーバの１機能として実現するようにしてもよい。
【００１６】ＬＤＡＰにおけるディレクトリアクセス要
求には、ディレクトリデータに変更を加えない参照系デ
ィレクトリアクセス要求と、変更を加える更新系ディレ
クトリアクセス要求とがある。参照系ディレクトリアク
セス要求は、検索要求のみであり、更新系ディレクトリ
アクセス要求には、エントリ追加要求，エントリ削除要
求，エントリ属性変更要求，ＲＤＮ変更要求がある。
求には、ディレクトリデータに変更を加えない参照系デ
ィレクトリアクセス要求と、変更を加える更新系ディレ
クトリアクセス要求とがある。参照系ディレクトリアク
セス要求は、検索要求のみであり、更新系ディレクトリ
アクセス要求には、エントリ追加要求，エントリ削除要
求，エントリ属性変更要求，ＲＤＮ変更要求がある。
【００１７】サプライヤ・ディレクトリサーバは、更新
系ディレクトリアクセス要求に従った変更操作に成功す
ると、この変更操作の履歴情報にタイムスタンプを付加
し、レプリケーションレコードとして、変更ログファイ
ルに格納する。このタイムスタンプは、レプリケーショ
ンレコードが格納された順序、すなわち、対応する更新
系ディレクトリアクセス要求に従った変更操作が行われ
た順序を識別するためのものである。
系ディレクトリアクセス要求に従った変更操作に成功す
ると、この変更操作の履歴情報にタイムスタンプを付加
し、レプリケーションレコードとして、変更ログファイ
ルに格納する。このタイムスタンプは、レプリケーショ
ンレコードが格納された順序、すなわち、対応する更新
系ディレクトリアクセス要求に従った変更操作が行われ
た順序を識別するためのものである。
【００１８】従来のレプリケーションサーバは、レプリ
ケーションを行う際には、まず、タイムスタンプが非減
少となる順序で、レプリケーションレコードを変更ログ
ファイルから取得し、取得したレプリケーションレコー
ドに基づいて、更新系ディレクトリアクセス要求（ＬＤ
ＡＰアクセス要求）を作成し、作成したＬＤＡＰアクセ
ス要求をコンシューマ・ディレクトリサーバへ発行する
ようになっている。
ケーションを行う際には、まず、タイムスタンプが非減
少となる順序で、レプリケーションレコードを変更ログ
ファイルから取得し、取得したレプリケーションレコー
ドに基づいて、更新系ディレクトリアクセス要求（ＬＤ
ＡＰアクセス要求）を作成し、作成したＬＤＡＰアクセ
ス要求をコンシューマ・ディレクトリサーバへ発行する
ようになっている。
【００１９】これにより、コンシューマ・ディレクトリ
サーバは、サプライヤ・ディレクトリサーバで変更操作
が行われる元となった更新系ディレクトリアクセス要求
と同一の更新系ディレクトリアクセス要求に従った変更
操作を、サプライヤ・ディレクトリサーバが変更操作を
行った順序と同一の順序で行うことができる。
サーバは、サプライヤ・ディレクトリサーバで変更操作
が行われる元となった更新系ディレクトリアクセス要求
と同一の更新系ディレクトリアクセス要求に従った変更
操作を、サプライヤ・ディレクトリサーバが変更操作を
行った順序と同一の順序で行うことができる。
【００２０】ただし、レプリケーションサーバは、上述
したように、変更操作を伝播するのみであるので、コン
シューマ・ディレクトリサーバの管理者は、レプリケー
ションの開始に先立って、マスタデータの複製を、レプ
リカデータとして用意しなければならない。
したように、変更操作を伝播するのみであるので、コン
シューマ・ディレクトリサーバの管理者は、レプリケー
ションの開始に先立って、マスタデータの複製を、レプ
リカデータとして用意しなければならない。
【００２１】レプリケーションのオペーレーションは、
レプリケーションサーバが、サプライヤ・ディレクトリ
サーバのレプリケーションレコード出力に応じてレプリ
ケーションを開始する場合は、「push」モデルとなり、
コンシューマ・ディレクトリサーバの状態に応じてレプ
リケーションを開始する場合は、「pull」モデルとな
る。
レプリケーションサーバが、サプライヤ・ディレクトリ
サーバのレプリケーションレコード出力に応じてレプリ
ケーションを開始する場合は、「push」モデルとなり、
コンシューマ・ディレクトリサーバの状態に応じてレプ
リケーションを開始する場合は、「pull」モデルとな
る。
【００２２】本明細書では、「push」モデルのレプリケ
ーションを前提とする。
ーションを前提とする。
【００２３】なお、タイムスタンプは、サプライヤ・デ
ィレクトリサーバが更新系ディレクトリアクセス要求を
受信した時点，変更操作を行った時点，レプリケーショ
ンレコードを変更ログファイルに格納した時点のうちの
いずれかの時点に基づく数値であり、変更操作が行われ
た順序で昇順となっていなければならない。
ィレクトリサーバが更新系ディレクトリアクセス要求を
受信した時点，変更操作を行った時点，レプリケーショ
ンレコードを変更ログファイルに格納した時点のうちの
いずれかの時点に基づく数値であり、変更操作が行われ
た順序で昇順となっていなければならない。
【００２４】図３に、従来のレプリケーションサーバが
行うレプリケーションのシーケンスを示す。
行うレプリケーションのシーケンスを示す。
【００２５】図３に示すように、従来のレプリケーショ
ンサーバは、まず、変更ログファイルからレプリケーシ
ョンレコード（３１）を読み出す。
ンサーバは、まず、変更ログファイルからレプリケーシ
ョンレコード（３１）を読み出す。
【００２６】続いて、レプリケーションサーバは、コン
シューマ・ディレクトリサーバへ、バインド（bind）要
求（３２）を発行し、それに対する応答（３３）を受け
取ることで、コンシューマ・ディレクトリサーバとの間
のコネクションを確立する。
シューマ・ディレクトリサーバへ、バインド（bind）要
求（３２）を発行し、それに対する応答（３３）を受け
取ることで、コンシューマ・ディレクトリサーバとの間
のコネクションを確立する。
【００２７】続いて、レプリケーションサーバは、読み
出したレプリケーションレコード（３１）に基づいてＬ
ＤＡＰアクセス要求（３４）を作成する。以下、これら
のＬＤＡＰアクセス要求を、「レプリケーション要求」
と呼ぶ。
出したレプリケーションレコード（３１）に基づいてＬ
ＤＡＰアクセス要求（３４）を作成する。以下、これら
のＬＤＡＰアクセス要求を、「レプリケーション要求」
と呼ぶ。
【００２８】そして、レプリケーションサーバは、コン
シューマ・ディレクトリサーバへ、作成したレプリケー
ション要求（３４）を発行し、それに対する応答（３
５）を受け取る。この応答（３５）に含まれているリタ
ーンコードが、レプリケーションが成功したことを示す
「LDAP_SUCCESS」であった場合は、レプリケーション状
態の記録（３７）を行う。ここでは、成功したレプリケ
ーションレコードのタイムスタンプを、レプリケーショ
ン状態ファイルに格納する。
シューマ・ディレクトリサーバへ、作成したレプリケー
ション要求（３４）を発行し、それに対する応答（３
５）を受け取る。この応答（３５）に含まれているリタ
ーンコードが、レプリケーションが成功したことを示す
「LDAP_SUCCESS」であった場合は、レプリケーション状
態の記録（３７）を行う。ここでは、成功したレプリケ
ーションレコードのタイムスタンプを、レプリケーショ
ン状態ファイルに格納する。
【００２９】レプリケーションサーバは、常に、レプリ
ケーション状態ファイルに格納したタイムスタンプ以降
のタイムスタンプを有するレプリケーションレコードの
うちの、最も古いタイムスタンプを有するレプリケーシ
ョンレコードを読み出すことにより、サプライヤ・ディ
レクトリサーバが変更操作を行った順序と同一の順序
で、レプリケーションを行うことができる。
ケーション状態ファイルに格納したタイムスタンプ以降
のタイムスタンプを有するレプリケーションレコードの
うちの、最も古いタイムスタンプを有するレプリケーシ
ョンレコードを読み出すことにより、サプライヤ・ディ
レクトリサーバが変更操作を行った順序と同一の順序
で、レプリケーションを行うことができる。
【００３０】その後、レプリケーションサーバは、アン
バインド（unbind）要求（３８）を発行し、コンシュー
マ・ディレクトリサーバとの間のコネクションを切断す
る。
バインド（unbind）要求（３８）を発行し、コンシュー
マ・ディレクトリサーバとの間のコネクションを切断す
る。
【００３１】以上のシーケンスにより、サプライヤ・デ
ィレクトリサーバで実行された変更操作と同様の変更操
作を、同様な順序で、コンシューマ・ディレクトリサー
バが実行するようにすることができ、サプライヤ・ディ
レクトリサーバが管理するマスタデータと、コンシュー
マ・ディレクトリサーバが管理するレプリカデータとを
等しくすることが可能となる。
ィレクトリサーバで実行された変更操作と同様の変更操
作を、同様な順序で、コンシューマ・ディレクトリサー
バが実行するようにすることができ、サプライヤ・ディ
レクトリサーバが管理するマスタデータと、コンシュー
マ・ディレクトリサーバが管理するレプリカデータとを
等しくすることが可能となる。
【００３２】上述したようなシーケンスを実現するため
のサーバプログラムの例として、ミシガン大学が開発し
たレプリケーションサービスプログラム「slurpd」が、
インターネット上で無償提供されている。
のサーバプログラムの例として、ミシガン大学が開発し
たレプリケーションサービスプログラム「slurpd」が、
インターネット上で無償提供されている。
【００３３】
【発明が解決しようとする課題】上述した従来技術で
は、コンシューマ・ディレクトリサーバが管理するレプ
リカデータが、磁気ディスクの物理的損傷等によリ失わ
れてしまった場合に、一般に地理的に離れた場所にある
サプライヤ・ディレクトリサーバが管理するマスタデー
タのコピーを取得して、レプリカデータを再構築する必
要があるので、管理者の手間がかかると共に、復旧まで
の時間を要する。
は、コンシューマ・ディレクトリサーバが管理するレプ
リカデータが、磁気ディスクの物理的損傷等によリ失わ
れてしまった場合に、一般に地理的に離れた場所にある
サプライヤ・ディレクトリサーバが管理するマスタデー
タのコピーを取得して、レプリカデータを再構築する必
要があるので、管理者の手間がかかると共に、復旧まで
の時間を要する。
【００３４】ここで、レプリカデータのバックアップを
取っておいたとしても、そのバックアップデータを使用
してレプリカデータを再構築することはできない。それ
は、バックアップデータが、どのレプリケーションレコ
ードについてまで反映済みであるのかが不明であるの
で、レプリケーションサーバは、バックアップデータに
対するレプリケーションを再開することができないから
である。このとき、レプリケーションサーバにおいて、
レプリケーション状態ファイルに格納されているタイム
スタンプは、障害発生時点での値であるので、バックア
ップデータには対応していない。
取っておいたとしても、そのバックアップデータを使用
してレプリカデータを再構築することはできない。それ
は、バックアップデータが、どのレプリケーションレコ
ードについてまで反映済みであるのかが不明であるの
で、レプリケーションサーバは、バックアップデータに
対するレプリケーションを再開することができないから
である。このとき、レプリケーションサーバにおいて、
レプリケーション状態ファイルに格納されているタイム
スタンプは、障害発生時点での値であるので、バックア
ップデータには対応していない。
【００３５】このように、従来技術は、レプリケーショ
ンサーバが、マスタデータとバックアップデータとの差
分を認識することができないので、レプリカデータの再
構築時に、バックアップデータに対するレプリケーショ
ンを行うことができないという問題点がある。
ンサーバが、マスタデータとバックアップデータとの差
分を認識することができないので、レプリカデータの再
構築時に、バックアップデータに対するレプリケーショ
ンを行うことができないという問題点がある。
【００３６】また、従来技術では、レプリケーションサ
ーバが、レプリケーション要求を発行してから、それに
対する応答を受信するまでの間に、電源断等の障害によ
りレプリケーションが異常終了してしまい、コンシュー
マ・ディレクトリサーバから応答を受信できなかった場
合には、最後にレプリケーションに成功したレプリケー
ションレコードのタイムスタンプが記録されないことと
なる。
ーバが、レプリケーション要求を発行してから、それに
対する応答を受信するまでの間に、電源断等の障害によ
りレプリケーションが異常終了してしまい、コンシュー
マ・ディレクトリサーバから応答を受信できなかった場
合には、最後にレプリケーションに成功したレプリケー
ションレコードのタイムスタンプが記録されないことと
なる。
【００３７】このため、レプリケーションサーバは、障
害の復旧後、レプリケーションを再開すると、前回のセ
ッションで行われたレプリケーションで発行したレプリ
ケーション要求と同一のレプリケーション要求を再度発
行してしまうこととなるので、前回のセッションで行わ
れたレプリケーションで発行したレプリケーション要求
に従ったコンシューマ・ディレクトリサーバの変更操作
が成功していた場合には、同一のレプリケーション要求
が重複してしまい、このレプリケーション要求に従った
変更操作は失敗する。このような場合、レプリケーショ
ンサーバが異常終了してしまい、管理者は、手動で復旧
作業を行う必要があるという問題点がある。
害の復旧後、レプリケーションを再開すると、前回のセ
ッションで行われたレプリケーションで発行したレプリ
ケーション要求と同一のレプリケーション要求を再度発
行してしまうこととなるので、前回のセッションで行わ
れたレプリケーションで発行したレプリケーション要求
に従ったコンシューマ・ディレクトリサーバの変更操作
が成功していた場合には、同一のレプリケーション要求
が重複してしまい、このレプリケーション要求に従った
変更操作は失敗する。このような場合、レプリケーショ
ンサーバが異常終了してしまい、管理者は、手動で復旧
作業を行う必要があるという問題点がある。
【００３８】そこで、本発明の第１の目的は、レプリカ
データが失われた場合でも、そのレプリカデータのバッ
クアップに対するレプリケーションを再開することを可
能にし、運用性を向上させたレプリケーションを実現す
ることにある。
データが失われた場合でも、そのレプリカデータのバッ
クアップに対するレプリケーションを再開することを可
能にし、運用性を向上させたレプリケーションを実現す
ることにある。
【００３９】また、本発明の第２の目的は、任意の時点
で予期できない障害によりレプリケーションを中断した
場合でも、障害の復旧後、正常にレプリケーションを再
開することを可能にし、運用性を向上させたレプリケー
ションを実現することにある。
で予期できない障害によりレプリケーションを中断した
場合でも、障害の復旧後、正常にレプリケーションを再
開することを可能にし、運用性を向上させたレプリケー
ションを実現することにある。
【００４０】
【課題を解決するための手段】上記第１の目的を達成す
るために、本発明は、第１の態様として、ディレクトリ
データのマスタデータを管理し、上記マスタデータを変
更した際の操作の履歴情報を記憶保持する第１のディレ
クトリサーバと、上記マスタデータの複製であるレプリ
カデータを管理する１つ以上の第２のディレクトリサー
バとが、少なくともネットワークで接続されたディレク
トリシステムにおいて、上記第１のディレクトリサー
バ、および、上記ネットワークに接続される別のサーバ
のうちのいずれか一方のサーバ（以下、「レプリケーシ
ョンサーバ」と称す。）にインストールされ、上記マス
タデータと上記レプリカデータとを同一の内容に保つレ
プリケーションツールであって、上記第１のディレクト
リサーバが記憶保持している履歴情報のうちから、処理
対象となる履歴情報を取得する履歴情報取得手段と、上
記履歴情報取得手段が取得した履歴情報に対応する操作
と同一の操作を上記レプリカデータについて行う旨を要
求するディレクトリアクセス要求（以下、「レプリケー
ション要求」と称す。）を、上記第２のディレクトリサ
ーバへ発行するレプリケーション要求発行手段と、上記
レプリケーション要求発行手段が発行したレプリケーシ
ョン要求に従って行われた上記第２のディレクトリサー
バの操作が成功した場合に、該操作に対応する履歴情報
を特定するための識別情報を、該第２のディレクトリサ
ーバが管理するレプリカデータ中に記録する識別情報記
録手段とを有するよう、上記レプリケーションサーバを
機能させ、上記履歴情報取得手段は、上記第２のディレ
クトリサーバが管理するレプリカデータ中に記録されて
いる識別情報を参照して、取得すべき履歴情報を決定す
ることを特徴としたレプリケーションツールを提供して
いる。
るために、本発明は、第１の態様として、ディレクトリ
データのマスタデータを管理し、上記マスタデータを変
更した際の操作の履歴情報を記憶保持する第１のディレ
クトリサーバと、上記マスタデータの複製であるレプリ
カデータを管理する１つ以上の第２のディレクトリサー
バとが、少なくともネットワークで接続されたディレク
トリシステムにおいて、上記第１のディレクトリサー
バ、および、上記ネットワークに接続される別のサーバ
のうちのいずれか一方のサーバ（以下、「レプリケーシ
ョンサーバ」と称す。）にインストールされ、上記マス
タデータと上記レプリカデータとを同一の内容に保つレ
プリケーションツールであって、上記第１のディレクト
リサーバが記憶保持している履歴情報のうちから、処理
対象となる履歴情報を取得する履歴情報取得手段と、上
記履歴情報取得手段が取得した履歴情報に対応する操作
と同一の操作を上記レプリカデータについて行う旨を要
求するディレクトリアクセス要求（以下、「レプリケー
ション要求」と称す。）を、上記第２のディレクトリサ
ーバへ発行するレプリケーション要求発行手段と、上記
レプリケーション要求発行手段が発行したレプリケーシ
ョン要求に従って行われた上記第２のディレクトリサー
バの操作が成功した場合に、該操作に対応する履歴情報
を特定するための識別情報を、該第２のディレクトリサ
ーバが管理するレプリカデータ中に記録する識別情報記
録手段とを有するよう、上記レプリケーションサーバを
機能させ、上記履歴情報取得手段は、上記第２のディレ
クトリサーバが管理するレプリカデータ中に記録されて
いる識別情報を参照して、取得すべき履歴情報を決定す
ることを特徴としたレプリケーションツールを提供して
いる。
【００４１】第１の態様によれば、第２のディレクトリ
サーバが管理するレプリカデータ中に記録されている識
別情報は、レプリケーション要求に従って行われた該第
２のディレクトリサーバの操作によって最後に変更され
たエントリ（レプリケーションによって最後に変更され
たエントリ）を特定することとなるので、レプリケーシ
ョンサーバは、この識別情報を参照することで、次にレ
プリケーションを行うべきエントリを知ることができ、
従って、第１のディレクトリサーバが管理するマスタデ
ータと、第２のディレクトリサーバが管理するレプリカ
データとの差分を認識することができる。
サーバが管理するレプリカデータ中に記録されている識
別情報は、レプリケーション要求に従って行われた該第
２のディレクトリサーバの操作によって最後に変更され
たエントリ（レプリケーションによって最後に変更され
たエントリ）を特定することとなるので、レプリケーシ
ョンサーバは、この識別情報を参照することで、次にレ
プリケーションを行うべきエントリを知ることができ、
従って、第１のディレクトリサーバが管理するマスタデ
ータと、第２のディレクトリサーバが管理するレプリカ
データとの差分を認識することができる。
【００４２】そこで、この識別情報を含むレプリカデー
タのバックアップを取っておけば、記録媒体の物理的破
損等によりレプリカデータが失われてしまった場合に、
第２のディレクトリサーバが、マスタデータ中の全ての
エントリを第１のディレクトリサーバから取得しなくて
も、バックアップを使用してレプリカデータを再構築す
ることができるようになるので、運用性を向上させるこ
とができる。
タのバックアップを取っておけば、記録媒体の物理的破
損等によりレプリカデータが失われてしまった場合に、
第２のディレクトリサーバが、マスタデータ中の全ての
エントリを第１のディレクトリサーバから取得しなくて
も、バックアップを使用してレプリカデータを再構築す
ることができるようになるので、運用性を向上させるこ
とができる。
【００４３】すなわち、第１の態様によれば、レプリカ
データが失われた場合でも、そのレプリカデータのバッ
クアップに対するレプリケーションを再開することを可
能にし、運用性を向上させたレプリケーションを実現す
るができる。
データが失われた場合でも、そのレプリカデータのバッ
クアップに対するレプリケーションを再開することを可
能にし、運用性を向上させたレプリケーションを実現す
るができる。
【００４４】なお、第１の態様において、上記履歴情報
が、対応する操作の実行順序を示す順序情報を含む場合
には、上記識別情報記録手段は、記録すべき識別情報と
して上記順序情報を用い、上記履歴情報取得手段は、参
照した識別情報に含まれる順序情報が示す実行順序より
後の実行順序を示す順序情報が含まれる履歴情報のうち
の、最も早い実行順序を示す順序情報が含まれる履歴情
報を、取得すべき履歴情報として決定するようにするこ
とができる。
が、対応する操作の実行順序を示す順序情報を含む場合
には、上記識別情報記録手段は、記録すべき識別情報と
して上記順序情報を用い、上記履歴情報取得手段は、参
照した識別情報に含まれる順序情報が示す実行順序より
後の実行順序を示す順序情報が含まれる履歴情報のうち
の、最も早い実行順序を示す順序情報が含まれる履歴情
報を、取得すべき履歴情報として決定するようにするこ
とができる。
【００４５】また、本発明は、第２の態様として、第１
の態様において、上記履歴情報取得手段は、上記識別情
報を検索するという操作を行う旨を要求するディレクト
リアクセス要求を、上記第２のディレクトリサーバへ発
行することで、該第２のディレクトリサーバが管理する
レプリカデータ中に記録されている識別情報を参照する
ことを特徴としたレプリケーションツールを提供してい
る。
の態様において、上記履歴情報取得手段は、上記識別情
報を検索するという操作を行う旨を要求するディレクト
リアクセス要求を、上記第２のディレクトリサーバへ発
行することで、該第２のディレクトリサーバが管理する
レプリカデータ中に記録されている識別情報を参照する
ことを特徴としたレプリケーションツールを提供してい
る。
【００４６】第２の態様によれば、上記識別情報を、レ
プリカデータ中の１つのエントリに設定される内容とし
て扱うことができるので、第２のディレクトリサーバと
っては、上記識別情報を検索するという操作を、上述し
た参照系ディレクトリアクセス要求に従った検索操作と
同様に行えばよく、従って、第２のディレクトリサーバ
の動作は、従来と同様の動作でよい。
プリカデータ中の１つのエントリに設定される内容とし
て扱うことができるので、第２のディレクトリサーバと
っては、上記識別情報を検索するという操作を、上述し
た参照系ディレクトリアクセス要求に従った検索操作と
同様に行えばよく、従って、第２のディレクトリサーバ
の動作は、従来と同様の動作でよい。
【００４７】また、本発明は、第３の態様として、第１
の態様および第２の態様のいずれかにおいて、上記識別
情報記録手段は、上記識別情報を記録するという操作を
行う旨を要求するディレクトリアクセス要求を、上記第
２のディレクトリサーバへ発行することで、該第２のデ
ィレクトリサーバが管理するレプリカデータ中に該識別
情報を記録することを特徴としたレプリケーションツー
ルを提供している。
の態様および第２の態様のいずれかにおいて、上記識別
情報記録手段は、上記識別情報を記録するという操作を
行う旨を要求するディレクトリアクセス要求を、上記第
２のディレクトリサーバへ発行することで、該第２のデ
ィレクトリサーバが管理するレプリカデータ中に該識別
情報を記録することを特徴としたレプリケーションツー
ルを提供している。
【００４８】第３の態様によれば、上記識別情報を、レ
プリカデータ中の１つのエントリに設定される内容とし
て扱うことができるので、第２のディレクトリサーバに
とっては、上記識別情報を記録するという操作を、上述
した更新系ディレクトリアクセス要求に従った変更操作
と同様に行えばよく、従って、第２のディレクトリサー
バの動作は、従来と同様の動作でよい。
プリカデータ中の１つのエントリに設定される内容とし
て扱うことができるので、第２のディレクトリサーバに
とっては、上記識別情報を記録するという操作を、上述
した更新系ディレクトリアクセス要求に従った変更操作
と同様に行えばよく、従って、第２のディレクトリサー
バの動作は、従来と同様の動作でよい。
【００４９】また、本発明は、第４の態様として、第１
の態様〜第３の態様のいずれかにおいて、上記レプリケ
ーション要求発行手段が発行したレプリケーション要求
に従って行われた上記第２のディレクトリサーバの操作
が失敗した場合でも、該レプリケーション要求と同一の
レプリケーション要求を２回以上連続して発行したこと
によって生じた失敗であり、かつ、該レプリケーション
要求と同一のレプリケーション要求を該第２のディレク
トリサーバが以前に受信しているならば、成功したとみ
なすエラー判定手段をさらに有するよう、上記レプリケ
ーションサーバを機能させることを特徴としたレプリケ
ーションツールを提供している。
の態様〜第３の態様のいずれかにおいて、上記レプリケ
ーション要求発行手段が発行したレプリケーション要求
に従って行われた上記第２のディレクトリサーバの操作
が失敗した場合でも、該レプリケーション要求と同一の
レプリケーション要求を２回以上連続して発行したこと
によって生じた失敗であり、かつ、該レプリケーション
要求と同一のレプリケーション要求を該第２のディレク
トリサーバが以前に受信しているならば、成功したとみ
なすエラー判定手段をさらに有するよう、上記レプリケ
ーションサーバを機能させることを特徴としたレプリケ
ーションツールを提供している。
【００５０】例えば、レプリケーション要求に従って行
われた第２のディレクトリサーバの操作が成功した後に
障害が発生し、レプリケーションが中断してしまった場
合には、上記識別情報の記録に失敗してしまうこととな
るので、障害の復旧後、レプリケーションサーバは、レ
プリケーションを再開すると、変更されていない誤った
識別情報を参照して、レプリケーション要求を発行する
こととなり、このレプリケーション要求に従って行われ
る第２のディレクトリサーバの操作は失敗することとな
る。
われた第２のディレクトリサーバの操作が成功した後に
障害が発生し、レプリケーションが中断してしまった場
合には、上記識別情報の記録に失敗してしまうこととな
るので、障害の復旧後、レプリケーションサーバは、レ
プリケーションを再開すると、変更されていない誤った
識別情報を参照して、レプリケーション要求を発行する
こととなり、このレプリケーション要求に従って行われ
る第２のディレクトリサーバの操作は失敗することとな
る。
【００５１】しかしながら、第４の態様によれば、レプ
リケーションサーバは、このような失敗を成功とみなす
ことができるので、レプリカデータを正しく保ちつつ、
レプリケーションを続行することが可能となる。
リケーションサーバは、このような失敗を成功とみなす
ことができるので、レプリカデータを正しく保ちつつ、
レプリケーションを続行することが可能となる。
【００５２】また、本発明は、第５の態様として、第１
の態様および第２の態様のいずれかにおいて、上記第２
のディレクトリサーバが、受信したディレクトリアクセ
ス要求中に予め定義された特定フィールドの設定内容に
従って、予め定義された特定操作を行うことが可能なデ
ィレクトリサーバである場合には、上記識別情報記録手
段は、上記レプリケーション要求発行手段が発行するレ
プリケーション要求中の特定フィールドに、上記識別情
報を記録するという特定操作を上記第２のディレクトリ
サーバが行うために必要な情報を設定することで、該第
２のディレクトリサーバが管理するレプリカデータ中に
該識別情報を記録することを特徴としたレプリケーショ
ンツールを提供している。
の態様および第２の態様のいずれかにおいて、上記第２
のディレクトリサーバが、受信したディレクトリアクセ
ス要求中に予め定義された特定フィールドの設定内容に
従って、予め定義された特定操作を行うことが可能なデ
ィレクトリサーバである場合には、上記識別情報記録手
段は、上記レプリケーション要求発行手段が発行するレ
プリケーション要求中の特定フィールドに、上記識別情
報を記録するという特定操作を上記第２のディレクトリ
サーバが行うために必要な情報を設定することで、該第
２のディレクトリサーバが管理するレプリカデータ中に
該識別情報を記録することを特徴としたレプリケーショ
ンツールを提供している。
【００５３】第５の態様によれば、第３の態様の効果に
加えて、レプリケーション要求の１回の発行で、上記識
別情報を記録するという操作を上記第２のディレクトリ
サーバに行わせることが可能となるので、レプリケーシ
ョンサーバは、レプリケーション要求以外に、上記識別
情報を記録するという操作を行う旨を要求するディレク
トリアクセス要求を発行する必要がなくなり、ネットワ
ークトラフィックの増加を押さえることができる。
加えて、レプリケーション要求の１回の発行で、上記識
別情報を記録するという操作を上記第２のディレクトリ
サーバに行わせることが可能となるので、レプリケーシ
ョンサーバは、レプリケーション要求以外に、上記識別
情報を記録するという操作を行う旨を要求するディレク
トリアクセス要求を発行する必要がなくなり、ネットワ
ークトラフィックの増加を押さえることができる。
【００５４】さらに、上記第２の目的を達成するために
は、レプリケーションサーバが、発行したレプリケーシ
ョン要求に従って行われた上記第２のディレクトリサー
バの操作が成功したか否かを知る前に障害が発生し、レ
プリケーションが中断してしまった場合でも、障害の復
旧後、レプーリケーションを正常に再開することができ
ない危険性があるという問題点を解決する必要がある。
は、レプリケーションサーバが、発行したレプリケーシ
ョン要求に従って行われた上記第２のディレクトリサー
バの操作が成功したか否かを知る前に障害が発生し、レ
プリケーションが中断してしまった場合でも、障害の復
旧後、レプーリケーションを正常に再開することができ
ない危険性があるという問題点を解決する必要がある。
【００５５】そこで、本発明においては、この問題点を
解決するためには、第３の態様および第５の態様のいず
れかにおいて、上記第２のディレクトリサーバが、上記
レプリケーション要求に従った操作、および、上記識別
情報を記録するという操作を、同一のトランザクション
として処理するようにすればよい。
解決するためには、第３の態様および第５の態様のいず
れかにおいて、上記第２のディレクトリサーバが、上記
レプリケーション要求に従った操作、および、上記識別
情報を記録するという操作を、同一のトランザクション
として処理するようにすればよい。
【００５６】このようにすれば、レプリカデータおよび
上記識別情報の一貫性を保証することができるようにな
るので、上記第２の目的を達成することができる。
上記識別情報の一貫性を保証することができるようにな
るので、上記第２の目的を達成することができる。
【００５７】
【発明の実施の形態】以下、本発明の実施の形態につい
て図面を参照して説明する。
て図面を参照して説明する。
【００５８】まず、本発明の第１の実施形態について説
明する。
明する。
【００５９】図２に、第１の実施形態に係るディレクト
リシステムのシステム構成を示す。図中、１ｓは第１の
ディレクトリサーバ、１ｃは第２のディレクトリサーバ
である。
リシステムのシステム構成を示す。図中、１ｓは第１の
ディレクトリサーバ、１ｃは第２のディレクトリサーバ
である。
【００６０】第１の実施形態においても、従来技術と同
様に、アクセス性能の維持および信頼性の向上を目的と
して、複数のディレクトリサーバ（ここでは、第１のデ
ィレクトリサーバ１ｓおよび第２のディレクトリサーバ
１ｃの２つである。）を備えるようにしており、サプラ
イヤ側である第１のディレクトリサーバ１ｓが、自身が
管理するディレクトリデータ（マスタデータ）が変更さ
れた場合に、コンシューマ側である第２のディレクトリ
サーバ１ｃへレプリケーション要求を発行することで、
第２のディレクトリサーバ１ｃが管理するディレクトリ
データ（レプリカデータ）を同一の内容に変更するレプ
リケーションを行うようになっている。ここで、第１の
実施形態においては、第１のディレクトリサーバ１ｓ
が、レプリケーションを行うレプリケーションサーバと
同一のサーバであるものとしている。
様に、アクセス性能の維持および信頼性の向上を目的と
して、複数のディレクトリサーバ（ここでは、第１のデ
ィレクトリサーバ１ｓおよび第２のディレクトリサーバ
１ｃの２つである。）を備えるようにしており、サプラ
イヤ側である第１のディレクトリサーバ１ｓが、自身が
管理するディレクトリデータ（マスタデータ）が変更さ
れた場合に、コンシューマ側である第２のディレクトリ
サーバ１ｃへレプリケーション要求を発行することで、
第２のディレクトリサーバ１ｃが管理するディレクトリ
データ（レプリカデータ）を同一の内容に変更するレプ
リケーションを行うようになっている。ここで、第１の
実施形態においては、第１のディレクトリサーバ１ｓ
が、レプリケーションを行うレプリケーションサーバと
同一のサーバであるものとしている。
【００６１】ただし、第１の実施形態においては、従来
技術とは異なり、レプリカデータのバックアップを取っ
ておくようにし、記録媒体の物理的破損等によりレプリ
カデータが失われてしまった場合に、バックアップデー
タに対するレプリケーションを再開することを可能とす
ることで、第２のディレクトリサーバ１ｃが、マスタデ
ータ中の全てのエントリを第１のディレクトリサーバ１
ｓから取得しなくても、バックアップを使用したレプリ
カデータの再構築を可能とし、運用性を向上させるよう
にしている。
技術とは異なり、レプリカデータのバックアップを取っ
ておくようにし、記録媒体の物理的破損等によりレプリ
カデータが失われてしまった場合に、バックアップデー
タに対するレプリケーションを再開することを可能とす
ることで、第２のディレクトリサーバ１ｃが、マスタデ
ータ中の全てのエントリを第１のディレクトリサーバ１
ｓから取得しなくても、バックアップを使用したレプリ
カデータの再構築を可能とし、運用性を向上させるよう
にしている。
【００６２】すなわち、バックアップを取っているエン
トリについては、第２のディレクトリサーバ１ｃが、こ
れを使用してレプリカデータを復旧し、バックアップを
取っていないエントリについてのみ、第１のディレクト
リサーバ１ｓがレプリケーションを再開することで、レ
プリカデータを復旧するようにしている。
トリについては、第２のディレクトリサーバ１ｃが、こ
れを使用してレプリカデータを復旧し、バックアップを
取っていないエントリについてのみ、第１のディレクト
リサーバ１ｓがレプリケーションを再開することで、レ
プリカデータを復旧するようにしている。
【００６３】そのためには、第１のディレクトリサーバ
１ｓが、自身が管理するマスタデータと、第２のディレ
クトリサーバ１ｃが管理するレプリカデータ（バックア
ップを使用して復旧されたレプリカデータ）との差分を
認識し、この差分についてのみレプリケーションを行う
必要があるが、従来技術では、この差分を認識すること
ができないという問題点があった。
１ｓが、自身が管理するマスタデータと、第２のディレ
クトリサーバ１ｃが管理するレプリカデータ（バックア
ップを使用して復旧されたレプリカデータ）との差分を
認識し、この差分についてのみレプリケーションを行う
必要があるが、従来技術では、この差分を認識すること
ができないという問題点があった。
【００６４】そこで、第１の実施形態においては、後述
するように、第１のディレクトリサーバ１ｓが、レプリ
ケーションによって最後に変更されたレプリカデータ中
のエントリを認識することを可能とすることで、マスタ
データとレプリカデータとの差分を認識することを可能
としている。
するように、第１のディレクトリサーバ１ｓが、レプリ
ケーションによって最後に変更されたレプリカデータ中
のエントリを認識することを可能とすることで、マスタ
データとレプリカデータとの差分を認識することを可能
としている。
【００６５】さて、図２に戻って、第１のディレクトリ
サーバ１ｓは、中央処理装置（ＣＰＵ）２ｓと、メモリ
３ｓと、磁気ディスク４ｓと、ディスクコントローラ５
ｓと、ＬＡＮコントローラ６ｓとを備えて構成されてい
る。
サーバ１ｓは、中央処理装置（ＣＰＵ）２ｓと、メモリ
３ｓと、磁気ディスク４ｓと、ディスクコントローラ５
ｓと、ＬＡＮコントローラ６ｓとを備えて構成されてい
る。
【００６６】第１のディレクトリサーバ１ｓの起動時に
は、ＣＰＵ２ｓによって、オペレーティングシステム
（ＯＳ）７ｓと、マスタデータ９ｓを管理するサプライ
ヤ・ディレクトリサーバプログラム８ｓと、レプリケー
ションを行うレプリケーションサーバプログラム１０と
が、磁気ディスク４ａから、ディスクコントローラ５ｓ
を介して、メモリ３ｓ上にロードされる。
は、ＣＰＵ２ｓによって、オペレーティングシステム
（ＯＳ）７ｓと、マスタデータ９ｓを管理するサプライ
ヤ・ディレクトリサーバプログラム８ｓと、レプリケー
ションを行うレプリケーションサーバプログラム１０と
が、磁気ディスク４ａから、ディスクコントローラ５ｓ
を介して、メモリ３ｓ上にロードされる。
【００６７】レプリケーションサーバプログラム１０
は、変更ログ取得プログラム１１と、リクエスト生成プ
ログラム１２と、レプリケーション状態記録プログラム
１５と、エラー判定プログラム１３と、通信制御プログ
ラム１４とを内部に有している。
は、変更ログ取得プログラム１１と、リクエスト生成プ
ログラム１２と、レプリケーション状態記録プログラム
１５と、エラー判定プログラム１３と、通信制御プログ
ラム１４とを内部に有している。
【００６８】また、磁気ディスク４ｓには、サプライヤ
・ディレクトリサーバプログラム８ｓが管理するレプリ
カデータ９ｓと、コンシューマ・ディレクトリサーバプ
ログラム８ｃに接続するために必要な情報が格納されて
いるレプリケーション定義ファイル１９と、サプライヤ
・ディレクトリサーバプログラム８ｓがマスタデータ９
ｓを変更した場合に、その変更操作の履歴情報が、レプ
リケーションレコードとして格納される変更ログファイ
ル２０と、レプリケーションサーバプログラム１０がレ
プリケーションに成功した場合に、該レプリケーション
を行う元となった変更操作に対応するレプリケーション
レコードを示すレコード識別子が格納されるレプリケー
ション状態ファイル２１とが存在している。
・ディレクトリサーバプログラム８ｓが管理するレプリ
カデータ９ｓと、コンシューマ・ディレクトリサーバプ
ログラム８ｃに接続するために必要な情報が格納されて
いるレプリケーション定義ファイル１９と、サプライヤ
・ディレクトリサーバプログラム８ｓがマスタデータ９
ｓを変更した場合に、その変更操作の履歴情報が、レプ
リケーションレコードとして格納される変更ログファイ
ル２０と、レプリケーションサーバプログラム１０がレ
プリケーションに成功した場合に、該レプリケーション
を行う元となった変更操作に対応するレプリケーション
レコードを示すレコード識別子が格納されるレプリケー
ション状態ファイル２１とが存在している。
【００６９】一方、第２のディレクトリサーバ１ｃは、
ＣＰＵ２ｃと、メモリ３ｃと、磁気ディスク４ｃと、デ
ィスクコントローラ５ｃと、ＬＡＮコントローラ６ｃと
を備えて構成されている。
ＣＰＵ２ｃと、メモリ３ｃと、磁気ディスク４ｃと、デ
ィスクコントローラ５ｃと、ＬＡＮコントローラ６ｃと
を備えて構成されている。
【００７０】第２のディレクトリサーバ１ｃの起動時に
は、ＣＰＵ２ｃによって、ＯＳ７ｃと、レプリカデータ
９ｃを管理するコンシューマ・ディレクトリサーバプロ
グラム８ｃとが、磁気ディスク４ｃから、ディスクコン
トローラ５ｃを介して、メモリ３ｃ上にロードされる。
は、ＣＰＵ２ｃによって、ＯＳ７ｃと、レプリカデータ
９ｃを管理するコンシューマ・ディレクトリサーバプロ
グラム８ｃとが、磁気ディスク４ｃから、ディスクコン
トローラ５ｃを介して、メモリ３ｃ上にロードされる。
【００７１】また、磁気ディスク４ｃには、コンシュー
マ・ディレクトリサーバプログラム８ｃが管理するレプ
リカデータ９ｃが存在している。
マ・ディレクトリサーバプログラム８ｃが管理するレプ
リカデータ９ｃが存在している。
【００７２】第１のディレクトリサーバ１ｓと第２のデ
ィレクトリサーバ１ｃとは、ローカルエリアネットワー
ク（ＬＡＮ）１００で接続されており、ＬＡＮコントロ
ーラ６ｓ，６ｃを介して互いに通信を行う。
ィレクトリサーバ１ｃとは、ローカルエリアネットワー
ク（ＬＡＮ）１００で接続されており、ＬＡＮコントロ
ーラ６ｓ，６ｃを介して互いに通信を行う。
【００７３】マスタデータ９ｓおよびレプリカデータ９
ｃ中の各エントリは、例えば、ユーザ識別情報を示すよ
うにすることができる。このとき、ユーザは、自身が使
用している端末（図示せず。）から、第１のディレクト
リサーバ１ｓまたは第２のディレクトリサーバ１ｃへ、
検索要求（参照系ディレクトリアクセス要求）を発行す
ることで、所望のユーザ識別情報を検索することが可能
であり、また、ユーザ（特に、管理者）は、自身が使用
している端末から、第１のディレクトリサーバ１ｓへ、
更新要求（更新系ディレクトリアクセス要求）を発行す
ることで、マスタデータ９ｓを変更することが可能であ
る。レプリケーションサーバプログラム１０は、マスタ
データ９ｓが変更されると、レプリカデータ９ｃの内容
を同一の内容に変更するために、レプリケーションを行
う。
ｃ中の各エントリは、例えば、ユーザ識別情報を示すよ
うにすることができる。このとき、ユーザは、自身が使
用している端末（図示せず。）から、第１のディレクト
リサーバ１ｓまたは第２のディレクトリサーバ１ｃへ、
検索要求（参照系ディレクトリアクセス要求）を発行す
ることで、所望のユーザ識別情報を検索することが可能
であり、また、ユーザ（特に、管理者）は、自身が使用
している端末から、第１のディレクトリサーバ１ｓへ、
更新要求（更新系ディレクトリアクセス要求）を発行す
ることで、マスタデータ９ｓを変更することが可能であ
る。レプリケーションサーバプログラム１０は、マスタ
データ９ｓが変更されると、レプリカデータ９ｃの内容
を同一の内容に変更するために、レプリケーションを行
う。
【００７４】なお、サプライヤ・ディレクトリサーバプ
ログラム８ｓおよびレプリケーションサーバプログラム
１０は、同一のサーバプログラムに含まれるような構成
としてもよいし、独立した構成のサーバプログラムであ
るようにしてもよい。さらに、独立した構成のサーバプ
ログラムであるようにした場合には、これらのサーバプ
ログラム８ｓ，１０は、同一のサーバ上に共に存在する
ようにしてもよいし、別のサーバ上に各々存在するよう
にしてもよい。
ログラム８ｓおよびレプリケーションサーバプログラム
１０は、同一のサーバプログラムに含まれるような構成
としてもよいし、独立した構成のサーバプログラムであ
るようにしてもよい。さらに、独立した構成のサーバプ
ログラムであるようにした場合には、これらのサーバプ
ログラム８ｓ，１０は、同一のサーバ上に共に存在する
ようにしてもよいし、別のサーバ上に各々存在するよう
にしてもよい。
【００７５】第１の実施形態においては、サプライヤ・
ディレクトリサーバプログラム８ｓおよびレプリケーシ
ョンサーバプログラム１０は、図２に示すように、独立
した構成のサーバプログラムであるものとし、同一のサ
ーバ（第１のディレクトリサーバ１ｓ）上に共に存在す
るものとする。また、コンシューマ・ディレクトリサー
バプログラム８ｃは、２つのサーバプログラム８ｓ，１
０が動作するサーバとは別のサーバ（第２のディレクト
リサーバ１ｃ）上に存在するものとする。
ディレクトリサーバプログラム８ｓおよびレプリケーシ
ョンサーバプログラム１０は、図２に示すように、独立
した構成のサーバプログラムであるものとし、同一のサ
ーバ（第１のディレクトリサーバ１ｓ）上に共に存在す
るものとする。また、コンシューマ・ディレクトリサー
バプログラム８ｃは、２つのサーバプログラム８ｓ，１
０が動作するサーバとは別のサーバ（第２のディレクト
リサーバ１ｃ）上に存在するものとする。
【００７６】なお、以下の図面において、同一の部分に
は同一の符号を付加する。
は同一の符号を付加する。
【００７７】図１に、第１の実施形態に係るレプリケー
ションサービスの機能構成を示す。
ションサービスの機能構成を示す。
【００７８】図１において、サプライヤ・ディレクトリ
サービス８ｓ′およびコンシューマ・ディレクトリサー
ビス８ｃ′は、各々、図２に示したサプライヤ・ディレ
クトリサーバプログラム８ｓおよびコンシューマ・ディ
レクトリサーバプログラム８ｃによって実現される機能
ブロックであり、マスタデータ９ｓおよびレプリカデー
タ９ｃは、サプライヤ・ディレクトリサービス８ｓ′お
よびコンシューマ・ディレクトリサービス８ｃ′によっ
て各々管理される。
サービス８ｓ′およびコンシューマ・ディレクトリサー
ビス８ｃ′は、各々、図２に示したサプライヤ・ディレ
クトリサーバプログラム８ｓおよびコンシューマ・ディ
レクトリサーバプログラム８ｃによって実現される機能
ブロックであり、マスタデータ９ｓおよびレプリカデー
タ９ｃは、サプライヤ・ディレクトリサービス８ｓ′お
よびコンシューマ・ディレクトリサービス８ｃ′によっ
て各々管理される。
【００７９】第１の実施形態においては、特に、コンシ
ューマ・ディレクトリサービス８ｃ′が管理するレプリ
カデータ９ｃ中には、レプリケーションによって最後に
変更されたレプリカデータ９ｃ中のエントリを特定する
ためのレプリケーションレコード識別子１０ｃが記録さ
れるようになっている。このレプリケーションレコード
識別子１０ｃは、実際には、コンシューマ・ディレクト
リサービス８ｃ′が管理するレプリカデータ９ｃ中の予
め定めたエントリに、該エントリに含まれる属性として
設定されるものであり、具体的には、図１０を用いて後
述するオブジェクトクラスのlastReplRecord属性の属性
値として設定される。
ューマ・ディレクトリサービス８ｃ′が管理するレプリ
カデータ９ｃ中には、レプリケーションによって最後に
変更されたレプリカデータ９ｃ中のエントリを特定する
ためのレプリケーションレコード識別子１０ｃが記録さ
れるようになっている。このレプリケーションレコード
識別子１０ｃは、実際には、コンシューマ・ディレクト
リサービス８ｃ′が管理するレプリカデータ９ｃ中の予
め定めたエントリに、該エントリに含まれる属性として
設定されるものであり、具体的には、図１０を用いて後
述するオブジェクトクラスのlastReplRecord属性の属性
値として設定される。
【００８０】変更ログ２０′は、図２に示した変更ログ
ファイル２０に相当しており、変更ログ２０′には、サ
プライヤ・ディレクトリサービス８ｓ′が変更操作を行
う契機となった更新要求（更新系ディレクトリアクセス
要求）が、タイムスタンプおよびレコード番号からなる
レコード識別子が付加されてから、レプリケーションレ
コードとして格納される。なお、タイムスタンプは、サ
プライヤ・ディレクトリサービス８ｓ′が更新系ディレ
クトリアクセス要求を受信した時点，変更操作を行った
時点，レプリケーションレコードを変更ログ２０′に格
納した時点のうちのいずれかの時点の時刻に基づく数値
であり、変更操作が行われた順序で昇順となっていなけ
ればならない。また、レコード番号は、変更操作が行わ
れる度に１づつ増加する数値である。
ファイル２０に相当しており、変更ログ２０′には、サ
プライヤ・ディレクトリサービス８ｓ′が変更操作を行
う契機となった更新要求（更新系ディレクトリアクセス
要求）が、タイムスタンプおよびレコード番号からなる
レコード識別子が付加されてから、レプリケーションレ
コードとして格納される。なお、タイムスタンプは、サ
プライヤ・ディレクトリサービス８ｓ′が更新系ディレ
クトリアクセス要求を受信した時点，変更操作を行った
時点，レプリケーションレコードを変更ログ２０′に格
納した時点のうちのいずれかの時点の時刻に基づく数値
であり、変更操作が行われた順序で昇順となっていなけ
ればならない。また、レコード番号は、変更操作が行わ
れる度に１づつ増加する数値である。
【００８１】一方、レプリケーションサービス１０′
は、図２に示したレプリケーションサーバプログラム１
０によって実現される機能ブロックであり、変更ログ取
得部１１′と、レプリケーション状態記録部１５′と、
リクエスト生成部１２′と、エラー判定部１３′と、通
信制御部１４′という５つの機能ブロックを内部に有し
ている。これら５つの機能ブロック１１′〜１５′は、
各々、図２に示した変更ログ取得プログラム１１，レプ
リケーション状態記録プログラム１５，リクエスト生成
プログラム１２，エラー判定プログラム１３，通信制御
プログラム１４によって実現される機能ブロックであ
る。
は、図２に示したレプリケーションサーバプログラム１
０によって実現される機能ブロックであり、変更ログ取
得部１１′と、レプリケーション状態記録部１５′と、
リクエスト生成部１２′と、エラー判定部１３′と、通
信制御部１４′という５つの機能ブロックを内部に有し
ている。これら５つの機能ブロック１１′〜１５′は、
各々、図２に示した変更ログ取得プログラム１１，レプ
リケーション状態記録プログラム１５，リクエスト生成
プログラム１２，エラー判定プログラム１３，通信制御
プログラム１４によって実現される機能ブロックであ
る。
【００８２】以下、５つの機能ブロック１１′〜１５′
について説明する。
について説明する。
【００８３】変更ログ取得部１１′は、レプリカデータ
９ｃ中のレプリケーションレコード識別子１０ｃに基づ
いて、変更ログ２０′からレプリケーションレコードを
取得する。レプリケーションレコード識別子１０ｃは、
レプリケーションによって最後に変更されたレプリカデ
ータ９ｃ中のエントリを特定するために、該エントリと
同一のエントリがマスタデータ９ｓにおいて変更された
際の変更操作に対応するレプリケーションレコードを特
定するようになっており、そのようなレプリケーション
レコード中のタイムスタンプおよびレコード番号を含む
ようになっている。レプリケーションは、変更されたマ
スタデータ９ｓ中のエントリと同一のレプリカデータ９
ｃ中のエントリについて、マスタデータ９ｓ中のエント
リが変更された際の変更操作と同一の変更操作が行われ
るようにすることで実現されるものであるので、マスタ
データ９ｓ中のエントリが変更された際の変更操作に対
応するレプリケーションレコードを特定することは、該
変更操作と同一の変更操作によって変更されたレプリカ
データ９ｃ中のエントリを特定することと等価である。
９ｃ中のレプリケーションレコード識別子１０ｃに基づ
いて、変更ログ２０′からレプリケーションレコードを
取得する。レプリケーションレコード識別子１０ｃは、
レプリケーションによって最後に変更されたレプリカデ
ータ９ｃ中のエントリを特定するために、該エントリと
同一のエントリがマスタデータ９ｓにおいて変更された
際の変更操作に対応するレプリケーションレコードを特
定するようになっており、そのようなレプリケーション
レコード中のタイムスタンプおよびレコード番号を含む
ようになっている。レプリケーションは、変更されたマ
スタデータ９ｓ中のエントリと同一のレプリカデータ９
ｃ中のエントリについて、マスタデータ９ｓ中のエント
リが変更された際の変更操作と同一の変更操作が行われ
るようにすることで実現されるものであるので、マスタ
データ９ｓ中のエントリが変更された際の変更操作に対
応するレプリケーションレコードを特定することは、該
変更操作と同一の変更操作によって変更されたレプリカ
データ９ｃ中のエントリを特定することと等価である。
【００８４】そこで、変更ログ取得部１１′は、レプリ
ケーションレコード識別子１０ｃに含まれているタイム
スタンプ以降のタイムスタンプ、および、レプリケーシ
ョンレコード識別子１０ｃに含まれているレコード番号
より大きいレコード番号を有するレプリケーションレコ
ードを、より小さいタイムスタンプおよびレコード番号
を有するレプリケーションレコードから順番に検索し、
変更ログ２０′から読み出す。これにより、レプリケー
ションサービス１０′は、サプライヤ・ディレクトリサ
ービス８ｓ′が変更操作を行った順序と同一の順序で、
レプリケーションを行うことが可能となる。
ケーションレコード識別子１０ｃに含まれているタイム
スタンプ以降のタイムスタンプ、および、レプリケーシ
ョンレコード識別子１０ｃに含まれているレコード番号
より大きいレコード番号を有するレプリケーションレコ
ードを、より小さいタイムスタンプおよびレコード番号
を有するレプリケーションレコードから順番に検索し、
変更ログ２０′から読み出す。これにより、レプリケー
ションサービス１０′は、サプライヤ・ディレクトリサ
ービス８ｓ′が変更操作を行った順序と同一の順序で、
レプリケーションを行うことが可能となる。
【００８５】リクエスト生成部１２′は、変更ログ取得
部１１′が読み出したレプリケーションレコードに基づ
いてレプリケーション要求を作成する。
部１１′が読み出したレプリケーションレコードに基づ
いてレプリケーション要求を作成する。
【００８６】通信制御部１４′は、リクエスト生成部１
２′が作成したレプリケーション要求をコンシューマ・
ディレクトリサービス８ｃ′へ発行し、それに対する応
答を受信する。
２′が作成したレプリケーション要求をコンシューマ・
ディレクトリサービス８ｃ′へ発行し、それに対する応
答を受信する。
【００８７】レプリケーション状態記録部１５′は、コ
ンシューマ・ディレクトリサービス８ｃ′が保持してい
るレプリケーションレコード識別子１０ｃを、レプリケ
ーションによって最後に変更されたレプリカデータ９ｃ
中のエントリを示すように変更する。すなわち、レプリ
ケーション状態記録部１５′は、発行したレプリケーシ
ョン要求の元となったレプリケーションレコード中のタ
イムスタンプおよびレコード番号を、レプリケーション
レコード識別子１０ｃが含むように変更する。
ンシューマ・ディレクトリサービス８ｃ′が保持してい
るレプリケーションレコード識別子１０ｃを、レプリケ
ーションによって最後に変更されたレプリカデータ９ｃ
中のエントリを示すように変更する。すなわち、レプリ
ケーション状態記録部１５′は、発行したレプリケーシ
ョン要求の元となったレプリケーションレコード中のタ
イムスタンプおよびレコード番号を、レプリケーション
レコード識別子１０ｃが含むように変更する。
【００８８】エラー判定部１３′は、既に発行したレプ
リケーション要求によって、レプリカデータ９ｃ中のエ
ントリが変更されているにも関わらず、レプリケーショ
ンレコード識別子１０ｃの変更に失敗したために、レプ
リケーションが失敗となってしまった旨を検出し、エラ
ー回復処理を行う。
リケーション要求によって、レプリカデータ９ｃ中のエ
ントリが変更されているにも関わらず、レプリケーショ
ンレコード識別子１０ｃの変更に失敗したために、レプ
リケーションが失敗となってしまった旨を検出し、エラ
ー回復処理を行う。
【００８９】図１０に、ディレクトリデータ中のエント
リが属するオブジェクトクラスのうちの、directorySer
verクラスおよびserverApplicationProcessクラスを示
す。これらのオブジェクトクラスは、ＩＳＯ８８２４と
して規定されたＡＳＮ.１（Abstract Syntax Notation
One）を用いて表記してある。
リが属するオブジェクトクラスのうちの、directorySer
verクラスおよびserverApplicationProcessクラスを示
す。これらのオブジェクトクラスは、ＩＳＯ８８２４と
して規定されたＡＳＮ.１（Abstract Syntax Notation
One）を用いて表記してある。
【００９０】directoryServerクラスは、serverApplica
tionProcessクラスのサブクラスとして任意に定義した
サブクラスであり、serverApplicationProcessクラス
は、Ｘ.５２１が定めるｄＳＡ（directorySystemAgen
t）クラスのサブクラスとして任意に定義したサブクラ
スである。
tionProcessクラスのサブクラスとして任意に定義した
サブクラスであり、serverApplicationProcessクラス
は、Ｘ.５２１が定めるｄＳＡ（directorySystemAgen
t）クラスのサブクラスとして任意に定義したサブクラ
スである。
【００９１】第１の実施形態においては、directorySer
verクラスが、任意に定義した属性であるlastReplRecor
d属性１０１を有するようにしている。このlastReplRec
ord属性１０１は、ディレクトリサーバプログラムがコ
ンシューマ側である場合にのみ存在する属性であり、レ
プリケーションレコード識別子１０ｃを示す。また、se
rverApplicationProcessクラスは、任意に定義した属性
であるipAddressおよびhostNameを有するようにしてお
り、これらの属性は、コンシューマ側のディレクトリサ
ーバを示す。
verクラスが、任意に定義した属性であるlastReplRecor
d属性１０１を有するようにしている。このlastReplRec
ord属性１０１は、ディレクトリサーバプログラムがコ
ンシューマ側である場合にのみ存在する属性であり、レ
プリケーションレコード識別子１０ｃを示す。また、se
rverApplicationProcessクラスは、任意に定義した属性
であるipAddressおよびhostNameを有するようにしてお
り、これらの属性は、コンシューマ側のディレクトリサ
ーバを示す。
【００９２】図１１に、lastReplRecord属性の属性値の
書式を示す。
書式を示す。
【００９３】lastReplRecord属性の属性値１１０は、大
文字／小文字を区別する文字列である。この属性値１１
０は、レプリケーションサーバプログラム１０が、レプ
リケーション定義ファイル１９に格納されているサプラ
イヤ・ディレクトリサーバ１ｓのホスト名（図６の６
９）、並びに、変更ログファイル２０に最後に格納され
たレプリケーションレコード（図７の７０）のレコード
番号（図７の７２）およびタイムスタンプ（図７の７
１）を、lastReplRecord属性値１１０中のホスト名１１
１，レコード番号１１２，タイムスタンプ１１３に各々
設定して作成する。
文字／小文字を区別する文字列である。この属性値１１
０は、レプリケーションサーバプログラム１０が、レプ
リケーション定義ファイル１９に格納されているサプラ
イヤ・ディレクトリサーバ１ｓのホスト名（図６の６
９）、並びに、変更ログファイル２０に最後に格納され
たレプリケーションレコード（図７の７０）のレコード
番号（図７の７２）およびタイムスタンプ（図７の７
１）を、lastReplRecord属性値１１０中のホスト名１１
１，レコード番号１１２，タイムスタンプ１１３に各々
設定して作成する。
【００９４】なお、ホスト名は、ＤＮＳ（Domain Name
Service）名であり、ＤＮＳサーバによって、インター
ネット上の情報処理装置を一意に識別可能なインターネ
ットアドレス（ＩＰアドレス）に変換される。
Service）名であり、ＤＮＳサーバによって、インター
ネット上の情報処理装置を一意に識別可能なインターネ
ットアドレス（ＩＰアドレス）に変換される。
【００９５】また、レプリケーション定義ファイル１９
および変更ログファイル２０の格納内容は、図６および
図７を用いて後述する。
および変更ログファイル２０の格納内容は、図６および
図７を用いて後述する。
【００９６】図４に、第１の実施形態に係るレプリケー
ションサービスのシーケンスを示す。
ションサービスのシーケンスを示す。
【００９７】図４に示すように、レプリケーションサー
バプログラム１０は、まず、コンシューマ・ディレクト
リサーバプログラム８ｃへ、バインド（bind）要求（４
０１）を発行し、それに対する応答（４０２）を受け取
ることで、コンシューマ・ディレクトリサーバプログラ
ム８ｃとの間のコネクションを確立する。
バプログラム１０は、まず、コンシューマ・ディレクト
リサーバプログラム８ｃへ、バインド（bind）要求（４
０１）を発行し、それに対する応答（４０２）を受け取
ることで、コンシューマ・ディレクトリサーバプログラ
ム８ｃとの間のコネクションを確立する。
【００９８】続いて、レプリケーションサーバプログラ
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃへ、lastReplRecord属性の属性値の検索を要求す
るためのlastReplRecord検索要求（４０３）を発行し、
lastReplRecord属性値を含む応答（４０４）を受信す
る。この応答（４０４）に含まれているlastReplRecord
属性値から、レプリケーションサーバプログラム１０
は、コンシューマ・ディレクトリサーバプログラム８ｃ
が管理するレプリカデータ９ｃ中のレプリケーションレ
コード識別子１０ｃを知ることができるので、前回のセ
ッションで行ったレプリケーションによって最後に変更
されたエントリを特定するためのレプリケーションレコ
ードのタイムスタンプおよびレコード番号を知ることが
できる。
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃへ、lastReplRecord属性の属性値の検索を要求す
るためのlastReplRecord検索要求（４０３）を発行し、
lastReplRecord属性値を含む応答（４０４）を受信す
る。この応答（４０４）に含まれているlastReplRecord
属性値から、レプリケーションサーバプログラム１０
は、コンシューマ・ディレクトリサーバプログラム８ｃ
が管理するレプリカデータ９ｃ中のレプリケーションレ
コード識別子１０ｃを知ることができるので、前回のセ
ッションで行ったレプリケーションによって最後に変更
されたエントリを特定するためのレプリケーションレコ
ードのタイムスタンプおよびレコード番号を知ることが
できる。
【００９９】続いて、レプリケーションサーバプログラ
ム１０は、レプリケーションが未実行のエントリについ
て、時系列的にレプリケーションを行うために、lastRe
plRecord属性値１１０に含まれているタイムスタンプお
よびレコード番号を取得し、取得したこれらの値に基づ
いて、レプリケーションレコードの読み出し（４０５）
を行う。
ム１０は、レプリケーションが未実行のエントリについ
て、時系列的にレプリケーションを行うために、lastRe
plRecord属性値１１０に含まれているタイムスタンプお
よびレコード番号を取得し、取得したこれらの値に基づ
いて、レプリケーションレコードの読み出し（４０５）
を行う。
【０１００】具体的には、レプリケーションサーバプロ
グラム１０は、取得したタイムスタンプ「８０００００
００」以降のタイムスタンプ、および、取得したレコー
ド番号「４５６」より大きいレコード番号を有するレプ
リケーションレコードのうちから、最も小さいタイムス
タンプおよびレコード番号を有するレプリケーションレ
コード４１４を、変更ログファイル２０から読み出す。
グラム１０は、取得したタイムスタンプ「８０００００
００」以降のタイムスタンプ、および、取得したレコー
ド番号「４５６」より大きいレコード番号を有するレプ
リケーションレコードのうちから、最も小さいタイムス
タンプおよびレコード番号を有するレプリケーションレ
コード４１４を、変更ログファイル２０から読み出す。
【０１０１】そして、読み出したレプリケーションレコ
ード４１４に基づいてレプリケーション要求を作成す
る。
ード４１４に基づいてレプリケーション要求を作成す
る。
【０１０２】なお、第１の実施形態においては、プロト
コルとして、ＬＤＳＰを採用することとしているので、
作成されるレプリケーション要求は、ＬＤＡＰアクセス
要求となる。また、ここでは、レプリケーションレコー
ド４１４から分かる変更操作が、エントリＡの追加操作
であるものとし、従って、作成されるＬＤＡＰアクセス
要求は、エントリＡ追加要求（４０６）となる。
コルとして、ＬＤＳＰを採用することとしているので、
作成されるレプリケーション要求は、ＬＤＡＰアクセス
要求となる。また、ここでは、レプリケーションレコー
ド４１４から分かる変更操作が、エントリＡの追加操作
であるものとし、従って、作成されるＬＤＡＰアクセス
要求は、エントリＡ追加要求（４０６）となる。
【０１０３】続いて、レプリケーションサーバプログラ
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃへ、作成したエントリＡ追加要求（４０６）を発
行する。このエントリＡ追加要求（４０６）を受信した
コンシューマ・ディレクトリサーバプログラム８ｃは、
エントリＡの追加（４０７）を実行し、実行結果を示す
応答（４０８）を返送する。
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃへ、作成したエントリＡ追加要求（４０６）を発
行する。このエントリＡ追加要求（４０６）を受信した
コンシューマ・ディレクトリサーバプログラム８ｃは、
エントリＡの追加（４０７）を実行し、実行結果を示す
応答（４０８）を返送する。
【０１０４】レプリケーションサーバプログラム１０
は、コンシューマ・ディレクトリサーバプログラム８ｃ
から応答（４０８）を受信すると、この応答（４０８）
に含まれているリターンコードが、レプリケーションが
成功したことを示す「LDAP_SUCCESS」であった場合に、
レプリケーションレコード４１４を示すレコード識別子
として、レプリケーションレコード４１４のタイムスタ
ンプ「８００００００１」およびレコード番号「４５
７」を、レプリケーション状態ファイル２１に格納（４
０９）する。
は、コンシューマ・ディレクトリサーバプログラム８ｃ
から応答（４０８）を受信すると、この応答（４０８）
に含まれているリターンコードが、レプリケーションが
成功したことを示す「LDAP_SUCCESS」であった場合に、
レプリケーションレコード４１４を示すレコード識別子
として、レプリケーションレコード４１４のタイムスタ
ンプ「８００００００１」およびレコード番号「４５
７」を、レプリケーション状態ファイル２１に格納（４
０９）する。
【０１０５】以上のシーケンスにより、サプライヤ・デ
ィレクトリサーバプログラム８ｓで実行されたエントリ
Ａの追加操作は、コンシューマ・ディレクトリサーバプ
ログラム８ｃへと伝播された。
ィレクトリサーバプログラム８ｓで実行されたエントリ
Ａの追加操作は、コンシューマ・ディレクトリサーバプ
ログラム８ｃへと伝播された。
【０１０６】さて、第１の実施形態においては、レプリ
ケーションサーバプログラム１０は、レプリケーション
要求に従ったコンシューマ・ディレクトリサーバプログ
ラム８ｃの変更操作が成功した後、レプリケーションレ
コード４１４のタイムスタンプ「８００００００１」お
よびレコード番号「４５７」を、コンシューマ・ディレ
クトリサーバプログラム８ｃ上に記録するようにする。
ケーションサーバプログラム１０は、レプリケーション
要求に従ったコンシューマ・ディレクトリサーバプログ
ラム８ｃの変更操作が成功した後、レプリケーションレ
コード４１４のタイムスタンプ「８００００００１」お
よびレコード番号「４５７」を、コンシューマ・ディレ
クトリサーバプログラム８ｃ上に記録するようにする。
【０１０７】具体的には、サプライヤ・ディレクトリサ
ーバプログラム８ｓが動作する第１のディレクトリサー
バ１ｓのホスト名、並びに、レプリケーションレコード
４１４のタイムスタンプおよびレコード番号を、図１１
に示すlastReplRecord属性値１１０のホスト名１１１，
タイムスタンプ１１３，レコード番号１１２に各々設定
して、新たなlastReplRecord属性値を作成し、lastRepl
Record属性値の変更を要求するためのlastReplRecord更
新要求（４１０）を発行する。そして、lastReplRecord
属性値が変更され（４１１）、lastReplRecord更新要求
（４１０）に対する応答（４１２）を受信すると、アン
バインド（unbind）要求（４１３）を発行し、コンシュ
ーマ・ディレクトリサーバプログラム８ｃとの間のコネ
クションを切断する。
ーバプログラム８ｓが動作する第１のディレクトリサー
バ１ｓのホスト名、並びに、レプリケーションレコード
４１４のタイムスタンプおよびレコード番号を、図１１
に示すlastReplRecord属性値１１０のホスト名１１１，
タイムスタンプ１１３，レコード番号１１２に各々設定
して、新たなlastReplRecord属性値を作成し、lastRepl
Record属性値の変更を要求するためのlastReplRecord更
新要求（４１０）を発行する。そして、lastReplRecord
属性値が変更され（４１１）、lastReplRecord更新要求
（４１０）に対する応答（４１２）を受信すると、アン
バインド（unbind）要求（４１３）を発行し、コンシュ
ーマ・ディレクトリサーバプログラム８ｃとの間のコネ
クションを切断する。
【０１０８】以上のシーケンスにより、コンシューマ・
ディレクトリサーバプログラム８ｃが管理するレプリカ
データ９ｃは、レプリケーションによって最後に変更さ
れたエントリを特定するためのレプリケーションレコー
ドを示すlastReplRecord属性値を、レプリケーションレ
コード識別子１０ｃとして有することとなる。
ディレクトリサーバプログラム８ｃが管理するレプリカ
データ９ｃは、レプリケーションによって最後に変更さ
れたエントリを特定するためのレプリケーションレコー
ドを示すlastReplRecord属性値を、レプリケーションレ
コード識別子１０ｃとして有することとなる。
【０１０９】上述したように、レプリケーションサーバ
プログラム１０は、レプリケーション要求の発行前に、
lastReplRecord属性値を検索し、前回のセッションで行
ったレプリケーションによって最後に変更されたエント
リを特定するためのレプリケーションレコード識別子１
０ｃを知ることで、次に行うべきレプリケーションの元
となるレプリケーションレコードを知ることができるよ
うになる。
プログラム１０は、レプリケーション要求の発行前に、
lastReplRecord属性値を検索し、前回のセッションで行
ったレプリケーションによって最後に変更されたエント
リを特定するためのレプリケーションレコード識別子１
０ｃを知ることで、次に行うべきレプリケーションの元
となるレプリケーションレコードを知ることができるよ
うになる。
【０１１０】同様にして、レプリケーションサーバプロ
グラム１０は、任意の時点でのレプリカデータ９ｃのバ
ックアップに対して、サプライヤ・ディレクトリサーバ
プログラム８ｓが管理するマスタデータ９ｓとの差分で
ある未実行のエントリを特定するためのレプリケーショ
ンレコードのみを取得し、レプリケーションを行うこと
で、マスタデータ９ｓの内容とレプリカデータ９ｃの内
容とを同一にすることが可能となる。
グラム１０は、任意の時点でのレプリカデータ９ｃのバ
ックアップに対して、サプライヤ・ディレクトリサーバ
プログラム８ｓが管理するマスタデータ９ｓとの差分で
ある未実行のエントリを特定するためのレプリケーショ
ンレコードのみを取得し、レプリケーションを行うこと
で、マスタデータ９ｓの内容とレプリカデータ９ｃの内
容とを同一にすることが可能となる。
【０１１１】従って、第１の実施形態によれば、lastRe
plRecord属性値を含むレプリカデータ９ｃのバックアッ
プを取っておけば、磁気ディスク４ｃの物理的損傷等に
よりレプリカデータ９ｃが失われてしまった場合でも、
バックアップデータに対するレプリケーションを再開す
ることが可能になるので、第２のディレクトリサーバ１
ｃが、マスタデータ９ｓ中の全てのエントリを第１のデ
ィレクトリサーバ１ｓから取得しなくても、バックアッ
プを使用したレプリカデータ９ｃの再構築が可能とな
り、運用性が向上する。
plRecord属性値を含むレプリカデータ９ｃのバックアッ
プを取っておけば、磁気ディスク４ｃの物理的損傷等に
よりレプリカデータ９ｃが失われてしまった場合でも、
バックアップデータに対するレプリケーションを再開す
ることが可能になるので、第２のディレクトリサーバ１
ｃが、マスタデータ９ｓ中の全てのエントリを第１のデ
ィレクトリサーバ１ｓから取得しなくても、バックアッ
プを使用したレプリカデータ９ｃの再構築が可能とな
り、運用性が向上する。
【０１１２】なお、第１の実施形態では、レプリケーシ
ョンサーバプログラム１０は、セッションごとに、レプ
リケーション要求の発行およびlastReplRecord更新要求
の発行を１度づつ実行し、該セッションを終了するよう
にしているが、１つのセッション中で、レプリケーショ
ン要求の発行およびlastReplRecord更新要求の発行を、
交互に複数回繰り返すようにしても、本発明における効
果は同じである。
ョンサーバプログラム１０は、セッションごとに、レプ
リケーション要求の発行およびlastReplRecord更新要求
の発行を１度づつ実行し、該セッションを終了するよう
にしているが、１つのセッション中で、レプリケーショ
ン要求の発行およびlastReplRecord更新要求の発行を、
交互に複数回繰り返すようにしても、本発明における効
果は同じである。
【０１１３】ところで、第１の実施形態においては、レ
プリケーション要求とlastReplRecord更新要求とを別個
の要求として発行するようにしているので、レプリケー
ション要求に従った変更操作が行われてから、lastRepl
Record更新要求に従った変更操作が行われるまでの間
は、lastReplRecord属性値は、正しいレプリケーション
レコード識別子１０ｃを示していないこととなる。
プリケーション要求とlastReplRecord更新要求とを別個
の要求として発行するようにしているので、レプリケー
ション要求に従った変更操作が行われてから、lastRepl
Record更新要求に従った変更操作が行われるまでの間
は、lastReplRecord属性値は、正しいレプリケーション
レコード識別子１０ｃを示していないこととなる。
【０１１４】そこで、この間に障害が発生した場合のエ
ラー回復処理が必要となり、以下に説明する。
ラー回復処理が必要となり、以下に説明する。
【０１１５】図５に、エントリＡ追加要求（５０１）に
従ったコンシューマ・ディレクトリサーバプログラム８
ｃの変更操作が成功し、レプリケーションサーバプログ
ラム１０がレプリケーション状態（５０２）を記録した
後に、第２のディレクトリサーバ１ｃの電源断等の障害
が発生し、lastReplRecord属性値（５０３）の変更操作
をコンシューマ・ディレクトリサーバプログラム８ｃが
実行せずに異常終了した場合のエラー回復処理を示す。
従ったコンシューマ・ディレクトリサーバプログラム８
ｃの変更操作が成功し、レプリケーションサーバプログ
ラム１０がレプリケーション状態（５０２）を記録した
後に、第２のディレクトリサーバ１ｃの電源断等の障害
が発生し、lastReplRecord属性値（５０３）の変更操作
をコンシューマ・ディレクトリサーバプログラム８ｃが
実行せずに異常終了した場合のエラー回復処理を示す。
【０１１６】この場合、コンシューマ・ディレクトリサ
ーバプログラム８ｃがlastReplRecord属性値（５０３）
の変更操作を実行していないので、レプリケーションサ
ーバプログラム１０は、再起動後、lastReplRecord属性
値を検索すると、前回のセッションで行ったレプリケー
ションで取得したlastReplRecord属性値と同じ値のlast
ReplRecord属性値を含む応答（５０４）を受信すること
となる。そこで、レプリケーションサーバプログラム１
０は、前回のセッションで変更ログファイル２０から読
み出したレプリケーションレコードＡ（５０５）を、再
度読み出してしまい、前回のセッションで発行したエン
トリＡ追加要求（５０１）と同一のエントリＡ追加要求
（５０６）を、再度発行してしまう。
ーバプログラム８ｃがlastReplRecord属性値（５０３）
の変更操作を実行していないので、レプリケーションサ
ーバプログラム１０は、再起動後、lastReplRecord属性
値を検索すると、前回のセッションで行ったレプリケー
ションで取得したlastReplRecord属性値と同じ値のlast
ReplRecord属性値を含む応答（５０４）を受信すること
となる。そこで、レプリケーションサーバプログラム１
０は、前回のセッションで変更ログファイル２０から読
み出したレプリケーションレコードＡ（５０５）を、再
度読み出してしまい、前回のセッションで発行したエン
トリＡ追加要求（５０１）と同一のエントリＡ追加要求
（５０６）を、再度発行してしまう。
【０１１７】ここで、コンシューマ・ディレクトリサー
バプログラム８ｃは、再起動前に実行したエントリＡ追
加要求（５０１）に従った変更操作が成功していた場合
に、エントリ追加要求（５０６）に従った変更操作を実
行しようとしても、エントリＡが既に存在していること
から、エントリ追加要求（５０６）に従った変更操作に
失敗してしまうので、それに対する応答（５０７）に含
まれるリターンコードは「LDAP_ALREADY_EXIST」とな
る。なお、「LDAP_ALREADY_EXIST」は、同一のエントリ
追加操作の重複により発生するリターンコードを示して
いる。
バプログラム８ｃは、再起動前に実行したエントリＡ追
加要求（５０１）に従った変更操作が成功していた場合
に、エントリ追加要求（５０６）に従った変更操作を実
行しようとしても、エントリＡが既に存在していること
から、エントリ追加要求（５０６）に従った変更操作に
失敗してしまうので、それに対する応答（５０７）に含
まれるリターンコードは「LDAP_ALREADY_EXIST」とな
る。なお、「LDAP_ALREADY_EXIST」は、同一のエントリ
追加操作の重複により発生するリターンコードを示して
いる。
【０１１８】そこで、第１の実施形態においては、レプ
リケーションサーバプログラム１０が、レプリケーショ
ン要求に対する応答に含まれているリターンコードが
「LDAP_ALREADY_EXIST」である場合には、該レプリケー
ション要求（ここでは、エントリＡ追加要求（５０６）
である。）が、前回のセッションで発行したレプリケー
ション要求と同一であるか否かを判断し、同一であるな
らば、該レプリケーション要求に対するコンシューマ・
ディレクトリサーバプログラム８ｃの変更操作が成功し
ているものとみなすようにし、続いて、lastReplRecord
更新要求を発行するようにする。
リケーションサーバプログラム１０が、レプリケーショ
ン要求に対する応答に含まれているリターンコードが
「LDAP_ALREADY_EXIST」である場合には、該レプリケー
ション要求（ここでは、エントリＡ追加要求（５０６）
である。）が、前回のセッションで発行したレプリケー
ション要求と同一であるか否かを判断し、同一であるな
らば、該レプリケーション要求に対するコンシューマ・
ディレクトリサーバプログラム８ｃの変更操作が成功し
ているものとみなすようにし、続いて、lastReplRecord
更新要求を発行するようにする。
【０１１９】なお、レプリケーションサーバプログラム
１０は、レプリケーションレコードＡ（５０５）のタイ
ムスタンプおよびレコード番号が、レプリケーション状
態ファイル２１に格納されているタイムスタンプおよび
レコード番号と各々同一であれば、前回のセッションで
発行したレプリケーション要求と今回のセッションで発
行したレプリケーション要求とが同一であると判断する
ことができる。
１０は、レプリケーションレコードＡ（５０５）のタイ
ムスタンプおよびレコード番号が、レプリケーション状
態ファイル２１に格納されているタイムスタンプおよび
レコード番号と各々同一であれば、前回のセッションで
発行したレプリケーション要求と今回のセッションで発
行したレプリケーション要求とが同一であると判断する
ことができる。
【０１２０】上述したエラー回復処理によれば、lastRe
plRecord属性値の変更が実行できなかった場合にも、レ
プリカデータ９ｃを正しく保ちつつ、レプリケーション
を続行することが可能になる。
plRecord属性値の変更が実行できなかった場合にも、レ
プリカデータ９ｃを正しく保ちつつ、レプリケーション
を続行することが可能になる。
【０１２１】ここで、レプリケーション定義ファイル１
９，変更ログファイル２０，レプリケーション状態ファ
イル２１に各々格納される情報について説明しておく。
９，変更ログファイル２０，レプリケーション状態ファ
イル２１に各々格納される情報について説明しておく。
【０１２２】まず、図６に、レプリケーション定義ファ
イル１９に格納される情報を示す。
イル１９に格納される情報を示す。
【０１２３】これらの情報は、レプリケーションサーバ
プログラム１０がコンシューマ・ディレクトリサーバプ
ログラム８ｃとの間のコネクションを確立する際に使用
される。
プログラム１０がコンシューマ・ディレクトリサーバプ
ログラム８ｃとの間のコネクションを確立する際に使用
される。
【０１２４】図６に示すように、レプリケーション定義
ファイル１９には、コンシューマ・ディレクトリサーバ
プログラム８ｃが動作するコンシューマ・ディレクトリ
サーバ１ｃのホスト名６１と、ポート番号６２と、バイ
ンド方法６３と、バインド時に用いる認証情報であるバ
インドＤＮ６４およびパスワード６５と、ディレクトリ
サーバオブジェクトＤＮ６７と、変更ログ位置６８と、
サプライヤ・ディレクトリサーバプログラム８ｓが動作
するサプライヤ・ディレクトリサーバ１ｓのホスト名６
９とが格納されている。
ファイル１９には、コンシューマ・ディレクトリサーバ
プログラム８ｃが動作するコンシューマ・ディレクトリ
サーバ１ｃのホスト名６１と、ポート番号６２と、バイ
ンド方法６３と、バインド時に用いる認証情報であるバ
インドＤＮ６４およびパスワード６５と、ディレクトリ
サーバオブジェクトＤＮ６７と、変更ログ位置６８と、
サプライヤ・ディレクトリサーバプログラム８ｓが動作
するサプライヤ・ディレクトリサーバ１ｓのホスト名６
９とが格納されている。
【０１２５】また、ディレクトリサーバオブジェクトＤ
Ｎ６７は、レプリケーションレコード識別子１０ｃ（す
なわち、lastReplRecord属性値が設定されたエントリ）
を指定するために用いるものであり、変更ログ位置６８
は、サプライヤ・ディレクトリサーバプログラム８ｓが
レプリケーションレコードを変更ログファイル２０に格
納するために用いる、ファイルの絶対パスである。
Ｎ６７は、レプリケーションレコード識別子１０ｃ（す
なわち、lastReplRecord属性値が設定されたエントリ）
を指定するために用いるものであり、変更ログ位置６８
は、サプライヤ・ディレクトリサーバプログラム８ｓが
レプリケーションレコードを変更ログファイル２０に格
納するために用いる、ファイルの絶対パスである。
【０１２６】第１の実施形態においては、バインド時に
行われる認証の認証方法として、レプリケーションサー
バプログラム１０がバインド時に送信するバインドＤＮ
６４およびパスワード６５が、コンシューマ・ディレク
トリサーバプログラム８ｃの管理者が予め登録している
バインドＤＮおよびパスワードと各々一致しているか否
かを判断する方法を採用しており、一致している場合
に、コンシューマ・ディレクトリサーバプログラム８ｃ
が、レプリケーションサーバプログラム１０に対してコ
ネクション確立を許可するようにしている。
行われる認証の認証方法として、レプリケーションサー
バプログラム１０がバインド時に送信するバインドＤＮ
６４およびパスワード６５が、コンシューマ・ディレク
トリサーバプログラム８ｃの管理者が予め登録している
バインドＤＮおよびパスワードと各々一致しているか否
かを判断する方法を採用しており、一致している場合
に、コンシューマ・ディレクトリサーバプログラム８ｃ
が、レプリケーションサーバプログラム１０に対してコ
ネクション確立を許可するようにしている。
【０１２７】レプリケーションサーバプログラム１０の
管理者は、レプリケーションサーバプログラム１０の起
動に先立って、レプリケーション定義情報ファイル１９
を作成しておく。
管理者は、レプリケーションサーバプログラム１０の起
動に先立って、レプリケーション定義情報ファイル１９
を作成しておく。
【０１２８】図７に、変更ログファイル２０に格納され
る情報を示す。
る情報を示す。
【０１２９】図７に示すように、変更ログファイル２０
には、１つのレプリケーションレコード７０ごとに、上
述したタイムスタンプ７１およびレコード番号７２と、
変更操作の対象ＤＮ７３と、変更操作種別７４と、変更
内容７５と、変更後のＲＤＮである新ＲＤＮ７６と、属
性値削除指示フラグ７７と、変更後の親ＲＤＮである新
上位ＲＤＮ７８とが格納されている。
には、１つのレプリケーションレコード７０ごとに、上
述したタイムスタンプ７１およびレコード番号７２と、
変更操作の対象ＤＮ７３と、変更操作種別７４と、変更
内容７５と、変更後のＲＤＮである新ＲＤＮ７６と、属
性値削除指示フラグ７７と、変更後の親ＲＤＮである新
上位ＲＤＮ７８とが格納されている。
【０１３０】第１の実施形態では、タイムスタンプ７１
は、1970年１月１日からの経過秒数を示す文字列である
としている。また、変更操作種別７４は、レプリケーシ
ョンレコード７０に対応する変更操作の種類を示し、変
更操作種別７４には、変更操作が「エントリ追加」であ
る場合は「add」という文字列が設定され、「エントリ
削除」である場合は「delete」が設定され、「エントリ
属性値変更」である場合は「modify」という文字列が設
定され、「ＲＤＮ変更」である場合は「modrdn」という
文字列が設定される。属性値削除指示フラグ７７には、
「ＲＤＮ変更」と同時に既存のＲＤＮ属性値を削除する
場合は「１」または「true」という文字列が設定され、
「ＲＤＮ変更」と同時に既存のＲＤＮ属性値を削除しな
い場合は「０」または「false」という文字列が設定さ
れる。
は、1970年１月１日からの経過秒数を示す文字列である
としている。また、変更操作種別７４は、レプリケーシ
ョンレコード７０に対応する変更操作の種類を示し、変
更操作種別７４には、変更操作が「エントリ追加」であ
る場合は「add」という文字列が設定され、「エントリ
削除」である場合は「delete」が設定され、「エントリ
属性値変更」である場合は「modify」という文字列が設
定され、「ＲＤＮ変更」である場合は「modrdn」という
文字列が設定される。属性値削除指示フラグ７７には、
「ＲＤＮ変更」と同時に既存のＲＤＮ属性値を削除する
場合は「１」または「true」という文字列が設定され、
「ＲＤＮ変更」と同時に既存のＲＤＮ属性値を削除しな
い場合は「０」または「false」という文字列が設定さ
れる。
【０１３１】変更内容７５は、変更操作が「エントリ追
加」および「エントリ属性変更操作」である場合にのみ
存在し、新ＲＤＮ７６，属性値削除指示フラグ７７，新
上位ＲＤＮ７８は、変更操作が「ＲＤＮ変更」である場
合にのみ存在する。
加」および「エントリ属性変更操作」である場合にのみ
存在し、新ＲＤＮ７６，属性値削除指示フラグ７７，新
上位ＲＤＮ７８は、変更操作が「ＲＤＮ変更」である場
合にのみ存在する。
【０１３２】図８に、変更操作が「エントリ属性変更操
作」である場合のレプリケーションレコード７０の変更
内容７５を示す。
作」である場合のレプリケーションレコード７０の変更
内容７５を示す。
【０１３３】図８に示すように、この場合の変更内容７
５は、１つの属性型８２ごとに、属性変更操作種別８１
と、０個以上の属性値８３とからなる組を構成してお
り、この組が１個以上存在する。属性変更操作種別８１
は、レプリケーションレコード７０に対応する変更操作
（「エントリ属性変更操作」）の種類を示し、属性変更
操作種別８１には、変更操作が「属性値追加」である場
合は「add」という文字列が設定され、「属性値削除」
である場合は「delete」という文字列が設定され、「属
性値変更」である場合は「replace」という文字列が設
定される。
５は、１つの属性型８２ごとに、属性変更操作種別８１
と、０個以上の属性値８３とからなる組を構成してお
り、この組が１個以上存在する。属性変更操作種別８１
は、レプリケーションレコード７０に対応する変更操作
（「エントリ属性変更操作」）の種類を示し、属性変更
操作種別８１には、変更操作が「属性値追加」である場
合は「add」という文字列が設定され、「属性値削除」
である場合は「delete」という文字列が設定され、「属
性値変更」である場合は「replace」という文字列が設
定される。
【０１３４】図９に、変更操作が「エントリ追加操作」
である場合のレプリケーションレコード７０の変更内容
７５を示す。
である場合のレプリケーションレコード７０の変更内容
７５を示す。
【０１３５】図９に示すように、この場合の変更内容７
５は、追加すべきエントリが有する属性型９１と、属性
値９２とからなる組を構成しており、この組が１個以上
存在する。
５は、追加すべきエントリが有する属性型９１と、属性
値９２とからなる組を構成しており、この組が１個以上
存在する。
【０１３６】図１２に、レプリケーション状態ファイル
２１に格納される情報を示す。
２１に格納される情報を示す。
【０１３７】図１２において、コンシューマ・ホスト名
１２１は、レプリケーションサーバプログラム１０が複
数のコンシューマ・ディレクトリサーバプログラム８ｃ
に対してレプリケーションを行う場合に、各コンシュー
マ・ディレクトリサーバプログラム８ｃが動作している
ディレクトリサーバのホスト名を設定し、各コンシュー
マ・ディレクトリサーバプログラム８ｃに対するレプリ
ケーション状態を識別するためにある。
１２１は、レプリケーションサーバプログラム１０が複
数のコンシューマ・ディレクトリサーバプログラム８ｃ
に対してレプリケーションを行う場合に、各コンシュー
マ・ディレクトリサーバプログラム８ｃが動作している
ディレクトリサーバのホスト名を設定し、各コンシュー
マ・ディレクトリサーバプログラム８ｃに対するレプリ
ケーション状態を識別するためにある。
【０１３８】また、タイムスタンプ１２２およびレコー
ド番号１２３には、レプリケーションに成功した最新の
レプリケーションレコード７０のタイムスタンプ７１お
よびレコード番号７２が設定され、変更ログファイル２
０に格納されているレプリケーションレコード７０中
の、どのレプリケーションレコード７０までレプリケー
ションが終了したかを示す。
ド番号１２３には、レプリケーションに成功した最新の
レプリケーションレコード７０のタイムスタンプ７１お
よびレコード番号７２が設定され、変更ログファイル２
０に格納されているレプリケーションレコード７０中
の、どのレプリケーションレコード７０までレプリケー
ションが終了したかを示す。
【０１３９】次に、ＬＤＡＰで用いられるリターンコー
ドについて説明しておく。
ドについて説明しておく。
【０１４０】まず、図１３に、Group１に属するＬＤＡ
Ｐリターンコードを示す。
Ｐリターンコードを示す。
【０１４１】Group１に属するＬＤＡＰリターンコード
は、同一のレプリケーション要求（ＬＤＡＰアクセス要
求）を複数回発行した場合に、ディレクトリサーバプロ
グラムが返すリターンコードである。
は、同一のレプリケーション要求（ＬＤＡＰアクセス要
求）を複数回発行した場合に、ディレクトリサーバプロ
グラムが返すリターンコードである。
【０１４２】このリターンコードは、更新系操作の種類
によって異なる。更新系操作が「エントリ追加」である
場合は、操作対象エントリのＤＮと同一のＤＮを有する
エントリが既に存在することを示す「LDAP_ALREADY_EXI
STS」となる。「エントリ削除」および「ＲＤＮ変更」
である場合は、操作対象エントリのＤＮと同一のＤＮを
有するエントリが既に存在しないことを示す「LDAP_NO_
SUCH_OBJECT」となる。「エントリ属性値追加」である
場合は、対象エントリの属性型に既に属性値が存在し複
数の属性値を持つことができないこと、または、同一の
属性値が既に存在することを示す「LDAP_TYPE_OR_VALUE
_EXISTS」となる。「エントリ属性値削除」である場合
は、対象エントリの属性値が既に存在しないことを示す
「LDAP_NO_SUCH_ATTRIBUTE」となる。
によって異なる。更新系操作が「エントリ追加」である
場合は、操作対象エントリのＤＮと同一のＤＮを有する
エントリが既に存在することを示す「LDAP_ALREADY_EXI
STS」となる。「エントリ削除」および「ＲＤＮ変更」
である場合は、操作対象エントリのＤＮと同一のＤＮを
有するエントリが既に存在しないことを示す「LDAP_NO_
SUCH_OBJECT」となる。「エントリ属性値追加」である
場合は、対象エントリの属性型に既に属性値が存在し複
数の属性値を持つことができないこと、または、同一の
属性値が既に存在することを示す「LDAP_TYPE_OR_VALUE
_EXISTS」となる。「エントリ属性値削除」である場合
は、対象エントリの属性値が既に存在しないことを示す
「LDAP_NO_SUCH_ATTRIBUTE」となる。
【０１４３】図１４に、Group２に属するＬＤＡＰリタ
ーンコードを示す。
ーンコードを示す。
【０１４４】Group２に属するＬＤＡＰリターンコード
は、ディレクトリサーバプログラムが、レプリケーショ
ン要求（ＬＤＡＰアクセス要求）に従った変更操作に成
功した場合に返すリターンコードである。
は、ディレクトリサーバプログラムが、レプリケーショ
ン要求（ＬＤＡＰアクセス要求）に従った変更操作に成
功した場合に返すリターンコードである。
【０１４５】以下、第１の実施形態におけるレプリケー
ションサーバプログラム１０の詳細な処理の流れについ
て、図１５〜図１８を用いて説明する。
ションサーバプログラム１０の詳細な処理の流れについ
て、図１５〜図１８を用いて説明する。
【０１４６】図１５は、第１の実施形態におけるレプリ
ケーションサーバプログラム１０の処理の流れを示すフ
ローチャートである。
ケーションサーバプログラム１０の処理の流れを示すフ
ローチャートである。
【０１４７】図１５に示すように、レプリケーションサ
ーバプログラム１０は、まず、変更ログファイル２０が
更新される場合に備えて、予め定めた待ち時間だけ待つ
（ステップ１５０２）。例えば、待ち時間は、５秒とす
ることができる。
ーバプログラム１０は、まず、変更ログファイル２０が
更新される場合に備えて、予め定めた待ち時間だけ待つ
（ステップ１５０２）。例えば、待ち時間は、５秒とす
ることができる。
【０１４８】そして、待ち時間内に、変更ログファイル
２０の更新を検出できなかった場合は（ステップ１５０
３）、ステップ１５０２に戻って、再び待つ。
２０の更新を検出できなかった場合は（ステップ１５０
３）、ステップ１５０２に戻って、再び待つ。
【０１４９】また、レプリケーションサーバプログラム
１０は、待ち時間内に、変更ログファイル２０の更新を
検出した場合は（ステップ１５０３）、図６に示すレプ
リケーション定義ファイル１９から、ホスト名６１，ポ
ート番号６２，バインド方法６３，バインドＤＮ６４，
パスワード６５を読み出し、読み出した内容を用いてバ
インド要求を作成し、コンシューマ・ディレクトリサー
バプログラム８ｃへ、作成したバインド要求を発行し、
それに対する応答を受信する（ステップ１５０４）。
１０は、待ち時間内に、変更ログファイル２０の更新を
検出した場合は（ステップ１５０３）、図６に示すレプ
リケーション定義ファイル１９から、ホスト名６１，ポ
ート番号６２，バインド方法６３，バインドＤＮ６４，
パスワード６５を読み出し、読み出した内容を用いてバ
インド要求を作成し、コンシューマ・ディレクトリサー
バプログラム８ｃへ、作成したバインド要求を発行し、
それに対する応答を受信する（ステップ１５０４）。
【０１５０】そして、コンシューマ・ディレクトリサー
バプログラム８ｃとの間のコネクションが確立すると、
コンシューマ・ディレクトリサーバプログラム８ｃから
認証を受け、セッションを開始する。
バプログラム８ｃとの間のコネクションが確立すると、
コンシューマ・ディレクトリサーバプログラム８ｃから
認証を受け、セッションを開始する。
【０１５１】その後、レプリケーションサーバプログラ
ム１０は、図６に示すレプリケーション定義ファイル１
９から変更ログ位置６８を読み出し、読み出した変更ロ
グ位置６８にある変更ログファイル２０から、図７に示
すレプリケーションレコード７０を取得する（ステップ
１５０５）。なお、ステップ１５０５は、変更ログ取得
プログラム１１によって行われる処理であり、その詳細
な処理内容については、図１６を用いて後述するが、ス
テップ１５０５では、１度に１つのレプリケーションレ
コード７０が、変更ログファイル２０から読み出される
ものとする。
ム１０は、図６に示すレプリケーション定義ファイル１
９から変更ログ位置６８を読み出し、読み出した変更ロ
グ位置６８にある変更ログファイル２０から、図７に示
すレプリケーションレコード７０を取得する（ステップ
１５０５）。なお、ステップ１５０５は、変更ログ取得
プログラム１１によって行われる処理であり、その詳細
な処理内容については、図１６を用いて後述するが、ス
テップ１５０５では、１度に１つのレプリケーションレ
コード７０が、変更ログファイル２０から読み出される
ものとする。
【０１５２】そして、読み出すべきレプリケーションレ
コード７０が存在し、該レプリケーションレコード７０
の取得に成功した場合は（ステップ１５０６）、取得し
たレプリケーションレコード７０に基づいてレプリケー
ション要求を作成し（ステップ１５０８）、コンシュー
マ・ディレクトリサーバプログラム８ｃに発行する（ス
テップ１５０９）。
コード７０が存在し、該レプリケーションレコード７０
の取得に成功した場合は（ステップ１５０６）、取得し
たレプリケーションレコード７０に基づいてレプリケー
ション要求を作成し（ステップ１５０８）、コンシュー
マ・ディレクトリサーバプログラム８ｃに発行する（ス
テップ１５０９）。
【０１５３】続いて、レプリケーションサーバプログラ
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃからの応答を受信し、受信した応答に含まれてい
るリターンコードを取得する（ステップ１５１０）。
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃからの応答を受信し、受信した応答に含まれてい
るリターンコードを取得する（ステップ１５１０）。
【０１５４】そして、前回のセッションでlastReplReco
rd属性値の変更が実行されなかったために、今回のセッ
ションで、前回のセッションで発行したレプリケーショ
ン要求と同一のレプリケーション要求が発行されてしま
い、エラーを起こした場合に相当するか否かを、取得し
たリターンコードから判断し、そのような場合であるな
らば、該リターンコードを、レプリケーション要求に従
った変更操作が成功したことを示す「LDAP_SUCCESS」に
書き直し、エラーを無視する（ステップ１５１１）。な
お、ステップ１５１１は、エラー判定プログラム１３に
よって行われる処理であり、その詳細な処理内容につい
ては、図１７を用いて後述する。
rd属性値の変更が実行されなかったために、今回のセッ
ションで、前回のセッションで発行したレプリケーショ
ン要求と同一のレプリケーション要求が発行されてしま
い、エラーを起こした場合に相当するか否かを、取得し
たリターンコードから判断し、そのような場合であるな
らば、該リターンコードを、レプリケーション要求に従
った変更操作が成功したことを示す「LDAP_SUCCESS」に
書き直し、エラーを無視する（ステップ１５１１）。な
お、ステップ１５１１は、エラー判定プログラム１３に
よって行われる処理であり、その詳細な処理内容につい
ては、図１７を用いて後述する。
【０１５５】その後、レプリケーションサーバプログラ
ム１０は、レプリケーション要求に従った変更操作が成
功したか否かをレプリケーション状態ファイル２１に記
録し、成功した場合には、さらに、lastReplRecord属性
値を変更する（ステップ１５１２）。なお、ステップ１
５１２は、レプリケーション状態記録プログラム１５に
よって行われる処理であり、その詳細の処理内容につい
ては、図１８を用いて後述する。
ム１０は、レプリケーション要求に従った変更操作が成
功したか否かをレプリケーション状態ファイル２１に記
録し、成功した場合には、さらに、lastReplRecord属性
値を変更する（ステップ１５１２）。なお、ステップ１
５１２は、レプリケーション状態記録プログラム１５に
よって行われる処理であり、その詳細の処理内容につい
ては、図１８を用いて後述する。
【０１５６】続いて、レプリケーションサーバプログラ
ム１０は、レプリケーション要求に対する応答に含まれ
ているリターンコード（ステップ１５１１で書き直され
ている場合もある。）が「LDAP_SUCCESS」であるか否か
を判断し（ステップ１５１３）、リターンコードが「LD
AP_SUCCESS」である場合は、アンバインド要求を作成
し、コンシューマ・ディレクトリサーバプログラム８ｃ
へ、作成したアンバインド要求を発行する（ステップ１
５１４）。
ム１０は、レプリケーション要求に対する応答に含まれ
ているリターンコード（ステップ１５１１で書き直され
ている場合もある。）が「LDAP_SUCCESS」であるか否か
を判断し（ステップ１５１３）、リターンコードが「LD
AP_SUCCESS」である場合は、アンバインド要求を作成
し、コンシューマ・ディレクトリサーバプログラム８ｃ
へ、作成したアンバインド要求を発行する（ステップ１
５１４）。
【０１５７】そして、コンシューマ・ディレクトリサー
バプログラム８ｃとの間のコネクションを解放すると、
ステップ１５０４に戻って、再度、バインド要求を発行
して、次のセッションを開始する。
バプログラム８ｃとの間のコネクションを解放すると、
ステップ１５０４に戻って、再度、バインド要求を発行
して、次のセッションを開始する。
【０１５８】一方、レプリケーションサーバプログラム
１０は、リターンコードが「LDAP_SUCCESS」でない場合
は、異常終了する（ステップ１５１６）。また、読み出
すべきレプリケーションレコード７０が存在しない場合
は（ステップ１５０６）、アンバインド要求を発行して
セッションを終了してから（ステップ１５０７）、ステ
ップ１５０２に戻って、再度、変更ログファイル２０が
更新されるのを待つ。
１０は、リターンコードが「LDAP_SUCCESS」でない場合
は、異常終了する（ステップ１５１６）。また、読み出
すべきレプリケーションレコード７０が存在しない場合
は（ステップ１５０６）、アンバインド要求を発行して
セッションを終了してから（ステップ１５０７）、ステ
ップ１５０２に戻って、再度、変更ログファイル２０が
更新されるのを待つ。
【０１５９】図１６に、図１５のステップ１５０５で変
更ログ取得プログラム１１が行う処理の流れを示す。
更ログ取得プログラム１１が行う処理の流れを示す。
【０１６０】図１６に示すように、変更ログ取得プログ
ラム１１は、まず、図６に示すレプリケーション定義フ
ァイル１９からディレクトリサーバオブジェクトＤＮ６
７を取得する（ステップ１６０１）。
ラム１１は、まず、図６に示すレプリケーション定義フ
ァイル１９からディレクトリサーバオブジェクトＤＮ６
７を取得する（ステップ１６０１）。
【０１６１】続いて、ディレクトリサーバオブジェクト
ＤＮ６７によって指定されるエントリの属性値、すなわ
ち、レプリケーションレコード識別子１０ｃを示すlast
ReplRecord属性値の検索を要求するためのlastReplReco
rd検索要求を作成し（ステップ１６０２）、作成したla
stReplRecord検索要求を発行し（ステップ１６０３）、
それに対する応答を受信する（ステップ１６０４）。
ＤＮ６７によって指定されるエントリの属性値、すなわ
ち、レプリケーションレコード識別子１０ｃを示すlast
ReplRecord属性値の検索を要求するためのlastReplReco
rd検索要求を作成し（ステップ１６０２）、作成したla
stReplRecord検索要求を発行し（ステップ１６０３）、
それに対する応答を受信する（ステップ１６０４）。
【０１６２】続いて、受信した応答に含まれているリタ
ーンコードが「LDAP_SUCCESS」であるか否かを判断する
（ステップ１６０５）。リターンコードが「LDAP_SUCCE
SS」である場合は、ステップ１６０６に進み、リターン
コードが「LDAP_SUCCESS」でない場合は、ステップ１６
０８に進んで、異常終了する。
ーンコードが「LDAP_SUCCESS」であるか否かを判断する
（ステップ１６０５）。リターンコードが「LDAP_SUCCE
SS」である場合は、ステップ１６０６に進み、リターン
コードが「LDAP_SUCCESS」でない場合は、ステップ１６
０８に進んで、異常終了する。
【０１６３】ステップ１６０６では、受信した応答か
ら、図１１に示すlastReplRecord属性値１１０を取り出
し、タイムスタンプ１１１およびレコード番号１１２を
取得する。そして、lastReplRecord属性値１１０に含ま
れているタイムスタンプ１１１以降のタイムスタンプ７
１、および、lastReplRecord属性値１１０に含まれてい
るレコード番号１１２より大きいレコード番号７２を有
するレプリケーションレコード７０を、変更ログファイ
ル２０から読み出し（ステップ１６０７）、変更ログ取
得プログラム１１を終了する。
ら、図１１に示すlastReplRecord属性値１１０を取り出
し、タイムスタンプ１１１およびレコード番号１１２を
取得する。そして、lastReplRecord属性値１１０に含ま
れているタイムスタンプ１１１以降のタイムスタンプ７
１、および、lastReplRecord属性値１１０に含まれてい
るレコード番号１１２より大きいレコード番号７２を有
するレプリケーションレコード７０を、変更ログファイ
ル２０から読み出し（ステップ１６０７）、変更ログ取
得プログラム１１を終了する。
【０１６４】図１７に、図１５のステップ１５１１でエ
ラー判定プログラム１３が行う処理の流れを示す。
ラー判定プログラム１３が行う処理の流れを示す。
【０１６５】図１７に示すように、エラー判定プログラ
ム１３は、まず、コンシューマ・ディレクトリサーバプ
ログラム８ｃから受信した応答に含まれているリターン
コードが、上述したGroup１に属しているか否かを判断
し（ステップ１７００）、Group１に属していない場合
は、エラー判定プログラム１３を終了する。
ム１３は、まず、コンシューマ・ディレクトリサーバプ
ログラム８ｃから受信した応答に含まれているリターン
コードが、上述したGroup１に属しているか否かを判断
し（ステップ１７００）、Group１に属していない場合
は、エラー判定プログラム１３を終了する。
【０１６６】また、リターンコードがGroup１に属して
いる場合は（ステップ１７００）、レプリケーションレ
コード７０が正しく、かつ、レプリケーションサーバプ
ログラム１０およびコンシューマ・サーバプログラム８
ｃが共に正常に動作しているにも関わらず、前回のセッ
ションでlastReplRecord属性値を変更できなかったため
に、レプリケーションサーバプログラム１０が同一のレ
プリケーション要求を重複して発行し、エラーとなった
可能性があると判断し、図１２に示すレプリケーション
状態ファイル２１から、タイムスタンプ１２２およびレ
コード番号１２３を読み出す（ステップ１７０１）。
いる場合は（ステップ１７００）、レプリケーションレ
コード７０が正しく、かつ、レプリケーションサーバプ
ログラム１０およびコンシューマ・サーバプログラム８
ｃが共に正常に動作しているにも関わらず、前回のセッ
ションでlastReplRecord属性値を変更できなかったため
に、レプリケーションサーバプログラム１０が同一のレ
プリケーション要求を重複して発行し、エラーとなった
可能性があると判断し、図１２に示すレプリケーション
状態ファイル２１から、タイムスタンプ１２２およびレ
コード番号１２３を読み出す（ステップ１７０１）。
【０１６７】その後、レプリケーションレコード７０の
タイムスタンプ７１およびレコード番号７２を、読み出
したタイムスタンプ１２２およびレコード番号１２３と
各々比較する（ステップ１７０２）。
タイムスタンプ７１およびレコード番号７２を、読み出
したタイムスタンプ１２２およびレコード番号１２３と
各々比較する（ステップ１７０２）。
【０１６８】そして、ステップ１７０２の比較の結果、
レプリケーションレコード７０のタイムスタンプ７１が
タイムスタンプ１２２と等しく、かつ、レプリケーショ
ンレコード７０のレコード番号７２がレコード番号１２
３と等しい場合は、今回のセッションで発行したレプリ
ケーション要求と同一のレプリケーション要求を、前回
のセッションで発行しており、前回のセッションで発行
したレプリケーション要求に従った変更操作が成功して
いるとみなし、リターンコードを、「LDAP_SUCCESS」に
書き直してから（ステップ１７０３）、エラー判定プロ
グラム１３を終了する。
レプリケーションレコード７０のタイムスタンプ７１が
タイムスタンプ１２２と等しく、かつ、レプリケーショ
ンレコード７０のレコード番号７２がレコード番号１２
３と等しい場合は、今回のセッションで発行したレプリ
ケーション要求と同一のレプリケーション要求を、前回
のセッションで発行しており、前回のセッションで発行
したレプリケーション要求に従った変更操作が成功して
いるとみなし、リターンコードを、「LDAP_SUCCESS」に
書き直してから（ステップ１７０３）、エラー判定プロ
グラム１３を終了する。
【０１６９】また、ステップ１７０２の比較の結果、上
述した場合以外の場合は、エラー判定プログラム１３を
終了する。
述した場合以外の場合は、エラー判定プログラム１３を
終了する。
【０１７０】図１８に、図１５のステップ１５１２でレ
プリケーション状態記録プログラム１５が行う処理の流
れを示す。
プリケーション状態記録プログラム１５が行う処理の流
れを示す。
【０１７１】図１８に示すように、レプリケーション状
態記録プログラム１５は、まず、コンシューマ・ディレ
クトリサーバプログラム８ｃから受信した応答に含まれ
ているリターンコードが、上述したGroup２に属してい
るか否かを判断し（ステップ１８０１）、Group２に属
していない場合は、レプリケーション状態記録プログラ
ム１５を終了する。
態記録プログラム１５は、まず、コンシューマ・ディレ
クトリサーバプログラム８ｃから受信した応答に含まれ
ているリターンコードが、上述したGroup２に属してい
るか否かを判断し（ステップ１８０１）、Group２に属
していない場合は、レプリケーション状態記録プログラ
ム１５を終了する。
【０１７２】また、リターンコードがGroup２に属して
いる場合は（ステップ１８０１）、レプリケーション要
求に従ったコンシューマ・ディレクトリサーバプログラ
ム８ｃの変更操作が成功したと判断し、レプリケーショ
ンレコード７０のタイムスタンプ７１およびレコード番
号７２を、図１２に示すレプリケーション状態ファイル
２１のタイムスタンプ１２２およびレコード番号１２３
に、各々格納する（ステップ１８０２）。
いる場合は（ステップ１８０１）、レプリケーション要
求に従ったコンシューマ・ディレクトリサーバプログラ
ム８ｃの変更操作が成功したと判断し、レプリケーショ
ンレコード７０のタイムスタンプ７１およびレコード番
号７２を、図１２に示すレプリケーション状態ファイル
２１のタイムスタンプ１２２およびレコード番号１２３
に、各々格納する（ステップ１８０２）。
【０１７３】続いて、図６に示すレプリケーション定義
ファイル１９から、ディレクトリサーバオブジェクトＤ
Ｎ６７を読み出し、読み出したディレクトリサーバオブ
ジェクトＤＮ６７によって指定されるエントリの属性
値、すなわち、レプリケーションレコード識別子１０ｃ
を示すlastReplRecord属性値の変更を要求するためのla
stReplRecord更新要求を作成し（ステップ１８０３）、
作成したｌａｓｔＲｅｐｌＲｅｃｏｒｄ更新要求を発行
し（ステップ１８０４）、それに対する応答を受信する
（ステップ１８０５）。
ファイル１９から、ディレクトリサーバオブジェクトＤ
Ｎ６７を読み出し、読み出したディレクトリサーバオブ
ジェクトＤＮ６７によって指定されるエントリの属性
値、すなわち、レプリケーションレコード識別子１０ｃ
を示すlastReplRecord属性値の変更を要求するためのla
stReplRecord更新要求を作成し（ステップ１８０３）、
作成したｌａｓｔＲｅｐｌＲｅｃｏｒｄ更新要求を発行
し（ステップ１８０４）、それに対する応答を受信する
（ステップ１８０５）。
【０１７４】最後に、受信した応答に含まれているリタ
ーンコードが「ＬＤＡＰ＿ＳＵＣＣＥＳＳ」であるか否
かを判断し（ステップ１８０６）、リターンコードが
「LDAP_SUCCESS」でない場合は、異常終了し（ステップ
１８０７）、リターンコードが「LDAP_SUCCESS」である
場合は、レプリケーション状態記録プログラム１５を終
了する。
ーンコードが「ＬＤＡＰ＿ＳＵＣＣＥＳＳ」であるか否
かを判断し（ステップ１８０６）、リターンコードが
「LDAP_SUCCESS」でない場合は、異常終了し（ステップ
１８０７）、リターンコードが「LDAP_SUCCESS」である
場合は、レプリケーション状態記録プログラム１５を終
了する。
【０１７５】以上説明したように、第１の実施形態によ
れば、レプリカデータ９ｃが、前回のセッションで行わ
れたレプリケーションによって最後に変更されたエント
リを特定するためのレプリケーションレコードを示すla
stReplRecord属性値を、ディレクトリレコード識別子１
０ｃとして有するようにしているので、レプリケーショ
ンサーバプログラム１０は、レプリケーションの実行に
先立って、このlastReplRecord属性値を取得すること
で、次にどのレプリケーションレコードに基づいてレプ
リケーションを行うべきであるかを判断することができ
る。従って、レプリカデータ９ｃのバックアップを取っ
ておけば、磁気ディスク４ｃの物理的損傷等によりレプ
リカデータ９ｃが失われた場合でも、第２のディレクト
リサーバ１ｃは、マスタデータ９ｓ中の全てのエントリ
を第１のディレクトリサーバ１ｓから取得しなくても、
バックアップを使用してレプリカデータ９ｃを再構築す
ることが可能となる。
れば、レプリカデータ９ｃが、前回のセッションで行わ
れたレプリケーションによって最後に変更されたエント
リを特定するためのレプリケーションレコードを示すla
stReplRecord属性値を、ディレクトリレコード識別子１
０ｃとして有するようにしているので、レプリケーショ
ンサーバプログラム１０は、レプリケーションの実行に
先立って、このlastReplRecord属性値を取得すること
で、次にどのレプリケーションレコードに基づいてレプ
リケーションを行うべきであるかを判断することができ
る。従って、レプリカデータ９ｃのバックアップを取っ
ておけば、磁気ディスク４ｃの物理的損傷等によりレプ
リカデータ９ｃが失われた場合でも、第２のディレクト
リサーバ１ｃは、マスタデータ９ｓ中の全てのエントリ
を第１のディレクトリサーバ１ｓから取得しなくても、
バックアップを使用してレプリカデータ９ｃを再構築す
ることが可能となる。
【０１７６】なお、第１の実施形態において、第２のデ
ィレクトリサーバ１ｃとっては、lastReplRecord属性更
新要求に従った変更操作を、レプリケーション要求に従
った変更操作と同様に行えばよく、また、lastReplReco
rd属性検索要求に従った検索操作も、参照系ディレクト
リアクセス要求に従った検索操作と同様に行えばよいの
で、第２のディレクトリサーバ１ｃが管理するレプリカ
データ９ｃ中に、図１０に示すオブジェクトクラスに属
し、lastReplRecord属性を有するようなエントリを、レ
プリケーションレコード識別子１０ｃを格納するための
エントリとして予め定義しておけば、第２のディレクト
リサーバ１ｃの動作は、従来と同様の動作でよい。
ィレクトリサーバ１ｃとっては、lastReplRecord属性更
新要求に従った変更操作を、レプリケーション要求に従
った変更操作と同様に行えばよく、また、lastReplReco
rd属性検索要求に従った検索操作も、参照系ディレクト
リアクセス要求に従った検索操作と同様に行えばよいの
で、第２のディレクトリサーバ１ｃが管理するレプリカ
データ９ｃ中に、図１０に示すオブジェクトクラスに属
し、lastReplRecord属性を有するようなエントリを、レ
プリケーションレコード識別子１０ｃを格納するための
エントリとして予め定義しておけば、第２のディレクト
リサーバ１ｃの動作は、従来と同様の動作でよい。
【０１７７】次に、本発明の第２の実施形態について説
明する。
明する。
【０１７８】ところで、従来技術では、レプリケーショ
ンを行う第１のディレクトリサーバ１ｓは、レプリケー
ション要求を発行してから、それに対する応答を受け取
る前に、電源断等の障害によりレプリケーションが異常
終了してしまった場合に、第２のディレクトリサーバ１
ｃでレプリケーション要求が反映されたか否かを知るこ
とができないので、障害の復旧後、レプーリケーション
を正常に再開することができない危険性があるという問
題点があり、第１の実施形態においては、この問題点を
解決するための方法については説明していなかった。
ンを行う第１のディレクトリサーバ１ｓは、レプリケー
ション要求を発行してから、それに対する応答を受け取
る前に、電源断等の障害によりレプリケーションが異常
終了してしまった場合に、第２のディレクトリサーバ１
ｃでレプリケーション要求が反映されたか否かを知るこ
とができないので、障害の復旧後、レプーリケーション
を正常に再開することができない危険性があるという問
題点があり、第１の実施形態においては、この問題点を
解決するための方法については説明していなかった。
【０１７９】すなわち、第１の実施形態においては、レ
プリケーションサーバプログラム１０は、レプリケーシ
ョン要求を発行してから、コンシューマ・ディレクトリ
サーバプログラム８ｃからの応答を受信するまでの間
に、電源断等の障害によりレプリケーションが異常終了
してしまった場合に、レプリケーション要求に従ったコ
ンシューマ・ディレクトリサーバプログラム８ｃの変更
操作が成功したか否かを判断することはできない。従っ
て、そのような場合には、管理者が、再度、異常終了前
に発行されたレプリケーション要求と同一のレプリケー
ション要求を発行させるか、または、lastReplRecord検
索要求を発行させるようにすることで、レプリケーショ
ン要求に従ったコンシューマ・ディレクトリサーバプロ
グラム８ｃの変更操作が成功したか否かを確認した上
で、次に行うべきレプリケーションの元となるレプリケ
ーションレコードを決めてやる必要がある。
プリケーションサーバプログラム１０は、レプリケーシ
ョン要求を発行してから、コンシューマ・ディレクトリ
サーバプログラム８ｃからの応答を受信するまでの間
に、電源断等の障害によりレプリケーションが異常終了
してしまった場合に、レプリケーション要求に従ったコ
ンシューマ・ディレクトリサーバプログラム８ｃの変更
操作が成功したか否かを判断することはできない。従っ
て、そのような場合には、管理者が、再度、異常終了前
に発行されたレプリケーション要求と同一のレプリケー
ション要求を発行させるか、または、lastReplRecord検
索要求を発行させるようにすることで、レプリケーショ
ン要求に従ったコンシューマ・ディレクトリサーバプロ
グラム８ｃの変更操作が成功したか否かを確認した上
で、次に行うべきレプリケーションの元となるレプリケ
ーションレコードを決めてやる必要がある。
【０１８０】そこで、第２の実施形態においては、任意
の時点で予期できない障害によりレプリケーションが異
常終了してしまった場合でも、障害の復旧後、レプーリ
ケーションを正常に再開することを可能とし、運用性を
向上させるようにする。
の時点で予期できない障害によりレプリケーションが異
常終了してしまった場合でも、障害の復旧後、レプーリ
ケーションを正常に再開することを可能とし、運用性を
向上させるようにする。
【０１８１】そのために、第２の実施形態においては、
コンシューマ・ディレクトリサーバプログラム８ｃがト
ランザクション機能を有するようにしており、レプリケ
ーション要求に従った変更操作、および、lastReplReco
rd更新要求に従った変更操作を、同一のトランザクショ
ンで処理するようにすることで、レプリカデータ９ｃお
よびlastReplRecord属性値の一貫性を保証するようにし
ている。
コンシューマ・ディレクトリサーバプログラム８ｃがト
ランザクション機能を有するようにしており、レプリケ
ーション要求に従った変更操作、および、lastReplReco
rd更新要求に従った変更操作を、同一のトランザクショ
ンで処理するようにすることで、レプリカデータ９ｃお
よびlastReplRecord属性値の一貫性を保証するようにし
ている。
【０１８２】以下、第２の実施形態について、第１の実
施形態との間の相違点に限り説明する。
施形態との間の相違点に限り説明する。
【０１８３】第２の実施形態に係るディレクトリシステ
ムのシステム構成は、図２に示すシステム構成から、エ
ラー判定プログラム１３を除いたシステム構成となる。
また、第２の実施形態に係るレプリケーションサービス
の機能構成は、図１に示す機能構成から、エラー判定部
１３′を除いた機能構成となる。
ムのシステム構成は、図２に示すシステム構成から、エ
ラー判定プログラム１３を除いたシステム構成となる。
また、第２の実施形態に係るレプリケーションサービス
の機能構成は、図１に示す機能構成から、エラー判定部
１３′を除いた機能構成となる。
【０１８４】また、第２の実施形態におけるコンシュー
マ・ディレクトリサーバプログラム８ｃは、バインド要
求からアンバインド要求まての間に受信した一連の要求
を、同一のトランザクションで処理する、トランザクシ
ョン機能を有するようになっている。
マ・ディレクトリサーバプログラム８ｃは、バインド要
求からアンバインド要求まての間に受信した一連の要求
を、同一のトランザクションで処理する、トランザクシ
ョン機能を有するようになっている。
【０１８５】具体的には、図４において、lastReplReco
rd属性値の変更（４１１）に失敗した場合には、直前に
行ったエントリＡの追加（４０７）を取り消すようにす
る。また、エントリＡの追加（４０７）を行った後、ア
ンバインド要求の到着以前に、コネクションが切断され
た場合も、直前に行ったエントリＡの追加（４０７）を
取り消すようにする。
rd属性値の変更（４１１）に失敗した場合には、直前に
行ったエントリＡの追加（４０７）を取り消すようにす
る。また、エントリＡの追加（４０７）を行った後、ア
ンバインド要求の到着以前に、コネクションが切断され
た場合も、直前に行ったエントリＡの追加（４０７）を
取り消すようにする。
【０１８６】従って、レプリケーション要求およびlast
ReplRecord更新要求は、常に、両方とも反映されるか、
両方とも反映されないかのいずれかとなる。これによ
り、レプリカデータ９ｃがレプリケーションレコード識
別子１０ｃとして有するlastReplRecord属性値は、常
に、レプリケーションによって最後に変更されたエント
リを特定するためのレプリケーションレコードを示す正
しい値となるので、第１の実施形態におけるエラー判定
プログラム１３は不要となる。
ReplRecord更新要求は、常に、両方とも反映されるか、
両方とも反映されないかのいずれかとなる。これによ
り、レプリカデータ９ｃがレプリケーションレコード識
別子１０ｃとして有するlastReplRecord属性値は、常
に、レプリケーションによって最後に変更されたエント
リを特定するためのレプリケーションレコードを示す正
しい値となるので、第１の実施形態におけるエラー判定
プログラム１３は不要となる。
【０１８７】以下、第２の実施形態におけるレプリケー
ションサーバプログラム１０の詳細な処理の流れについ
て、図１９および図２８を用いて説明する。
ションサーバプログラム１０の詳細な処理の流れについ
て、図１９および図２８を用いて説明する。
【０１８８】図１９は、第２の実施形態におけるレプリ
ケーションサーバプログラム１０の処理の流れを示すフ
ローチャートである。
ケーションサーバプログラム１０の処理の流れを示すフ
ローチャートである。
【０１８９】図１９に示すように、レプリケーションサ
ーバプログラム１０は、まず、変更ログファイル２０が
更新される場合に備えて、予め定めた待ち時間だけ待つ
（ステップ１９０２）。例えば、待ち時間は、５秒とす
ることができる。
ーバプログラム１０は、まず、変更ログファイル２０が
更新される場合に備えて、予め定めた待ち時間だけ待つ
（ステップ１９０２）。例えば、待ち時間は、５秒とす
ることができる。
【０１９０】そして、待ち時間内に、変更ログファイル
２０の更新を検出できなかった場合は（ステップ１９０
３）、ステップ１９０２に戻って、再び待つ。
２０の更新を検出できなかった場合は（ステップ１９０
３）、ステップ１９０２に戻って、再び待つ。
【０１９１】また、レプリケーションサーバプログラム
１０は、待ち時間内に、変更ログファイル２０の更新を
検出した場合は（ステップ１９０３）、図６に示すレプ
リケーション定義ファイル１９から、ホスト名６１，ポ
ート番号６２，バインド方法６３，バインドＤＮ６４，
パスワード６５を読み出し、読み出した内容を用いてバ
インド要求を作成し、コンシューマ・ディレクトリサー
バプログラム８ｃへ、作成したバインド要求を発行し、
それに対する応答を受信する（ステップ１９０４）。
１０は、待ち時間内に、変更ログファイル２０の更新を
検出した場合は（ステップ１９０３）、図６に示すレプ
リケーション定義ファイル１９から、ホスト名６１，ポ
ート番号６２，バインド方法６３，バインドＤＮ６４，
パスワード６５を読み出し、読み出した内容を用いてバ
インド要求を作成し、コンシューマ・ディレクトリサー
バプログラム８ｃへ、作成したバインド要求を発行し、
それに対する応答を受信する（ステップ１９０４）。
【０１９２】そして、コンシューマ・ディレクトリサー
バプログラム８ｃとの間のコネクションが確立すると、
コンシューマ・ディレクトリサーバプログラム８ｃから
認証を受け、セッションを開始する。
バプログラム８ｃとの間のコネクションが確立すると、
コンシューマ・ディレクトリサーバプログラム８ｃから
認証を受け、セッションを開始する。
【０１９３】その後、レプリケーションサーバプログラ
ム１０は、図６に示すレプリケーション定義ファイル１
９から変更ログ位置６８を読み出し、読み出した変更ロ
グ位置６８にある変更ログファイル２０から、図７に示
すレプリケーションレコード７０を取得する（ステップ
１９０５）。なお、ステップ１９０５は、変更ログ取得
プログラム１１によって行われる処理であり、その詳細
な処理内容は、図１６を用いて説明した通りである。ス
テップ１９０５では、１度に１つのレプリケーションレ
コード７０が、変更ログファイル２０から読み出される
ものとする。
ム１０は、図６に示すレプリケーション定義ファイル１
９から変更ログ位置６８を読み出し、読み出した変更ロ
グ位置６８にある変更ログファイル２０から、図７に示
すレプリケーションレコード７０を取得する（ステップ
１９０５）。なお、ステップ１９０５は、変更ログ取得
プログラム１１によって行われる処理であり、その詳細
な処理内容は、図１６を用いて説明した通りである。ス
テップ１９０５では、１度に１つのレプリケーションレ
コード７０が、変更ログファイル２０から読み出される
ものとする。
【０１９４】そして、読み出すべきレプリケーションレ
コード７０が存在し、該レプリケーションレコード７０
の取得に成功した場合は（ステップ１９０６）、取得し
たレプリケーションレコード７０に基づいてレプリケー
ション要求を作成し（ステップ１９０８）、コンシュー
マ・ディレクトリサーバプログラム８ｃへ発行する（ス
テップ１９０９）。
コード７０が存在し、該レプリケーションレコード７０
の取得に成功した場合は（ステップ１９０６）、取得し
たレプリケーションレコード７０に基づいてレプリケー
ション要求を作成し（ステップ１９０８）、コンシュー
マ・ディレクトリサーバプログラム８ｃへ発行する（ス
テップ１９０９）。
【０１９５】続いて、レプリケーションサーバプログラ
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃからの応答を受信し、受信した応答に含まれてい
るリターンコードを取得する（ステップ１９１０）。
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃからの応答を受信し、受信した応答に含まれてい
るリターンコードを取得する（ステップ１９１０）。
【０１９６】その後、レプリケーションサーバプログラ
ム１０は、lastReplRecord属性値を変更する（ステップ
１９１２）。なお、ステップ１９１２は、レプリケーシ
ョン状態記録プログラム１５によって行われる処理であ
り、その詳細の処理内容については、図２８を用いて後
述する。
ム１０は、lastReplRecord属性値を変更する（ステップ
１９１２）。なお、ステップ１９１２は、レプリケーシ
ョン状態記録プログラム１５によって行われる処理であ
り、その詳細の処理内容については、図２８を用いて後
述する。
【０１９７】続いて、レプリケーションサーバプログラ
ム１０は、レプリケーション要求に対する応答に含まれ
ているリターンコードが「LDAP_SUCCESS」であるか否か
を判断し（ステップ１９１３）、リターンコードが「LD
AP_SUCCESS」である場合は、アンバインド要求を作成
し、コンシューマ・ディレクトリサーバプログラム８ｃ
に対して、作成したアンバインド要求を発行する（ステ
ップ１９１４）。
ム１０は、レプリケーション要求に対する応答に含まれ
ているリターンコードが「LDAP_SUCCESS」であるか否か
を判断し（ステップ１９１３）、リターンコードが「LD
AP_SUCCESS」である場合は、アンバインド要求を作成
し、コンシューマ・ディレクトリサーバプログラム８ｃ
に対して、作成したアンバインド要求を発行する（ステ
ップ１９１４）。
【０１９８】そして、コンシューマ・ディレクトリサー
バプログラム８ｃとの間のコネクションを解放すると、
ステップ１９０４に戻って、再度、バインド要求を発行
して、次のセッションを開始する。
バプログラム８ｃとの間のコネクションを解放すると、
ステップ１９０４に戻って、再度、バインド要求を発行
して、次のセッションを開始する。
【０１９９】一方、レプリケーションサーバプログラム
１０は、リターンコードが「LDAP_SUCCESS」でない場合
は、異常終了する（ステップ１９１６）。また、読み出
すべきレプリケーションレコード７０が存在しない場合
は（ステップ１９０６）、アンバインド要求を発行して
セッションを終了してから（ステップ１９０７）、ステ
ップ１９０２に戻って、再度、変更ログファイル２０が
更新されるのを待つ。
１０は、リターンコードが「LDAP_SUCCESS」でない場合
は、異常終了する（ステップ１９１６）。また、読み出
すべきレプリケーションレコード７０が存在しない場合
は（ステップ１９０６）、アンバインド要求を発行して
セッションを終了してから（ステップ１９０７）、ステ
ップ１９０２に戻って、再度、変更ログファイル２０が
更新されるのを待つ。
【０２００】図２８に、図１９のステップ１９１２でレ
プリケーション状態記録プログラム１５が行う処理の流
れを示す。
プリケーション状態記録プログラム１５が行う処理の流
れを示す。
【０２０１】図２８に示すように、レプリケーション状
態記録プログラム１５は、まず、コンシューマ・ディレ
クトリサーバプログラム８ｃから受信した応答に含まれ
ているリターンコードが、上述したGroup２に属してい
るか否かを判断し（ステップ２８０１）、Group２に属
していない場合は、レプリケーション状態記録プログラ
ム１５を終了する。
態記録プログラム１５は、まず、コンシューマ・ディレ
クトリサーバプログラム８ｃから受信した応答に含まれ
ているリターンコードが、上述したGroup２に属してい
るか否かを判断し（ステップ２８０１）、Group２に属
していない場合は、レプリケーション状態記録プログラ
ム１５を終了する。
【０２０２】また、リターンコードがGroup２に属して
いる場合は（ステップ２８０１）、レプリケーション要
求に従ったコンシューマ・ディレクトリサーバプログラ
ム８ｃの変更操作が成功したと判断し、図６に示すレプ
リケーション定義ファイル１９から、ディレクトリサー
バオブジェクトＤＮ６７を読み出し、読み出したディレ
クトリサーバオブジェクトＤＮ６７によって指定される
エントリの属性値、すなわち、レプリケーションレコー
ド識別子１０ｃを示すlastReplRecord属性値の変更を要
求するためのlastReplRecord更新要求を作成し（ステッ
プ２８０３）、作成したlastReplRecord更新要求を発行
し（ステップ２８０４）、それに対する応答を受信する
（ステップ２８０５）。
いる場合は（ステップ２８０１）、レプリケーション要
求に従ったコンシューマ・ディレクトリサーバプログラ
ム８ｃの変更操作が成功したと判断し、図６に示すレプ
リケーション定義ファイル１９から、ディレクトリサー
バオブジェクトＤＮ６７を読み出し、読み出したディレ
クトリサーバオブジェクトＤＮ６７によって指定される
エントリの属性値、すなわち、レプリケーションレコー
ド識別子１０ｃを示すlastReplRecord属性値の変更を要
求するためのlastReplRecord更新要求を作成し（ステッ
プ２８０３）、作成したlastReplRecord更新要求を発行
し（ステップ２８０４）、それに対する応答を受信する
（ステップ２８０５）。
【０２０３】最後に、受信した応答に含まれているリタ
ーンコードが「LDAP_SUCCESS」であるか否かを判断し
（ステップ２８０６）、リターンコードが「LDAP_SUCCE
SS」でない場合は、異常終了し（ステップ２８０７）、
リターンコードが「LDAP_SUCCESS」である場合は、レプ
リケーション状態記録プログラム１５を終了する。
ーンコードが「LDAP_SUCCESS」であるか否かを判断し
（ステップ２８０６）、リターンコードが「LDAP_SUCCE
SS」でない場合は、異常終了し（ステップ２８０７）、
リターンコードが「LDAP_SUCCESS」である場合は、レプ
リケーション状態記録プログラム１５を終了する。
【０２０４】以上説明したように、第２の実施形態によ
れば、第１の実施形態の特徴に加えて、トランザクショ
ン機能を有するコンシューマ・ディレクトリサーバプロ
グラム８ｃにより、レプリケーション要求に従った変更
操作、および、lastReplRecord更新要求に従った変更操
作を、同一のトランザクションで処理するようにしてい
るので、レプリカデータ９ｃおよびlastReplRecord属性
値の一貫性を保証することができる。
れば、第１の実施形態の特徴に加えて、トランザクショ
ン機能を有するコンシューマ・ディレクトリサーバプロ
グラム８ｃにより、レプリケーション要求に従った変更
操作、および、lastReplRecord更新要求に従った変更操
作を、同一のトランザクションで処理するようにしてい
るので、レプリカデータ９ｃおよびlastReplRecord属性
値の一貫性を保証することができる。
【０２０５】従って、任意の時点で予期できない障害に
よりレプリケーションが異常終了してしまった場合で
も、障害の復旧後、レプーリケーションを正常に再開す
ることができるので、運用性を向上させることができ、
また、管理者は、レプリケーションがどこまで進行した
かを気にする必要はない。
よりレプリケーションが異常終了してしまった場合で
も、障害の復旧後、レプーリケーションを正常に再開す
ることができるので、運用性を向上させることができ、
また、管理者は、レプリケーションがどこまで進行した
かを気にする必要はない。
【０２０６】なお、第２の実施形態では、レプリケーシ
ョンサーバプログラム１０は、セッションごとに、レプ
リケーション要求の発行およびlastReplRecord更新要求
の発行を１度づつ実行し、該セッションを終了するよう
にしているが、１つのセッション中で、レプリケーショ
ン要求を複数回発行し、アンバインド要求の発行の直前
に、最後に発行したレプリケーション要求に対応するla
stReplRecord更新要求を発行するようにしても、コンシ
ューマ・ディレクトリサーバプログラム８ｃが有するト
ランザクション機能により、レプリカデータ９ｃおよび
lastReplRecord属性値の一貫性が保証されるので、本発
明における効果は同じである。
ョンサーバプログラム１０は、セッションごとに、レプ
リケーション要求の発行およびlastReplRecord更新要求
の発行を１度づつ実行し、該セッションを終了するよう
にしているが、１つのセッション中で、レプリケーショ
ン要求を複数回発行し、アンバインド要求の発行の直前
に、最後に発行したレプリケーション要求に対応するla
stReplRecord更新要求を発行するようにしても、コンシ
ューマ・ディレクトリサーバプログラム８ｃが有するト
ランザクション機能により、レプリカデータ９ｃおよび
lastReplRecord属性値の一貫性が保証されるので、本発
明における効果は同じである。
【０２０７】次に、本発明の第３の実施形態について説
明する。
明する。
【０２０８】第１の実施形態および第２の実施形態にお
いては、レプリケーションサーバプログラム１０が、レ
プリケーション要求以外に、lastReplRecord属性の変更
を要求するためのlastReplRecord更新要求を発行する必
要があるので、通常のレプリケーションサービスに比べ
て、ネットワークトラフィックが増加する。
いては、レプリケーションサーバプログラム１０が、レ
プリケーション要求以外に、lastReplRecord属性の変更
を要求するためのlastReplRecord更新要求を発行する必
要があるので、通常のレプリケーションサービスに比べ
て、ネットワークトラフィックが増加する。
【０２０９】そこで、第３の実施形態においては、last
ReplRecord更新要求を発行する代わりに、ＬＤＡＰの拡
張機能を利用して、新たなlastReplRecord属性値をコン
シューマ・ディレクトリサーバプログラム８ｃに伝える
ようにすることで、ネットワークトラフィックの増加を
押さえるようにする。
ReplRecord更新要求を発行する代わりに、ＬＤＡＰの拡
張機能を利用して、新たなlastReplRecord属性値をコン
シューマ・ディレクトリサーバプログラム８ｃに伝える
ようにすることで、ネットワークトラフィックの増加を
押さえるようにする。
【０２１０】以下、第３の実施形態について、第１の実
施形態との間の相違点に限り説明する。
施形態との間の相違点に限り説明する。
【０２１１】第３の実施形態においては、lastReplReco
rd属性値を変更する動作を、コンシューマ・ディレクト
リサーバプログラム８ｃの拡張機能によって実現するよ
うにしている。すなわち、第３の実施形態においては、
コンシューマ・ディレクトリサーバプログラム８ｃは、
受信したレプリケーション要求中のControlフィールド
に、拡張機能の適用が指示されている場合には、該レプ
リケーション要求に従った変更操作に加えて、lastRepl
Record属性値の変更操作を実行するようにし、この２つ
の変更操作を、同一のトランザクションで処理する機能
を有するようになっている。
rd属性値を変更する動作を、コンシューマ・ディレクト
リサーバプログラム８ｃの拡張機能によって実現するよ
うにしている。すなわち、第３の実施形態においては、
コンシューマ・ディレクトリサーバプログラム８ｃは、
受信したレプリケーション要求中のControlフィールド
に、拡張機能の適用が指示されている場合には、該レプ
リケーション要求に従った変更操作に加えて、lastRepl
Record属性値の変更操作を実行するようにし、この２つ
の変更操作を、同一のトランザクションで処理する機能
を有するようになっている。
【０２１２】図２７に、第３の実施形態に係るディレク
トリシステムのシステム構成を示す。
トリシステムのシステム構成を示す。
【０２１３】図２７に示すように、第３の実施形態に係
るディレクトリシステムのシステム構成が、図２に示す
システム構成と異なる点は、エラー判定プログラム１
３，レプリケーション状態記録プログラム１５，レプリ
ケーション状態ファイル２１が存在していない点、およ
び、lastReplRecord属性値を変更する拡張機能を実行す
る拡張プログラム８０ｃが存在している点である。
るディレクトリシステムのシステム構成が、図２に示す
システム構成と異なる点は、エラー判定プログラム１
３，レプリケーション状態記録プログラム１５，レプリ
ケーション状態ファイル２１が存在していない点、およ
び、lastReplRecord属性値を変更する拡張機能を実行す
る拡張プログラム８０ｃが存在している点である。
【０２１４】第３の実施形態における拡張プログラム８
０ｃは、コンシューマ・ディレクトリサーバプログラム
８ｃを構成するプログラムであり、受信したレプリケー
ション要求に含まれているControlフィールドの値によ
って起動される。
０ｃは、コンシューマ・ディレクトリサーバプログラム
８ｃを構成するプログラムであり、受信したレプリケー
ション要求に含まれているControlフィールドの値によ
って起動される。
【０２１５】図２６に、第３の実施形態に係るレプリケ
ーションサービスの機能構成を示す。
ーションサービスの機能構成を示す。
【０２１６】図２６に示すように、第３の実施形態に係
るレプリケーションサービスの機能構成が、図１に示す
機能構成と異なる点は、エラー判定部１３′およびレプ
リケーション状態記録部１５′が存在していない点、お
よび、図２７に示した拡張プログラム８０ｃによって実
現される機能ブロックである拡張部８０ｃ′が存在して
いる点である。
るレプリケーションサービスの機能構成が、図１に示す
機能構成と異なる点は、エラー判定部１３′およびレプ
リケーション状態記録部１５′が存在していない点、お
よび、図２７に示した拡張プログラム８０ｃによって実
現される機能ブロックである拡張部８０ｃ′が存在して
いる点である。
【０２１７】図２０は、ＲＦＣ１７７７として規定され
たＬＤＡＰアクセス要求を、ＩＳＯ８８２４として規定
されたＡＳＮ.１を用いて表記したものである。
たＬＤＡＰアクセス要求を、ＩＳＯ８８２４として規定
されたＡＳＮ.１を用いて表記したものである。
【０２１８】messageId（２００１）は、１つのＬＤＡ
Ｐセッション中で、ＬＤＡＰアクセス要求を一意に識別
するために付けられる値である。ProtocalOp（２００
２）は、ＬＤＡＰアクセス要求の実際の内容を示す。Co
ntrols（２００３）は、対応するＬＤＡＰアクセス要求
にのみ適用される拡張機能を示す。
Ｐセッション中で、ＬＤＡＰアクセス要求を一意に識別
するために付けられる値である。ProtocalOp（２００
２）は、ＬＤＡＰアクセス要求の実際の内容を示す。Co
ntrols（２００３）は、対応するＬＤＡＰアクセス要求
にのみ適用される拡張機能を示す。
【０２１９】アプリケーション開発者は、独自の拡張機
能を、ディレクトリサーバプログラム内に予め用意して
おき、ＬＤＡＰアクセス要求中のControls（２００３）
によって、拡張機能の適用をディレクトリサーバプログ
ラムに指示することが可能である。
能を、ディレクトリサーバプログラム内に予め用意して
おき、ＬＤＡＰアクセス要求中のControls（２００３）
によって、拡張機能の適用をディレクトリサーバプログ
ラムに指示することが可能である。
【０２２０】図２１に、Controls（２００３）のＡＳ
Ｎ.１による表記を示す。
Ｎ.１による表記を示す。
【０２２１】Controls（２００３）は、複数のcontrol
フィールドからなり、各controlフィールドにおいて、c
ontrolType（２１０１）には、拡張機能を一意に識別す
るために、ＣＣＩＴＴのＸ.２０８勧告に記述された、
全世界で一意な識別子（LDAPOID）が設定され、critica
lity（２１０２）には、「TRUE」または「FALSE」が設
定され、controlValue（２１０３）には、拡張機能で独
自に使用される値が、オクテット文字列として設定され
る。
フィールドからなり、各controlフィールドにおいて、c
ontrolType（２１０１）には、拡張機能を一意に識別す
るために、ＣＣＩＴＴのＸ.２０８勧告に記述された、
全世界で一意な識別子（LDAPOID）が設定され、critica
lity（２１０２）には、「TRUE」または「FALSE」が設
定され、controlValue（２１０３）には、拡張機能で独
自に使用される値が、オクテット文字列として設定され
る。
【０２２２】コンシューマ・ディレクトリサーバプログ
ラム８ｃは、criticality（２１０２）に「TRUE」が設
定されている場合は、controlType（２１０３）に対応
する拡張機能を認識／実行できないならば、リターンコ
ードとして、拡張機能が未サポートであることを示す
「unsupportedCriticalExtension」を返す。また、crit
icality（２１０２）に「FALSE」が設定されている場合
は、Controls（２００３）を無視する。
ラム８ｃは、criticality（２１０２）に「TRUE」が設
定されている場合は、controlType（２１０３）に対応
する拡張機能を認識／実行できないならば、リターンコ
ードとして、拡張機能が未サポートであることを示す
「unsupportedCriticalExtension」を返す。また、crit
icality（２１０２）に「FALSE」が設定されている場合
は、Controls（２００３）を無視する。
【０２２３】図２２に、第３の実施形態におけるレプリ
ケーション要求が含むControlフィールドのＡＳＮ.１に
よる表記を示す。
ケーション要求が含むControlフィールドのＡＳＮ.１に
よる表記を示す。
【０２２４】第３の実施形態において、Controlフィー
ルドで適用が指示される拡張機能は、lastReplRecord属
性値を変更する機能である。
ルドで適用が指示される拡張機能は、lastReplRecord属
性値を変更する機能である。
【０２２５】ControlType（２２０１）には、この拡張
機能を示すオブジェクト識別子（「<repOid>」）が設定
される。criticality（２２０２）には、「TRUE」が設
定され、controlValue（２２０３）には、新たなlastRe
plRecord属性値（「<lastReplRecord>」）が設定され
る。
機能を示すオブジェクト識別子（「<repOid>」）が設定
される。criticality（２２０２）には、「TRUE」が設
定され、controlValue（２２０３）には、新たなlastRe
plRecord属性値（「<lastReplRecord>」）が設定され
る。
【０２２６】図２３に、第３の実施形態に係るレプリケ
ーションサービスのシーケンスを示す。
ーションサービスのシーケンスを示す。
【０２２７】図２３に示すように、レプリケーションサ
ーバプログラム１０は、まず、コンシューマ・ディレク
トリサーバプログラム８ｃへ、バインド（bind）要求
（２３０１）を発行し、それに対する応答（２３０２）
を受け取ることで、コンシューマ・ディレクトリサーバ
プログラム８ｃとの間のコネクションを確立する。
ーバプログラム１０は、まず、コンシューマ・ディレク
トリサーバプログラム８ｃへ、バインド（bind）要求
（２３０１）を発行し、それに対する応答（２３０２）
を受け取ることで、コンシューマ・ディレクトリサーバ
プログラム８ｃとの間のコネクションを確立する。
【０２２８】続いて、レプリケーションサーバプログラ
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃへ、lastReplRecord属性の属性値の検索を要求す
るためのlastReplRecord検索要求（２３０３）を発行
し、lastReplRecord属性値を含む応答（２３０４）を受
信する。この応答（２３０４）に含まれているlastRepl
Record属性値から、レプリケーションサーバプログラム
１０は、コンシューマ・ディレクトリサーバプログラム
８ｃが管理するレプリカデータ９ｃ中のレプリケーショ
ンレコード識別子１０ｃを知ることができるので、前回
のセッションで行ったレプリケーションによって最後に
変更されたエントリを特定するためのレプリケーション
レコードのタイムスタンプおよびレコード番号を知るこ
とができる。
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃへ、lastReplRecord属性の属性値の検索を要求す
るためのlastReplRecord検索要求（２３０３）を発行
し、lastReplRecord属性値を含む応答（２３０４）を受
信する。この応答（２３０４）に含まれているlastRepl
Record属性値から、レプリケーションサーバプログラム
１０は、コンシューマ・ディレクトリサーバプログラム
８ｃが管理するレプリカデータ９ｃ中のレプリケーショ
ンレコード識別子１０ｃを知ることができるので、前回
のセッションで行ったレプリケーションによって最後に
変更されたエントリを特定するためのレプリケーション
レコードのタイムスタンプおよびレコード番号を知るこ
とができる。
【０２２９】続いて、レプリケーションサーバプログラ
ム１０は、レプリケーションが未実行のエントリについ
て、時系列的にレプリケーションを行うために、lastRe
plRecord属性値に含まれているタイムスタンプおよびレ
コード番号を取得し、取得したこれらの値に基づいて、
レプリケーションレコードの読み出し（２３０５）を行
う。
ム１０は、レプリケーションが未実行のエントリについ
て、時系列的にレプリケーションを行うために、lastRe
plRecord属性値に含まれているタイムスタンプおよびレ
コード番号を取得し、取得したこれらの値に基づいて、
レプリケーションレコードの読み出し（２３０５）を行
う。
【０２３０】具体的には、レプリケーションサーバプロ
グラム１０は、取得したタイムスタンプ「８０００００
００」以降のタイムスタンプ、および、取得したレコー
ド番号「４５６」より大きいレコード番号を有するレプ
リケーションレコードのうちから、最も小さいタイムス
タンプおよびレコード番号を有するレプリケーションレ
コード２３１４を、変更ログファイル２０から読み出
す。
グラム１０は、取得したタイムスタンプ「８０００００
００」以降のタイムスタンプ、および、取得したレコー
ド番号「４５６」より大きいレコード番号を有するレプ
リケーションレコードのうちから、最も小さいタイムス
タンプおよびレコード番号を有するレプリケーションレ
コード２３１４を、変更ログファイル２０から読み出
す。
【０２３１】そして、読み出したレプリケーションレコ
ード２３１４に基づいてレプリケーション要求を作成す
る。
ード２３１４に基づいてレプリケーション要求を作成す
る。
【０２３２】なお、第３の実施形態においては、プロト
コルとして、ＬＤＡＰを採用することとしているので、
作成されるレプリケーション要求は、ＬＤＡＰアクセス
要求となる。また、ここでは、レプリケーションレコー
ド２３１４から分かる変更操作が、エントリＡの追加操
作であるものとし、従って、作成されるＬＤＡＰアクセ
ス要求は、エントリＡ追加要求（２３０６）となる。
コルとして、ＬＤＡＰを採用することとしているので、
作成されるレプリケーション要求は、ＬＤＡＰアクセス
要求となる。また、ここでは、レプリケーションレコー
ド２３１４から分かる変更操作が、エントリＡの追加操
作であるものとし、従って、作成されるＬＤＡＰアクセ
ス要求は、エントリＡ追加要求（２３０６）となる。
【０２３３】続いて、レプリケーションサーバプログラ
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃへ、作成したエントリＡ追加要求（２３０６）を
発行する。
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃへ、作成したエントリＡ追加要求（２３０６）を
発行する。
【０２３４】なお、第３の実施形態においては、レプリ
ケーションサーバプログラム１０は、レプリカデータ９
ｃ中のディレクトリレコード識別子１０ｃを変更するた
めに、サプライヤ・ディレクトリサーバプログラム８ｓ
が動作する第１のディレクトリサービス１ｓのホスト
名、並びに、レプリケーションレコード（２３１１）が
有するタイムスタンプおよびレコード番号を、図１１に
示すlastReplRecord属性値１１０のホスト名１１１，タ
イムスタンプ１１３，レコード番号１１２に各々設定し
て、新たなlastReplRecord属性値を作成し、作成したla
stReplRecord属性値を、エントリＡ追加要求（２３０
６）中のControlフィールドのcontrolValueに設定する
ようにする。
ケーションサーバプログラム１０は、レプリカデータ９
ｃ中のディレクトリレコード識別子１０ｃを変更するた
めに、サプライヤ・ディレクトリサーバプログラム８ｓ
が動作する第１のディレクトリサービス１ｓのホスト
名、並びに、レプリケーションレコード（２３１１）が
有するタイムスタンプおよびレコード番号を、図１１に
示すlastReplRecord属性値１１０のホスト名１１１，タ
イムスタンプ１１３，レコード番号１１２に各々設定し
て、新たなlastReplRecord属性値を作成し、作成したla
stReplRecord属性値を、エントリＡ追加要求（２３０
６）中のControlフィールドのcontrolValueに設定する
ようにする。
【０２３５】このようなエントリＡ追加要求（２３０
６）を受信したコンシューマ・ディレクトリサーバプロ
グラム８ｃは、エントリＡの追加（２３０７）と、last
ReplRecord属性値の変更（２３０８）とを、同一のトラ
ンザクションで処理し、実行結果を示す応答（２３０
９）を送信する。
６）を受信したコンシューマ・ディレクトリサーバプロ
グラム８ｃは、エントリＡの追加（２３０７）と、last
ReplRecord属性値の変更（２３０８）とを、同一のトラ
ンザクションで処理し、実行結果を示す応答（２３０
９）を送信する。
【０２３６】レプリケーションサーバプログラム１０
は、コンシューマ・ディレクトリサーバプログラム８ｃ
から応答（２３０９）を受信すると、アンバインド（un
bind）要求（２３１０）を発行し、コンシューマ・ディ
レクトリサーバプログラム８ｃとの間のコネクションを
切断する。
は、コンシューマ・ディレクトリサーバプログラム８ｃ
から応答（２３０９）を受信すると、アンバインド（un
bind）要求（２３１０）を発行し、コンシューマ・ディ
レクトリサーバプログラム８ｃとの間のコネクションを
切断する。
【０２３７】以上のシーケンスにより、サプライヤ・デ
ィレクトリサーバプログラム８ｓで実行されたエントリ
Ａの追加操作は、コンシューマ・ディレクトリサーバプ
ログラム８ｃへと伝播され、さらに、レプリカデータ９
ｃは、レプリケーションによって最後に変更されたエン
トリＡを特定するためのレプリケーションレコードを示
す新たなlastReplRecord属性値を、レプリケーションレ
コード識別子１０ｃとして有することになる。
ィレクトリサーバプログラム８ｓで実行されたエントリ
Ａの追加操作は、コンシューマ・ディレクトリサーバプ
ログラム８ｃへと伝播され、さらに、レプリカデータ９
ｃは、レプリケーションによって最後に変更されたエン
トリＡを特定するためのレプリケーションレコードを示
す新たなlastReplRecord属性値を、レプリケーションレ
コード識別子１０ｃとして有することになる。
【０２３８】また、エントリＡの追加操作とlastReplRe
cord属性値の変更操作とが、同一のトランザクションで
処理されることで、レプリカデータ９ｃおよびlastRepl
Record属性値の一貫性も保証される。
cord属性値の変更操作とが、同一のトランザクションで
処理されることで、レプリカデータ９ｃおよびlastRepl
Record属性値の一貫性も保証される。
【０２３９】以下、第３の実施形態におけるレプリケー
ションサーバプログラム１０の詳細な処理の流れについ
て、図２５を用いて説明する。
ションサーバプログラム１０の詳細な処理の流れについ
て、図２５を用いて説明する。
【０２４０】図２５は、第３の実施形態におけるレプリ
ケーションサーバプログラム１０の処理の流れを示すフ
ローチャートである。
ケーションサーバプログラム１０の処理の流れを示すフ
ローチャートである。
【０２４１】図２５に示すように、レプリケーションサ
ーバプログラム１０は、まず、変更ログファイル２０が
更新される場合に備えて、予め定めた待ち時間だけ待つ
（ステップ２５０２）。例えば、待ち時間は、５秒とす
ることができる。
ーバプログラム１０は、まず、変更ログファイル２０が
更新される場合に備えて、予め定めた待ち時間だけ待つ
（ステップ２５０２）。例えば、待ち時間は、５秒とす
ることができる。
【０２４２】そして、待ち時間内に、変更ログファイル
２０の更新を検出できなかった場合は（ステップ２５０
３）、ステップ２５０２に戻って、再び待つ。
２０の更新を検出できなかった場合は（ステップ２５０
３）、ステップ２５０２に戻って、再び待つ。
【０２４３】また、レプリケーションサーバプログラム
１０は、待ち時間内に、変更ログファイル２０の更新を
検出した場合は（ステップ２５０３）、図６に示すレプ
リケーション定義ファイル１９から、ホスト名６１，ポ
ート番号６２，バインド方法６３，バインドＤＮ６４，
パスワード６５を読み出し、読み出した内容を用いてバ
インド要求を作成し、コンシューマ・ディレクトリサー
バプログラム８ｃへ、作成したバインド要求を発行し、
それに対する応答を受信する（ステップ２５０４）。
１０は、待ち時間内に、変更ログファイル２０の更新を
検出した場合は（ステップ２５０３）、図６に示すレプ
リケーション定義ファイル１９から、ホスト名６１，ポ
ート番号６２，バインド方法６３，バインドＤＮ６４，
パスワード６５を読み出し、読み出した内容を用いてバ
インド要求を作成し、コンシューマ・ディレクトリサー
バプログラム８ｃへ、作成したバインド要求を発行し、
それに対する応答を受信する（ステップ２５０４）。
【０２４４】そして、コンシューマ・ディレクトリサー
バプログラム８ｃとの間のコネクションが確立すると、
コンシューマ・ディレクトリサーバプログラム８ｃから
認証を受け、セッションを開始する。
バプログラム８ｃとの間のコネクションが確立すると、
コンシューマ・ディレクトリサーバプログラム８ｃから
認証を受け、セッションを開始する。
【０２４５】その後、レプリケーションサーバプログラ
ム１０は、図６に示すレプリケーション定義ファイル１
９から変更ログ位置６８を読み出し、読み出した変更ロ
グ位置６８にある変更ログファイル２０から、図７に示
すレプリケーションレコード７０を取得する（ステップ
２５０５）。なお、ステップ２５０５は、変更ログ取得
プログラム１１によって行われる処理であり、その詳細
な処理内容は、図１６を用いて説明した通りである。ス
テップ２５０５では、１度に１つのレプリケーションレ
コード７０が、変更ログファイル２０から読み出される
ものとする。
ム１０は、図６に示すレプリケーション定義ファイル１
９から変更ログ位置６８を読み出し、読み出した変更ロ
グ位置６８にある変更ログファイル２０から、図７に示
すレプリケーションレコード７０を取得する（ステップ
２５０５）。なお、ステップ２５０５は、変更ログ取得
プログラム１１によって行われる処理であり、その詳細
な処理内容は、図１６を用いて説明した通りである。ス
テップ２５０５では、１度に１つのレプリケーションレ
コード７０が、変更ログファイル２０から読み出される
ものとする。
【０２４６】そして、読み出すべきレプリケーションレ
コード７０が存在し、該レプリケーションレコード７０
の取得に成功した場合は（ステップ２５０６）、取得し
たレプリケーションレコード７０に基づいてレプリケー
ション要求を作成し（ステップ２５０８）、コンシュー
マ・ディレクトリサーバプログラム８ｃへ発行する（ス
テップ２５０９）。なお、第３の実施形態においては、
レプリケーションサーバプログラム１０は、ステップ２
５０８では、レプリケーション要求中のControlフィー
ルドに、図２２に示す値を設定する。
コード７０が存在し、該レプリケーションレコード７０
の取得に成功した場合は（ステップ２５０６）、取得し
たレプリケーションレコード７０に基づいてレプリケー
ション要求を作成し（ステップ２５０８）、コンシュー
マ・ディレクトリサーバプログラム８ｃへ発行する（ス
テップ２５０９）。なお、第３の実施形態においては、
レプリケーションサーバプログラム１０は、ステップ２
５０８では、レプリケーション要求中のControlフィー
ルドに、図２２に示す値を設定する。
【０２４７】続いて、レプリケーションサーバプログラ
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃからの応答を受信し、受信した応答に含まれてい
るリターンコードを取得する（ステップ２５１０）。
ム１０は、コンシューマ・ディレクトリサーバプログラ
ム８ｃからの応答を受信し、受信した応答に含まれてい
るリターンコードを取得する（ステップ２５１０）。
【０２４８】続いて、レプリケーションサーバプログラ
ム１０は、取得したリターンコードが「LDAP_SUCCESS」
であるか否かを判断し（ステップ２５１１）、リターン
コードが「LDAP_SUCCESS」である場合は、アンバインド
要求を作成し、コンシューマ・ディレクトリサーバプロ
グラム８ｃに対して、作成したアンバインド要求を発行
する（ステップ２５１２）。
ム１０は、取得したリターンコードが「LDAP_SUCCESS」
であるか否かを判断し（ステップ２５１１）、リターン
コードが「LDAP_SUCCESS」である場合は、アンバインド
要求を作成し、コンシューマ・ディレクトリサーバプロ
グラム８ｃに対して、作成したアンバインド要求を発行
する（ステップ２５１２）。
【０２４９】そして、コンシューマ・ディレクトリサー
バプログラム８ｃとの間のコネクションを解放すると、
ステップ２５０４に戻って、再度、バインド要求を発行
して、次のセッションを開始する。
バプログラム８ｃとの間のコネクションを解放すると、
ステップ２５０４に戻って、再度、バインド要求を発行
して、次のセッションを開始する。
【０２５０】一方、レプリケーションサーバプログラム
１０は、リターンコードが「LDAP_SUCCESS」でない場合
は、異常終了する（ステップ２５１３）。また、読み出
すべきレプリケーションレコード７０が存在しない場合
は（ステップ２５０６）、アンバインド要求を発行して
セッションを終了してから（ステップ２５０７）、ステ
ップ２５０２に戻って、再度、変更ログファイル２０が
更新されるのを待つ。
１０は、リターンコードが「LDAP_SUCCESS」でない場合
は、異常終了する（ステップ２５１３）。また、読み出
すべきレプリケーションレコード７０が存在しない場合
は（ステップ２５０６）、アンバインド要求を発行して
セッションを終了してから（ステップ２５０７）、ステ
ップ２５０２に戻って、再度、変更ログファイル２０が
更新されるのを待つ。
【０２５１】図２４に、第３の実施形態における拡張機
能を説明するために、コンシューマ・ディレクトリサー
バプログラム８ｃにおける、レプリケーション要求受信
から応答返信までの部分的なフローチャートを示す。
能を説明するために、コンシューマ・ディレクトリサー
バプログラム８ｃにおける、レプリケーション要求受信
から応答返信までの部分的なフローチャートを示す。
【０２５２】図２４に示すように、コンシューマ・ディ
レクトリサーバプログラム８ｃは、レプリケーション要
求を受信すると、このレプリケーション要求を解析する
（ステップ２４０１）。
レクトリサーバプログラム８ｃは、レプリケーション要
求を受信すると、このレプリケーション要求を解析する
（ステップ２４０１）。
【０２５３】続いて、コンシューマ・ディレクトリサー
バプログラム８ｃは、要求内容に基づいた更新要求を、
レプリカデータ９ｃを管理しているデータベースに発行
することで、レプリカデータ９ｃを変更する（ステップ
２４０２）。そして、変更操作に成功したか否かを判断
し（ステップ２４０３）、失敗した場合には、エラー応
答を返す（ステップ２４０９）。
バプログラム８ｃは、要求内容に基づいた更新要求を、
レプリカデータ９ｃを管理しているデータベースに発行
することで、レプリカデータ９ｃを変更する（ステップ
２４０２）。そして、変更操作に成功したか否かを判断
し（ステップ２４０３）、失敗した場合には、エラー応
答を返す（ステップ２４０９）。
【０２５４】また、変更操作に成功した場合には（ステ
ップ２４０３）、受信したレプリケーション要求につい
て、controlTypeの値が、拡張機能を示す識別子であるC
ontrolフィールドを有しているか否かを確認する（ステ
ップ２４０４）。
ップ２４０３）、受信したレプリケーション要求につい
て、controlTypeの値が、拡張機能を示す識別子であるC
ontrolフィールドを有しているか否かを確認する（ステ
ップ２４０４）。
【０２５５】controlTypeの値が、拡張機能を示す識別
子であるControlフィールドを有していない場合は、ス
テップ２４０７に進む。また、controlTypeの値が、拡
張機能を示す識別子であるControlフィールドを有して
いる場合は、レプリケーションレコード識別子１０ｃを
示すlastReplRecord属性値を、controlValueの値に変更
する（ステップ２４０５）。
子であるControlフィールドを有していない場合は、ス
テップ２４０７に進む。また、controlTypeの値が、拡
張機能を示す識別子であるControlフィールドを有して
いる場合は、レプリケーションレコード識別子１０ｃを
示すlastReplRecord属性値を、controlValueの値に変更
する（ステップ２４０５）。
【０２５６】さらに、変更操作に成功した場合には（ス
テップ２４０６）、データベースに対して、その時点ま
でに行われた全ての変更操作を有効化してトランザクシ
ョンを終了するためのコミット（Commit）要求を発行す
る（ステップ２４０７）。そして、最後に、成功したこ
とを示す応答を送信し（ステップ２４０８）、受信した
レプリケーション要求についての処理を終了する。
テップ２４０６）、データベースに対して、その時点ま
でに行われた全ての変更操作を有効化してトランザクシ
ョンを終了するためのコミット（Commit）要求を発行す
る（ステップ２４０７）。そして、最後に、成功したこ
とを示す応答を送信し（ステップ２４０８）、受信した
レプリケーション要求についての処理を終了する。
【０２５７】なお、変更操作に失敗した場合には（ステ
ップ２４０６）、その時点までに行われた全ての変更操
作を無効化してトランザクションを終了するためのロー
ルバック（Rollback）要求を発行して（ステップ２４１
０）、受信したレプリケーション要求を取り消してか
ら、エラー応答を送信する（ステップ２４１１）。
ップ２４０６）、その時点までに行われた全ての変更操
作を無効化してトランザクションを終了するためのロー
ルバック（Rollback）要求を発行して（ステップ２４１
０）、受信したレプリケーション要求を取り消してか
ら、エラー応答を送信する（ステップ２４１１）。
【０２５８】以上説明したように、第３の実施形態によ
れば、第１の実施形態および第２の実施形態の特徴に加
えて、レプリケーションサーバプログラム１０が、ＬＤ
ＡＰの拡張機能であるControlsを用いて、個々のレプリ
ケーション要求に、lastReplRecord属性値の変更指示を
付加するようにしているので、レプリケーション要求以
外に、lastReplRecord属性の変更を要求するためのlast
ReplRecord更新要求を発行する必要がなくなり、ネット
ワークトラフィックの増加を押さえることができる。
れば、第１の実施形態および第２の実施形態の特徴に加
えて、レプリケーションサーバプログラム１０が、ＬＤ
ＡＰの拡張機能であるControlsを用いて、個々のレプリ
ケーション要求に、lastReplRecord属性値の変更指示を
付加するようにしているので、レプリケーション要求以
外に、lastReplRecord属性の変更を要求するためのlast
ReplRecord更新要求を発行する必要がなくなり、ネット
ワークトラフィックの増加を押さえることができる。
【０２５９】
【発明の効果】以上説明したように、本発明によれば、
コンシューマ側のディレクトリサーバが管理するレプリ
カデータ中に、レプリケーションによって最後に変更さ
れたエントリを特定するための情報を記録するようにし
ているので、レプリケーションを行うサーバは、この情
報に基づいて、次にレプリケーションを行うべきエント
リを知ることができ、従って、サプライヤ側のディレク
トリサーバが管理するマスタデータと、コンシューマ側
のディレクトリサーバが管理するレプリカデータとの差
分を認識することができる。
コンシューマ側のディレクトリサーバが管理するレプリ
カデータ中に、レプリケーションによって最後に変更さ
れたエントリを特定するための情報を記録するようにし
ているので、レプリケーションを行うサーバは、この情
報に基づいて、次にレプリケーションを行うべきエント
リを知ることができ、従って、サプライヤ側のディレク
トリサーバが管理するマスタデータと、コンシューマ側
のディレクトリサーバが管理するレプリカデータとの差
分を認識することができる。
【０２６０】そこで、レプリカデータのバックアップを
取っておけば、記録媒体の物理的破損等によりレプリカ
データが失われてしまった場合に、コンシューマ側のデ
ィレクトリサーバが、マスタデータ中の全てのエントリ
をサプライヤ側のディレクトリサーバから取得しなくて
も、バックアップを使用してレプリカデータを再構築す
ることができるようになるので、運用性を向上させるこ
とができるという効果がある。
取っておけば、記録媒体の物理的破損等によりレプリカ
データが失われてしまった場合に、コンシューマ側のデ
ィレクトリサーバが、マスタデータ中の全てのエントリ
をサプライヤ側のディレクトリサーバから取得しなくて
も、バックアップを使用してレプリカデータを再構築す
ることができるようになるので、運用性を向上させるこ
とができるという効果がある。
【０２６１】また、本発明によれば、コンシューマ側の
ディレクトリサーバにおいて、レプリカデータを管理す
るプログラムがトランザクション機能を有するように
し、このトランザクション機能を用いて、エントリの変
更操作および該エントリを示す情報の変更操作を、同一
のトランザクションで処理するようにしているので、レ
プリカデータ、および、レプリカデータ中の最後に変更
されたエントリを特定するための情報の一貫性を保証す
ることができる。
ディレクトリサーバにおいて、レプリカデータを管理す
るプログラムがトランザクション機能を有するように
し、このトランザクション機能を用いて、エントリの変
更操作および該エントリを示す情報の変更操作を、同一
のトランザクションで処理するようにしているので、レ
プリカデータ、および、レプリカデータ中の最後に変更
されたエントリを特定するための情報の一貫性を保証す
ることができる。
【０２６２】従って、任意の時点で予期できない障害に
よりレプリケーションが異常終了してしまった場合で
も、障害の復旧後、レプーリケーションを正常に再開す
ることができるようになるので、運用性を向上させるこ
とができるという効果がある。また、管理者は、レプリ
ケーションがどこまで進行したかを気にする必要がない
ので、管理者の負担を軽減させることができるという効
果がある。
よりレプリケーションが異常終了してしまった場合で
も、障害の復旧後、レプーリケーションを正常に再開す
ることができるようになるので、運用性を向上させるこ
とができるという効果がある。また、管理者は、レプリ
ケーションがどこまで進行したかを気にする必要がない
ので、管理者の負担を軽減させることができるという効
果がある。
【図１】第１の実施形態に係るレプリケーションサービ
スの機能構成を示す説明図。
スの機能構成を示す説明図。
【図２】第１の実施形態に係るディレクトリシステムの
システム構成を示す説明図。
システム構成を示す説明図。
【図３】従来のレプリケーションサービスのシーケンス
を示す説明図。
を示す説明図。
【図４】第１の実施形態および第２の実施形態に係るレ
プリケーションサービスのシーケンスを示す説明図。
プリケーションサービスのシーケンスを示す説明図。
【図５】第１の実施形態におけるエラー回復処理を示す
説明図。
説明図。
【図６】レプリケーション定義ファイルに格納される情
報を示す説明図。
報を示す説明図。
【図７】変更ログファイルに格納される情報を示す説明
図。
図。
【図８】図７に示すレプリケーションレコード中の変更
操作種別が「modify」である場合に、レプリケーション
レコード中の変更内容に設定される情報を示す説明図で
ある。
操作種別が「modify」である場合に、レプリケーション
レコード中の変更内容に設定される情報を示す説明図で
ある。
【図９】図７に示すレプリケーションレコード中の変更
操作種別が「add」である場合に、レプリケーションレ
コード中の変更内容に設定される情報を示す説明図。
操作種別が「add」である場合に、レプリケーションレ
コード中の変更内容に設定される情報を示す説明図。
【図１０】第１の実施形態〜第３の実施形態におけるオ
ブジェクトクラスのサブクラスを示す説明図。
ブジェクトクラスのサブクラスを示す説明図。
【図１１】第１の実施形態〜第３の実施形態におけるレ
プリケーションレコード識別子であるlastReplRecord属
性値の書式を示す説明図。
プリケーションレコード識別子であるlastReplRecord属
性値の書式を示す説明図。
【図１２】レプリケーション状態ファイル２１に格納さ
れる情報を示す説明図。
れる情報を示す説明図。
【図１３】Group１に属するＬＤＡＰリターンコードを
示す説明図。
示す説明図。
【図１４】Group２に属するＬＤＡＰリターンコードを
示す説明図。
示す説明図。
【図１５】第１の実施形態におけるレプリケーションサ
ーバプログラムの処理の流れを示すフローチャート。
ーバプログラムの処理の流れを示すフローチャート。
【図１６】第１の実施形態〜第３の実施形態における変
更ログ取得プログラムの処理の流れを示すフローチャー
ト。
更ログ取得プログラムの処理の流れを示すフローチャー
ト。
【図１７】第１の実施形態におけるエラー判定プログラ
ムの処理の流れを示すフローチャート。
ムの処理の流れを示すフローチャート。
【図１８】第１の実施形態におけるレプリケーション状
態記録プログラムの処理の流れを示すフローチャート。
態記録プログラムの処理の流れを示すフローチャート。
【図１９】第２の実施形態におけるレプリケーションサ
ーバプログラムの処理の流れを示すフローチャート。
ーバプログラムの処理の流れを示すフローチャート。
【図２０】ＬＤＡＰで規定されるＬＤＡＰアクセス要求
の表記を示す説明図。
の表記を示す説明図。
【図２１】ＬＤＡＰで規定されるControlsの表記を示す
説明図。
説明図。
【図２２】第３の実施形態におけるレプリケーション要
求が含むControlフィールドに設定される情報を示す説
明図。
求が含むControlフィールドに設定される情報を示す説
明図。
【図２３】第３の実施形態に係るレプリケーションサー
ビスのシーケンスを示す説明図。
ビスのシーケンスを示す説明図。
【図２４】第３の実施形態におけるコンシューマ・ディ
レクトリサーバプログラムが行う、レプリケーション要
求受信から応答返信までの部分的な処理の流れを示すフ
ローチャート。
レクトリサーバプログラムが行う、レプリケーション要
求受信から応答返信までの部分的な処理の流れを示すフ
ローチャート。
【図２５】第３の実施形態におけるレプリケーションサ
ーバプログラムの処理の流れを示すフローチャート。
ーバプログラムの処理の流れを示すフローチャート。
【図２６】第３の実施形態に係るレプリケーションサー
ビスの機能構成を示す説明図。
ビスの機能構成を示す説明図。
【図２７】第３の実施形態に係るディレクトリシステム
のシステム構成を示す説明図。
のシステム構成を示す説明図。
【図２８】第２の実施形態におけるレプリケーション状
態記録プログラムの処理の流れを示すフローチャート。
態記録プログラムの処理の流れを示すフローチャート。
１ｓ…第１のディレクトリサーバ、１ｃ…第２のディレ
クトリサーバ、２ｓ，２ｃ…中央処理装置（ＣＰＵ）、
３ｓ，３ｃ…メモリ、４ｓ，４ｃ…磁気ディスク、５
ｓ，５ｃ…ディスクコントローラ、６ｓ，６ｃ…ＬＡＮ
コントローラ、７ｓ，７ｃ…オペレーティングシステム
（ＯＳ）、８ｓ…サプライヤ・ディレクトリサーバプロ
グラム、８ｃ…コンシューマ・ディレクトリサーバプロ
グラム、９ｓ…マスタデータ、９ｃ…レプリカデータ、
１０…レプリケーションサーバプログラム、１１…変更
ログ取得プログラム、１２…リクエスト生成プログラ
ム、１３…エラー判定プログラム、１４…通信制御プロ
グラム、１５…レプリケーション状態記録プログラム、
１９…レプリケーション定義ファイル、２０…変更ログ
ファイル、２１…レプリケーション状態ファイル、１０
ｃ…レプリケーションレコード識別子、８ｓ′…サプラ
イヤ・ディレクトリサービス、８ｃ′…コンシューマ・
ディレクトリサービス、１０′…レプリケーションサー
ビス、１１′…変更ログ取得部、１２′…リクエスト生
成部、１３′…エラー判定部、１４′…通信制御部、１
５′…レプリケーション状態記録部、２０′…変更ロ
グ、８０…拡張プログラム、８０′…拡張部、１００…
ローカルエリアネットワーク（ＬＡＮ）。
クトリサーバ、２ｓ，２ｃ…中央処理装置（ＣＰＵ）、
３ｓ，３ｃ…メモリ、４ｓ，４ｃ…磁気ディスク、５
ｓ，５ｃ…ディスクコントローラ、６ｓ，６ｃ…ＬＡＮ
コントローラ、７ｓ，７ｃ…オペレーティングシステム
（ＯＳ）、８ｓ…サプライヤ・ディレクトリサーバプロ
グラム、８ｃ…コンシューマ・ディレクトリサーバプロ
グラム、９ｓ…マスタデータ、９ｃ…レプリカデータ、
１０…レプリケーションサーバプログラム、１１…変更
ログ取得プログラム、１２…リクエスト生成プログラ
ム、１３…エラー判定プログラム、１４…通信制御プロ
グラム、１５…レプリケーション状態記録プログラム、
１９…レプリケーション定義ファイル、２０…変更ログ
ファイル、２１…レプリケーション状態ファイル、１０
ｃ…レプリケーションレコード識別子、８ｓ′…サプラ
イヤ・ディレクトリサービス、８ｃ′…コンシューマ・
ディレクトリサービス、１０′…レプリケーションサー
ビス、１１′…変更ログ取得部、１２′…リクエスト生
成部、１３′…エラー判定部、１４′…通信制御部、１
５′…レプリケーション状態記録部、２０′…変更ロ
グ、８０…拡張プログラム、８０′…拡張部、１００…
ローカルエリアネットワーク（ＬＡＮ）。
Claims (14)
- 【請求項１】ディレクトリデータのマスタデータを管理
し、上記マスタデータを変更した際の操作の履歴情報を
記憶保持する第１のディレクトリサーバと、上記マスタ
データの複製であるレプリカデータを管理する１つ以上
の第２のディレクトリサーバとが、少なくともネットワ
ークで接続されたディレクトリシステムにおいて、 上記マスタデータと上記レプリカデータとを同一の内容
に保つレプリケーション方法であって、 上記第１のディレクトリサーバ、および、上記ネットワ
ークに接続される別のサーバのうちのいずれか一方のサ
ーバ（以下、「レプリケーションサーバ」と称す。）
は、 上記第１のディレクトリサーバが記憶保持している履歴
情報のうちから、処理対象となる履歴情報を取得し、 取得した履歴情報に対応する操作と同一の操作を上記レ
プリカデータについて行う旨を要求するディレクトリア
クセス要求（以下、「レプリケーション要求」と称
す。）を、上記第２のディレクトリサーバへ発行し、 上記レプリケーション要求に従って行われた上記第２の
ディレクトリサーバの操作が成功した場合に、該操作に
対応する履歴情報を特定するための識別情報を、該第２
のディレクトリサーバが管理するレプリカデータ中に記
録し、 上記第１のディレクトリサーバが記憶保持している履歴
情報のうちから、処理対象となる履歴情報を取得する際
に、上記第２のディレクトリサーバが管理するレプリカ
データ中に記録されている識別情報を参照して、取得す
べき履歴情報を決定することを特徴とするレプリケーシ
ョン方法。 - 【請求項２】請求項１記載のレプリケーション方法であ
って、 上記レプリケーションサーバは、 上記識別情報を検索するという操作を行う旨を要求する
ディレクトリアクセス要求を、上記第２のディレクトリ
サーバへ発行することで、該第２のディレクトリサーバ
が管理するレプリカデータ中に記録されている識別情報
を参照することを特徴とするレプリケーション方法。 - 【請求項３】請求項１または２記載のレプリケーション
方法であって、 上記レプリケーションサーバは、 上記識別情報を記録するという操作を行う旨を要求する
ディレクトリアクセス要求を、上記第２のディレクトリ
サーバへ発行することで、該第２のディレクトリサーバ
が管理するレプリカデータ中に該識別情報を記録するこ
とを特徴とするレプリケーション方法。 - 【請求項４】請求項１，２または３記載のレプリケーシ
ョン方法であって、 上記レプリケーションサーバは、 上記レプリケーション要求に従って行われた上記第２の
ディレクトリサーバの操作が失敗した場合でも、該レプ
リケーション要求と同一のレプリケーション要求を２回
以上連続して発行したことによって生じた失敗であり、
かつ、該レプリケーション要求と同一のレプリケーショ
ン要求を該第２のディレクトリサーバが以前に受信して
いるならば、成功したとみなすことを特徴とするレプリ
ケーション方法。 - 【請求項５】請求項１または２記載のレプリケーション
方法であって、 上記第２のディレクトリサーバは、 受信したディレクトリアクセス要求中に予め定義された
特定フィールドの設定内容に従って、予め定義された特
定操作を行い、 上記レプリケーションサーバは、 上記レプリケーション要求中の特定フィールドに、上記
識別情報を記録するという特定操作を上記第２のディレ
クトリサーバが行うために必要な情報を設定すること
で、該第２のディレクトリサーバが管理するレプリカデ
ータ中に該識別情報を記録することを特徴とするレプリ
ケーション方法。 - 【請求項６】請求項３または５記載のレプリケーション
方法であって、 上記第２のディレクトリサーバは、 上記レプリケーション要求に従った操作、および、上記
識別情報を記録するという操作を、同一のトランザクシ
ョンとして処理することを特徴とするレプリケーション
方法。 - 【請求項７】請求項１，２，３，４，５または６記載の
レプリケーション方法であって、 上記第１のディレクトリサーバおよび上記第２のディレ
クトリサーバは、 １つのオブジェクトクラスに属し、かつ、１つ以上の属
性を有するオブジェクトとして、上記マスタデータおよ
び上記レプリカデータを構成するエントリの各々を管理
し、 上記識別情報は、 予め定義された特定オブジェクトクラスに属し、かつ、
予め定義された特定属性を有するオブジェクトとして管
理されるエントリ中に、該特定属性の属性値として記録
されることを特徴とするレプリケーション方法。 - 【請求項８】ディレクトリデータのマスタデータを管理
し、上記マスタデータを変更した際の操作の履歴情報を
記憶保持する第１のディレクトリサーバと、上記マスタ
データの複製であるレプリカデータを管理する１つ以上
の第２のディレクトリサーバとが、少なくともネットワ
ークで接続されたディレクトリシステムにおいて、 上記第１のディレクトリサーバ、および、上記ネットワ
ークに接続される別のサーバのうちのいずれか一方のサ
ーバ（以下、「レプリケーションサーバ」と称す。）に
インストールされ、上記マスタデータと上記レプリカデ
ータとを同一の内容に保つレプリケーションツールであ
って、 上記第１のディレクトリサーバが記憶保持している履歴
情報のうちから、処理対象となる履歴情報を取得する履
歴情報取得手段と、 上記履歴情報取得手段が取得した履歴情報に対応する操
作と同一の操作を上記レプリカデータについて行う旨を
要求するディレクトリアクセス要求（以下、「レプリケ
ーション要求」と称す。）を、上記第２のディレクトリ
サーバへ発行するレプリケーション要求発行手段と、 上記レプリケーション要求発行手段が発行したレプリケ
ーション要求に従って行われた上記第２のディレクトリ
サーバの操作が成功した場合に、該操作に対応する履歴
情報を特定するための識別情報を、該第２のディレクト
リサーバが管理するレプリカデータ中に記録する識別情
報記録手段とを有するよう、上記レプリケーションサー
バを機能させ、 上記履歴情報取得手段は、 上記第２のディレクトリサーバが管理するレプリカデー
タ中に記録されている識別情報を参照して、取得すべき
履歴情報を決定することを特徴とするレプリケーション
ツール。 - 【請求項９】請求項８記載のレプリケーションツールで
あって、 上記履歴情報が、対応する操作の実行順序を示す順序情
報を含む場合に、 上記識別情報記録手段は、 記録すべき識別情報として上記順序情報を用い、 上記履歴情報取得手段は、 参照した識別情報に含まれる順序情報が示す実行順序よ
り後の実行順序を示す順序情報が含まれる履歴情報のう
ちの、最も早い実行順序を示す順序情報が含まれる履歴
情報を、取得すべき履歴情報として決定することを特徴
とするレプリケーションツール。 - 【請求項１０】請求項８または９記載のレプリケーショ
ンツールであって、 上記履歴情報取得手段は、 上記識別情報を検索するという操作を行う旨を要求する
ディレクトリアクセス要求を、上記第２のディレクトリ
サーバへ発行することで、該第２のディレクトリサーバ
が管理するレプリカデータ中に記録されている識別情報
を参照することを特徴とするレプリケーションツール。 - 【請求項１１】請求項８，９または１０記載のレプリケ
ーションツールであって、 上記識別情報記録手段は、 上記識別情報を記録するという操作を行う旨を要求する
ディレクトリアクセス要求を、上記第２のディレクトリ
サーバへ発行することで、該第２のディレクトリサーバ
が管理するレプリカデータ中に該識別情報を記録するこ
とを特徴とするレプリケーションツール。 - 【請求項１２】請求項８，９，１０または１１記載のレ
プリケーションツールであって、 上記レプリケーション要求発行手段が発行したレプリケ
ーション要求に従って行われた上記第２のディレクトリ
サーバの操作が失敗した場合でも、該レプリケーション
要求と同一のレプリケーション要求を２回以上連続して
発行したことによって生じた失敗であり、かつ、該レプ
リケーション要求と同一のレプリケーション要求を該第
２のディレクトリサーバが以前に受信しているならば、
成功したとみなすエラー判定手段をさらに有するよう、
上記レプリケーションサーバを機能させることを特徴と
するレプリケーションツール。 - 【請求項１３】請求項８，９または１０記載のレプリケ
ーションツールであって、 上記第２のディレクトリサーバが、受信したディレクト
リアクセス要求中に予め定義された特定フィールドの設
定内容に従って、予め定義された特定操作を行うことが
可能なディレクトリサーバである場合に、 上記識別情報記録手段は、 上記レプリケーション要求発行手段が発行するレプリケ
ーション要求中の特定フィールドに、上記識別情報を記
録するという特定操作を上記第２のディレクトリサーバ
が行うために必要な情報を設定することで、該第２のデ
ィレクトリサーバが管理するレプリカデータ中に該識別
情報を記録することを特徴とするレプリケーションツー
ル。 - 【請求項１４】ディレクトリデータのマスタデータを管
理し、上記マスタデータを変更した際の操作の履歴情報
を記憶保持する第１のディレクトリサーバと、上記マス
タデータの複製であるレプリカデータを管理する１つ以
上の第２のディレクトリサーバとが、少なくともネット
ワークで接続されたディレクトリシステムにおいて用い
られ、 上記マスタデータと上記レプリカデータとを同一の内容
に保つレプリケーションサーバであって、 上記第１のディレクトリサーバが記憶保持している履歴
情報のうちから、処理対象となる履歴情報を取得する履
歴情報取得手段と、 上記履歴情報取得手段が取得した履歴情報に対応する操
作と同一の操作を上記レプリカデータについて行う旨を
要求するディレクトリアクセス要求（以下、「レプリケ
ーション要求」と称す。）を、上記第２のディレクトリ
サーバへ発行するレプリケーション要求発行手段と、 上記レプリケーション要求発行手段が発行したレプリケ
ーション要求に従って行われた上記第２のディレクトリ
サーバの操作が成功した場合に、該操作に対応する履歴
情報を特定するための識別情報を、該第２のディレクト
リサーバが管理するレプリカデータ中に記録する識別情
報記録手段とを有し、 上記履歴情報取得手段は、 上記第２のディレクトリサーバが管理するレプリカデー
タ中に記録されている識別情報を参照して、取得すべき
履歴情報を決定することを特徴とするレプリケーション
サーバ。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP9334333A JPH11167510A (ja) | 1997-12-04 | 1997-12-04 | レプリケーション方法、レプリケーションツール、および、レプリケーションサーバ |
| US09/203,570 US6301589B1 (en) | 1997-12-04 | 1998-12-02 | Replication method |
| US09/969,727 US20020059329A1 (en) | 1997-12-04 | 2001-10-04 | Replication method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP9334333A JPH11167510A (ja) | 1997-12-04 | 1997-12-04 | レプリケーション方法、レプリケーションツール、および、レプリケーションサーバ |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH11167510A true JPH11167510A (ja) | 1999-06-22 |
Family
ID=18276193
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP9334333A Pending JPH11167510A (ja) | 1997-12-04 | 1997-12-04 | レプリケーション方法、レプリケーションツール、および、レプリケーションサーバ |
Country Status (2)
| Country | Link |
|---|---|
| US (2) | US6301589B1 (ja) |
| JP (1) | JPH11167510A (ja) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001014205A (ja) * | 1999-06-30 | 2001-01-19 | Jisedai Joho Hoso System Kenkyusho:Kk | 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法 |
| JP2001014206A (ja) * | 1999-06-30 | 2001-01-19 | Jisedai Joho Hoso System Kenkyusho:Kk | 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法 |
| WO2001042924A1 (en) * | 1999-12-13 | 2001-06-14 | Kabushiki Kaisha Toshiba | Data structure managing device, data structure managing system, data structure managing method, and recorded medium where data structure managing program is stored |
| JP2002132568A (ja) * | 2000-10-30 | 2002-05-10 | Nec Corp | 顧客管理システム及び顧客管理方法 |
| JP2002149465A (ja) * | 2000-11-09 | 2002-05-24 | Nec Informatec Systems Ltd | 情報共有システム |
| JP2009116722A (ja) * | 2007-11-08 | 2009-05-28 | Nec Corp | ストレージ装置およびタイムスタンプの付与方法 |
| JP2016053814A (ja) * | 2014-09-03 | 2016-04-14 | 富士通株式会社 | データ検索制御プログラム、コンピュータ、およびデータ検索制御方法 |
| JP2018169791A (ja) * | 2017-03-30 | 2018-11-01 | 日本電気株式会社 | 情報管理方法および情報処理システム |
| JP2021532465A (ja) * | 2018-08-02 | 2021-11-25 | ヒタチ ヴァンタラ エルエルシー | サーバ情報の分散回復 |
| US11561958B2 (en) | 2020-04-20 | 2023-01-24 | Fujitsu Limited | Information processing device and information processing system |
Families Citing this family (63)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6412017B1 (en) | 1996-07-01 | 2002-06-25 | Microsoft Corporation | Urgent replication facility |
| JP3792419B2 (ja) * | 1998-11-27 | 2006-07-05 | 株式会社日立製作所 | ディレクトリデータ変換方法、ディレクトリデータ変換プログラムが記憶された記憶媒体、およびディレクトリ変換サーバ |
| US7801913B2 (en) * | 1998-12-07 | 2010-09-21 | Oracle International Corporation | System and method for querying data for implicit hierarchies |
| US6587856B1 (en) | 1998-12-07 | 2003-07-01 | Oracle International Corporation | Method and system for representing and accessing object-oriented data in a relational database system |
| US6748374B1 (en) | 1998-12-07 | 2004-06-08 | Oracle International Corporation | Method for generating a relational database query statement using one or more templates corresponding to search conditions in an expression tree |
| US6473829B1 (en) * | 1999-05-28 | 2002-10-29 | International Business Machines Corporation | Data storage device providing communication between processing units |
| US6859821B1 (en) * | 1999-07-19 | 2005-02-22 | Groove Networks, Inc. | Method and apparatus for prioritizing data change requests and maintaining data consistency in a distributed computer system equipped for activity-based collaboration |
| US6615223B1 (en) * | 2000-02-29 | 2003-09-02 | Oracle International Corporation | Method and system for data replication |
| DE10102649B4 (de) * | 2000-03-30 | 2006-05-24 | International Business Machines Corp. | System und Verfahren für die Realisierung von Transaktionen mit Unterstützung durch ein Verzeichniszugriffs-LDAP-Protokoll |
| US6542907B1 (en) * | 2000-03-31 | 2003-04-01 | International Business Machines Corporation | Method and apparatus for decentralized, invertible generation of bounded-length globally unique replica identifiers |
| US6957234B1 (en) * | 2000-05-26 | 2005-10-18 | I2 Technologies Us, Inc. | System and method for retrieving data from a database using a data management system |
| US7162499B2 (en) * | 2000-06-21 | 2007-01-09 | Microsoft Corporation | Linked value replication |
| US6505200B1 (en) * | 2000-07-06 | 2003-01-07 | International Business Machines Corporation | Application-independent data synchronization technique |
| US6704885B1 (en) * | 2000-07-28 | 2004-03-09 | Oracle International Corporation | Performing data backups with a stochastic scheduler in a distributed computing environment |
| US7016897B2 (en) * | 2000-12-29 | 2006-03-21 | International Business Machines Corporation | Authentication referral search for LDAP |
| US6879564B2 (en) * | 2001-02-28 | 2005-04-12 | Microsoft Corp. | Method for designating communication paths in a network |
| US6728849B2 (en) | 2001-12-14 | 2004-04-27 | Hitachi, Ltd. | Remote storage system and method |
| US7398302B2 (en) * | 2001-03-30 | 2008-07-08 | Hitachi, Ltd. | Remote copy with path selection and prioritization |
| US7437437B2 (en) * | 2001-04-25 | 2008-10-14 | Hewlett-Packard Development Company, L.P. | Access authentication for distributed networks |
| US7702791B2 (en) * | 2001-07-16 | 2010-04-20 | Bea Systems, Inc. | Hardware load-balancing apparatus for session replication |
| US7409420B2 (en) * | 2001-07-16 | 2008-08-05 | Bea Systems, Inc. | Method and apparatus for session replication and failover |
| EP1415236B1 (en) * | 2001-07-16 | 2018-04-18 | Oracle International Corporation | Method and apparatus for session replication and failover |
| US9659292B1 (en) * | 2001-08-30 | 2017-05-23 | EMC IP Holding Company LLC | Storage-based replication of e-commerce transactions in real time |
| US20030088654A1 (en) * | 2001-11-02 | 2003-05-08 | Gordon Good | Directory server schema replication |
| US7035922B2 (en) * | 2001-11-27 | 2006-04-25 | Microsoft Corporation | Non-invasive latency monitoring in a store-and-forward replication system |
| US7185359B2 (en) * | 2001-12-21 | 2007-02-27 | Microsoft Corporation | Authentication and authorization across autonomous network systems |
| US7024429B2 (en) | 2002-01-31 | 2006-04-04 | Nextpage,Inc. | Data replication based upon a non-destructive data model |
| US7376708B2 (en) * | 2002-01-31 | 2008-05-20 | Claredi Corporation | Systems and methods relating to the establishment of EDI trading partner relationships |
| US7107355B2 (en) * | 2002-02-11 | 2006-09-12 | Sun Microsystems, Inc. | High availability lightweight directory access protocol service |
| US20030191781A1 (en) * | 2002-04-03 | 2003-10-09 | Seyhan Civanlar | Directory-based service activation system and method |
| US7600021B2 (en) * | 2002-04-03 | 2009-10-06 | Microsoft Corporation | Delta replication of source files and packages across networked resources |
| JP2004334574A (ja) * | 2003-05-08 | 2004-11-25 | Hitachi Ltd | ストレージの運用管理プログラム、運用管理方法及び管理計算機 |
| GB2401693B (en) * | 2003-05-15 | 2005-08-17 | Sun Microsystems Inc | Conflictless replication in a multi-master directory system |
| GB2402297B (en) * | 2003-05-15 | 2005-08-17 | Sun Microsystems Inc | Update dependency control for multi-master replication |
| US7203687B2 (en) * | 2004-02-26 | 2007-04-10 | International Business Machines Corporation | Peer-to-peer replication member initialization and deactivation |
| US7490083B2 (en) | 2004-02-27 | 2009-02-10 | International Business Machines Corporation | Parallel apply processing in data replication with preservation of transaction integrity and source ordering of dependent updates |
| US8688634B2 (en) * | 2004-02-27 | 2014-04-01 | International Business Machines Corporation | Asynchronous peer-to-peer data replication |
| JP4489500B2 (ja) * | 2004-05-26 | 2010-06-23 | 株式会社日立製作所 | バックアップ方法、バックアップシステム、ディスク制御装置、及びバックアッププログラム |
| US8244913B1 (en) | 2004-10-13 | 2012-08-14 | Progress Software Corporation | Replication horizon determination with an independent distributed database system |
| US9020887B2 (en) | 2004-12-21 | 2015-04-28 | Proofpoint, Inc. | Managing the status of documents in a distributed storage system |
| WO2007032046A1 (ja) * | 2005-09-12 | 2007-03-22 | Fujitsu Limited | Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法 |
| US7370235B1 (en) * | 2005-09-29 | 2008-05-06 | Emc Corporation | System and method for managing and scheduling recovery after a failure in a data storage environment |
| US8935429B2 (en) | 2006-12-19 | 2015-01-13 | Vmware, Inc. | Automatically determining which remote applications a user or group is entitled to access based on entitlement specifications and providing remote application access to the remote applications |
| US7779091B2 (en) | 2005-12-19 | 2010-08-17 | Vmware, Inc. | Method and system for providing virtualized application workspaces |
| US20080033966A1 (en) * | 2006-08-04 | 2008-02-07 | Mark Frederick Wahl | System and method for recovery detection in a distributed directory service |
| US20080059941A1 (en) * | 2006-08-30 | 2008-03-06 | Timothy Payne | Method and system for supporting a collaborative development environment |
| US7797281B1 (en) * | 2007-01-12 | 2010-09-14 | Symantec Operating Corporation | Granular restore of data objects from a directory service |
| US20080270596A1 (en) * | 2007-04-25 | 2008-10-30 | Mark Frederick Wahl | System and method for validating directory replication |
| CN101295306B (zh) * | 2007-04-26 | 2012-09-05 | 国际商业机器公司 | 目录服务器中的修改条目名称操作方法和相应设备 |
| US8019727B2 (en) * | 2007-09-26 | 2011-09-13 | Symantec Corporation | Pull model for file replication at multiple data centers |
| CN101933014B (zh) * | 2007-09-28 | 2013-11-20 | 阿珀蒂奥有限公司 | 用于复制和同步的系统和方法 |
| US9143559B2 (en) * | 2007-12-05 | 2015-09-22 | International Business Machines Corporation | Directory server replication |
| US8150802B2 (en) * | 2008-03-24 | 2012-04-03 | Microsoft Corporation | Accumulating star knowledge in replicated data protocol |
| US8135838B2 (en) * | 2008-04-08 | 2012-03-13 | Geminare Incorporated | System and method for providing data and application continuity in a computer system |
| US8352482B2 (en) * | 2009-07-21 | 2013-01-08 | Vmware, Inc. | System and method for replicating disk images in a cloud computing based virtual machine file system |
| US8234518B2 (en) * | 2009-07-21 | 2012-07-31 | Vmware, Inc. | Method for voting with secret shares in a distributed system |
| US8352490B2 (en) | 2009-10-22 | 2013-01-08 | Vmware, Inc. | Method and system for locating update operations in a virtual machine disk image |
| US8190947B1 (en) * | 2010-02-11 | 2012-05-29 | Network Appliance, Inc. | Method and system for automatically constructing a replica catalog for maintaining protection relationship information between primary and secondary storage objects in a network storage system |
| US8341134B2 (en) | 2010-12-10 | 2012-12-25 | International Business Machines Corporation | Asynchronous deletion of a range of messages processed by a parallel database replication apply process |
| US20130262393A1 (en) * | 2012-03-30 | 2013-10-03 | Matevz Mrak | Database backup without particularly specifying server |
| US9727625B2 (en) | 2014-01-16 | 2017-08-08 | International Business Machines Corporation | Parallel transaction messages for database replication |
| US9218407B1 (en) | 2014-06-25 | 2015-12-22 | Pure Storage, Inc. | Replication and intermediate read-write state for mediums |
| US10650024B2 (en) * | 2015-07-30 | 2020-05-12 | Google Llc | System and method of replicating data in a distributed system |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3345025B2 (ja) | 1991-01-16 | 2002-11-18 | 富士ゼロックス株式会社 | 分散ディレクトリの知識整合システム |
| US5392390A (en) * | 1992-04-10 | 1995-02-21 | Intellilink Corp. | Method for mapping, translating, and dynamically reconciling data between disparate computer platforms |
| US6604118B2 (en) * | 1998-07-31 | 2003-08-05 | Network Appliance, Inc. | File system image transfer |
| US5684990A (en) * | 1995-01-11 | 1997-11-04 | Puma Technology, Inc. | Synchronization of disparate databases |
| US5956489A (en) * | 1995-06-07 | 1999-09-21 | Microsoft Corporation | Transaction replication system and method for supporting replicated transaction-based services |
| US6097882A (en) * | 1995-06-30 | 2000-08-01 | Digital Equipment Corporation | Method and apparatus of improving network performance and network availability in a client-server network by transparently replicating a network service |
| US5978813A (en) * | 1995-09-25 | 1999-11-02 | International Business Machines Corporation | System for providing synchronization between a local area network and a distributing computer environment |
| US5819020A (en) * | 1995-10-16 | 1998-10-06 | Network Specialists, Inc. | Real time backup system |
| US5765171A (en) * | 1995-12-29 | 1998-06-09 | Lucent Technologies Inc. | Maintaining consistency of database replicas |
| US5706510A (en) * | 1996-03-15 | 1998-01-06 | Hewlett-Packard Company | Zymbolic history management system |
| US6049809A (en) * | 1996-10-30 | 2000-04-11 | Microsoft Corporation | Replication optimization system and method |
| US6330568B1 (en) * | 1996-11-13 | 2001-12-11 | Pumatech, Inc. | Synchronization of databases |
| AU6151598A (en) * | 1997-02-11 | 1998-08-26 | Connected Corporation | File comparison for data backup and file synchronization |
| US6411966B1 (en) * | 1998-09-21 | 2002-06-25 | Microsoft Corporation | Method and computer readable medium for DNS dynamic update to minimize client-server and incremental zone transfer traffic |
-
1997
- 1997-12-04 JP JP9334333A patent/JPH11167510A/ja active Pending
-
1998
- 1998-12-02 US US09/203,570 patent/US6301589B1/en not_active Expired - Fee Related
-
2001
- 2001-10-04 US US09/969,727 patent/US20020059329A1/en not_active Abandoned
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001014205A (ja) * | 1999-06-30 | 2001-01-19 | Jisedai Joho Hoso System Kenkyusho:Kk | 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法 |
| JP2001014206A (ja) * | 1999-06-30 | 2001-01-19 | Jisedai Joho Hoso System Kenkyusho:Kk | 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法 |
| WO2001042924A1 (en) * | 1999-12-13 | 2001-06-14 | Kabushiki Kaisha Toshiba | Data structure managing device, data structure managing system, data structure managing method, and recorded medium where data structure managing program is stored |
| US7222125B2 (en) | 1999-12-13 | 2007-05-22 | Kabushiki Kaisha Toshiba | Data structure managing device, data structure managing system, data structure managing method, and recorded medium where data structure managing program is stored |
| JP2002132568A (ja) * | 2000-10-30 | 2002-05-10 | Nec Corp | 顧客管理システム及び顧客管理方法 |
| JP2002149465A (ja) * | 2000-11-09 | 2002-05-24 | Nec Informatec Systems Ltd | 情報共有システム |
| JP2009116722A (ja) * | 2007-11-08 | 2009-05-28 | Nec Corp | ストレージ装置およびタイムスタンプの付与方法 |
| JP2016053814A (ja) * | 2014-09-03 | 2016-04-14 | 富士通株式会社 | データ検索制御プログラム、コンピュータ、およびデータ検索制御方法 |
| JP2018169791A (ja) * | 2017-03-30 | 2018-11-01 | 日本電気株式会社 | 情報管理方法および情報処理システム |
| JP2021532465A (ja) * | 2018-08-02 | 2021-11-25 | ヒタチ ヴァンタラ エルエルシー | サーバ情報の分散回復 |
| US11561958B2 (en) | 2020-04-20 | 2023-01-24 | Fujitsu Limited | Information processing device and information processing system |
Also Published As
| Publication number | Publication date |
|---|---|
| US6301589B1 (en) | 2001-10-09 |
| US20020059329A1 (en) | 2002-05-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6301589B1 (en) | Replication method | |
| JP3782932B2 (ja) | ファイルをバックアップするための方法、システム及びプログラム記録媒体 | |
| US5659682A (en) | Scheme to determine completion of directory operations for server recovery | |
| US6539381B1 (en) | System and method for synchronizing database information | |
| US20060288056A1 (en) | File version management device, method, and program | |
| JP4222642B2 (ja) | ローカル・エリア・ネットワークと分散コンピューティング環境との間の同期化をするシステム | |
| JP4732661B2 (ja) | クライアントのデータベースとサーバーのデータベースとを同期させる方法 | |
| CN101253484B (zh) | 一种用于保存来自客户端的数据的方法及一种客户端 | |
| JP4590105B2 (ja) | ウェブサーバコンテンツ複製 | |
| US7600087B2 (en) | Distributed remote copy system | |
| EP1271321A1 (en) | System and method for recovering from a failed synchronization session | |
| JP2008033912A (ja) | Ｎａｓ向けのｃｄｐの方法および装置 | |
| WO2003096231A1 (en) | Database scattering system | |
| JPH0922374A (ja) | 異種ファイルへのアクセスを可能とする情報処理システム及びその制御方法 | |
| WO2007068600A2 (en) | Generating backup sets to a specific point in time | |
| JPH0962526A (ja) | 耐故障型ｒｐｃシステムおよび方法 | |
| JP2008197745A (ja) | ストレージ仮想化システムにおける記憶制御装置 | |
| CN114528260A (zh) | 文件访问请求的处理方法、电子设备及计算机程序产品 | |
| JP2000315157A (ja) | プログラム更新／回復方法 | |
| JP2001060175A (ja) | 情報処理システムのデータ保守方法 | |
| JP2000082003A (ja) | 異種ファイルへのアクセスを可能とする情報処理システム及びその制御方法 | |
| JP5418070B2 (ja) | 業務操作支援方法及びコンピュータ装置 | |
| JP3776769B2 (ja) | ファイルサーバシステムおよびその制御方法 | |
| JP2938860B1 (ja) | 分散型データ管理システム | |
| JPH0887410A (ja) | プログラム更新／回復方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050524 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20051018 |