JPH04165437A - Data base synchronization system - Google Patents
Data base synchronization systemInfo
- Publication number
- JPH04165437A JPH04165437A JP2291606A JP29160690A JPH04165437A JP H04165437 A JPH04165437 A JP H04165437A JP 2291606 A JP2291606 A JP 2291606A JP 29160690 A JP29160690 A JP 29160690A JP H04165437 A JPH04165437 A JP H04165437A
- Authority
- JP
- Japan
- Prior art keywords
- database
- record
- slave
- updated
- main
- 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
- 238000000034 method Methods 0.000 claims abstract description 22
- 238000004891 communication Methods 0.000 claims abstract description 9
- 238000010586 diagram Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 239000000725 suspension Substances 0.000 description 3
- 230000003139 buffering effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
Abstract
Description
【発明の詳細な説明】
〔産業上の利用分野〕
本発明はデータベース同期方式に関し、特に通信回線で
結ばれた主データベースと従データベースとで同一デー
タを重複して保持するデータベースシステムのデータベ
ース同期方式に間する。[Detailed Description of the Invention] [Field of Industrial Application] The present invention relates to a database synchronization method, and particularly to a database synchronization method for a database system that holds the same data redundantly in a main database and a slave database connected by a communication line. in between.
従来、同一のデータを主従のデータベースで重複保持す
るデータベースシステムにおいては、従データベースの
内容を主データベースの内容と−致させるため、従デー
タベースを保持するローカル局が通信障害や運転休止の
後に再起動する際には、次の二つの方法が用いられてい
る。Conventionally, in database systems that hold the same data redundantly in master and slave databases, in order to match the contents of the slave database with the contents of the master database, the local station holding the slave database has to be restarted after a communication failure or suspension of operation. When doing so, the following two methods are used.
第1の方法は、センター局の主データベースを一部ロツ
ク〈更新の凍結)し、その内容をすべて検索してローカ
ル局に転送し、従データベースの内容を初期化し直した
後、主データベースの口・ツクを解除して運用に入る方
法である。The first method is to partially lock (freeze updates) the main database of the center station, search all its contents and transfer them to the local station, reinitialize the contents of the slave database, and then・This is a method to release the tsukku and start operation.
第2の方法は、センター局およびローカル局の双方がジ
ャーナルファイルを用し)ですべての履歴を保持し、ロ
ーカル局が再起動する際には自局のジャーナルファイル
の更新前イメージを用いて従データベースの内容をチエ
ツクポイントまで戻した後に、センター側のジャーナル
ファイルの更新後イメージを用いて従データベースの内
容を更新し主データベースに合わせる方法である。The second method is to keep all the history in both the center station and the local station (using a journal file), and when the local station restarts, it uses the pre-update image of its own journal file to keep track. This method involves returning the contents of the database to the checkpoint and then updating the contents of the slave database to match the main database using the updated image of the journal file on the center side.
上述した従来のデータベース同期方式のうち第1の方法
は、主データベースをロックするので主データベースは
常時更新可能ではないため、多量のデータをリアルタイ
ムで更新する必要のある場合や、多数のローカル局が同
期管理のため主データベースを参照する際には、データ
のバッファリングその他複雑な制御が必要となり、装置
の大規模化およびコストアップを招く欠点がある。又、
ローカル局が運休状態から再運用に移る際には主データ
ベースの全内容を引き出して従データベースの内容を初
期化する必要があり、その通信のために大量のトラフィ
ックが発生するという閏題点もある。Among the conventional database synchronization methods described above, the first method locks the main database, so the main database cannot be updated at all times. When referring to the main database for synchronization management, data buffering and other complicated controls are required, which has the drawback of increasing the scale and cost of the device. or,
When a local station returns to operation from a suspended state, it is necessary to pull out all the contents of the main database and initialize the contents of the secondary database, and there is also the problem that a large amount of traffic is generated for this communication. .
他方、ジャーナルファイルを使用する第2の方法は、複
数の局で多量のジャーナルファイルを保持する必要があ
るほか、センター局とローカル局との間で更新前イメー
ジを採取するチエツクポイントの同期を管理する必要が
あり、第1の方法と同様に装置の大規模化および複雑化
を招く欠点がある。On the other hand, the second method of using journal files requires that multiple stations maintain a large number of journal files, and also manages the synchronization of checkpoints for collecting pre-update images between the center station and local stations. Similar to the first method, this method has the drawback of increasing the scale and complexity of the device.
本発明の目的は、上述の欠点を除去し、主従関係のある
多元管理のデータベースシステムにおいて、簡早な方法
で同期を管理できるデータベース同期方式を提供するこ
とである。An object of the present invention is to eliminate the above-mentioned drawbacks and provide a database synchronization method that can manage synchronization in a simple manner in a multi-managed database system with a master-slave relationship.
本発明のデータベース同期方式は2主データベースとこ
の主データベースの全部または一部のコピーから成る従
データベースとが通信回線で結合されたデータベースシ
ステムで前記従データベースの内容を前記主データベー
スと常に一致させるためのデータベース同期方式におい
て、データベースの更新単位であるレコードごとにリビ
ジョン番号を設け、更新する新レコードには既存の全リ
ビジョン番号よりも大きいく又は小さい)リビジョン番
号を付与し、前記従データベースが失われたデータベー
ス同期を回復するときその従データベース内の最大(又
は最小)のリビジョン番号よりも大きい(又は小さい)
リビジョン番号のレコードを前記主データベースから検
索して対応するキーを有するレコードを更新するよう構
成されている。The database synchronization method of the present invention is a database system in which two primary databases and a secondary database, which is a copy of all or part of the primary database, are connected via a communication line, and the contents of the secondary database are always made to match those of the primary database. In the database synchronization method of greater than (or less than) the highest (or lowest) revision number in its slave database when restoring synchronization
The system is configured to retrieve a record with a revision number from the main database and update a record with a corresponding key.
次に、本発明の実施例について図面を参照して説明する
。Next, embodiments of the present invention will be described with reference to the drawings.
第1図は本発明の一実施例のファイル構成図、第2図は
データベースシステムの構成例を示すブロック図である
。FIG. 1 is a file configuration diagram of an embodiment of the present invention, and FIG. 2 is a block diagram showing an example of the configuration of a database system.
データベースの1フアイルは、第1図に示すように、第
1〜第MのM個のレコードから成り、各レコードは第1
〜第NのN個のフィールドを持っている。そして、N個
のフィールドのうち第1゜第2フイールドはデータベー
スを検索するためのキー(各レコードを一意的に識別で
きる情報)及び副次キーとして使用され、第N番目のフ
ィールドにリビジョン番号のフィールドが設定されてい
る。As shown in Fig. 1, one file of the database consists of M records, numbered 1st to Mth.
~Nth field has N fields. Of the N fields, the first and second fields are used as a key (information that uniquely identifies each record) and secondary keys for searching the database, and the Nth field contains the revision number. field is set.
センター局の主データベース1と各ローカル局の従デー
タベース2〜4とは、第2図のように通信回線で接続さ
れており、従データベース2.3は主データベース1の
全部のコピーを、従データベース4は一部のコピーを有
し、各ローカル局は従データベース2〜4の内容を常に
主データベース】に一致させる必要があるものとする。The main database 1 of the center station and the slave databases 2 to 4 of each local station are connected by communication lines as shown in Fig. 2, and the slave database 2.3 stores all copies of the master database 1. 4 has a partial copy, and each local station must always match the contents of the slave databases 2 to 4 with the main database.
主データベース1では、最初に各レコードを一意的に識
別できるようにレコードの登録順に第Nフィールドにリ
ビジョン番号として連続番号(第1図のファイルかに個
ある場合は1〜kM)を設定しておく、以後、レコード
の更新があると更新する新レコードの第Nフィールドに
は既に設定されているリビジョン番号の最大値(kM)
に1を加算した番号を与え、主データベース1を更新す
ると共にすべてのローカル局に対し更新された新レコー
ドをブロードキャスト〈同報通知)する。In the main database 1, first set a consecutive number as a revision number (1 to km if there are as many files as shown in Figure 1) in the Nth field in the order in which records are registered so that each record can be uniquely identified. After that, when the record is updated, the maximum revision number (kM) that is already set in the Nth field of the new record will be updated.
1 is added to the number, the main database 1 is updated, and the updated new record is broadcast (broadcast notification) to all local stations.
各ローカル局は、センター局から送られてくる更新情報
(新レコード)を受信すると、そのキー(第1及び第2
レコード)を参照して、自局の従データベース内にある
同一キーのレコードを送られてきた新レコードと入れ換
えて従データベースを更新する。When each local station receives the update information (new record) sent from the center station, it updates its key (first and second record).
record) and replaces the record with the same key in the slave database of its own station with the new record sent, thereby updating the slave database.
新規レコードの追加の場合は、更新と同様にセンター局
で新リビジョン番号が付与されて送信され、各ローカル
局はキーを参照し該当するレコードがない場合は追加と
判断して無条件に登録するものとする。但し、一部コピ
ーを保持する従データベース4の場合は、副次キーなど
で必要性を判断して登録する。When adding a new record, the center station assigns a new revision number and sends it, just like when updating, and each local station refers to the key and if the corresponding record does not exist, it is determined to be an addition and is registered unconditionally. shall be taken as a thing. However, in the case of the slave database 4 that holds a partial copy, the necessity is determined using a secondary key and the like before registration.
次に、ローカル局が運用休止状態から運転を再開し、従
データベースと主データベースの内容の同期をとる必要
がある場合には、自局の従データベースの全レコードの
リビジョン番号のうぢ最新の値(最大値)を検出し、そ
れ以上のリビジョン番号を持つレコードという条件で主
データベースを検索して更新情報を引き出せばよい1、
二の際、従データベース側では、主データベースが発す
るブロードキャストによる更新情報と、ローカル局から
の要求によるセンター局からの検索結果の情報とを別種
の情報として区別する必要はなく、全く同一の処理で従
データベースに更新を加えればよい。Next, when the local station resumes operation from a suspended state and it is necessary to synchronize the contents of the slave database and the main database, the revision numbers of all records in the slave database of the local station are updated to the latest values. (maximum value) and retrieve update information by searching the main database for records with revision numbers higher than that1.
In the second case, on the slave database side, there is no need to distinguish between the broadcast update information issued by the main database and the search result information from the center station based on a request from the local station as different types of information, and they are processed in exactly the same way. All you have to do is update the secondary database.
以上の手順を時間軸に添って示し7なのが第31′;4
である。第3図においては、従データベース側が主デー
タベースからのブロードキャストによる更新情報をリビ
ジョン番号R=nのまで正常に受信し、この時点で何ら
かの原因により運休状態に入りリビジョン番号R=n+
1からR=n+mまでのm個のレコードの更新情報が反
映されなかった場合を示している。その後、運休の原因
が除かれて再起動した時、従データベースは自データベ
ース内の最新リビジョン番号R=nを取り出し、リビジ
ョン番号Ranの条件で主データベースの検索を要求し
、リビジョン番号R≧n+1のレコード群(R’−n+
1.R=n+2.−R=n+m>を再送してもらい、こ
れで自データベースの内容を更新することにより主デー
タベースと一致させている。従データベースの運休中に
同一レコードが複数回更新された場合は、古い更新レコ
ードは新しい更新情報により再更新されているので、必
然的に最新の更新情報のみが検索される。The above steps are shown along the time axis, and 7 is 31';
It is. In FIG. 3, the slave database normally receives update information broadcast from the main database up to revision number R=n, and at this point it enters a suspension state for some reason, with revision number R=n+
This shows a case where update information for m records from 1 to R=n+m is not reflected. Afterwards, when the cause of the suspension is removed and restarted, the secondary database retrieves the latest revision number R=n in its own database, requests a search of the main database under the condition of revision number Ran, and sets the revision number R≧n+1. Record group (R'-n+
1. R=n+2. -R=n+m> is retransmitted, and by updating the contents of its own database with this, it matches the main database. If the same record is updated multiple times while the secondary database is out of service, only the latest updated information will necessarily be searched because the old updated record will be re-updated with new updated information.
以上の実施例では、更新レコードに付与されるリビジョ
ン番号は、更新ごとに順次1が加算されていくものとし
たが、1の加算でなくても単調に増加するようにすれば
同様の効果を得ることができる。又、加算でなく、既存
のリビジョン番号の最小値から順次1を減算しても同様
の効果が得られる。更に、初期状態では主データベース
の各レコードにそれぞれ異なる連続番号を付与するよう
説明したが、連続番号でなくてもよく、すべてのレコー
ドに同一番号(例えばO)を付与し、でも差し支えない
。In the above embodiment, the revision number given to the updated record is assumed to be incremented by 1 for each update, but the same effect can be obtained by making it increase monotonically even if it is not incremented by 1. Obtainable. Furthermore, the same effect can be obtained by sequentially subtracting 1 from the minimum existing revision number instead of adding. Furthermore, although it has been explained that in the initial state, each record in the main database is assigned a different consecutive number, it is not necessary to assign consecutive numbers, and the same number (for example, O) may be assigned to all records.
以ト詳細に説明したように、本発明は、同一のデータを
通信回線で接続された複数のデータベースで保持するデ
ータベースシステムにいおいてレコードの1フイールド
にリビジョン番号を設けることにより、主データベース
をロックし全内容を伝送して初期化する必要もなく、各
データベ・−スでそれぞれ多量のジャーナルファイルを
保有する必要もなく、単純な方法で主従のデータベース
の内容を一致させることができる効果がある。As described in detail above, the present invention provides a revision number in one field of a record in a database system in which the same data is held in multiple databases connected by communication lines, thereby making it possible to update the main database. There is no need to lock, transmit and initialize all contents, and there is no need for each database to have a large number of journal files, and the effect is that the contents of the master and slave databases can be made consistent with a simple method. be.
第1図は本発明の一実施例のファイル構成図、第2図は
データベースシステムの構成のブロック図、第3図は主
データベースと従データベース間の通信フローの説明図
である。
1・・・・・・主データベース、2,3.4・・・・・
・従データベース。FIG. 1 is a file configuration diagram of an embodiment of the present invention, FIG. 2 is a block diagram of the configuration of a database system, and FIG. 3 is an explanatory diagram of a communication flow between a main database and a slave database. 1... Main database, 2, 3.4...
・Slave database.
Claims (1)
一部のコピーから成る従データベースとが通信回線で結
合されたデータベースシステムで前記従データベースの
内容を前記主データベースと常に一致させるためのデー
タベース同期方式において、データベースの更新単位で
あるレコードごとにリビジョン番号を設け、更新する新
レコードには既存の全リビジョン番号よりも大きい(又
は小さい)リビジョン番号を付与し、前記従データベー
スが失われたデータベース同期を回復するときその従デ
ータベース内の最大(又は最小)のリビジョン番号より
も大きい(又は小さい)リビジョン番号のレコードを前
記主データベースから検索して対応するキーを有するレ
コードを更新することを特徴とするデータベース同期方
式。 2、更新する新レコードに既存の全リビジョン番号中の
最大値に1を加算したリビジョン番号を付与することを
特徴とする請求項1記載のデータベース同期方式。 3、更新する新レコードに既存の全リビジョン番号中の
最小値から1を減算したリビジョン番号を付与すること
を特徴とする請求項1記載のデータベース同期方式。[Claims] 1. In a database system in which a main database and a sub-database consisting of a copy of all or part of the main database are connected via a communication line, the contents of the sub-database are always made to match the main database. In the database synchronization method of When restoring database synchronization, the main database is searched for a record with a revision number greater (or smaller) than the largest (or smallest) revision number in the slave database, and the record with the corresponding key is updated. Characteristic database synchronization method. 2. The database synchronization method according to claim 1, wherein a revision number obtained by adding 1 to the maximum value among all existing revision numbers is assigned to the new record to be updated. 3. The database synchronization method according to claim 1, wherein the new record to be updated is given a revision number obtained by subtracting 1 from the minimum value among all existing revision numbers.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2291606A JPH04165437A (en) | 1990-10-29 | 1990-10-29 | Data base synchronization system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2291606A JPH04165437A (en) | 1990-10-29 | 1990-10-29 | Data base synchronization system |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH04165437A true JPH04165437A (en) | 1992-06-11 |
Family
ID=17771128
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2291606A Pending JPH04165437A (en) | 1990-10-29 | 1990-10-29 | Data base synchronization system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH04165437A (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06119224A (en) * | 1992-10-08 | 1994-04-28 | Nri & Ncc Co Ltd | On-line system consisting of host computer and work station both of which have data base |
JPH07152616A (en) * | 1993-11-26 | 1995-06-16 | Tokyo Gas Co Ltd | Decentralized data processing method |
JPH0887436A (en) * | 1994-09-19 | 1996-04-02 | Nec Corp | Decentralized db processing system |
JPH08328930A (en) * | 1995-05-26 | 1996-12-13 | Nec Corp | Inter-system interface system |
US5649195A (en) * | 1995-05-22 | 1997-07-15 | International Business Machines Corporation | Systems and methods for synchronizing databases in a receive-only network |
JPH1115713A (en) * | 1997-06-19 | 1999-01-22 | Sanyo Electric Co Ltd | Data transmitter-receiver |
KR19990078538A (en) * | 1998-12-26 | 1999-11-05 | 김형순 | Data queue for database synchronization and method for operating it |
KR100501904B1 (en) * | 1999-12-14 | 2005-07-25 | 주식회사 케이티 | Database replication and synchronization method using object identifier |
-
1990
- 1990-10-29 JP JP2291606A patent/JPH04165437A/en active Pending
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06119224A (en) * | 1992-10-08 | 1994-04-28 | Nri & Ncc Co Ltd | On-line system consisting of host computer and work station both of which have data base |
JPH07152616A (en) * | 1993-11-26 | 1995-06-16 | Tokyo Gas Co Ltd | Decentralized data processing method |
JPH0887436A (en) * | 1994-09-19 | 1996-04-02 | Nec Corp | Decentralized db processing system |
US5649195A (en) * | 1995-05-22 | 1997-07-15 | International Business Machines Corporation | Systems and methods for synchronizing databases in a receive-only network |
JPH08328930A (en) * | 1995-05-26 | 1996-12-13 | Nec Corp | Inter-system interface system |
JPH1115713A (en) * | 1997-06-19 | 1999-01-22 | Sanyo Electric Co Ltd | Data transmitter-receiver |
KR19990078538A (en) * | 1998-12-26 | 1999-11-05 | 김형순 | Data queue for database synchronization and method for operating it |
KR100501904B1 (en) * | 1999-12-14 | 2005-07-25 | 주식회사 케이티 | Database replication and synchronization method using object identifier |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4732661B2 (en) | How to synchronize the client database with the server database | |
US6012059A (en) | Method and apparatus for replicated transaction consistency | |
US7428657B2 (en) | Method for rolling back from snapshot with log | |
US6539381B1 (en) | System and method for synchronizing database information | |
CA2100533C (en) | Method and system for synchronizing computer mail user directories | |
US5940829A (en) | Work flow management system | |
CN100478902C (en) | Geographically distributed clusters | |
JP4414381B2 (en) | File management program, file management apparatus, and file management method | |
CN101933014B (en) | System and method for replication and synchronisation | |
US7099896B2 (en) | Synchronizing data between disparate schemas using composite version | |
US20080005199A1 (en) | Collection-Based Object Replication | |
US20080109622A1 (en) | Point in Time Remote Copy for Multiple Sites | |
JPH06168169A (en) | Distributed transaction processing using two-phase commit protocol provided with assumption commit without log force | |
US20070011159A1 (en) | Distributed data store with an orderstamp to ensure progress | |
JP2003522344A (en) | Database synchronization / organization system and method | |
US7668880B1 (en) | Offsite computer file backup system providing rapid recovery and method thereof | |
CN106682140A (en) | Multi-system user incremental synchronization method based on timestamps and mapping strategies | |
US6782399B2 (en) | Ultra-high speed database replication with multiple audit logs | |
JPH10161916A (en) | Detection of update conflict accompanying duplication of data base | |
JPWO2014141343A1 (en) | Data multiplexing system | |
JPH05204739A (en) | System for synchronizing overlapped distributed data bases | |
JPH04165437A (en) | Data base synchronization system | |
JP2004164401A (en) | Database system, center server, and access method for database | |
JP2007219598A (en) | Multiplex database system, its synchronization method, database server, and database server program | |
CN105593839A (en) | Distributed disaster recovery file sync server system |