(57)【要約】【課題】  ネットワークを介して、サーバと複数のデバイス間でデータベースを同期するシステムにおいて、サーバ障害からの復旧後に、サーバの負荷を高めることなく、複数デバイスからの変更をサーバに同期できる状態で、サーバ障害発生中にデバイスが最新のデータを参照可能にする。【解決手段】  サーバ障害の判定または通知に基づいて、データ項目ごとにサーバのデータ同期処理の一部を代行するデバイス（ホストデバイス）を設ける。サーバよりスペックの低いデバイスでデータ同期処理の一部を代替するため、データ項目ごとに処理を受け持つデバイス（ホストデバイス）を割り当て、ホストデバイスは、他のデバイスからの変更要求の受付をおこなうものとする。ホストデバイスでデータ項目ごとに変更要求の蓄積・集約をおこなうことで、サーバ復旧時のサーバの変更要求処理量を減らすとともに、サーバ障害発生中もデバイスが最新のデータを参照可能にする。【選択図】  図１
2015162223.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して、同期処理提供装置との間でデータベースを同期する複数のデータ処理装置のうちの一つのデータ処理装置であり、
前記同期処理提供装置のデータベースと前記データ処理装置のデータベースとを同期する第一の同期モードと、前記データ処理装置のデータベースと他のデータ処理装置のデータベースとを同期する第二の同期モードとを有するデータ処理装置であって、
前記同期処理提供装置の障害の判定または前記同期処理提供装置の障害の通知の少なくとも何れかに基づいて、前記データ処理装置の同期モードを判定する判定手段と、
前記判定手段で前記第一の同期モードと判定された場合、前記データ処理装置のデータの変更要求を前記同期処理提供装置に送信し、前記判定手段で前記第二の同期モードと判定された場合、前記データ処理装置のデータの変更要求を他のデータ処理装置に送信する送信手段と、
を備えることを特徴とするデータ処理装置。
【請求項２】
前記判定手段では、前記データ処理装置のデータベースのデータ項目ごとに前記同期モードを判定し、
前記送信手段は、前記第一の同期モードと判定されたデータ項目のデータの変更要求を前記同期処理提供装置に送信し、前記第二の同期モードと判定されたデータ項目のデータの変更要求を前記他のデータ処理装置に送信することを特徴とする請求項１記載のデータ処理装置。
【請求項３】
前記第二の同期モードで、前記データ処理装置のデータベースと前記他のデータ処理装置のデータベースとを同期するために、
前記データ処理装置のデータベースのデータ項目ごとに異なるように対応付けられた他のデータ処理装置を判断する判断手段と、
前記データ処理装置のデータベースのデータの変更要求を対応する前記他のデータ処理装置に送信する送信手段と、
前記他のデータ処理装置のデータベースのデータ更新の有無を問い合わせて更新があった場合に、前記他のデータ処理装置から更新されたデータを取得する取得手段と、
を更に備えることを特徴とする請求項１または２記載のデータ処理装置。
【請求項４】
前記判定手段で前記第一の同期モードと判定され、前記送信手段で前記データ処理装置のデータの変更要求を前記同期処理提供装置へ送信し、前記同期処理提供装置による該データの同期処理が終わる前に前記同期処理提供装置の障害を通知された場合、前記送信手段は、前記データの変更要求を前記他のデータ処理装置に送信することを特徴とする請求項１乃至３何れか１項に記載のデータ処理装置。
【請求項５】
前記送信手段の送信先の他のデータ処理装置は前記データ処理装置のデータベースのデータ項目ごとに予め定められていることを特徴とする請求項１乃至４何れか１項に記載のデータ処理装置。
【請求項６】
前記送信手段の送信先の他のデータ処理装置を他のデータ処理装置の負荷状況に応じて決定する決定手段を更に備えることを特徴とする請求項１乃至５何れか１項に記載のデータ処理装置。
【請求項７】
前記データ項目は、表領域、テーブル、レコードの何れかであることを特徴とする請求項２、３、５何れか１項に記載のデータ処理装置。
【請求項８】
ネットワークを介して、同期処理提供装置との間でデータベースを同期する複数のデータ処理装置のうちの一つのデータ処理装置であり、
前記同期処理提供装置のデータベースと前記データ処理装置のデータベースとを同期する第一の同期モードと、前記データ処理装置のデータベースと他のデータ処理装置のデータベースとを同期する第二の同期モードとを有するデータ処理装置であって、
前記同期処理提供装置の障害の判定または前記同期処理提供装置の障害の通知の少なくとも何れかに基づいて、前記データ処理装置の同期モードが前記二の同期モードと判定された場合、前記他のデータ処理装置から受け付けたデータの変更要求を集約するデータ処理手段と、
前記同期処理提供装置の復旧の判定または前記同期処理提供装置の復旧の通知の少なくとも何れかに基づいて、
前記データ処理装置の同期モードが前記第一のモードと判定された場合、前記データ処理手段で集約したデータの変更要求を同期処理提供装置に送信する送信手段と、
を備えることを特徴とするデータ処理装置。
【請求項９】
前記第二の同期モードにおいて、
前記データ処理装置で集約したデータの変更要求を同期処理提供装置へ送信して以降、同期処理提供装置からの同期再開通知を受信するまでの間に、他のデータ処理装置から受け付けた差分のデータの変更要求を蓄積することを特徴とする請求項８記載のデータ処理装置。
【請求項１０】
前記第二の同期モードにおいて、
前記他のデータ処理装置から前記データ処理装置のデータベースのデータ更新の有無の問い合わせを受け、更新があった場合に、前記他のデータ処理装置に更新されたデータを送信することを特徴とする請求項８記載のデータ処理装置。
【請求項１１】
ネットワークを介して、複数のデータ処理装置とデータベースを同期する同期処理提供装置であって、
前記同期処理提供装置が障害から復旧した場合、前記複数のデータ処理装置から受け付けたデータの変更要求を集約するデータ処理装置から、集約されたデータの変更要求を受信する受信手段と、
データの変更を前記同期処理提供装置のマスタデータベースへ反映する反映手段と、
前記データの変更を前記同期処理提供装置のマスタデータベースへ反映し終わると、前記同期処理提供装置による前記複数のデータ処理装置のデータベースと前記同期処理提供装置のマスタデータベースとのデータ同期処理の再開通知を、前記複数のデータ処理装置のうちの少なくとも１つのデータ処理装置に送信する送信手段と、
を備えることを特徴とする同期処理提供装置。
【請求項１２】
前記反映手段は、前記データベースのデータ項目ごとに前記データの変更を前記マスタデータベースに反映させ、
前記データ項目ごとに、前記同期処理提供装置による前記複数のデータ処理装置のデータベースと前記同期処理提供装置のマスタデータベースとのデータ同期処理を再開することを特徴とする請求項１１記載の同期処理提供装置。
【請求項１３】
前記データ項目は、表領域、テーブル、レコードの何れかであることを特徴とする請求項１２に記載の同期処理提供装置。
【請求項１４】
ネットワークを介して、同期処理提供装置との間でデータベースを同期する複数のデータ処理装置のうちの一つのデータ処理装置であり、
前記同期処理提供装置のデータベースと前記データ処理装置のデータベースとを同期する第一の同期モードと、前記データ処理装置のデータベースと他のデータ処理装置のデータベースとを同期する第二の同期モードとを有するデータ処理装置を制御するデータ処理方法であって、
前記同期処理提供装置の障害の判定または前記同期処理提供装置の障害の通知の少なくとも何れかに基づいて、前記データ処理装置の同期モードを判定する判定工程と、
前記判定工程で前記第一の同期モードと判定された場合、前記データ処理装置のデータの変更要求を前記同期処理提供装置に送信し、前記判定工程で前記第二の同期モードと判定された場合、前記データ処理装置のデータの変更要求を他のデータ処理装置に送信する送信工程と、
を備えることを特徴とするデータ処理方法。
【請求項１５】
ネットワークを介して、同期処理提供装置との間でデータベースを同期する複数のデータ処理装置のうちの一つのデータ処理装置であり、
前記同期処理提供装置のデータベースと前記データ処理装置のデータベースとを同期する第一の同期モードと、前記データ処理装置のデータベースと他のデータ処理装置のデータベースとを同期する第二の同期モードとを有するデータ処理装置を制御するデータ処理方法であって、
前記同期処理提供装置の障害の判定または前記同期処理提供装置の障害の通知の少なくとも何れかに基づいて、前記データ処理装置の同期モードが前記二のモードと判定された場合、前記他のデータ処理装置から受け付けたデータの変更要求を集約するデータ処理工程と、
前記同期処理提供装置の復旧の判定または前記同期処理提供装置の復旧の通知の少なくとも何れかに基づいて、
前記データ処理装置の同期モードが前記第一のモードと判定された場合、前記データ処理工程で集約したデータの変更要求を同期処理提供装置に送信する送信工程と、
を備えることを特徴とするデータ処理方法。
【請求項１６】
ネットワークを介して、複数のデータ処理装置とデータベースを同期する同期処理提供装置を制御する同期処理提供方法であって、
前記同期処理提供装置が障害から復旧した場合、前記複数のデータ処理装置から受け付けたデータの変更要求を集約するデータ処理装置から、集約されたデータの変更要求を受信する受信工程と、
データの変更を前記同期処理提供装置のマスタデータベースへ反映する反映工程と、
前記データの変更を前記同期処理提供装置のマスタデータベースへ反映し終わると、前記同期処理提供装置による前記複数のデータ処理装置のデータベースと前記同期処理提供装置のマスタデータベースとのデータ同期処理の再開通知を、前記複数のデータ処理装置のうちの少なくとも１つのデータ処理装置に送信する送信工程と、
を備えることを特徴とする同期処理提供方法。
【請求項１７】
請求項１４に記載のデータ処理方法をコンピュータに実行させるためのプログラム。
【請求項１８】
請求項１５に記載のデータ処理方法をコンピュータに実行させるためのプログラム。
【請求項１９】
請求項１６に記載の同期処理提供方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介したデータベースの同期に関するものである。
【背景技術】
【０００２】
複数のデバイス間でデータの同期を取ることが一般的になっている。例えば、タブレット端末やカメラ、複合機に代表されるデバイスに記録されているスケジュールや写真、アドレス帳、設定値情報などのデータをサーバに同期することにより、複数のデバイスの間でのデータ共有が実現されている。これらのデータは、通常、デバイスのデータベースに格納されて管理されている。デバイスは、データ処理装置であり、サーバは同期処理提供装置である。
【０００３】
一般的なデータ同期システムでは、１つのサーバと複数のデバイス間で同期をおこなう。全デバイスのデータを１ヶ所のサーバに集めている。データの変更は、サーバを介して全デバイスに同期されており、全デバイスのデータは常に最新の状態に保たれている。このようなデータ同期システムの課題として、サーバの障害を挙げることができる。サーバで障害が発生している間は、データの同期処理をおこなえないので最新のデータを利用できない上、サーバの復旧直後にデバイスから大量の同期処理が依頼されるため、復旧時のサーバの負荷が高まってしまう。
【０００４】
特許文献１は、複数のサーバで構成されるシステムであり、データ項目ごとにデータ同期を担当するサーバを割り当てる方式が開示されている。１つのサーバに障害が発生した際には、該当サーバのデータ同期処理を別の稼働中のサーバが代替することで、システムとしての同期を保つことができる。
【０００５】
特許文献２は、１つのサーバと１つのデバイスから構成されるシステムであり、デバイスはサーバへの変更命令を蓄積・集約する手段をもつ。これから変更をおこなうデータ項目と同一項目への変更命令がすでに蓄積されている場合には、蓄積済みの該当項目に対する変更情報を削除したうえで、新しい変更情報を蓄積する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−３３９０７９
【特許文献２】特開２００１−２９７０２５
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１は、１つのサーバに障害が発生した際に、他のサーバでデータ同期処理を代替することができるが、高スペックのサーバが複数台必要となる。特許文献２は、サーバへの変更命令が多発した場合でも変更要求を集約して保持するため、サーバが要求される変更処理量が少なくなるという利点がある。ただし、複数のデバイス間の変更を集約するものではなく、サーバに障害が発生した期間中は、データ同期処理をおこなうことができないため、デバイスが最新のデータを参照できなくなるという課題がある。
【０００８】
本発明は、上記の問題を鑑みてなされたものであり、同期処理提供装置の障害発生中に複数のデータ処理装置が最新のデータを参照可能にすることを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係るデータ処理装置は以下の構成を備える。すなわち、ネットワークを介して、同期処理提供装置との間でデータベースを同期する複数のデータ処理装置のうちの一つのデータ処理装置であり、前記同期処理提供装置のデータベースと前記データ処理装置のデータベースとを同期する第一の同期モードと、前記データ処理装置のデータベースと他のデータ処理装置のデータベースとを同期する第二の同期モードとを有するデータ処理装置であって、前記同期処理提供装置の障害の判定または前記同期処理提供装置の障害の通知の少なくとも何れかに基づいて、前記データ処理装置の同期モードを判定する判定手段と、前記判定手段で前記第一の同期モードと判定された場合、前記データ処理装置のデータの変更要求を前記同期処理提供装置に送信し、前記判定手段で前記第二の同期モードと判定された場合、前記データ処理装置のデータの変更要求を他のデータ処理装置に送信する送信手段。
【００１０】
本発明に係るデータ処理装置は以下の構成を備える。すなわち、ネットワークを介して、同期処理提供装置との間でデータベースを同期する複数のデータ処理装置のうちの一つのデータ処理装置であり、前記同期処理提供装置のデータベースと前記データ処理装置のデータベースとを同期する第一の同期モードと、前記データ処理装置のデータベースと他のデータ処理装置のデータベースとを同期する第二の同期モードとを有するデータ処理装置であって、前記同期処理提供装置の障害の判定または前記同期処理提供装置の障害の通知の少なくとも何れかに基づいて、前記データ処理装置の同期モードが前記二のモードと判定された場合、前記他のデータ処理装置から受け付けたデータの変更要求を集約するデータ処理手段と、前記同期処理提供装置の復旧の判定または前記同期処理提供装置の復旧の通知の少なくとも何れかに基づいて、前記データ処理装置の同期モードが前記第一のモードと判定された場合、前記データ処理手段で集約したデータの変更要求を同期処理提供装置に送信する送信手段。
【００１１】
本発明に係る同期処理提供装置は以下の構成を備える。すなわち、ネットワークを介して、複数のデータ処理装置とデータベースを同期する同期処理提供装置であって、前記同期処理提供装置が障害から復旧した場合、前記複数のデータ処理装置から受け付けたデータの変更要求を集約するデータ処理装置から、集約されたデータの変更要求を受信する受信手段と、データの変更を前記同期処理提供装置のマスタデータベースへ反映する反映手段と、前記データの変更を前記同期処理提供装置のマスタデータベースへ反映し終わると、前記同期処理提供装置による前記複数のデータ処理装置のデータベースと前記同期処理提供装置のマスタデータベースとのデータ同期処理の再開通知を、前記複数のデータ処理装置のうちの少なくとも１つのデータ処理装置に送信する送信手段。
【発明の効果】
【００１２】
本発明によれば、あるデータ処理装置がデータの変更要求の蓄積を行うようにすることで、同期処理提供装置の障害発生中に複数のデータ処理装置が最新のデータを参照可能にする。
【図面の簡単な説明】
【００１３】
【図１】本実施形態のデータ同期のイメージを示す図。
【図２】本実施形態のシステムの構成を示す図。
【図３】本実施形態のユーザデータの形式を示す図。
【図４】第１の実施形態の管理データの形式を示す図。
【図５】本実施形態のアイドル時のデバイスの処理を示すフローチャート。
【図６】本実施形態のデータ変更反映時のデバイスの処理を示すフローチャート。
【図７】本実施形態におけるデバイス間同期モード移行時のデバイスの処理を示すフローチャート。
【図８】本実施形態におけるホストデバイスにおける変更要求集約・送信処理を示すフローチャート。
【図９】本実施形態におけるデータアクセス時のデバイスの処理を示すフローチャート。
【図１０】本実施形態における通常同期モード時のデバイスの処理を示すフローチャート。
【図１１】本実施形態におけるデバイス間同期モード時のデバイスの処理を示すフローチャート。
【図１２】第１の実施形態におけるデータ同期中にサーバ障害が起こった場合の同期モード移行を示すフローチャート。
【図１３】第１の実施形態におけるサーバ復旧処理を示すフローチャート。
【図１４】第２の実施形態の管理データの形式を示す図。
【図１５】第２の実施形態におけるサーバ復旧処理を示すフローチャート。
【図１６】ステップＳ１５０３の詳細な処理を示すフローチャート。
【発明を実施するための形態】
【００１４】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
【００１５】
（第１の実施形態）
図１は、本実施形態におけるデータ同期のイメージを示す図である。本実施形態のデータ同期システムは、同期サーバ１０１と複数のデバイス１０２およびデバイス１０３（デバイスはｎ個）で構成される。デバイスはデータ処理装置である。サーバは同期処理提供装置である。同期サーバ１０１とデバイス１０２およびデバイス１０３は、インターネットやイントラネット経由で通信することができる。本実施形態では、マスタデータベース１０４およびローカルデータベース１０５内に格納するデータとして、複数ユーザで共有するアドレス帳データを用いる。ローカルデータベースは各デバイスに存在する。ユーザのアドレス帳データは、所属部門単位ごとに管理されており、マスタデータベース１０４上に集約されている。各ユーザが保持するデバイス上のローカルデータベースは、マスタデータベース１０４と同期している。デバイスに接続されている通信回線に障害が発生するなど、ネットワークにつながらない状況が発生しても、マスタデータベース１０４と同期済みのデータについては、ローカルデータベースを参照することで、最新のアドレス帳を参照することが可能である。本同期システムは、同期モードとして２つの同期モードを備える。サーバに障害が発生していない時の同期モードである通常同期モードと、サーバ障害発生時の同期モードであるデバイス間同期モードである。
【００１６】
図１（Ａ）は、通常同期モード時の同期構成を示した図である。通常同期モードでは、マスタデータベース１０４とローカルデータベース内のデータは双方向に同期されており、一方のデータベースへの変更はリアルタイムに他方へ反映される。つまり、デバイス１０２でローカルデータベース１０５に変更がおこなわれると、その変更要求が同期サーバ１０１に送信され、マスタデータベース１０４に変更内容が反映される。その上で、同期サーバ１０１から他のデバイス群に変更要求が送信され、各デバイス内のローカルデータベースに変更内容が反映される。
【００１７】
図１（Ｂ）は、デバイス間同期モード時の同期構成を示した図である。ここでは、同期サーバ１０１にシステム障害あるいは通信障害が発生し、デバイスとの通信がおこなえない状態となっている。デバイス間同期モードでは、同期サーバ１０１の機能の一部をデバイスが代替する。この代替デバイスを「ホストデバイス」と呼ぶ。本図では、デバイス１０３がホストデバイスとして機能している。本実施形態では、ホストデバイスは、データ項目ごとに設定される。１つのホストデバイスがサーバの役割を果たすのは、メモリ量・演算能力などの不足により難しい。複数のホストデバイスが、ほぼ重複しないデータ範囲のデータの同期処理を分担すれば、サーバ復旧時にホストデバイスからサーバに変更を反映するときに、競合が生じないという利点がある。
【００１８】
デバイス間同期モードにおいて、ホストデバイスは、各デバイスの単方向同期対象である。デバイス１０２内のローカルデータベース１０５内の特定のデータ項目への変更は、そのデータ項目のホストデバイスであるデバイス１０３内のローカルデータベース１０６に単方向に同期される。単方向同期であるとは、ホストデバイスのローカルデータベース１０６の変更はホストデバイス以外のローカルデータベース１０５に自動で反映されないということを意味する。つまり、特定のデータ項目についてホストデバイスのローカルデータベース１０６は常に最新であるが、ホストデバイス以外のローカルデータベース１０５は常に最新であるとは限らない状態になっている。各デバイスからホストデバイスに要求すれば、各デバイスのデータをホストデバイスの最新のデータと同期することができる。
【００１９】
図２（Ａ）は、本実施形態を適用するデータ同期システムを示す構成図である。図１（Ａ）記載の同期サーバ１０１とデバイス１０２の内部構成を示している。デバイス１０２とデバイス１０３含めｎ個のデバイスの内部構成は同一であるため、記載を省略する。
【００２０】
同期サーバ１０１は、１つあるいは複数のＰＣから構成される。ＣＰＵ２０１は、ＲＯＭ２０２に格納されている制御プログラムを実行することにより、同期サーバ１０１の制御をおこなう。同期サーバ１０１がプログラムを実行することにより、当該システムは、後述するフローチャートに示す各処理を実行するための各種手段として機能する。ＲＡＭ２０３は、各構成要素からの各種データを一時記憶する。また、プログラムを展開し、同期サーバ１０１が実行可能な状態にする。記憶装置２０４は、本実施形態の処理対象となるデータを保持している。たとえば、同期対象となるデータそのものや、その管理情報をマスタデータベース１０４に格納して保持することができる。記憶装置２０４としては、フラッシュメモリ、ＨＤＤなどを用いることができる。同期サーバ１０１は、通信部２０５を介して、デバイス１０２と通信することができる。
【００２１】
デバイス１０２は、タブレット端末、携帯電話端末、デジタルカメラ、プリンタ複合機等である。ＣＰＵ２０６は、ＲＯＭ２０７に格納されている制御プログラムを実行することにより、デバイス１０２の制御をおこなう。デバイスはデータ処理を行うデータ処理装置である。ＲＡＭ２０８は、各構成要素からの各種データを一時記憶する。また、プログラムを展開し、デバイス１０２が実行可能な状態にする。入力部２０９は、操作ボタン、タッチパネル等で構成され、ユーザからの指示を受け付ける。表示部２１０は、液晶パネル等で構成され、本実施形態の処理対象となるデータを表示する。記憶装置２１１は、本実施形態の処理対象となるデータを保持している。たとえば、同期対象となるデータそのものや、その管理情報をローカルデータベース１０５に格納して保持することができる。また、デバイス１０２は、通信部２１２を介して、同期サーバ１０１と通信することができる。
【００２２】
なお、本実施形態では後述するフローチャートの各ステップに対応する処理を、ＣＰＵ２０１およびＣＰＵ２０６を用いてソフトウェアで実現するが、その処理の一部又は全部を電子回路などのハードウェアで実現するようにしても良い。
【００２３】
図２（Ｂ）は、本実施形態におけるデータ処理部分の構成を示した構成図である。デバイス１０２内の同期モード変更部２１３は、２つの同期モードの切り替え処理をおこなう。同期モード判定部２１４は、データへのアクセス要求発生時に同期モードを判定し、判定された同期モードに応じた処理を指示する。データアクセス要求は、データへの登録・削除・更新・検索処理を指す。このうち、データへの登録・削除・更新をまとめて、変更要求と表現する。データ処理部２１５は、ユーザからのアクセス要求やサーバからの変更要求に応じて、ローカルデータベース１０５への変更・検索処理を実施する。また、自身がホストデバイスとして機能する場合には、他のデバイスからの変更要求を蓄積し、集約する処理をおこなう。
【００２４】
データ受信部２１６は、同期サーバ１０１や他のデバイスからの通知の受け取りや、同期対象となる変更要求の受信をおこなう。データ送信部２１７は、同期サーバ１０１や他のデバイスへ情報を通知や、変更要求の送信をおこなう。
【００２５】
同期サーバ１０１は、データ処理部２１８を持ち、デバイスから受信した変更要求に応じて、マスタデータベース１０４への変更処理を実施する。同期処理部２１９は、データ処理部２１８がマスタデータベース１０４への変更処理を実施した場合に、全デバイスに対して変更要求を送信する指示を出す。また、データ送信部２２０とデータ受信部２２１を持ち、デバイス１０２のデータ受信部２１６、データ送信部２１７と、それぞれ通知情報や変更要求の送受信をおこなう。
【００２６】
図３は、本システムにおいて扱うユーザデータの形式を示した図である。テーブル３０１およびテーブル３０６は、４つのカラムから構成されており、ユーザのアドレス帳データを格納している。４つのカラムはそれぞれ、アドレスの識別情報であるＩＤ３０２、名前３０３、電話番号３０４、メールアドレス３０５を管理するものである。ＩＤ３０２はアドレス帳内で一意であり、たとえば住所情報などの拡張情報を、テーブル３０１・テーブル３０６から分離して別テーブルで管理する場合に、レコードの対応付けに用いることができる。本例では、部門ごとにアドレス帳を管理しており、部門単位でテーブルが作成されている。テーブル３０１とテーブル３０６は、スキーマ構成は同一であるが、それぞれ別部門のアドレス帳を管理するものである。
【００２７】
テーブル３０７は、ユーザ名３０８と所属部門３０９の対応を管理するものであり、テーブル３１０は、部門３１１と部門に対応するアドレス帳を管理するテーブル名３１２の対応を管理するものである。ユーザが機器にログインした際に、テーブル３０７を参照し、ユーザの所属部門を取得し、そのうえで、テーブル３１０から所属部門に対応するアドレス帳を管理するテーブル名を取得しておく。ユーザからのアドレス帳の参照・変更要求があった場合には、取得済みのテーブル名を利用して、該当テーブルへのアクセスをおこなう。
【００２８】
データへの変更要求は、システム内部では、ＳＱＬ文で表現される。変更要求は、ＩＮＳＥＲＴ文、ＤＥＬＥＴＥ文、ＵＰＤＡＴＥ文のいずれかから成るＳＱＬクエリを指す。ＤＥＬＥＴＥ文、ＵＰＤＡＴＥ文のＷＨＥＲＥ句には、必ずＩＤ３０２が指定され、変更対象のレコードをクエリから特定可能になっている。
【００２９】
図４は、同期処理のための管理データの形式を示した図である。本実施形態では、ユーザデータのテーブル単位でホストデバイスを設定する。テーブルごとにホストデバイスを設定することで、各データは一意のホストデバイスに対応付けられることになる。本構成によって同一のデータは１つのホストデバイスに集約されるため、複数のホストデバイス間での変更の競合が発生しない。テーブル４０１は、ユーザデータのテーブル名４０２に対応付けられたホストデバイス名４０３を記録する。
【００３０】
また、本実施形態では、サーバの障害が検出された場合に、ホストデバイスにサーバ障害を通知し、ホストデバイスが複数のデバイスにサーバ障害を通知することで、サーバの障害情報を伝搬（送信）する構成とする。もちろん、全てのデバイスに一斉にサーバ障害を通知しても良い。
【００３１】
そのために、各デバイスとホストデバイスの通知伝搬のための対応付けをテーブル４０４に設定しておく。テーブル４０４は、デバイス名４０５が通知送信先であり、ホストデバイス４０６が通知送信元であることを示している。ホストデバイス以外のデバイスがサーバ障害を検出した場合には、まず自身の通知送信元として設定されたホストデバイスにサーバ障害を通知する。通知を受け取ったホストデバイスは、自身の通知送信先として設定された複数デバイスにサーバ障害を通知する。また、ホストデバイス自身がサーバ障害を検出した場合の処理体系を単純化するため、ホストデバイスについても通知送信元として自身を設定しておく。
【００３２】
また、本図には記載していないが、デバイスごとに現在の同期モードが通常モードとデバイス間同期モードのどちらのモードであるかを管理する構造をもち、同期モード判定部２１４において、同期モードの判定に用いる。図４に示した管理テーブルをサーバおよび全デバイスが保持しており、データに対応付けられたホストデバイスの判定や、自身がホストデバイスであるか否かの判定、自身の通知送信先のデバイスの特定のために参照する。自デバイスに関係するテーブル・自デバイスに対応づいたホストデバイスの情報のみ切り出して保持しても良い。
【００３３】
上述の動作を、フローチャートに従って説明する。
【００３４】
図５は、デバイスのアイドル時の処理を示したフローチャートである。サーバや他のデバイスからのデータ受信があった場合に、データ種別に応じた処理を実施するものである。
【００３５】
まず、ステップＳ５０１では、サーバや他のデバイスから送られてきたデータの受信があったか否かを判定する。データを受信した場合には、受信データの種別によって、ステップＳ５０２〜ステップＳ５０５へ処理が分岐する。受信データが、サーバや他のデバイスからの同期対象データである場合には、ステップＳ５０２へ進む。ステップＳ５０２では、受信した変更要求の自身のローカルデータベースへの反映処理をおこなう。
【００３６】
受信データが、サーバの障害通知であった場合には、ステップＳ５０３へ、サーバからの同期再開通知であった場合には、ステップＳ５０４へ、サーバの復旧通知であった場合には、ステップＳ５０５へと分岐する。ステップＳ５０３では、自身の同期モードのデバイス間同期モードへの変更を行う。ステップＳ５０４では、自身の同期モードの通常同期モードへの変更を行う。ステップＳ５０５では、ホストデバイスなら、変更要求の集約をおこない、集約した変更要求をサーバへ送信する処理をおこなう。復旧通知が受けてから変更要求の集約を行っても良いし、復旧通知を受ける前に順次、変更要求の集約を行っていても良い。ステップＳ５０２、ステップＳ５０３、ステップＳ５０５の詳細は、別フローにて説明する。
【００３７】
一方、ステップＳ５０１で、サーバや他のデバイスから送られてきたデータの受信がなかった場合には、本フローを終了する。
本フローは、他の処理要求が割り込まない限り、ステップＳ５０１から繰り返し実行される。一定期間サーバからのデータ受信がない場合には、サーバ障害発生有無の確認をおこなうものとする。サーバに問い合わせをおこない、応答があるか否かによりサーバ障害の発生を判定する。サーバからの応答がなかった場合に、サーバ障害が発生したと判定し、自身のホストデバイスに、サーバ障害を通知する。
【００３８】
図６は、ステップＳ５０２のデバイスにおける変更要求反映処理のフローチャートである。通常同期モード時には、サーバからの変更要求の反映処理であり、デバイス間同期モード時は、他のデバイスからの変更要求をホストデバイスとして反映する処理となる。デバイス間同期モードにおいて、本フローはホストデバイスでのみ実施されるものである。
【００３９】
まず、ステップＳ６０１で、自身のローカルデータベースにサーバまたは他のデバイスからの同期データの反映をおこなう。次に、ステップＳ６０２で、同期モードを判定する。同期モードがデバイス間同期モードである場合には他のデバイスから自身（本フローではホストデバイス）に対しての変更要求を蓄積する。これは、サーバ障害発生間に自身（本フローではホストデバイス）のローカルデータベースに対しておこなった変更を、サーバ復旧後にサーバのマスタデータベースに反映するためである。一方、同期モードが通常モードである場合には、本フローを終了する。
【００４０】
図７は、ステップＳ５０３のデバイス間同期モードへ移行する際のデバイスの処理を示すフローチャートである。本フローは、サーバの障害通知またはサーバの障害判定をトリガとして実施される。
【００４１】
まず、ステップＳ７０１で自身の同期モードをデバイス間同期モードに変更する。次に、ステップＳ７０２で自身がホストデバイスであるか否かを判断する。ホストデバイスであった場合には、ステップＳ７０３で自身の通知送信先として図４の４０４のテーブルで設定された全デバイスにサーバの障害を通知する。
【００４２】
つづいて、ステップＳ７０４で、サーバ障害の通知元を判定する。通知元が他のホストデバイスであった場合には、そのまま本フローを終了する。通知元が他のホストデバイス以外、つまりホストデバイス自身または自身の通知送信先のデバイスであった場合には、ステップＳ７０５で他のホストデバイスにサーバ障害を通知して処理を終える。
【００４３】
図８は、ホストデバイスにおけるステップＳ５０５の変更要求集約・送信処理のフローチャートである。本フローでは、データ項目ごとにレコード単位で変更要求を集約し、変更要求のサイズを圧縮する。ここでは、１テーブルが１つのデータ項目に相当する。本フローは、サーバの復旧通知をトリガとして実施される。変更要求の集約には、一般的なトランザクションログ圧縮の技術を利用することができる。本フローではＵＰＤＡＴＥクエリのみを受け付ける場合について記載するが、本実施形態で利用できる変更要求集約処理はこれに限定されるものではない。
【００４４】
まずステップＳ８０１で、集約対象のレコードを設定する。つづいて、ステップＳ８０２で、ステップＳ８０１で設定したレコードに対する変更要求が複数あるかをチェックする。同一レコードに対する変更要求が複数あった場合には、ステップＳ８０３へ進み、同一のレコードに対する変更要求の中から、最新のタイムスタンプの変更要求以外を削除し、集約する。ステップＳ８０４で、全レコードに対して、変更要求の集約が終了したかを判定し、未集約のレコードがある場合には、ステップＳ８０１から処理を繰り返す。全データ項目に対して、変更要求の集約が終了した場合には、ステップＳ８０５でサーバに集約した変更要求を送信し、本フローを終了する。
【００４５】
なお、本フローで変更要求をサーバへ送信して以降、同期再開通知を受信するまでの間に、デバイスから変更要求を受け付けた場合には、サーバへの変更要求送信時点からの差分の変更要求の蓄積をおこなう。図５のステップＳ５０４で同期再開通知を受信し、通常同期モードへ移行したときに、差分の変更要求をサーバへ送信する。
【００４６】
図９は、ユーザからのデータアクセス要求が発生した場合のデバイスにおける処理を示すフローチャートである。まず、ステップＳ９０１で、自身の同期モードを判定する。判定処理は、自身が保持している同期モードの情報を読み取って同期モード判定部２１４において判定する。同期モードが通常同期モードである場合には、ステップＳ９０２へ、デバイス間同期モードである場合には、ステップＳ９０３へ進む。ステップＳ９０２およびステップＳ９０３の具体的な処理内容は別フローにて記載する。
【００４７】
図１０は、通常同期モード時のデータアクセス処理のフローチャートである。まず、ステップＳ１００１で、自身のデータベースに対して、ユーザからの要求に応じた変更・検索処理をおこなう。ステップＳ１００２では、ステップＳ１００１でおこなった処理が変更処理であったか否かを判定する。変更処理が実施された場合には、サーバのデータベースへ同期が必要であるため、ステップＳ１００３へ進み、サーバに変更要求を送信する。一方、変更処理がおこなわれなかった場合には、本フローを終了する。
【００４８】
図１１は、デバイス間同期モード時のデータアクセス処理のフローチャートである、まず、ステップＳ１１０１でアクセス対象のデータに対応付けられたホストデバイスを判定する。本実施形態では、アクセス対象のデータのテーブルに基づいて、テーブル４０１を参照することでホストデバイスの判定をおこなう。
【００４９】
次に、ステップＳ１１０２で、自身のデータベース内のアクセス対象データが最新であるか否かを判定する。自身のデータベース内のデータよりもホストデバイスのデータのほうが、他のデバイスからのデータ変更要求により更新されて新しいことがある。本処理は、ステップＳ１１０１で判定したホストデバイスにデータ更新の有無の問い合わせをおこなうことで実現する。たとえば、データ項目やテーブルごとに変更日時を示すタイムスタンプを設け、自身のデータベース内のデータのタイムスタンプと、ホストデバイス内のデータのタイムスタンプを比較することで、データが最新であるか否かを判定することができる。自身のデータが最新でなかった場合には、ステップＳ１１０３へ進み、ホストデバイスから最新のデータを受信し、自身のデータベースに同期をおこない、ステップＳ１１０４へ進む。自身のデータが最新であった場合には、データの同期はおこなわずに、ステップＳ１１０４へ進む。
【００５０】
ステップＳ１１０４では、ユーザからのアクセス要求に応じたデータの変更・検索処理をおこなう。ステップＳ１１０５では、ステップＳ１１０４において、データの変更処理がおこなわれたか否かを判定する。変更処理がおこなわれた場合には、ホストデバイスに対して変更処理の同期が必要であるため、ステップＳ１１０６でホストデバイスに変更要求を送信する。変更処理がおこなわれなかった場合には、本フローを終了する。
【００５１】
図１２は、図１０のステップＳ１００３で、デバイスがサーバへ変更要求を送信中に、サーバに障害が発生した場合のデバイスの処理フローを示すフローチャートである。サーバへ変更要求送信中にサーバ障害が発生した場合に、デバイス間同期モードへ移行するよう構成することができる。本フローは、図７に示すフローチャートで同期モードをデバイス間同期モードに変更した後に、実施するものである。
【００５２】
まずステップＳ１２０１で、サーバへの送信途中であったデータに対応付けられたホストデバイスを判定する。次にステップＳ１２０２で、自身のデータベース内のアクセス対象データが最新であるか否かを判定する。本処理は、図１１のステップＳ１１０２で示した処理と同様におこなうことができる。ホストデバイス内のデータと同期しているかチェックしている。自身のデータが最新でなかった場合には、ステップＳ１２０３へ進み、図１０のステップＳ１００１で実施済みであった変更処理の破棄をおこなう。その上で、ステップＳ１２０４でホストデバイスから最新のデータを受信し、自身のデータベースに同期をおこない、ステップＳ１２０５で、自身のデータベースへの変更処理を再度実施する。これは、自身とホストデバイスにおいて、同タイミングで変更処理がおこなわれた場合には、変更競合を解消するために、まずホストデバイス側の変更処理を反映し、その変更内容を参照した上で、自身の変更要求の反映をおこなうことを示している。たとえば（Ａ，Ｂ，Ｃ）という３種類の値が格納されたデータベースがあった場合に、ホストデバイスでＡをＢに変更という処理が実行され、（Ｂ，Ｂ，Ｃ）というデータに変更されたとする。その後に、わずかな時間差で他のデバイスでＢをＣに変更という処理を実行する場合、本来データは、（Ｃ，Ｃ，Ｃ）という状態になるべきである。このとき、ホストデバイスでの変更結果を反映できていない状態で、処理を実行してしまうと、（Ａ，Ｃ，Ｃ）という状態になってしまう。このように、変更競合とは、同一データに対して、複数デバイスが同タイミングで変更をおこなったために、正しい値が得られない状態である。
【００５３】
ステップＳ１２０５の後またはステップＳ１２０２で自身のデータが最新であると判断された場合には、ステップＳ１２０６へ進む。ステップＳ１２０６では、ホストデバイスに変更要求を送信し、本フローを終了する。
【００５４】
図１３は、同期サーバ１０１が、障害から復旧する際の処理を示したフローチャートである。起動時に障害復旧処理であるか否かを判定し、障害復旧処理である場合には、ホストデバイスからの変更要求を順次受け付け、サーバ内のデータベースに反映をおこなった後に、システム全体での同期処理を再開する。
【００５５】
ステップＳ１３０１でシステムを起動し、ステップＳ１３０２で障害からの復旧であるか否かを判定する。この判定は、たとえば正常終了時にログを記録するようにし、終了ログがあるか否かで判定することができる。障害復旧であった場合には、ステップＳ１３０３へ進み、そうでなかった場合には本フローを終了する。ステップＳ１３０３では、サーバ内のデータベースに、ホストデバイスからの変更を反映するデータ項目を１つ設定する。ここで設定したデータ項目についての同期処理をステップＳ１３０４〜ステップＳ１３０６でおこなう。
【００５６】
ステップＳ１３０４では、ステップＳ１３０３で設定したデータ項目に対応するホストデバイスに対して、サーバの復旧を通知する。ステップＳ１３０５では、対象のホストデバイスから集約された変更要求を受信し、ステップＳ１３０６でサーバ内のデータベースに反映する。ステップＳ１３０７で全項目の変更反映が終了したかを判定し、終了していない場合にはステップＳ１３０３から処理を繰り返す。終了した場合には、ステップＳ１３０８で全デバイスに対して同期処理の再開を通知し、本フローを終了する。
【００５７】
本実施形態によって、サーバの障害発生中でも複数のデバイス間で最新のデータを利用できるようになるとともに、サーバの障害発生間の変更要求をホストデバイスが集約することで、サーバ復旧時のデータ同期処理の負荷を軽減することができる。
【００５８】
（第２の実施形態）
以下、本発明の第２の実施形態を説明する。なお、第１の実施形態と同一構成部分についてはその説明を省略する。
【００５９】
第１の実施形態は、サーバの復旧後、全データ項目に対するサーバへの変更反映が終了した後に、同期を一斉に再開するものであった。このため、全データ項目のサーバへの変更反映までデバイス間同期モードが継続することになる。デバイス数が多い場合、全デバイスの変更反映までに長時間かかる可能性があり、ホストデバイスの負荷が高まってしまう。また、サーバへの変更反映が終了したデータ項目に対して、同期が再開されるまでの間に、デバイスが変更処理をおこなうと、同期再開時に全ホストデバイスがサーバに対して差分の変更要求の反映をおこなう必要が発生する。この場合、サーバへの変更反映終了後から同期再開までの間に多数の差分変更要求が蓄積されていると、同期再開時のサーバ負荷が高まってしまう。
【００６０】
本実施形態は、データ項目ごとに同期モードを設定することで、データ項目ごとに順次同期を再開可能にすることで、サーバへの変更要求反映時点から同期再開までの時間を短くし、差分の変更要求が蓄積される可能性を減らすものである。
【００６１】
本実施形態における管理テーブルを図１４に示す。テーブル１４０１は、ユーザデータのテーブルごとに同期モードを管理するものであり、同一デバイス内であってもテーブルごとに異なる同期モードを設定することが可能である。サーバへの変更反映が終わったテーブルから順に通常同期モードでの同期を再開する。サーバへの変更反映から同期が再開されるまでの過渡期に、テーブルごとに同期モードが異なっている。
【００６２】
したがって、本実施形態では、図６のステップＳ６０２および図９のステップＳ９０１での同期モード判定処理は、アクセス対象のデータ項目の同期モードを判定する処理となる。また、図７のステップＳ７０１のデバイス間同期モードへの移行時には、全データ項目の同期モードをデバイス間同期モードに変更する必要がある。
【００６３】
図１５は、本実施形態におけるサーバの復旧時処理のフローチャートを示したものである。第一の実施形態のサーバ復旧時処理のステップＳ１３０１〜ステップＳ１３０６と同一処理であるステップについては説明を省略する。ステップＳ１５０３は、各デバイスに対して変更内容があるか否かを問い合わせ、変更内容が無いデータ項目に対しては、同期再開を通知する。ステップＳ１５０３の詳細は、図１６で説明をおこなう。ステップＳ１５０４では、変更があったためステップＳ１５０３で同期が再開されなかったデータ項目の中から、サーバに変更を反映するデータ項目を設定する。ステップＳ１５０８は、全デバイスに対してステップＳ１５０４で設定したデータ項目に対する同期再開を通知する。ステップＳ１５０９で、全項目に対して変更内容をサーバ内データベースに反映終了したかを判定し、終了していれば本フローを終了、そうでなければステップＳ１５０４から処理を繰り返す。
【００６４】
図１６は、図１５のステップＳ１５０３の処理フローを示したフローチャートである。
ステップＳ１６０１で、変更有無の確認をおこなうデータ項目を設定し、ステップＳ１６０２で該当データに対応づいたホストデバイスに変更有無の問い合わせをおこなう。変更があった場合には、ステップＳ１６０４へ進み、変更がなかった場合には、ステップＳ１６０３へ進む。ステップＳ１６０３では、対象のデータ項目についての同期再開を全デバイスに通知する。ステップＳ１６０４では、全データ項目についての変更有無判定が終了したか否かを判定する。全データ項目についての変更有無判定が終了するまで、ステップＳ１６０１から処理を繰り返す。本構成によれば、障害発生間に変更内容がなくサーバへの反映処理が不要であるデータ項目について、早期に同期を再開することができる。
【００６５】
本実施形態においては、図１５に示したように同期再開通知がデータ項目ごとに順次サーバからデバイスに通知される。図５のステップＳ５０４で、通常同期モードに移行する際には、同期再開が通知されたデータ項目についてのみ同期モードを変更することで、データの同期を順次再開することができる。
【００６６】
なお、本実施形態では、ホストデバイスとなるデバイスは事前に定めておき、テーブル４０１に記憶しておくものとするが、ホストデバイスを動的に決定するようにしてもよい。この構成によれば、たとえば障害発生時の各デバイスの負荷状況や平均負荷に応じて、ホストデバイスを設定することができ、該当データを保持するデバイスの内、処理負荷の低いデバイスをホストデバイスに割り当てることができるようになる。
【００６７】
本実施形態では、ユーザデータとして、アドレス帳を用いたが、機器の設定値情報などを用いることもできる。また、本実施形態では、データベースのテーブル単位で同期モードを設定するものとしたが、表領域単位またはレコード単位で設定しても良い。
【００６８】
本実施形態の構成によれば、第１の実施形態で得られる効果に加え、データ項目ごとに順次同期処理を再開することで、サーバ復旧後の同期再開をスムーズにおこなうことができる。
【００６９】
（その他の実施形態）
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００７０】
１０１  同期サーバ
１０２  デバイス
１０３  デバイス
１０４  マスタデータベース
１０５  ローカルデータベース
１０６  ローカルデータベース
【図１】
2015162223.tif 000003
【図２】
2015162223.tif 000004
【図３】
2015162223.tif 000005
【図４】
2015162223.tif 000006
【図５】
2015162223.tif 000007
【図６】
2015162223.tif 000008
【図７】
2015162223.tif 000009
【図８】
2015162223.tif 000010
【図９】
2015162223.tif 000011
【図１０】
2015162223.tif 000012
【図１１】
2015162223.tif 000013
【図１２】
2015162223.tif 000014
【図１３】
2015162223.tif 000015
【図１４】
2015162223.tif 000016
【図１５】
2015162223.tif 000017
【図１６】
2015162223.tif 000018