JP7428894B2 - 情報処理装置、情報処理システム、及び情報処理プログラム - Google Patents

情報処理装置、情報処理システム、及び情報処理プログラム Download PDF

Info

Publication number
JP7428894B2
JP7428894B2 JP2020074859A JP2020074859A JP7428894B2 JP 7428894 B2 JP7428894 B2 JP 7428894B2 JP 2020074859 A JP2020074859 A JP 2020074859A JP 2020074859 A JP2020074859 A JP 2020074859A JP 7428894 B2 JP7428894 B2 JP 7428894B2
Authority
JP
Japan
Prior art keywords
data
record
server
difference
database
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.)
Active
Application number
JP2020074859A
Other languages
English (en)
Other versions
JP2021174065A (ja
Inventor
隆 秋山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2020074859A priority Critical patent/JP7428894B2/ja
Priority to US17/156,673 priority patent/US11561958B2/en
Publication of JP2021174065A publication Critical patent/JP2021174065A/ja
Application granted granted Critical
Publication of JP7428894B2 publication Critical patent/JP7428894B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/219—Managing data history or versioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、情報処理装置、情報処理システム、及び情報処理プログラムに関する。
データベースを参照する際の負荷分散等を実現するために、当該データベースの内容を複製したデータベースを作成することがある。この場合、複製元のデータベースはマスタDB(database)と呼ばれ、複製先のデータベースはレプリカDBと呼ばれる。
データベースを参照するクライアント端末が複数存在する場合、マスタDBだけでなくレプリカDBにも各クライアント端末が参照することによりマスタDBの負荷分散を実現できる。
しかし、レプリカDBを利用するシステムにおいては、マスタDBからレプリカDBを複製するときのレスポンスタイムを短くするという点で改善の余地がある。
特開平１１－１６７５１０号公報 特開平１０－４９４１６号公報
一側面によれば、レスポンスタイムを短くすることを目的とする。
一側面によれば、第１のデータベースの複数のレコードの各々を複数のサーバが操作した後の該レコードのデータと、前記操作が行われた順序を示す識別子とを対応付けて記憶した、複数の前記サーバごとに設けられた複数の第２のデータベースから、第１の期間に記憶された前記データを取得するデータ取得部と、取得した前記データを、前記識別子が示す順に第３のデータベースに格納するデータ格納部と、を有し、前記データ格納部は、同一の前記レコードの前記データが複数の前記第２のデータベースに存在する場合に、同一の前記レコードの前記データのうちで、最後に操作された前記レコードの前記データのみを前記第３のデータベースに格納することを特徴とする情報処理装置が提供される。
一側面によれば、レスポンスタイムの低下を抑制することができる。
図１は、検討に使用したシステムの構成図である。 図２は、検討に使用したシステムにおける処理の流れを示す模式図である。 図３は、検討に使用したシステムにおける処理の流れを示す模式図である。 図４は、排他制御の模式図である。 図５は、本実施形態に係る情報処理システムのシステム構成図である。 図６は、本実施形態に係るディスク装置の模式図である。 図７は、本実施形態におけるマスタDBの内容を示す模式図である。 図８（ａ）は、本実施形態に係る第１の採番DBの内容について示す模式図であり、図８（ｂ）は、本実施形態に係るチェックポイントDBの内容について示す模式図である。 図９は、本実施形態に係る第１の差分DBの内容について示す模式図である。 図１０は、本実施形態に係る情報処理システムの処理の流れを示す模式図である。 図１１は、本実施形態において、マスタDBの同一レコードに対する複数の操作の間で許容される状態遷移を示す模式図である。 図１２は、本実施形態において、操作間の遷移の具体例を示す模式図である。 図１３は、本実施形態において、操作間の状態遷移を利用してレプリカDBの一貫性を保つ方法を示す模式図である。 図１４は、本実施形態に係る第１のサーバの機能構成図である。 図１５は、本実施形態に係るレプリカDB作成サーバの機能構成図である。 図１６は、本実施形態に係る主キー一覧の模式図である。 図１７は、本実施形態に係る第１のサーバの処理を示すフローチャートである。 図１８は、本実施形態において、各サーバが各採番DBと各差分の各々にアクセスする際の模式図である。 図１９は、チェックポイントDBを操作するときに本実施形態に係るレプリカDB作成サーバが行う情報処理方法のフローチャートである。 図２０は、レプリカDBを作成するときに本実施形態に係るレプリカDB作成サーバが行う情報処理方法のフローチャート（その１）である。 図２１は、レプリカDBを作成するときに本実施形態に係るレプリカDB作成サーバが行う情報処理方法のフローチャート（その２）である。 図２２は、本実施形態に係る第１のサーバと第２のサーバの各々のハードウェア構成図である。 図２３は、本実施形態に係るレプリカDB作成サーバのハードウェア構成図である。
本実施形態の説明に先立ち、本願発明者が検討した事項について説明する。
図１は、検討に使用したシステムの構成図である。
このシステム１は、マスタDBからレプリカDBを複製するシステムであって、業務サーバ２、ディスク装置３、レプリカDB作成サーバ４、及びクライアント端末５を有する。これらの各装置は、インターネット等のネットワーク６を介して相互に接続される。
このうち、業務サーバ２は、クライアント端末５の要求に応じてディスク装置３のデータベースの更新や挿入等の操作を行うサーバである。ここでは、業務サーバ２は、業務用のアプリケーションプログラムである業務アプリ７と、ディスク装置３のデータベースを管理するDB管理アプリ８とを実行する。
また、ディスク装置３は、マスタDB、採番DB、差分DB、及びレプリカDBを記憶したストレージ装置である。
マスタDBは、各クライアント端末５が参照するデータベースである。また、採番DBは、マスタDBのレコードに対して削除、挿入、及び更新等の操作があった場合に、レコードの操作の順序を示す番号を格納するデータベースである。
更に、差分DBは、マスタDBのレコードが操作された場合に、操作後のレコードのデータを格納するデータベースである。また、レプリカDBは、マスタDBのレコードを複製したレコードを格納されるデータベースである。
そして、レプリカDB作成サーバ４はレプリカDBを作成するサーバである。また、クライアント端末５は、システム１の利用者が操作するPC(Personal Computer)等の計算機である。
次に、このシステム１における処理の流れについて説明する。
図２は、システム１における処理の流れを示す模式図である。
まず、クライアント端末５が、業務サーバ２に対してマスタDBの操作を依頼する（Ｐ１）。その操作としては、レコードの削除、挿入、及び更新のいずれかがある。
次いで、業務サーバ２の業務アプリ７が、トランザクションTS1においてDB管理アプリ８に対してマスタDBの操作を依頼し、DB管理アプリ８がマスタDBのレコードのデータを操作する（Ｐ２）。ここでは、操作後の当該レコードのデータが「A」であるとする。また、以下では操作が行われた後のデータのことを単に操作後データとも呼ぶ。
次に、DB管理アプリ８に実装されているトリガを利用して、業務アプリ７が、マスタDBのレコードの操作後データが「A」であることを検知する（Ｐ３）。
次いで、業務アプリ７が、DB管理アプリ８に対して採番DBの最新の通番を１だけカウントアップするように要求し、カウントアップ後の通番をDB管理アプリ８を介して取得する（Ｐ４）。ここでは、採番DBの最新の通番が「０」であり、それを１だけカウントアップした通番「１」を業務アプリ７が取得する。
続いて、業務アプリ７が、DB管理アプリ８を介して、操作後データ「A」と通番「１」とを対応付けて差分DBに格納する（Ｐ５）。
次いで、クライアント端末５が、業務サーバ２に対して再びマスタDBの操作を依頼する（Ｐ６）。
次に、業務アプリ７が、今度はトランザクションTS2においてDB管理アプリ８に対してマスタDBの操作を依頼し、DB管理アプリ８がマスタDBのレコードのデータを操作する（Ｐ７）。この例では、当該レコードの操作後データが「B」であるとする。
次に、DB管理アプリ８に実装されているトリガを利用して、業務アプリ７が、マスタDBのレコードの操作後データが「B」であることを検知する（Ｐ８）。
次いで、業務アプリ７が、DB管理アプリ８に対して採番DBの最新の通番を１だけカウントアップするように要求し、カウントアップ後の通番をDB管理アプリ８を介して取得する（Ｐ９）。この例では、採番DBの最新の通番は「１」となっているため、それを１だけカウントアップした通番「２」を業務アプリ７が取得することになる。
続いて、業務アプリ７が、DB管理アプリ８を介して、操作後データ「B」と通番「２」とを対応付けて差分DBに格納する（Ｐ１０）。
次に、レプリカDB作成サーバ４が、差分DBに格納されている操作後データを通番が小さい順に読み込み、それをレプリカDBに格納する（Ｐ１１）。この例では、レプリカDB作成サーバ４は、最初に通番が「１」の操作後データ「A」をレプリカDBに格納し、次に通番が「２」の操作後データ「B」をレプリカDBに格納する。その後、レプリカDB作成サーバ４は、レプリカDBに格納した操作後データを差分DBから削除する。
以上により、このシステム１の基本処理を終える。
このシステム１によれば、業務サーバ２が、マスタDBのレコードの操作後データを通番と対応付けて差分DBに格納し（Ｐ５、Ｐ１０）、レプリカDB作成サーバ４が操作後データを通番順にレプリカDBに格納する（Ｐ１１）。これにより、レプリカDBの内容がマスタDBの内容と同一となり、マスタDBを複製したレプリカDBを得ることができる。そのため、クライアント端末５が、マスタDBに代えてレプリカDBを参照することが可能となり、マスタDBにアクセスが集中するのを防止できる。
ところで、図２においては一つの業務サーバ２がディスク装置３にアクセスする例を説明したが、場合によっては複数の業務サーバ２がディスク装置３にアクセスするシステムも考えられる。例えば、複数の業務サーバ２とディスク装置３の各々を異なる地域や国に分散して配置することにより、ある地域の業務サーバ２に障害が発生しても他の地域の業務サーバ２でシステム１を継続して利用できるようにする場合がある。
図３は、この場合のシステム１における処理の流れを示す模式図である。
この場合は、まず、クライアント端末５が、複数の業務サーバ２のうちの一つに対してマスタDBの操作を依頼する（Ｐ２１）。
次いで、当該業務サーバ２の業務アプリ７が、トランザクションTS1においてDB管理アプリ８に対してマスタDBの操作を依頼し、DB管理アプリ８がマスタDBのレコードを操作する（Ｐ２２）。ここでは、当該レコードの操作後データが「A」であるとする。
次に、DB管理アプリ８に実装されているトリガを利用して、業務アプリ７が、マスタDBのレコードの操作後データが「A」であることを検知する（Ｐ２３）。
次いで、業務アプリ７が、DB管理アプリ８に対して採番DBの最新の通番を１だけカウントアップするように要求し、カウントアップ後の通番をDB管理アプリ８を介して取得する（Ｐ２４）。図２の例と同様に、ここでは採番DBの最新の通番が「０」であり、それを１だけカウントアップした通番「１」を業務アプリ７が取得する。
続いて、業務アプリ７が、DB管理アプリ８を介して、操作後データ「A」と通番「１」とを対応付けて差分DBに格納する（Ｐ２５）。
次に、上記とは別の業務サーバ２に対し、クライアント端末５がマスタDBの操作を依頼する（Ｐ２６）。
続いて、その依頼を受けた業務サーバ２の業務アプリ７が、トランザクションTS2において自装置のDB管理アプリ８に対してマスタDBの操作を依頼し、DB管理アプリ８がマスタDBのレコードを操作する（Ｐ２７）。図２の例と同様に、この例でも当該レコードの操作後データが「B」であるとする。
そして、DB管理アプリ８に実装されているトリガを利用して、業務アプリ７が、マスタDBのレコードの操作後データが「B」であることを検知する（Ｐ２８）。
次いで、業務アプリ７が、DB管理アプリ８に対して採番DBの最新の通番を１だけカウントアップするように要求し、カウントアップ後の通番をDB管理アプリ８を介して取得する（Ｐ２９）。ここでは採番DBの最新の通番は「１」となっているため、それを１だけカウントアップした通番「２」を業務アプリ７が取得する。
続いて、業務アプリ７が、DB管理アプリ８を介して、操作後データ「B」と通番「２」とを対応付けて差分DBに格納する（Ｐ３０）。
次に、レプリカDB作成サーバ４が、差分DBに格納されている操作後データを通番が小さい順に読み込み、それをレプリカDBに格納する（Ｐ３１）。
以上により、業務サーバ２が複数存在する場合のシステム１の基本処理を終える。この場合も、各業務サーバ２が、レコードの操作後データと採番DBの通番とを対応付けて差分DBに格納することにより、マスタDBと同一内容のレプリカDBをレプリカDB作成サーバ４が作成できる。
しかし、このように複数の業務サーバ２が採番DBと差分DBにアクセスする場合には、採番DBと差分DBの各々の一貫性を保証するために、DB管理アプリ８がアクセスの排他制御を行う必要がある。
図４は、その排他制御の模式図である。
図４に示すように、この例では、採番DBの一貫性を保証するために、一つの業務サーバ２が前述のステップＰ２４を実行した後に、他の業務サーバ２が前述のステップＰ２９を行う必要がある。
同様に、差分DBの一貫性を保証するために、一つの業務サーバ２が前述のステップＰ２５を実行した後に、他の業務サーバ２が前述のステップＰ３０を行う必要がある。
このように採番DBと差分DBの各々へのアクセスを排他的に行うと、例えばステップＰ２４を実行してからステップＰ３０が終了するまでのレスポンスタイムT0が長くなる。特に、業務サーバ２の台数が多くなるとレスポンスタイムT0の長時間化が顕著となる。
（本実施形態）
図５は、本実施形態に係る情報処理システムのシステム構成図である。
この情報処理システム２０は、マスタDBからレプリカDBを複製するシステムであって、第１及び第２のサーバ２１、２２、ディスク装置２３、レプリカDB作成サーバ２４、及びクライアント端末２５を有する。これらの各装置は、インターネット等のネットワーク２６を介して相互に接続される。
このうち、第１のサーバ２１と第２のサーバ２２は、クライアント端末２５の要求に応じてディスク装置２３のデータベースに対してレコードの挿入、削除、及び更新のいずれかの操作を行うサーバである。
また、ディスク装置２３は、マスタDBやレプリカDB等の各種のデータベースを記憶したHDD(Hard Disk Drive)やSSD(Solid State Drive)等のストレージ装置である。そして、レプリカDB作成サーバ２４は、情報処理装置の一例であって、ディスク装置２３にレプリカDBを作成するサーバである。更に、クライアント端末２５は、情報処理システム２０の利用者が操作するPC等の計算機である。
次に、ディスク装置２３に記憶されている各種のデータベースについて説明する。
図６は、ディスク装置２３の模式図である。
図６に示すように、ディスク装置２３は、第１の採番DB３１、第２の採番DB３２、第１の差分DB４１、第２の差分DB４２、マスタDB４３、チェックポイントDB４４、及びレプリカDB４５を記憶する。
このうち、マスタDB４３は複製元のデータベースであり、レプリカDB４５は複製先のデータベースである。
また、第１の採番DB３１と第１の差分DB４１は、第１のサーバ２１に対応付けられたデータベースであり、各サーバ２１、２２のうちで第１のサーバ２１のみがアクセス可能である。
一方、第２の採番DB３２と第２の差分DB４２は、第２のサーバ２２に対応付けられたデータベースであり、各サーバ２１、２２のうちで第２のサーバ２２のみがアクセス可能である。
なお、第１の差分DB４１と第２の差分DB４２は、いずれも第２のデータベースの一例である。そして、第１の採番DB３１と第２の採番DB３２は、いずれも第５のデータベースの一例である。
また、チェックポイントDB４４は、第４のデータベースの一例であって、予め定められたチェック期間内における各差分DB４１、４２の内容を取得するときに使用するデータベースである。
次に、マスタDB４３、第１及び第２の採番DB３１、３２、第１及び第２の差分DB４１、４２、及びチェックポイントDB４４の各々の内容について説明する。
図７は、マスタDB４３の内容を示す模式図である。
図７の例では、表名が「社員名簿」、「得意先名簿」、及び「支店一覧」の三つのデータベースがマスタDBに格納される。これらのデータベースの各々には、一行分のデータであるレコード４３ａが複数格納される。なお、マスタDB４３に格納されるデータベースの個数はこれに限定されず、一つのデータベースのみがマスタDB４３に格納されてもよいし、四つ以上のデータベースがマスタDB４３に格納されてもよい。
複数のレコード４３ａのうちの一つを一意に識別する主キーはデータベースごとに異なる。例えば、表名が「社員番号」の主キーは属性「社員番号」である。また、表名が「得意先名簿」の主キーは属性「得意先名」である。そして、表名が「支店一覧」の主キーは属性「支店番号」である。
図８（ａ）は、第１の採番DB３１の内容について示す模式図である。
図８（ａ）に示すように、第１の採番DB３１は、属性として通番のみを備えたデータベースである。通番は、第１のサーバ２１がマスタDB４３の操作を行った順序を識別する識別子の一例である。ここでは、その通番子として整数を採用する。
これと同様に、第２の採番DB３２も属性として通番のみを有するデータベースである。例えば、第２の採番DB３２には、第２のサーバ２２がマスタDB４３の操作を行った順序を識別する識別子として整数値の通番が格納される。
図８（ｂ）は、チェックポイントDB４４の内容について示す模式図である。
図８（ｂ）に示すように、チェックポイントDB４４は、表名が「チェックポイント」のデータベースである。そのチェックポイントDB４４には、予め定められたチェック期間CTごとに更新される属性「チェックポイント」として文字列「CKPT」のみが格納される。チェック期間CTの長さは特に限定されないが、ここでは１分程度とする。また、チェック期間CTは、第１の期間の一例である。
図９は、第１の差分DB４１の内容について示す模式図である。
図９に示すように、第１の差分DB４１は、「通番」、「データ種」、「表名」、「主キー」、「操作内容」、「操作前データ」、及び「操作後データ」の各属性を対応付けた複数の差分レコード４９を記憶する。
このうち、「通番」は、第１の採番DB３１における「通番」である。また、「データ種」は、マスタDB４３とチェックポイントDB４４のどちらの操作後データが第１の差分DB４１に格納されているのかを特定する文字列である。例えば、マスタDB４３の操作後データの場合には文字列「DB」が「データ種」に格納される。また、チェックポイントDB４４の操作後データの場合には文字列「CKPT」が「データ種」に格納される。
「表名」は、マスタDB４３とチェックポイントDB４４のいずれかに記憶されているデータベースの表名である。
「主キー」は、マスタDB４３の複数の属性のうちで、レコード４３ａを一意に特定できる属性である。なお、チェックポイントDB４４に対応した差分レコード４９の「主キー」には文字列「CKPT」が格納される。
「操作内容」は、第１のサーバ２１がマスタDB４３に対して行った操作の内容である。例えば、「更新」、「削除」、及び「挿入」が「操作内容」となる。なお、第１のサーバ２１がチェックポイントDB４４に対して行う操作は常に挿入であるため、チェックポイントDB４４に対応した「操作内容」には「挿入」となる。
そして、「操作前データ」は、マスタDB４３とチェックポイントDB４４の各々を第１のサーバ２１が操作する前にこれらのデータベースに格納されているデータである。一方、「操作後データ」は、マスタDB４３とチェックポイントDB４４の各々を第１のサーバ２１が操作した後にこれらのデータに格納されているデータである。
チェックポイントDB４４の内容は常に文字列「CKPT」であるため、「操作前データ」と「操作後データ」はどちらも「CKPT」となる。
なお、第２の差分DB４２も、上記した第１の差分DB４１と同じ属性を対応つけた差分レコード４９を記憶する。その属性のうち、「通番」には、第２の採番DB３２の「通番」が格納される。そして、「操作前データ」には、マスタDB４３とチェックポイントDB４４の各々を第２のサーバ２２が操作する前にこれらのデータベースに格納されているデータが格納される。更に、「操作後データ」には、マスタDB４３とチェックポイントDB４４の各々を第２のサーバ２２が操作した後にこれらのデータに格納されているデータが格納される。
次に、この情報処理システム２０においてマスタDB４３の内容をレプリカDB４５に複製するときの処理の流れについて説明する。
図１０は、情報処理システム２０の処理の流れを示す模式図である。
本実施形態では、第１のサーバ２１と第２のサーバ２２の各々がディスク装置２３にアクセスするときに、アクセスの排他制御を行わずに以下のようにしてマスタDB４３の内容をレプリカDB４５に複製する。
まず、第１のサーバ２１が、マスタDB４３の操作を依頼する通知をクライアント端末２５（図５参照）から受け付け、それを契機としてマスタDB４３のレコード４３ａを操作する（Ｐ４１）。
次に、第１のサーバ２１が、トリガを利用することにより、マスタDBを操作した後のレコード４３ａの操作後データを取得する（Ｐ４２）。ここでは操作後データが「A」であるとする。
次いで、第１のサーバ２１が、第１の採番DB３１の最新の通番を１だけカウントアップし、カウントアップ後の通番を取得する（Ｐ４３）。この例では、第１の採番DB３１の最新の通番が「０」であり、それを１だけカウントアップした通番「１」を第１のサーバ２１が取得する。
続いて、第１のサーバ２１が、操作後データ「A」と通番「１」とを対応付けた差分レコード４９を第１の差分DB４１に格納する（Ｐ４４）。なお、図１０においては、図９の「操作後データ」と「通番」以外の差分レコード４９の属性は省略している。
その後、上記と同様にして第１のサーバ２１がマスタDB４３の操作を行い、操作後データと通番とを対応付けた差分レコード４９を第１の差分DB４１に格納する（Ｐ４５～Ｐ４７）。一例として、第１のサーバ２１は、操作後データ「B」、「C」、「D」をそれぞれ通番「２」、「３」、「４」と対応付けた差分レコード４９を第１の差分DB４１に格納する。
そして、上記のステップＰ４１～Ｐ４７と非同期に、第２のサーバ２２がマスタDB４３、第２の採番DB３２、及び第２の差分DB４２にアクセスする（Ｐ４８～Ｐ５３）。
例えば、第２のサーバ２２は、マスタDB４３の操作を依頼する通知をクライアント端末２５（図５参照）から受け付け、それを契機としてマスタDB４３のレコード４３ａを操作する（Ｐ４８）。
次に、第２のサーバ２２が、トリガを利用することにより、マスタDBの操作後データを取得する（Ｐ４９）。この例では操作後データが「X」であるとする。
続いて、第１のサーバ２１が、第２の採番DB３２の最新の通番を１だけカウントアップし、カウントアップ後の通番を取得する（Ｐ５０）。この例では、第２の採番DB３２の最新の通番が「４」であり、それを１だけカウントアップした通番「５」を第２のサーバ２２が取得する。
なお、第２の採番DB３２における通番は、第２のサーバ２２がマスタDB４３の操作を行った順序を識別する整数であって、第１の採番DB３１における通番とは独立している。そのため、第２の採番DB３２の通番「５」と、第１の採番DB３１の通番「１」との先後は任意であり、通番「５」が通番「１」よりも先であってもよいし、通番「５」が通番「１」よりも後であってもよい。これについては他の通番についても同様である。
そして、第２のサーバ２２が、操作後データ「X」と通番「５」とを対応付けた差分レコード４９を第２の差分DB４２に格納する（Ｐ５１）。
その後、上記と同様にして第２のサーバ２２がマスタDB４３の操作を行い、差分レコード４９を第２の差分DB４２に格納する（Ｐ５２～Ｐ５３）。例えば、第２のサーバ２２は、操作後データ「Y」、「Z」をそれぞれ通番「６」、「７」と対応付けた差分レコード４９を第２の差分DB４２に格納する。
次いで、レプリカDB作成サーバ２４が、チェックポイントDB４４を操作することにより、文字列「CKPT」をチェックポイントDB４４に挿入する（Ｐ５４）。レプリカDB作成サーバ２４がチェックポイントDB４４を操作するのは、予め定められたチェック期間CTに一回のみである。よって、レプリカDB作成サーバ２４は、チェック期間CTごとに定期的に文字列「CKPT」をチェックポイントDB４４に挿入することになる。
なお、図８（ｂ）に示したように、この操作の前にもチェックポイントDB４４には文字列「CKPT」が格納されているため、この操作の前後でチェックポイントDB４４の内容は変わらない。
次に、レプリカDB作成サーバ２４が、トリガを利用することにより、チェックポイントDB４４に挿入された文字列「CKPT」を取得する（Ｐ５５）。
続いて、レプリカDB作成サーバ２４が、第１の採番DB３１を参照して、該第１の採番DB３１における最新の通番を１だけカウントアップした通番を特定する（Ｐ５６）。この例では、第１の採番DB３１における最新の通番は「４」であるため、これを１だけカウントアップした通番「５」をレプリカDB作成サーバ２４が特定する。その通番「５」は、第１の差分DB４１におけるチェック期間CTの終点を示す終点識別子の一例である。
次に、レプリカDB作成サーバ２４が、その通番「５」と文字列「CKPT」とを対応付けて第１の差分DB４１に格納する（Ｐ５７）。
続いて、レプリカDB作成サーバ２４が、第２の採番DB３２を参照して、該第２の採番DB３２における最新の通番を１だけカウントアップした通番を特定する（Ｐ５８）。ここでは、第２の採番DB３２における最新の通番は「７」であるため、これを１だけカウントアップした通番「８」をレプリカDB作成サーバ２４が特定する。その通番「８」は、第２の差分DB４２におけるチェック期間CTの終点を示す終点識別子の一例である。
そして、レプリカDB作成サーバ２４が、その通番「８」と文字列「CKPT」とを対応付けて第２の差分DB４２に格納する（Ｐ５９）。
次いで、レプリカDB作成サーバ２４が、第１の差分DB４１を参照して、文字列「CKPT」と対応付けられた通番「５」を特定する（Ｐ６０）。
そして、レプリカDB作成サーバ２４が、通番「５」よりも順序が先の通番を含む全ての差分レコード４９を第１の差分DB４１から取得し、通番が小さい順に操作後データをレプリカDB４５に格納する（Ｐ６１）。
この例では、通番「５」よりも先の通番「１」～「４」に対応付けられた操作後データ「A」～「D」を含む差分レコード４９をレプリカDB作成サーバ２４が取得する。そして、レプリカDB作成サーバ２４が、これらの操作後データを「A」、「B」、「C」、「D」の順にレプリカDB４５に格納する。
その後に、レプリカDB作成サーバ２４が、通番「５」よりも順序が先の通番を含む差分レコード４９を第１の差分DB４１から削除する。この例では、レプリカDB作成サーバ２４は、操作後データ「A」～「D」を含む差分レコード４９を第１の差分DB４１から削除する。
同様に、レプリカDB作成サーバ２４が、第２の差分DB４２を参照して、文字列「CKPT」と対応付けられた通番「８」を特定する（Ｐ６２）。
そして、レプリカDB作成サーバ２４が、特定した通番「８」よりも順序が先の通番を含む全ての差分レコード４９を第２の差分DB４２から取得し、通番が小さい順に各操作後データをレプリカDB４５に格納する（Ｐ６３）。
ここでは、通番「８」よりも先の通番「５」～「７」に対応付けられた操作後データ「X」～「Z」を含む差分レコード４９をレプリカDB作成サーバ２４が取得する。そして、レプリカDB作成サーバ２４が、これらの操作後データを「X」、「Y」、「Z」の順にレプリカDB４５に格納する。
その後に、レプリカDB作成サーバ２４が、通番「８」よりも順序が先の通番を含む差分レコード４９を第２の差分DB４２から削除する。この例では、レプリカDB作成サーバ２４は、操作後データ「X」～「Z」を含む差分レコード４９を第２の差分DB４２から削除する。
以上により、情報処理システム２０における基本処理を終える。
これによれば、第１及び第２のサーバ２１、２２ごとに第１及び第２の採番DB３１、３２と第１及び第２の差分DB４１、４２を設け、かつレプリカDB作成サーバ２４が操作後データを通番順にレプリカDB４５に格納する。そのため、各採番DB３１、３２と各差分DB４１、４２への各サーバ２１、２２のアクセスに対して排他制御をしなくても、レプリカDBにおける操作後データの一貫性を保証できる。
なお、Ｐ５７ではレプリカDB作成サーバ２４が第１の差分DB４１にアクセスしているため、このタイミングではレプリカDB作成サーバ２４と第１のサーバ２１の各々の第１の差分DB４１へのアクセスを排他的に行うことになる。但し、Ｐ５７が実行されるのはチェック期間CTに一回のみなので、これにより情報処理システム２０のレスポンスタイムが大きく悪化することはない。
また、この例では、各サーバ２１、２２とは別にレプリカDB作成サーバ２４を設けたが、第１のサーバ２１と第２のサーバ２２のいずれかにレプリカDB作成サーバ２４の機能を持たせてもよい。この場合は、例えば、第１のサーバ２１が前述のＰ５４～Ｐ６３の処理を行うことになる。
ところで、第１の採番DB３１の通番「１」～「４」は、第１のサーバ２１がマスタDB４３を操作した順番を示す。そのため、上記のように通番通りに操作後データ「A」～「D」をレプリカDB４５に格納することにより、第１のサーバ２１が操作したレコードの一貫性は保たれる。
但し、第１の採番DB３１と第２の採番DB３２のそれぞれの通番では時間的な先後を特定できないため、これらの通番のみでは第１のサーバ２１と第２のサーバ２２の各々がマスタDB４３を操作した順番を特定できない。例えば、第１の採番DB３１の通番「３」は第２の採番DB３２の通番「５」よりも小さいが、通番「３」に対する操作が通番「５」に対する操作よりも先に行われたとは限らない。
そのため、第１のサーバ２１と第２のサーバ２２がマスタDB４３の同一のレコード４３ａを操作した場合には、レプリカDB４５に通番順に操作後データを格納してもレプリカDB４５の一貫性が保たれない。
その場合には、以下のようにして同一のレコード４３ａに対する複数の操作の間で許容される状態遷移に基づいて最後に操作されたレコード４３ａの操作後データを特定し、当該操作後データをレプリカDB４５に格納する。
図１１は、マスタDB４３の同一レコード４３ａに対する複数の操作の間で許容される状態遷移を示す模式図である。
この状態遷移５０は、マスタDB４３の一貫性を保つために許容される操作の状態遷移である。
図１１に示されるように、複数の操作の間で許容されるのは（１）～（５）の遷移のみである。このうち、（１）は、あるレコード４３ａに対して「挿入」を行った後に、そのレコード４３ａの「更新」を行う遷移である。また、（２）は、あるレコード４３ａを「更新」した後に、そのレコード４３ａの「更新」を再び行う遷移である。
（３）は、あるレコード４３ａの「更新」をした後に、そのレコード４３ａを「削除」する遷移である。（４）は、あるレコード４３ａを「挿入」した後に、そのレコード４３ａを「削除」する遷移である。
そして、（５）は、あるレコード４３ａを「削除」した後に、そのレコード４３ａを再び「挿入」する遷移である。
図１２は、操作間の遷移の具体例を示す模式図である。
なお、図１２においては、各操作をした後の差分レコード４９も併記してある。
この例では、（１）の遷移において、挿入されたレコード４３ａのデータが「A」から「B」に更新される。また、（２）の遷移において、レコード４３ａのデータが「B」から「C」に更新される。
そして、（３）の遷移においては、データが「B」に更新されたレコード４３ａが削除される。更に、（４）の遷移においては、データとして「A」が挿入されたレコード４３ａが削除される。
また、（５）の遷移においては、削除されたレコード４３ａのデータを「A」にし、再びそのレコード４３ａを挿入する。
このように複数の操作の間で許容される状態遷移を利用すると、各サーバ２１、２２がマスタDB４３の同一のレコード４３ａを操作した場合であっても、以下のようにレプリカDB４５の一貫性を保つことができる。
図１３は、操作間の状態遷移を利用してレプリカDB４５の一貫性を保つ方法を示す模式図である。
ここでは、第１のサーバ２１と第２のサーバ２２の各々が、マスタDB４３の同一のレコード４３ａに対し、「Aを挿入」→「Bに更新」→「Cに更新」という三つの操作をこの順に行った場合を例にして説明する。例えば、「Aを挿入」と「Ｂに更新」を第１のサーバ２１が行い、「Ｃに更新」を第２のサーバ２２が行ったものとする。また、各サーバ２１、２２が操作する前の当該レコード４３ａの初期値は空であるとする。
この場合は、まず、レプリカDB作成サーバ２４が、第１の差分DB４１と第２の差分DB４２の各々の差分レコード４９の中に、マスタDB４３の同一のレコード４３ａに対応したものがあるかを判定する。
ここで、同一のレコード４３ａに対応した差分レコード４９があると判定された場合には、レプリカDB作成サーバ２４は、レプリカDB４５の当該レコード４３ａを自装置の記憶部に退避させる（Ｐ７１）。この例では、レプリカDB作成サーバ２４は、初期値が空のレコード４３ａを記憶部に退避させる。
次に、レプリカDB作成サーバ２４が、第１の差分DB４１と第２の差分DB４２の各々の差分レコード４９と状態遷移５０とに基づいて、最後に操作されたレコード４３ａを特定する（Ｐ７２）
この例では、三つの差分レコード４９の各々の「操作内容」は「挿入」、「更新」、「更新」である。状態遷移５０によれば、これらの操作間で許容される遷移は、（１）の「挿入」→「更新」の遷移と、（２）の「更新」→「更新」の遷移の二つである。そして、これら二つの遷移が可能なのは、「挿入」→「更新」→「更新」という遷移のみである。
最後の二つの「更新」を行った順序は、差分レコード４９の「操作前データ」と「操作後データ」から判断できる。例えば、二つの「更新」のうちの一方の「操作後データ」が他方の「操作前データ」に一致すれば、二つの「更新」がこの順に行われたことになる。図１３の例では、最初に「Bに更新」が行われ、その後に「Aに更新」が行われたことになる。
以上により、最後に行われた操作は、「B」から「C」への更新であることが特定できる。
その後、レプリカDB作成サーバ２４は、上記のようにして最後に操作されたレコード４３ａに対応する操作後データのみをレプリカDB４５に格納する（Ｐ７３）。
これにより、各サーバ２１、２２がマスタDB４３の同一のレコード４３ａに対して操作を行った場合でも、最後の操作における操作後データのみがレプリカDB４５に格納されるため、レプリカDB４５の一貫性を保つことができる。
なお、このように状態遷移５０を利用せずに、レコード４３ａを操作した時刻を示すタイムスタンプを各サーバ２１、２２が差分レコード４９に付与することも考えられる。この場合は、レプリカDB作成サーバ２４は、タイムスタンプ順に差分レコード４９を並べ替えることにより、最後に操作されたレコード４３ａに対応する差分レコード４９を特定することになる。しかし、各サーバ２１、２２が計測する時刻を正確に合わせるのは困難であるため、この方法では並べ替えた後の差分レコード４９の順序が時刻順になる保障がない。
これに対し、この例のように状態遷移５０を利用すれば時刻順に差分レコード４９を正しく並べ替えることができ、最後の差分レコード４９を正しく求めることができる。
次に、情報処理システム２０の各装置の機能構成について説明する。
図１４は、第１のサーバ２１の機能構成図である。
図１４に示すように、第１のサーバ２１は、通信部５１と制御部５２とを有する。
このうち、通信部５１は、第１のサーバ２１をネットワーク２６に接続するための通信インターフェースである。
一方、制御部５２は、第１のサーバ２１の各部を制御する処理部であって、受付部５３、操作部５４、通番取得部５５、及びデータ格納部５６を備える。
受付部５３は、マスタDB４３の操作を要求する操作要求をクライアント端末２５から受け付ける処理部である。また、操作部５４は、マスタDB４３のレコード４３ａに対し、挿入、更新、及び削除等の操作を行う処理部である。
そして、通番取得部５５は、第１の採番DB３１から最新の通番を取得する処理部である。更に、データ格納部５６は、操作部５４が操作したレコード４３ａの操作後データと、通番取得部５５が取得した通番とを対応付けて第１の差分DB４１に格納する処理部である。
なお、第２のサーバ２２も上記と同様の機能構成を有する。例えば、第２のサーバ２２の通信部５１は、該第２のサーバ２２をネットワーク２６に接続する。また、第２のサーバ２２の通番取得部５５は、第２の採番DB３２から通番を取得する。そして、第２のサーバ２２のデータ格納部５６は、レコード４３ａの操作後データと通番とを対応付けて第２の差分DB４２に格納する。
図１５は、レプリカDB作成サーバ２４の機能構成図である。
図１５に示すように、レプリカDB作成サーバ２４は、通信部６１、記憶部６２、及び制御部６３を有する。
このうち、通信部６１は、レプリカDB作成サーバ２４をネットワーク２６に接続するための通信インターフェースである。
一方、記憶部６２は、主キー一覧８０を記憶する。
図１６は、主キー一覧８０の模式図である。
主キー一覧８０は、第１のサーバ２１と第２のサーバ２２の両方から操作が行われたマスタDB４３のレコード４３ａを特定するための情報である。ここでは、各サーバ２１、２２の両方から操作されたレコード４３ａの「表名」と「主キー」とが対応付けられて主キー一覧８０に格納される。
例えば、表名が「社員名簿」のデータベースを考える。このデータベースの主キーは「社員番号」である。この場合は、マスタDB４３に格納されている表名が「社員名簿」のデータベースのレコード４３ａのうち、「社員番号」が「1234」で特定されるレコードを、第１のサーバ２１と第２のサーバ２２の両方が操作したということになる。
再び図１５を参照する。
制御部６３は、レプリカDB作成サーバ２４の各部を制御する処理部である。この例では、制御部６３は、データ取得部６７、通番取得部６８、操作部６９、検知部７０、特定部７１、及び通番格納部７２を有する。更に、制御部６３は、データ格納部７３、削除部７４、生成部７５、及び判定部７６を有する。
このうち、データ取得部６７は、第１の差分DB４１と第２の差分DB４２の各々から差分レコード４９を取得する処理部である。また、通番取得部６８は、第１の採番DB３１と第２の採番DB３２の各々から最新の通番を取得する処理部である。
操作部６９は、チェック期間CTごとにチェックポイントDB４４を操作することにより、チェックポイントDB４４に文字列「CKPT」を定期的に挿入する処理部である。この例では、操作部６９は、チェック期間CTごとにチェックポイントDB４４に文字列「CKPT」を挿入する。
そして、検知部７０は、チェック期間CT内にチェックポイントDBが操作されたことを検知する処理部である。一例として、検知部７０は、操作部６９がチェックポイントDB４４に文字列「CKPT」を挿入したときに、トリガを利用してチェックポイントDB４４が操作されたことを検知する。
特定部７１は、検知部７０が上記の操作を検知したときに、第１の採番DB３１と第２の採番DB３２の各々を参照して、各採番DB３１、３２における最新の通番に１を加えた通番を特定する処理部である。図１０の例では、特定部７１は、第１の採番DB３１における最新の通番「４」に１を加えた通番「５」を特定する。これと共に、特定部７１は、第２の採番DB３２における最新の通番「７」に１を加えた通番「８」を特定する。
通番格納部７２は、識別子格納部の一例であって、特定部７１が特定した通番を、チェック期間CTの終点を示す終点識別子として各差分DB４１、４２に格納する処理部である。図１０の例では、通番格納部７２は、第１の差分DB４１に終点識別子として通番「５」を文字列「CKPT」と対応付けて格納し、第２の差分DB４２に終点識別子として通番「８」を文字列「CKPT」と対応付けて格納する。
データ格納部７３は、データ取得部６７が取得した差分レコード４９に含まれる操作後データを通番順にレプリカDB４５に格納する処理部である。
削除部７４は、データ取得部６７が差分レコード４９を取得した後に、終点識別子よりも順序が先の通番を含む差分レコード４９を各差分DB４１、４２の各々から削除する処理部である。例えば、図１０の場合には、削除部７４は、第１の差分DB４１において終点識別子「５」よりも先の「１」～「４」の通番を含む差分レコード４９を該第１の差分DB４１から削除する。同様に、削除部７４は、第２の差分DB４２において終点識別子「８」よりも先の「５」～「７」の通番を含む差分レコード４９を該第２の差分DB４２から削除する。
生成部７５は、前述の主キー一覧８０を記憶部６２に生成する処理部である。そして、判定部７６は、主キー一覧８０を参照することにより、データ取得部６７が取得した差分レコード４９の中に、第１のサーバ２１と第２のサーバ２２の両方が操作したレコード４３ａに係るものが存在するかを判定する。
なお、この例では、第１及び第２のサーバ２１、２２とは別にレプリカDB作成サーバ２４を設けたが、前述のようにレプリカDB作成サーバ２４の機能を各サーバ２１、２２のいずれかに持たせてもよい。例えば、第１のサーバ２１の制御部５２にレプリカDB作成サーバ２４の制御部６３の機能を持たせ、かつ、第１のサーバ２１にレプリカDB作成サーバ２４の記憶部６２の機能を持たせてもよい。
次に、本実施形態に係る情報処理方法について説明する。
図１７は、第１のサーバ２１の処理を示すフローチャートである。
まず、第１のサーバ２１の受付部５３が、マスタDB４３の操作を要求する操作要求をクライアント端末２５から受け付ける（ステップＰ３１）。
次いで、操作部５４が、操作要求に応じてマスタDB４３のレコード４３ａを操作する（ステップＳ３２）。例えば、操作要求がレコード４３ａの更新を要求している場合には、操作部５４は当該レコード４３ａを更新する。
次に、通番取得部５５が、例えばトリガを利用してレコード４３ａが操作されたことを検知し、これを契機として第１の採番DB３１から最新の通番を取得する（ステップＳ３３）。
その後、データ格納部５６が、トリガによって検知されたレコード４３ａの操作後データと、ステップＳ３３で取得した通番とを対応付けた差分レコード４９を第１の差分DB４１に格納する（ステップＳ３４）。
この際、データ格納部５６は、図９のように「データ種」、「表名」、「主キー」、「操作内容」、及び「操作前データ」も通番と対応付けて第１の差分DB４１に格納する。
この例では、「データ種」には、マスタDB４３を操作したことを示す文字列「DB」が格納される。また、「表名」には、「社員名簿」等のように操作が行われたデータベースの表名が格納される。更に、「主キー」には、操作が行われたレコード４３ａを一意に特定する属性が格納される。上記の「社員名簿」の場合には属性「社員番号」が主キーとなる。そして、「操作内容」は、レコード４３ａに対して行われた操作を示す「挿入」、「更新」、及び「削除」のいずれかが格納される。また、「操作前データ」には、操作前におけるレコード４３ａのデータが格納される。
この後は、第１のサーバ２１の業務が終わるまでステップＳ３１～Ｓ３４を繰り返す。
また、第２のサーバ２２も同様にして上記のステップＳ３１～Ｓ３４を実行する。
図１８は、図１７のフローチャートに従って各サーバ２１、２２が各採番DB３１、３２と各差分DB４１、４２の各々にアクセスする際の模式図である。
図１８に示すように、本実施形態では、第１のサーバ２１がアクセスする第１の採番DB３１と第１の差分DB４１の各々を、第２のサーバ２２がアクセスする第２の採番DB３２と第２の差分DB４２の各々と別にした。そのため、第１のサーバ２１が第１の採番DB３１にアクセスするステップＳ３３と、第２のサーバ２２が第２の採番DB３２にアクセスするステップＳ３３とを排他的に行わなくても、各採番DB３１、３２の一貫性が保たれる。同様に、各サーバ２１、２２のそれぞれのステップＳ３４を排他的に行わなくても各差分DB４１、４２の一貫性が保たれる。
その結果、第１のサーバ２１がステップＳ３３を実行してから第２のサーバ２２がステップＳ３４を終えるまでのレスポンスタイムT1を、図４のレスポンスタイムT0よりも短くすることができる。
次に、レプリカDB作成サーバ２４が行う情報処理方法について説明する。レプリカDB作成サーバ２４が行う情報処理方法は、チェックポイントDB４４を操作する処理と、レプリカDB４５を作成する処理とがある。
最初に、チェックポイントDB４４を操作する場合の情報処理方法について説明する。
図１９は、チェックポイントDB４４を操作するときにレプリカDB作成サーバ２４が行う情報処理方法のフローチャートである。
まず、操作部６９が、チェックポイントDB４４を操作することにより、チェックポイントDB４４に文字列「CKPT」を挿入する（ステップＳ３５）。
次いで、チェックポイントDB４４の操作があったことを検知部７０が検知し、これを契機として特定部７１が各採番DB３１、３２における最新の通番に１を加えた通番を特定する（ステップＳ３６）。
そして、通番格納部７２が、特定部７１が特定した通番を、チェック期間CTの終点を示す終点識別子として各差分DB４１、４２に格納する（ステップＳ３７）。このとき、通番格納部７２は、図１０のＰ５７と同様に、終点識別子と文字列「CKPT」とを対応付けて各差分DB４１、４２に格納する。
この後は、チェック期間CTに１回の周期でステップＳ３５～Ｓ３７を繰り返す。
以上により、チェックポイントDB４４を操作するときにレプリカDB作成サーバ２４が行う情報処理方法の基本処理を終える。
次に、レプリカDB４５を作成する場合の情報処理方法について説明する。
図２０及び図２１は、レプリカDB４５を作成するときにレプリカDB作成サーバ２４が行う情報処理方法のフローチャートである。
この情報処理方法は、レプリカDB作成サーバ２４が後述の情報処理プログラムを実行することにより行われ、管理者が当該情報処理プログラムを起動することにより開始する。
まず、検知部７０が、チェックポイントDB４４に対する操作があるかを検知する（ステップＳ４１）。例えば、検知部７０は、操作部６９がチェックポイントDB４４に文字列「CKPT」を挿入したときにチェックポイントDB４４が操作されたことを検知する。
ここで、操作がない場合（ステップＳ４１：否定）にはステップＳ４２に移る。ステップＳ４２ではレプリカDB作成サーバ２４が一定の時間だけ待機した後に再びステップＳ４１に戻る。
一方、操作がある場合（ステップＳ４１：肯定）にはステップＳ４３に移る。
ステップＳ４３においては、第１の採番DB３１における最新の通番に１を加えた終点識別子を特定部７１が特定する。ステップＳ４３は、各採番DB３１、３２の数だけ繰り返される。よって、ステップＳ４３においては、特定部７１は、第２の採番DB３２における最新の通番に１を加えた終点識別子も特定する。
次に、生成部７５が、各差分DB４１、４２の各々から終点識別子よりも順序が先の差分レコード４９を取得し、これらの差分レコード４９から主キー一覧８０を記憶部６２に生成する（ステップＳ４４）。例えば、生成部７５は、第１の差分DB４１の複数の差分レコード４９のうちで、「主キー」と「表名」が第２の差分DB４２の差分レコード４９におけるのと同じレコードを特定する。そして、生成部７５は、特定した差分レコード４９の「主キー」、「表名」、及び「操作前データ」を記憶部６２の主キー一覧８０に格納する。
これにより、図１３のＰ７１と同様に、第１のサーバ２１と第２のサーバ２２の両方から操作されたレコード４３ａに対応した差分レコード４９が記憶部６２に退避されることになる。
次いで、データ取得部６７が、終点識別子よりも順序が先の差分レコード４９を、第１の差分DB４１から通番順に取得する（ステップＳ４５）。ステップＳ４５は各差分DB４１、４２ごとに行われる。よって、データ取得部６７は、第２の差分DB４２にある差分レコード４９についても同様に取得する。
更に、この例では、チェック期間CTに一度だけ行われるチェックポイントDB４４に対する操作があった場合（ステップＳ４１：肯定）にステップＳ４５が実行される。これにより、データ取得部６７は、終点識別子よりも順序が先の差分レコード４９を、チェック期間において操作されたレコード４３ａに対応した差分レコード４９として取得することになる。
次に、判定部７６が、ステップＳ４５で取得した差分レコード４９の「表名」と「主キー」が主キー一覧８０にあるかを判定する（ステップＳ４６）。ここで、ないと判定された場合（ステップＳ４６：否定）にはステップＳ４７に移る。
ステップＳ４７においては、データ格納部７３が、ステップＳ４５で取得した差分レコード４９に含まれる操作後データをレプリカDB４５に格納する。ステップＳ４５～Ｓ４７は、ステップＳ４３で取得した終点識別子よりも順序が先の差分レコード４９に対して通番順に行われる。これにより、データ格納部７３は、通番順に操作後データをレプリカDB４５に格納することになる。
一方、ステップＳ４６で差分レコード４９の「表名」と「主キー」が主キー一覧８０にあると判定された場合（ステップＳ４６：肯定）は、該差分レコード４９に対応するレコード４３ａが各サーバ２１、２２から操作されたことになる。この場合には、図１３に例示したように、当該レコード４３ａに対する複数の操作のうちで最後の操作に対応した差分レコード４９の操作後データのみをレプリカDB４５に格納する必要があるため、ステップＳ４７をスキップする。
次に、判定部７６が、記憶部６２に主キー一覧８０があるかどうかを判定する（ステップＳ４８）。
ここで、主キー一覧８０があると判定された場合（ステップＳ４８：肯定）は、第１のサーバ２１と第２のサーバ２２の両方から操作が行われたマスタDB４３のレコード４３ａが存在することになる。この場合には、図１３を参照して説明したように、最後に操作されたレコード４３ａに対応する差分レコード４９を状態遷移５０に基づいて以下のように特定する。
まず、データ取得部６７が、各差分DB４１、DB４２にある複数の差分レコード４９のうち、「表名」と「主キー」が主キー一覧８０に存在する差分レコード４９を各差分DB４１、４２から取得する（ステップＳ４９）。このようにして取得した複数の差分レコード４９の各々には、同一のレコード４３ａを各サーバ２１、２２が操作したときの操作後データが格納されている。
次に、データ格納部７３が、複数の差分レコード４９の各々を、図１１の状態遷移５０を利用して操作順に並べ替えることにより、最後に操作されたレコード４３ａに対応した差分レコード４９を特定する（ステップＳ５０）。一例として、データ格納部７３は、複数の差分レコード４９の「操作内容」、「操作前データ」、及び「操作後データ」の各々が状態遷移５０と整合するように差分レコード４９を並べ替える。そして、データ格納部７３は、その並びの最後にある差分レコード４９を、最後に操作されたレコード４３ａに対応した差分レコード４９であると特定する。
図１３を参照して説明したように、このように状態遷移５０を利用して差分レコード４９を並べ替えることにより、タイムスタンプを利用しなくても最後の差分レコード４９を正確に求めることができる。
次に、データ格納部７３が、ステップＳ４９で取得した複数の差分レコード４９のうちで、ステップＳ５０で特定した最後の差分レコード４９の操作後データのみをレプリカDB４５に格納する（ステップＳ５１）。
次いで、生成部７５が、記憶部６２から主キー一覧８０を削除する（ステップＳ５２）。なお、前述のステップＳ４８で記憶部６２に主キー一覧８０がないと判定された場合にも主キー一覧８０を削除する。
続いて、削除部７４が、終点識別子よりも順序が先の通番を含む差分レコード４９を各差分DB４１、４２の各々から削除する（ステップＳ５３）。図１０の例では、削除部７４は、第１の差分DB４１における終点識別子である「５」よりも先の通番「１」～「４」を含む差分レコード４９を削除する。また、削除部７４は、第２の差分DB４２における終点識別子である「８」よりも先の通番「５」～「７」を含む差分レコード４９を削除する。
次いで、判定部７６が、管理者から情報処理プログラムの実行を終了する指示があったかを判定する（ステップＳ５４）。ここで、指示がない場合（ステップＳ５４：否定）にはステップＳ４１に戻る。
一方、指示があった場合（ステップＳ５４：肯定）には処理を終える。
以上により、レプリカDB作成サーバ２４が行う情報処理方法の基本処理が終了する。
上記した本実施形態によれば、図１８に示したように、第１及び第２のサーバ２１、２２ごとに第１及び第２の採番DB３１、３２を設ける。そして、本実施形態では各サーバ２１、２２ごとに第１及び第２の差分DB４１、４２を設けため、レスポンスタイムT1を短くすることができる。
しかも、図２０のステップＳ４７において、データ格納部７３が通番順に操作後データをレプリカDB４５に格納する。これにより、操作が行われた順に操作後データがレプリカDB４５に格納されるため、レプリカDB４５の一貫性を保証できる。
更に、同一レコード４３ａについての差分レコード４９が各差分DB４１、４２にある場合には、ステップＳ５１において、データ格納部７３が、最後に操作された差分レコード４９の操作後データのみをレプリカDB４５に格納する。そのため、第１のサーバ２１と第２のサーバ２２の両方が同一のレコード４３ａを操作した場合であっても、レプリカDB４５の一貫性を保つことができる。
更に、操作部６９がチェック期間CTごとにチェックポイントDB４４を操作するため、チェック期間CTごとにステップＳ４１でＹＥＳと判定されてステップＳ４７が実行される。その結果、ステップＳ４７において、データ格納部７３が、チェック期間CTにおいて操作されたレコード４３ａの操作後データを一括してレプリカDB４５に格納できる。
（ハードウェア構成）
図２２は、本実施形態に係る第１のサーバ２１と第２のサーバ２２の各々のハードウェア構成図である。
図２２に示すように、各サーバ２１、２２は、記憶装置２１ａ、メモリ２１ｂ、プロセッサ２１ｃ、及び通信インターフェース２１ｄを有する。これらの各部は、バス２１ｇにより相互に接続される。
このうち、記憶装置２１ａは、HDDやSSD等の不揮発性のストレージであって、本実施形態に係る各サーバ２１、２２用の情報処理プログラム１００を記憶する。
なお、情報処理プログラム１００をコンピュータが読み取り可能な記録媒体９０に記録させておき、プロセッサ２１ｃに記録媒体９０の情報処理プログラム１００を読み取らせるようにしてもよい。
そのような記録媒体９０としては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体９０として使用してもよい。これらの記録媒体９０は、物理的な形態を持たない搬送波のような一時的な媒体ではない。
更に、公衆回線、インターネット、及びLAN(Local Area Network)等に接続された装置に情報処理プログラム１００を記憶させてもよい。その場合は、プロセッサ２１ｃがその情報処理プログラム１００を読み出して実行すればよい。
一方、メモリ２１ｂは、DRAM(Dynamic Random Access Memory)等のようにデータを一時的に記憶するハードウェアであって、その上に情報処理プログラム１００が展開される。
プロセッサ２１ｃは、CPU(Central Processing Unit)やGPU(Graphical Processing Unit)等のハードウェアであって、メモリ２１ｂと協働して情報処理プログラム１００を実行する。
このようにメモリ２１ｂとプロセッサ２１ｃとが協働して情報処理プログラム１００を実行することにより図１４の制御部５２が実現される。その制御部５２には、受付部５３、操作部５４、通番取得部５５、及びデータ格納部５６の各処理部が含まれる。
更に、通信インターフェース２１ｄは、各サーバ２１、２２をネットワーク２６（図５参照）に接続するためのNIC(Network Interface Card)等の通信インターフェースである。その通信インターフェース２１ｄにより、図１４の通信部５１が実現される。
図２３は、本実施形態に係るレプリカDB作成サーバ２４のハードウェア構成図である。
図２３に示すように、レプリカDB作成サーバ２４は、記憶装置２４ａ、メモリ２４ｂ、プロセッサ２４ｃ、及び通信インターフェース２４ｄを有する。これらの各部は、バス２４ｇにより相互に接続される。
このうち、記憶装置２４ａは、HDDやSSD等の不揮発性のストレージであって、本実施形態に係るレプリカDB作成サーバ２４用の情報処理プログラム１０１を記憶する。
なお、情報処理プログラム１０１をコンピュータが読み取り可能な記録媒体９０に記録させておき、プロセッサ２１ｃに記録媒体９０の情報処理プログラム１０１を読み取らせるようにしてもよい。
更に、公衆回線、インターネット、及びLAN等に接続された装置に情報処理プログラム１００を記憶させてもよい。その場合は、プロセッサ２４ｃがその情報処理プログラム１０１を読み出して実行すればよい。
一方、メモリ２４ｂは、DRAM等のようにデータを一時的に記憶するハードウェアであって、その上に情報処理プログラム１０１が展開される。
プロセッサ２４ｃは、レプリカDB作成サーバ２４の各部を制御するCPUやGPU等のハードウェアである。また、プロセッサ２４ｃは、メモリ２４ｂと協働して情報処理プログラム１０１を実行する。
このようにメモリ２４ｂとプロセッサ２４ｃとが協働して情報処理プログラム１０１を実行することにより図１５の制御部６３が実現される。その制御部６３には、データ取得部６７、通番取得部６８、操作部６９、検知部７０、特定部７１、通番格納部７２、データ格納部７３、削除部７４、生成部７５、及び判定部７６の各部が含まれる。
また、図１５の記憶部６２は、記憶装置２４ａとメモリ２４ｂによって実現される。
更に、通信インターフェース２４ｄは、レプリカDB作成サーバ２４をネットワーク２６（図５参照）に接続するためのNIC等の通信インターフェースである。その通信インターフェース２４ｄにより、図１５の通信部６１が実現される。
以上説明した各実施形態に関し、更に以下の付記を開示する。
（付記１） 第１のデータベースの複数のレコードの各々を複数のサーバが操作した後の該レコードのデータと、前記操作が行われた順序を示す識別子とを対応付けて記憶した、複数の前記サーバごとに設けられた複数の第２のデータベースから、第１の期間に記憶された前記データを取得するデータ取得部と、
取得した前記データを、前記識別子が示す順に第３のデータベースに格納するデータ格納部と、
を有することを特徴とする情報処理装置。
（付記２） 前記データ格納部は、同一の前記レコードの前記データが複数の前記第２のデータベースに存在する場合に、同一の前記レコードの前記データのうちで、最後に操作された前記レコードの前記データのみを前記第３のデータベースに格納することを特徴とする付記１に記載の情報処理装置。
（付記３） 前記第２のデータベースは、前記識別子、前記データ、前記操作の内容、及び前記操作をする前の前記レコードのデータの各々を対応付けて記憶し、
前記データ格納部は、
取得した前記データと、該データに対応する前記操作の内容と、該データに対応する前記操作をする前の前記データと、複数の前記操作の間で許容される状態遷移とに基づいて、最後に操作された前記レコードを特定することを特徴とする付記２に記載の情報処理装置。
（付記４） 前記第１の期間に第４のデータベースが操作されたことを検知する検知部と、
前記検知部が前記操作を検知したときに、前記識別子を複数の前記サーバごとに記憶した複数の第５のデータベースを参照して、各々の前記第５のデータベースにおける最新の前記識別子に１を加えた前記識別子を特定する特定部と、
特定した前記識別子に対応した前記サーバに対応付けられた前記第２のデータベースに、該識別子を、前記第１の期間の終点を示す終点識別子として格納する識別子格納部と、
前記データ取得部が前記データを取得した後に、前記終点識別子よりも順序が先の前記識別子と対応付けられた前記データを、複数の前記第２のデータベースの各々から削除する削除部とを更に有し、
前記データ取得部は、
前記第２のデータベースにおいて前記終点識別子よりも順序が先の前記データを、前記第１の期間における前記データとして取得することを特徴とする付記１に記載の情報処理装置。
（付記５） 前記第１の期間ごとに前記第４のデータベースを操作する操作部を更に有することを特徴とする付記４に記載の情報処理装置。
（付記６） 情報処理装置と複数のサーバとを備えた情報処理システムであって、
複数の前記サーバの各々は、
第１のデータベースのレコードを操作する操作部と、
複数の前記サーバの各々に対応した複数の第２のデータベースのうちで自装置に対応する前記第２のデータベースに、前記操作をした後の前記レコードのデータを、前記操作を行った順序を示す識別子に対応付けて格納する第１のデータ格納部とを有し、
前記情報処理装置は、
複数の前記第２のデータベースの各々から、第１の期間に記憶された前記データを取得するデータ取得部と、
取得した前記データを、前記識別子が示す順に第３のデータベースに格納する第２のデータ格納部とを有する、
ことを特徴とする情報処理システム。
（付記７） 前記第２のデータ格納部は、同一の前記レコードにおける前記データが複数の前記第２のデータベースに存在する場合に、同一の前記レコードの前記データのうちで、最後に操作された前記レコードに対応する前記データのみを前記第３のデータベースに格納することを特徴とする付記６に記載の情報処理システム。
（付記８） 前記第１のデータ格納部は、前記第２のデータベースに、前記識別子、前記データ、前記操作の内容、及び前記操作をする前の前記レコードのデータの各々を対応付けて格納し、
前記第２のデータ格納部は、
取得した前記データと、該データに対応する前記操作の内容と、該データに対応する前記操作をする前の前記データと、複数の前記操作の間で許容される状態遷移とに基づいて、最後に操作された前記レコードを特定することを特徴とする付記７に記載の情報処理システム。
（付記９） コンピュータに、
第１のデータベースの複数のレコードの各々を複数のサーバが操作した後の該レコードのデータと、前記操作が行われた順序を示す識別子とを対応付けて記憶した、複数の前記サーバごとに設けられた複数の第２のデータベースから、第１の期間に記憶された前記データを取得し、
取得した前記データを、前記識別子が示す順に第３のデータベースに格納する、
処理を実行させるための情報処理プログラム。
（付記１０） 前記コンピュータに、
同一の前記レコードにおける前記データが複数の前記第２のデータベースに存在する場合に、同一の前記レコードの前記データのうちで、最後に操作された前記レコードに対応する前記データのみを前記第３のデータベースに格納する、
処理を実行させるための付記９に記載の情報処理プログラム。
（付記１１） 前記第２のデータベースは、前記識別子、前記データ、前記操作の内容、及び前記操作をする前の前記レコードのデータの各々を対応付けて記憶し、
前記コンピュータに、
取得した前記データと、該データに対応する前記操作の内容と、該データに対応する前記操作をする前の前記データと、複数の前記操作の間で許容される状態遷移とに基づいて、最後に操作された前記レコードを特定する、
処理を実行させるための付記１０に記載の情報処理プログラム。
１…システム、２…業務サーバ、３…ディスク装置、４…レプリカDB作成サーバ、５…クライアント端末、６…ネットワーク、７…業務アプリ、８…DB管理アプリ、２０…情報処理システム、２１…第１のサーバ、２２…第２のサーバ、２３…ディスク装置、２４…レプリカDB作成サーバ、２５…クライアント端末、２６…ネットワーク、３１…第１の採番DB、３２…第２の採番DB、４１…第１の差分DB、４２…第２の差分DB、４３…マスタDB、４３ａ…レコード、４４…チェックポイントDB、４５…レプリカDB、４９…差分レコード、５１…通信部、５２…制御部、５３…受付部、５４…操作部、５５…通番取得部、５６…データ格納部、６１…通信部、６２…記憶部、６３…制御部、６７…データ取得部、６８…通番取得部、６９…操作部、７０…検知部、７１…特定部、７２…通番格納部、７３…データ格納部、７４…削除部、７５…生成部、７６…判定部、８０…主キー一覧、CT…チェック期間。

Claims (4)

  1. 第１のデータベースの複数のレコードの各々を複数のサーバが操作した後の該レコードのデータと、前記操作が行われた順序を示す識別子とを対応付けて記憶した、複数の前記サーバごとに設けられた複数の第２のデータベースから、第１の期間に記憶された前記データを取得するデータ取得部と、
    取得した前記データを、前記識別子が示す順に第３のデータベースに格納するデータ格納部と、
    を有し、
    前記データ格納部は、同一の前記レコードの前記データが複数の前記第２のデータベースに存在する場合に、同一の前記レコードの前記データのうちで、最後に操作された前記レコードの前記データのみを前記第３のデータベースに格納することを特徴とする情報処理装置。
  2. 前記第２のデータベースは、前記識別子、前記データ、前記操作の内容、及び前記操作をする前の前記レコードのデータの各々を対応付けて記憶し、
    前記データ格納部は、
    取得した前記データと、該データに対応する前記操作の内容と、該データに対応する前記操作をする前の前記データと、複数の前記操作の間で許容される状態遷移とに基づいて、最後に操作された前記レコードを特定することを特徴とする請求項１に記載の情報処理装置。
  3. 情報処理装置と複数のサーバとを備えた情報処理システムであって、
    複数の前記サーバの各々は、
    第１のデータベースのレコードを操作する操作部と、
    複数の前記サーバの各々に対応した複数の第２のデータベースのうちで自装置に対応する前記第２のデータベースに、前記操作をした後の前記レコードのデータを、前記操作を行った順序を示す識別子に対応付けて格納する第１のデータ格納部とを有し、
    前記情報処理装置は、
    複数の前記第２のデータベースの各々から、第１の期間に記憶された前記データを取得するデータ取得部と、
    取得した前記データを、前記識別子が示す順に第３のデータベースに格納する第２のデータ格納部とを有し、
    前記第２のデータ格納部は、同一の前記レコードの前記データが複数の前記第２のデータベースに存在する場合に、同一の前記レコードの前記データのうちで、最後に操作された前記レコードの前記データのみを前記第３のデータベースに格納する、
    ことを特徴とする情報処理システム。
  4. コンピュータに、
    第１のデータベースの複数のレコードの各々を複数のサーバが操作した後の該レコードのデータと、前記操作が行われた順序を示す識別子とを対応付けて記憶した、複数の前記サーバごとに設けられた複数の第２のデータベースから、第１の期間に記憶された前記データを取得し、
    取得した前記データを、前記識別子が示す順に第３のデータベースに格納し、
    同一の前記レコードにおける前記データが複数の前記第２のデータベースに存在する場合に、同一の前記レコードの前記データのうちで、最後に操作された前記レコードに対応する前記データのみを前記第３のデータベースに格納する、
    処理を実行させるための情報処理プログラム。
JP2020074859A 2020-04-20 2020-04-20 情報処理装置、情報処理システム、及び情報処理プログラム Active JP7428894B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2020074859A JP7428894B2 (ja) 2020-04-20 2020-04-20 情報処理装置、情報処理システム、及び情報処理プログラム
US17/156,673 US11561958B2 (en) 2020-04-20 2021-01-25 Information processing device and information processing system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020074859A JP7428894B2 (ja) 2020-04-20 2020-04-20 情報処理装置、情報処理システム、及び情報処理プログラム

Publications (2)

Publication Number Publication Date
JP2021174065A JP2021174065A (ja) 2021-11-01
JP7428894B2 true JP7428894B2 (ja) 2024-02-07

Family

ID=78081764

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020074859A Active JP7428894B2 (ja) 2020-04-20 2020-04-20 情報処理装置、情報処理システム、及び情報処理プログラム

Country Status (2)

Country Link
US (1) US11561958B2 (ja)
JP (1) JP7428894B2 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012155634A (ja) 2011-01-28 2012-08-16 Fujitsu Frontech Ltd 情報処理プログラム、情報処理装置および情報処理方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2718674B2 (ja) * 1987-02-09 1998-02-25 富士通株式会社 データベースシステム
US5280611A (en) * 1991-11-08 1994-01-18 International Business Machines Corporation Method for managing database recovery from failure of a shared store in a system including a plurality of transaction-based systems of the write-ahead logging type
US5778395A (en) 1995-10-23 1998-07-07 Stac, Inc. System for backing up files from disk volumes on multiple nodes of a computer network
JPH11167510A (ja) 1997-12-04 1999-06-22 Hitachi Ltd レプリケーション方法、レプリケーションツール、および、レプリケーションサーバ
US6738748B2 (en) * 2001-04-03 2004-05-18 Accenture Llp Performing predictive maintenance on equipment
WO2004049242A2 (en) * 2002-11-26 2004-06-10 Digimarc Id Systems Systems and methods for managing and detecting fraud in image databases used with identification documents
US7647344B2 (en) * 2003-05-29 2010-01-12 Experian Marketing Solutions, Inc. System, method and software for providing persistent entity identification and linking entity information in an integrated data repository
US7403945B2 (en) * 2004-11-01 2008-07-22 Sybase, Inc. Distributed database system providing data and space management methodology
US7962458B2 (en) * 2008-06-12 2011-06-14 Gravic, Inc. Method for replicating explicit locks in a data replication engine
US10909143B1 (en) * 2017-04-14 2021-02-02 Amazon Technologies, Inc. Shared pages for database copies
US11429576B2 (en) * 2019-07-23 2022-08-30 Macrometa Corporation Methods and systems for garbage deletion in a document database

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012155634A (ja) 2011-01-28 2012-08-16 Fujitsu Frontech Ltd 情報処理プログラム、情報処理装置および情報処理方法

Also Published As

Publication number Publication date
US11561958B2 (en) 2023-01-24
US20210326323A1 (en) 2021-10-21
JP2021174065A (ja) 2021-11-01

Similar Documents

Publication Publication Date Title
US11442961B2 (en) Active transaction list synchronization method and apparatus
JP4414381B2 (ja) ファイル管理プログラム、ファイル管理装置、ファイル管理方法
KR100926880B1 (ko) Ｄｂｍｓ에서의 데이터 복제 방법 및 시스템
US8843454B2 (en) Elimination of duplicate objects in storage clusters
US7672966B2 (en) Adding extrinsic data columns to an existing database schema using a temporary column pool
JPWO2018154698A1 (ja) ファイルストレージ、オブジェクトストレージ、およびストレージシステム
CN110019066A (zh) 数据库处理方法及装置、系统
KR20080106431A (ko) 기업 자원 계획 시스템 내에서의 동시성 제어 방법, 컴퓨터판독가능 매체 및 컴퓨터
JP2006202337A (ja) データ処理の方法及び装置
CN103842969A (zh) 信息处理系统
US20010054045A1 (en) Data management system, server, and data management method
US20100217750A1 (en) Archive apparatus, conversion apparatus and conversion program
CN111930850A (zh) 数据校验方法、装置、计算机设备和存储介质
CN110555317B (zh) 一种应用文件更改处理方法、装置及系统
US7945538B2 (en) Method and arrangements for node recovery
US11687564B2 (en) Continuous real-time masked database replication
CN114741453A (zh) 数据同步的方法、系统及计算机可读存储介质
US20060004877A1 (en) Method and system for data processing with data replication for the same
CN111309799A (zh) 数据合并的实现方法、装置、系统及存储介质
US20120209891A1 (en) Database management method, database management system and database management program
JP3612449B2 (ja) 分散データベースシステムにおける主従関係情報同期方式
JP7428894B2 (ja) 情報処理装置、情報処理システム、及び情報処理プログラム
JP2000259473A (ja) データベース管理方式
JP2002222107A (ja) データ同期装置
KR102214697B1 (ko) 데이터베이스 관리 시스템에서 데이터 저장을 위한 공간 관리를 제공하는 컴퓨터 프로그램

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230112

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20231004

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231017

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231025

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20231226

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240108

R150 Certificate of patent or registration of utility model

Ref document number: 7428894

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150