JP7263297B2 - ハイブリッドクラウド弾性スケーリングおよび高性能データ仮想化のためのリアルタイムクロスシステムデータベースレプリケーション - Google Patents

ハイブリッドクラウド弾性スケーリングおよび高性能データ仮想化のためのリアルタイムクロスシステムデータベースレプリケーション Download PDF

Info

Publication number
JP7263297B2
JP7263297B2 JP2020154565A JP2020154565A JP7263297B2 JP 7263297 B2 JP7263297 B2 JP 7263297B2 JP 2020154565 A JP2020154565 A JP 2020154565A JP 2020154565 A JP2020154565 A JP 2020154565A JP 7263297 B2 JP7263297 B2 JP 7263297B2
Authority
JP
Japan
Prior art keywords
replica
replication
log
source
transaction
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
JP2020154565A
Other languages
English (en)
Other versions
JP2021082257A (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.)
SAP SE
Original Assignee
SAP SE
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 SAP SE filed Critical SAP SE
Publication of JP2021082257A publication Critical patent/JP2021082257A/ja
Application granted granted Critical
Publication of JP7263297B2 publication Critical patent/JP7263297B2/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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • 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
    • 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
    • G06F16/2282—Tablespace storage structures; Management thereof
    • 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/2379—Updates performed during online database operations; commit processing

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

企業は、データベース管理システムを使用して、かなりの数のデータベーストランザクションを処理し得る。これは、たとえば、保険会社、金融サービス会社、eコマースWebサイトなどによってデータベース管理システムが使用されているときであり得る。大量のデータベーストランザクションの処理を助けるために、データベース管理システムは、読取りトランザクションをレプリカノードのレプリカテーブルに配信し得る。データベース管理システムは、ソースノードのソーステーブルからレプリカノードの対応するレプリカテーブルに変更をレプリケートすることによって、レプリカテーブルを維持し得る。しかしながら、そのような変更のレプリケートは、特に、ソーステーブルが頻繁に更新されるとき、遅くなる可能性がある。これによって、データベース管理システムの読取りトランザクションの性能が制限され、ソーステーブルとレプリカテーブルとの間に可視性のギャップが生じる場合がある。
いくつかの場合には、非同期テーブルレプリケーション(「ATR」)がそのようなプロセスを効率的に促進し得る。しかしながら、ATRの使用は、ソーステーブルと同じランドスケープにある(たとえば、同じシステム上にあり、同じデータベースソフトウェアを共有する)レプリカテーブルに制限される場合がある。したがって、安全で自動的で正確な方法で、リアルタイムのクロスランドスケープデータベーステーブルレプリケーションを提供することが望ましい場合がある。
レプリカテーブルへのデータベーストランザクションのRTRは、レプリケーションおよびトランザクションコミットログエントリ(データベーストランザクションを表す)を受信することを含み得る。レプリケーションログエントリは行ID値を有し、レプリカテーブルの行は行ID値を有する。レプリケーションログエントリは、並列ログリプレーヤにディスパッチされ、関連するトランザクションコミットログエントリは、トランザクションコミットログリプレーヤにディスパッチされ得る。行ID値が比較され得、比較に基づいて並列ログリプレーヤでレプリケーションログエントリをリプレイする。次いで、データベーストランザクションは、トランザクションログリプレーヤで関連するトランザクションコミットログエントリをリプレイすることによって、レプリカテーブルにコミットされ得、データベーストランザクションが、トランザクションの一貫性を有する行レベルの並列リプレイおよびDDLのレプリケーションに関連付けられており、レプリカシステムでのDDLステートメントの再構築が、1つまたは複数のメタデータ更新ログエントリに関連付けられている。
いくつかの実施形態は、少なくとも1つのプロセッサによって、レプリケーションログエントリおよび関連付けられたトランザクションコミットログエントリを受信するための手段であり、レプリケーションログエントリおよび関連するトランザクションコミットログエントリが一緒に、レプリカテーブルの行にリプレイされるデータベーストランザクションを表し、レプリケーションログエントリが行ID値を有し、レプリカテーブルの行が行ID値を有する、受信するための手段と、少なくとも1つのプロセッサによって、レプリケーションログエントリを並列ログリプレーヤにディスパッチし、関連するトランザクションコミットログエントリをトランザクションコミットログリプレーヤにディスパッチするための手段と、少なくとも1つのプロセッサによって、レプリケーションログエントリの行ID値をレプリカテーブルの行の行ID値と比較するための手段と、少なくとも1つのプロセッサによって、比較に基づいて、並列ログリプレーヤでレプリケーションログエントリをリプレイするための手段と、少なくとも1つのプロセッサによって、トランザクションログリプレーヤで関連するトランザクションコミットログエントリをリプレイすることによって、データベーストランザクションをレプリカテーブルにコミットするための手段であり、データベーストランザクションが、トランザクションの一貫性を有する行レベルの並列リプレイおよびDDLのレプリケーションに関連付けられており、レプリカシステムでのDDLステートメントの再構築が、1つまたは複数のメタデータ更新ログエントリに関連付けられている、コミットするための手段とを含む。
本明細書に開示されているいくつかの実施形態のいくつかの技術的利点は、安全で自動的で正確な方法で、リアルタイムのクロスランドスケープデータベーステーブルレプリケーションを提供するための改善されたシステムおよび方法である。
非同期テーブルレプリケーションによる分散データベースシステムのブロック図である。 非同期テーブルレプリケーションのためのトランザクションログおよび並列ログのリプレイによる分散データベースシステムのブロック図である。 いくつかの実施形態による、ハイブリッドクラウドによる弾性スケーリングのリアルタイムテーブルレプリケーション使用例である。 いくつかの実施形態による、複数のリモートシステムからの効率的なデータ仮想化のリアルタイムテーブルレプリケーションの使用例である。 いくつかの実施形態による、全体的なリアルタイムテーブルレプリケーションアーキテクチャである。 いくつかの実施形態による、クロスランドスケープリアルタイムテーブルレプリケーションを示す図である。 RTRセットアップ、アクティブ化、および非アクティブ化に関連付けられている図である。 RTRセットアップ、アクティブ化、および非アクティブ化に関連付けられている図である。 RTRセットアップ、アクティブ化、および非アクティブ化に関連付けられている図である。 RTRセットアップ、アクティブ化、および非アクティブ化に関連付けられている図である。 RTRセットアップ、アクティブ化、および非アクティブ化に関連付けられている図である。 RTRセットアップ、アクティブ化、および非アクティブ化に関連付けられている図である。 RTRセットアップ、アクティブ化、および非アクティブ化に関連付けられている図である。 いくつかの実施形態による、ソースシステムおよびレプリカシステムを含むアーキテクチャを示す図である。 異なるバイナリバージョン間のクロスデータベース非同期テーブルレプリケーションを示す図である。 いくつかの実施形態による、レプリカテーブルをレプリケートする方法を示す図である。 いくつかの実施形態による、データ定義言語ログのリプレイを表す図である。 いくつかの実施形態による、リアルタイムテーブルレプリケーションのアクティブ化およびデータ定義言語ステートメントの生成を示す図である。 いくつかの実施形態による、リアルタイムテーブルレプリケーション方法を示す図である。 いくつかの実施形態による、リアルタイムテーブルレプリケーション表示を示す図である。 様々な実施形態を実装するのに有用なコンピュータシステムの一例を示す図である。
以下の詳細な説明では、実施形態の完全な理解を提供するために、多数の特定の詳細が示されている。しかしながら、実施形態は、これらの特定の詳細なしで実施されてもよいことが当業者によって理解されよう。他の例では、周知の方法、手順、構成要素、および回路は、実施形態を不明瞭にしないように、詳細には記載されていない。
本発明の1つまたは複数の特定の実施形態について以下で記載する。これらの実施形態の簡潔な説明を提供しようとして、実際の実装のすべての特徴が明細書に記載されていない場合がある。任意のそのような実際の実装の開発では、任意のエンジニアリングプロジェクトや設計プロジェクトのように、実装ごとに異なる場合がある、システム関連およびビジネス関連の制約の遵守など、開発者固有の目標を達成するために、多数の実装固有の決定を行う必要があることを諒解されたい。さらに、そのような開発努力は、複雑で時間がかかる可能性があるが、それでも、本開示の利益を有する当業者にとっては、設計、作製、および製造の日常業務であることを諒解されたい。
本明細書で提供されるのは、ソーステーブルが頻繁に更新されるレプリケーションの性能を高め、ソーステーブルとレプリカテーブルとの間の可視性のギャップを低減するためのシステム、方法、および/またはコンピュータプログラム製品の実施形態、および/またはそれらの組合せおよび部分組合せである。一実施形態は、レプリカテーブルの行にリプレイされるデータベーストランザクションのレプリケーションログエントリおよびトランザクションコミットログエントリを受信することによって動作する。レプリケーションログエントリは、レプリケーションログエントリの行ID列の値とレプリカテーブルの行の行ID列の値との比較に基づいて、レプリカノードのレプリカテーブルと並列にリプレイされる。データベーストランザクションは、トランザクションコミットログエントリを連続的にリプレイすることによって、トランザクションの一貫性を有してレプリカテーブルにコミットされる。したがって、レプリケーションログエントリが並列にリプレイされ、データベーストランザクションがトランザクションの一貫性を有してコミットされるので、データベース管理システムは、ソーステーブルとレプリカテーブルとの間のより速いレプリケーションを実行し、これによって、ソーステーブルとレプリカテーブルとの間の可視性のギャップが低減する。
データベース管理システムは、データベース内のデータの編成、記憶、および取出しを制御するコンピュータソフトウェアプログラムの集まりである。データベースは、編成されたデータの集まりである。データベースは、データベースモデルに従って編成され得る。データベースモデルは、データベースの論理構造、およびデータの記憶、編成、および操作方法を決定する。たとえば、リレーショナルモデルは、普及しているデータベースモデルである。
リレーショナルデータベースモデルは、データをテーブルのセットとして編成し、そこから、テーブルを再編成する必要なく、多くの異なる方法でデータにアクセスしたり、データを再アセンブルしたりすることができる。各テーブルは、列に1つまたは複数のデータカテゴリを含み得る。各行は、列によって定義されたカテゴリのデータの一意のインスタンスを含み得る。たとえば、ビジネスオーダーエントリデータベースは、名前、住所、電話番号などの列を有する顧客を記載するテーブルを含んでいてよい。各行は、主キーを有し得る。主キーは、行を一意に識別するように指定された列または列の組合せである。
各テーブルは、行ベースのストレージまたは列ベースのストレージのいずれかを使用して表され得る。行ベースのストレージでは、データベース管理システムは、データを行ごとにデータベースに記憶する。列ベースのストレージでは、データベース管理システムは、データを列ごとにデータベースに記憶する。
列ベースのストレージを使用するデータベース管理システムは、行ベースのストレージを使用するデータベース管理システムよりも高速であることが多い。これは、データベース管理システムが大規模なデータリポジトリにおいて読取り集約的な操作を実行する場合に多い。これは、列指向データベース管理システムは操作を実行するときに関連する列をスキャンするだけでよいからである。対照的に、行指向データベース管理システムは、読み取っている行の列をスキャンする必要がある。
列指向データベースシステムは、操作が数列のみに実行され得る場合に選択されることが多い。同様に、列指向データベースシステムは、テーブルが多数の列を有し、またはテーブルが多数の行を有し、列操作が、典型的にデータベース管理システムによって実行される場合に選択され得る。
データベースのクエリ、挿入、または更新の要求は、データベース言語を使用してデータベース管理システムに対して行われ得る。データベース言語は、データベース管理システムの要求に使用されるコンピュータ言語である。たとえば、構造化照会言語(「SQL」)は、データベース管理システムとの通信に使用されるデータベース言語である。
データベースへのクエリ、挿入、または更新の要求は、データベース管理システムによるデータベーストランザクションとして実行され得る。データベーストランザクションは、1つまたは複数の独立した作業単位からなり、各々がデータベースへのデータの読取り、書込みを行う。データベーストランザクションは、読取りまたは書込みであり得る。読取りデータベーストランザクションは、データベースへのデータの書込みを行わない。たとえば、クエリは、読取りデータベーストランザクションである。書込みデータベーストランザクションは、データベースにデータを書き込む。たとえば、挿入は、書込みデータベーストランザクションである。
データベース管理システムは、データベーストランザクションを完全に実行するか、またはまったく実行しないかのいずれかである。データベーストランザクションの実行中にエラーが発生しない場合、データベース管理システムは、トランザクションをデータベースにコミットする。データベース管理システムは、トランザクションコミット操作を実行することによって、データベーストランザクションをデータベースにコミットする。トランザクションコミット操作によって、データベース管理システムは、データベーストランザクションの範囲内のすべてのデータ操作をデータベースに適用する。
データベーストランザクションの実行中にエラーが発生した場合、データベーストランザクションの範囲内のデータ操作は、データベース管理システムによってデータベースに適用されない。データベース管理システムによって、部分的に完了したデータベーストランザクションをデータベースにコミットすることはできない。言い換えれば、データベース管理システムによるデータベーストランザクションの実行によって、データベースは常に一貫した状態になる。
データベース管理システムは、他のデータベーストランザクションとは別個にデータベーストランザクションを実行する。さらに、データベース管理システムは、データベーストランザクションの実行の結果が既存のデータベースの制約を満たすことをチェックする。各データベーストランザクションを追跡し、管理するために、データベース管理システムは、各データベーストランザクションにトランザクションIDを割り当てる。
図1は、例示的な実施形態による、テーブルレプリケーションによる分散データベースシステム100を示す。分散データベースシステム100は、データベース管理システム102および分散データベース104を含む。
データベース管理システム102は、分散データベース104内のデータの編成、記憶、および取出しを制御するコンピュータソフトウェアプログラムの集まりである。分散データベース104におけるデータのクエリ、挿入、または更新の要求は、データベース管理システム102によってデータベーストランザクションとして実行される。
分散データベース104は、ソースノード106およびレプリカノード108に記憶される。ソースノード106およびレプリカノード108は、同じ物理的位置に配置された別個のコンピュータであり得る。ソースノード106およびレプリカノード108はまた、相互接続されたコンピュータのネットワーク上に分散された別個のコンピュータであってもよい。
分散データベース104は、リレーショナルデータベースである。たとえば、分散データベース104は、テーブルA、B、C、D、E、およびFを含む。分散データベース104のテーブルは、ソースノード106およびレプリカノード108に記憶される。
ソースノード106に記憶されたテーブルは、ソーステーブルである。ソースノード106内のソーステーブルは、分散データベース104内の現在のデータを含む。当業者によって諒解されるように、ソースノード106内のソーステーブルは、複数のソースノードにわたって記憶され得る。具体的には、複数のソースノードの各ソースノードは、ソーステーブルのサブセットを分散データベース104に記憶し、その特定のサブセットにおいて排他的に動作し得る。
レプリカノード108に記憶されているテーブルは、レプリカテーブルである。レプリカテーブルは、ソースノード106内のソーステーブルのコピーである。当業者によって諒解されるように、レプリカテーブルは、複数のレプリカノードにわたって記憶され得る。
データベース管理システム102は、レプリカノード108へのレプリケーションのためにソースノード106に記憶された1つまたは複数のソーステーブルを指定し得る。次いで、データベース管理システム102は、これらの指定されたソーステーブルのコピーをレプリカノード108においてレプリカテーブルとして維持する。たとえば、データベース管理システム102は、ソースノード106におけるテーブルEおよびFをレプリカノード108においてテーブルE'およびF'としてレプリケートする。言い換えれば、テーブルE'およびF'は、テーブルEおよびFのコピーである。当業者によって諒解されるように、データベース管理システム102は、使用要件に応じて、ソースノード106内のソーステーブルのすべてまたは適切なサブセットをレプリカノード108にレプリケートし得る。
レプリカノード108でレプリカテーブルを維持することによって、データベース管理システム102は、ソースノード106におけるソーステーブルとレプリカノード108におけるレプリカテーブルとの間で読取りデータベーストランザクションを分散し得る。言い換えれば、データベース管理システム102は、読取りデータベーストランザクションをレプリカテーブルに分散することによって、負荷分散を実行することができる。これは、中央処理ユニット(「CPU」)の消費およびソースノード106におけるテーブル競合を低減することによって、分散データベース104のデータベース管理システム102の全体的な読取りデータベーストランザクション性能を向上させ得る。
データベース管理システム102は、読取りデータベーストランザクションをソーステーブルまたはレプリカテーブルのいずれかにサブミットしてもよい。これは、データベース管理システム102が、ソースノード106内のソーステーブルの状態を、レプリカノード108内のレプリカテーブルの状態に維持するためである。
データベース管理システム102は、ソースベース106内のソーステーブルに書込みデータベーストランザクションをサブミットする必要がある。これは、ソースノード106内のソーステーブルが現在のデータを含むためである。ソースノード106内のソーステーブルが古いデータを含むことになるので、データベース管理システム102は、書込みデータベーストランザクションをレプリカノード108内のレプリカテーブルに直接送信することができない。具体的には、ソースノード106内のソーステーブル内のデータは、レプリカノード108内のレプリカテーブル内のデータと一致しなくなる。
ソースノード106内のソーステーブル内のデータがレプリカノード108内のレプリカテーブル内のデータと一致することを確実にするために、データベース管理システム102は、ソースノード106内のソーステーブルにあるすべての書込みデータベーストランザクションを、レプリカノード108内の対応するレプリカテーブルにリプレイする。これは、レプリカテーブル内のデータが、対応するソーステーブル内のデータと一致することを確実にする。
データベース管理システム102は、同期的または非同期的のいずれかで、ソーステーブルにおけるすべての書込みデータベーストランザクションを対応するレプリカテーブルにリプレイし得る。同期テーブルレプリケーションでは、データベース管理システム102は、ソーステーブルおよび対応するレプリカテーブルを同時に更新する。言い換えれば、データベース管理システム102は、ソーステーブルと同じトランザクション境界中にレプリカテーブルを更新する。これは、レプリカテーブルがソーステーブルと同じデータを含むことを確実にする。しかしながら、同期テーブルレプリケーションは、データベース管理システム102の書込みデータベーストランザクション応答時間をしばしば増加させる。これは、レプリカテーブルが対応するソーステーブルと同時にデータベース管理システム102によって更新されるためである。
ATRでは、データベース管理システム102は、ソーステーブルとレプリカテーブルを同時に更新しない。むしろ、データベース管理システム102は、書込みデータベーストランザクションがソーステーブルでコミットされた後、レプリカテーブルを更新し得る。これは、レプリカテーブルは、ソーステーブルと比較して古いデータを含み得ることを意味する。しかしながら、ATRは、同期テーブルレプリケーションよりもデータベース管理システム102の生じる性能オーバーヘッドが著しく少なくなることが多い。
データベース管理システム102は、ATRを実行すると、生じる性能オーバーヘッドがより少なくなることが多いが、テーブルレプリケーションにかなりの遅延をもたらすことが多い。これは、データベース管理システム102が、レプリカテーブルにおいて書込みデータベーストランザクションをリプレイするとき、トランザクションの一貫性を確保する必要があるためである。具体的には、データベース管理システム102は、トランザクションの一貫性を確保するために、レプリカテーブルにおいて書込みデータベーストランザクションをよりゆっくりリプレイしなければならない場合がある。
図2は、例示的な実施形態による、ATRのためのトランザクションログおよび並列ログのリプレイによる分散データベースシステムを示す。ATRのこの例示的な実施形態は、依然としてトランザクションの一貫性を確保しながら、書込みデータベーストランザクションを並列にリプレイすることによって、テーブルレプリケーションの遅延を最小限に抑える。具体的には、この例示的な実施形態におけるデータベース管理システムは、トランザクションコミットログエントリのリプレイを直列化しながら、レプリケーションログエントリを並列にリプレイする。
書込みデータベーストランザクションを並列にリプレイするデータベース管理システムの技術的問題は、トランザクションが分散データベース内のレプリカテーブルの同じ行を更新するとき、トランザクションの一貫性を確保することである。図2の実施形態の図2の例では、ソーステーブルにおいて同じ行の3つの連続した書込みデータベーストランザクション(たとえば、T1、T2、T3など)がある。トランザクションT1は、第1のトランザクションであり、ソーステーブルに行を挿入する。トランザクションT2は、第2のトランザクションであり、ソーステーブルの行を更新する。トランザクションT3は、最後のトランザクションであり、同じくソーステーブルの行を更新する。
トランザクションの一貫性を確保するために、データベース管理システムは、これらの3つのデータベース書込みトランザクションをレプリカテーブルで順番にリプレイしなければならない。たとえば、トランザクションT2がトランザクションT3の後にリプレイされる場合、レプリカテーブルにおける行の列1の最後の値は「B」である。しかしながら、これは、「C」であるソーステーブルの行の列1の値と一致しないことになる。
例示的な実施形態では、データベース管理システムは、テーブルIDに基づいてレプリカノードでデータベース書込みトランザクションをリプレイすることによってトランザクションの一貫性を確保し得る。言い換えれば、データベース管理システムは、一度に単一のデータベース書込みトランザクションをレプリカテーブルにリプレイし得る。しかしながら、データベース管理システムがソーステーブルを頻繁に更新する場合、データベース管理システムは、データベース書込みトランザクションをレプリカテーブルに連続的にリプレイする必要があり得る。これは、データベース管理システムがデータベース書込みトランザクションをリプレイし得る速度を大幅に制限する可能性がある。
図2の実施形態は、ソーステーブルおよびレプリカテーブルにおいて行ID列を作成することによって、この技術的問題を克服する。具体的には、ソーステーブルまたはレプリカテーブルの各行は、行ID列を有する。行ID列の長さは短い可能性がある。たとえば、行ID列の長さは8バイトであり得る。しかしながら、当業者は、行ID列が異なる長さのものであり得ることを諒解されよう。
図2の実施形態では、データベース管理システムは、行への書込みデータベーストランザクションについて、ソーステーブルの行の行ID列の値を増分する。データベース管理システムは、同様に、レプリカテーブルにおいて書込みデータベーストランザクションをリプレイした後、レプリカテーブルの対応する行の行ID列の値を増分する。
行が更新されると、行ID列の値が増分されるので、行ID列の値は、行の主キー列値とは異なる。対照的に、行について、主キー列の値は更新されない。言い換えれば、行ID列の値は、変更識別子であり、主キー列の値は、行識別子である。
図2の実施形態では、データベース管理システムは、最小限の性能オーバーヘッドで、各書込みデータベーストランザクションの行ID列の値を増分し得る。これは、図2の実施形態の2つの側面による。
第1に、図2の実施形態では、行ID列の値の長さは短い。具体的には、行ID列の値の長さは8バイトであり得る。行ID列の値の長さは短いので、データベース管理システムは、単一のアトミックハードウェア命令を使用して行ID列の値を増分し得る。たとえば、行ID列の値は、コンペアアンドスワップ命令を使用して増分され得る。データベース管理システムは、最小限のオーバーヘッドで単一のアトミックハードウェア命令を実行できるので、行ID列の値を効率的に増分し得る。
第2に、次の行ID列の値は、行ID列の利用可能な値の最大値としてリセットすることができるので、データベース管理システムは、行ID列の値の増分を記録する必要がない場合がある。たとえば、データベース管理システムは、データベース管理システムの再起動後、行ID列の値を、行ID列の利用可能な値の最大値としてリセットする場合がある。
図2の実施形態は、図1の分散データベースシステム104を含む。分散データベース104のテーブルは、ソースノード106およびレプリカノード108に記憶される。ソースノード106およびレプリカノード108もまた、図1からのものである。
ソースノード106は、書込みセット抽出器202、レプリケーションログ生成器204、ログ送信バッファ206、ログ送信機208、およびトランザクションマネージャ210を含む。書込みセット抽出器202は、ソースノード106におけるソーステーブルの行における各書込みデータベーストランザクションの操作タイプ、テーブルID、トランザクションID、新しい行画像、および行ID列の値を抽出する。
操作タイプは、実行されている書込みデータベーストランザクションのタイプを表す。たとえば、書込みデータベーストランザクションは、挿入、更新、または削除操作とすることができる。テーブルIDは、更新される行を含むテーブルを一意に識別する値である。データベース管理システムは、各ソーステーブルに一意のテーブルID値を割り当て得る。
トランザクションIDは、データベース管理システムによって実行される書込みデータベーストランザクションを一意に識別する値である。トランザクションIDによって、データベース管理システムは、書込みデータベーストランザクションが実行される順序を確実にすることができる。たとえば、同じ所与の行について、トランザクションIDが101の書込みデータベーストランザクションは、トランザクションIDが102の書込みデータベーストランザクションの前に実行されなければならない。そうでない場合、行は、不正確なデータを含む。
レプリケーションログ生成器204は、ソーステーブルの変更された行のレプリケーションログエントリを生成する。具体的には、レプリケーションログエントリは、操作タイプ、テーブルID、トランザクションID、書込みセット抽出器202によって抽出された変更された行の新しい行の画像を含み得る。加えて、レプリケーションログエントリは、1つまたは複数の行ID列の値を含み得る。
挿入操作の場合、レプリケーションログエントリは、挿入された行の新しい行ID列の値を含む。更新操作の場合、レプリケーションログエントリは、更新操作前の行の古い行ID列の値、および更新操作が完了した後の新しい行ID列の値を含む。削除操作の場合、レプリケーションログエントリは、削除操作が完了する前に削除される行の古い行ID列の値を含む。当業者によって諒解されるように、レプリケーションログエントリは、様々な方法で表され、記憶され得る。
レプリケーションログ生成器204は、生成されたレプリケーションログエントリをログ送信バッファ206に付加する。ログ送信バッファ206は、レプリケーションログエントリおよびトランザクションコミットログエントリを記憶する。
ログ送信機208は、ログ送信バッファ206内のレプリケーション書込みログエントリおよびトランザクションコミットログエントリをレプリカノード108に送信する。たとえば、ソースノード106およびレプリカノード108がコンピュータネットワークを介して接続されている場合、ログ送信機208は、ログ送信バッファ206内のレプリケーションログエントリをコンピュータネットワークを介してレプリカノード108に送信する。
ソースノード106のソーステーブルでのトランザクションの一貫性を確保するために、トランザクションマネージャ210は、トランザクションコミット操作を実行して、書込みデータベーストランザクションをソーステーブルに適用する。加えて、トランザクションマネージャ210は、書込みデータベーストランザクションがトランザクションマネージャ210によってソーステーブルにコミットされると、トランザクションコミットログエントリを作成する。
トランザクションコミットログエントリは、コミットされた書込みデータベーストランザクションのトランザクションIDを含む。トランザクションマネージャ210は、トランザクションコミットログエントリをログ送信バッファ206に付加する。ログ送信機208は、ログ送信バッファ206内のトランザクションコミットログエントリをレプリカノード108に送信して、コミットされた書込みデータベーストランザクションをレプリカテーブルに適用する。
レプリカノード108において、レプリケーションログ受信機およびディスパッチャ212は、レプリケーションログエントリおよびトランザクションコミットログエントリをソースノード106から受信する。レプリケーションログ受信機およびディスパッチャ212は、ログエントリのタイプに応じて、受信されたログエントリを並列ログリプレーヤ214またはトランザクションログリプレーヤ216にディスパッチする。
受信されたログエントリがレプリケーションログエントリである場合、レプリケーションログ受信機およびディスパッチャ212は、レプリケーションログエントリを並列書込みログリプレーヤ214にディスパッチする。並列ログリプレーヤ214は、複数のキューを含む場合があり、各キューには、リプレイのためのレプリケーションログエントリが割り当てられ得る。並列ログリプレーヤ214は、各キューに割り当てられたレプリケーションログエントリを同時に並列にリプレイし得る。レプリケーションログエントリを並列にリプレイすることによって、並列ログリプレーヤ214は、ソースノード106とレプリカノード108との間のテーブルレプリケーション遅延を最小限に抑え得る。
さらに、並列ログリプレーヤ214は、同じレプリカテーブルの2つのレプリケーションログエントリを並列にリプレイし得る。これは、以下で説明するように、トランザクションログリプレーヤ216がトランザクションコミットログエントリを連続的にリプレイするので可能である。
受信されたログエントリがトランザクションコミットログエントリである場合、レプリケーションログ受信機およびディスパッチャ212は、トランザクションコミットログエントリをトランザクションログリプレーヤ216にディスパッチする。これは、並列ログリプレーヤ214によるレプリケーションログエントリの並列リプレイ中にトランザクションの一貫性を確保するのに必要である。
図2の実施形態は、2つの条件を実施することによって、並列ログリプレーヤ214によるレプリケーションログエントリの並列リプレイ中のトランザクションの一貫性を確保する。第1に、レプリケーションログエントリのリプレイの結果は、対応するトランザクションコミットログエントリがリプレイされた後でのみ、レプリカテーブルにおいて可視となり得る。言い換えれば、データベース管理システムは、ソーステーブルで行われた変更が実際にレプリカテーブルで持続される前に、対応するトランザクションコミットログエントリをリプレイする必要がある。第2に、レプリケーションログエントリは、ソーステーブルでの実行順序とは無関係に並列にリプレイされ得るが、トランザクションコミットログエントリは、ソーステーブルで実行されたのとまったく同じ順序でリプレイされる必要がある。
図2の実施形態は、トランザクションコミットログエントリをトランザクションコミットリプレーヤ216で連続的にリプレイし、レプリケーションログエントリをそれらの行ID列の値に基づいて並列ログリプレーヤ214で並列にリプレイすることによって、これら2つの条件が確実に満たされるようにする。具体的には、並列ログリプレーヤ214は、その古い行ID列の値がレプリカテーブルにおいて可視になった後、更新または削除操作についてレプリケーションログエントリをリプレイする。これは、同じ行への2つの競合する書込みデータベーストランザクションの第2のトランザクションが、その前の書込みデータベーストランザクションがリプレイされ、コミットされた後にのみリプレイされることを確実にする。これは、第1の書込みデータベーストランザクションがコミットされた後、行ID列の値の更新を含む第1の書込みデータベーストランザクションの結果がレプリカテーブルにおいて可視になるためである。また、第1の書込みデータベーストランザクションは、トランザクションログリプレーヤが第1の書込みデータベーストランザクションと同じトランザクションIDのトランザクションコミットログエントリをリプレイするときにコミットされる。並列ログリプレーヤ214がこの条件に従ってレプリケーションログエントリをリプレイする場合、レプリカテーブル内の行の行ID列の値は、レプリケーションログエントリに含まれる新しい行ID列の値で更新される(更新ログエントリの場合)。
図2の実施形態は、競合する書込みセットの行ID列の値に基づく動的検出を実行したので、レプリケーションログエントリは、制限なしに、並列ログリプレーヤ214の複数のキューにレプリケーションログ受信機およびディスパッチャ212によって自由にディスパッチすることができる。特に、レプリケーションログ受信機およびディスパッチャ212は、テーブルレベルの直列化を実行することなくレプリケーションログエントリをディスパッチすることができる。これによって、レプリケーションログリプレイ性能が大幅に加速する可能性があり、これにより、ATR下でのソーステーブルとレプリカテーブルとの間の可視性のギャップも低減する。
データベースレプリケーションは、障害回復、高可用性、および負荷分散など、実用的な目的のために、多くの企業のミッションクリティカルなデータベースシステムで使用されることに留意されたい。レプリケーションオプションの例は、以下を含む。
・システムレプリケーション:リカバリredoログをレプリカシステムに配布することによって、データベースコンテンツ全体をレプリケートし、主に障害回復または高可用性に使用される。
・前述のように、ATRシステムは、データ操作言語(「DML」)要求をレプリカシステムに配布することによって、選択されたテーブルのコンテンツをレプリケートしてもよく、主に、マルチノードスケールアウト展開での負荷分散に使用される(すなわち、ワークロードを処理するとき、より多くの計算リソースを活用するために、選択されたテーブルのワークロードを複数のノードに分散する)。
・トリガベースのテーブルレプリケーション:構造化照会言語(「SQL」)トリガによって抽出された変更された行を配布することによって、選択されたテーブルのコンテンツをレプリケートし、主にATRのような負荷分散に使用される。それらの中で、ATRは、システムがテーブルまたはサブテーブル(サブテーブルパーティションまたは列)を負荷分散のためにレプリケートしたいとき、およびシステムがソースシステムに対するより短い伝搬遅延および低いオーバーヘッドを達成したいときも、より良いオプションであり得る。ATRは、最初は、同じスケールアウトシステムインスタンスに属するデータベースノード間のレプリケーションオプションとして設計された。
しかしながら、複数の独立したランドスケープ(たとえば、システムインスタンス)にわたるリアルタイムテーブルレプリケーションのビジネス需要が増大するにつれて、ATRの設計および実装は、本明細書に記載される実施形態によって大幅に拡大され得る。この新しく拡張されたバージョンのATRは、リアルタイム(またはリモート)テーブルレプリケーション(「RTR」)と呼ばれることがある。そのような拡張により、RTRは、以下の2つの例の状況を含む、より広範囲のデータベースレプリケーションアプリケーションに対応し得る。
第1の例示的な状況では、システムが動的に変化するワークロード量を処理する必要があるとき、システム容量を弾性的(elastically)にスケーリングすることが理想的である。ワーストケースの潜在的なピークワークロードを想定してハードウェアを事前購入することなく、代わりに、必要な処理能力を必要に応じて動的に追加することができる(クラウド経由で利用可能なハードウェアリソースを利用して)。たとえば、図3は、いくつかの実施形態による、オンプレミスサーバ310とクラウドリソース320の両方を有する弾性スケーリングを有するRTRを使用するシステム300である。グラフ330によって示されるように、負荷が所定の量を超えて増加するとき(たとえば、年末または四半期末)、クラウド320からの追加のリソースが、オンプレミスサーバ310を補足するために割り振られ得る。
このアーキテクチャは、理論的にはATRで可能であり得るが、RTRは、(1)ソースシステムとレプリカシステムとの間に同じトランザクションドメインを必要としない、および(2)レプリカシステムは、ソースシステムと同じバージョンのデータベースソフトウェアである必要はないという利点を有し得る。その結果、ソースシステムと比較して、異なるライフサイクルでレプリカシステムにパッチを適用したりアップグレードしたりすることができ、システムアーキテクチャ全体により柔軟性をもたらす。たとえば、従来のエンタープライズリソースプランニング(「ERP」)ワークロードは、オンプレミスバージョンのデータベースソフトウェア(ソースシステム)で提供される可能性があるが、新しいタイプの高度な分析ワークロードは、データベースソフトウェア(レプリカシステム)のより新しい(および/またはより頻繁にアップグレードされる)クラウドバージョンで提供することができる。
第2の例示的な状況では、複数のリモートシステムから分散されたデータは、ATRと比較して、RTRでより効率的にクエリされ得る。たとえば、新しい分析クエリが、ERPシステムからのデータベーステーブルとカスタマーリレーションシップマネジメント(「CRM」)システムからの他のデータベーステーブルの両方を必要とするとき、2つのソースを別々にクエリし、アプリケーション層でアドホックな方法でマージすることができる。たとえば、図4は、いくつかの実施形態による、複数のリモートシステム(ERP410およびCRM420)からの効率的なデータ仮想化を使用するRTRシステム400である。次いで、クラウド環境430の新しい分析は、RTRを使用して、リモートシステム410、420の両方から必要な情報を収集することができる。複数のリモートソースシステム410、420にRTRを使用することによって、クエリを、すべての実行でネットワークホップを伴うことなく効率的に、また、データベース層でクエリをネイティブに処理することによってより透過的に処理することができる。このRTRベースのリアルタイムデータ仮想化は、いくつかの実施形態によれば、クラウドコンピューティング環境の特徴であり得る。
そのようなリアルタイムのクロスシステムレプリケーションを可能にするために、RTRは、ATRと比較して、以下の追加の側面に対処する必要があり得る。
・ソースシステムとレプリカシステムとの間の別個のトランザクションドメイン
・ソースシステムとレプリカシステムとの間の別個のメタデータドメイン
・ソースシステムとレプリカシステムとの間で潜在的に異なるソフトウェアバイナリバージョン
・ソースシステムとレプリカシステムとの間の地理的距離。
いくつかの実施形態によれば、RTRの主要なアーキテクチャの特徴は、以下を含み得る。
・厳密なトランザクションの一貫性を確保しながら、行レベルの並列リプレイ
・データ定義言語(「DDL」)レプリケーション、および1つまたは複数のメタデータ更新ログエントリからレプリカシステムでのDDLステートメントの再構築
・厳密なトランザクションの一貫性を確保しながら、テーブルレベルの並列DDLレプリケーション
・複数のレプリケーションオブジェクトの粒度のサポート:テーブルのセット、テーブル、サブテーブル(1つまたは複数の列、1つまたは複数のパーティション)
・複数の個別のリモートソースシステムからのレプリケーション(「N対1のレプリケーション」)、複数の個別のリモートレプリカシステムへのレプリケーション(「1対Nのレプリケーション」)、および第1のレプリカテーブルを第2のレプリカテーブルのソースとするチェーンレプリケーションを含む、様々なレプリケーショントポロジのサポート
・典型的なストアアンドフォワード機構に依存しないインメモリログレプリケーション
・ソースシステムとレプリカシステムとの間の伝搬遅延を低減するためのプッシュベースの早期ログ配布。
図5は、いくつかの実施形態による全体的なリアルタイムテーブルレプリケーションアーキテクチャ500である。システムは、プライマリ520(および関連するリカバリログ530およびチェックポイント540)、および1つまたは複数のレプリカサーバ522(および関連するリカバリログ550およびチェックポイント560)からなり、各々、必ずしもいかなる共有ストレージも使用することなく、コモディティネットワーク相互接続により、互いに接続することができる。すべての書込み要求は、アプリケーションプロセス510に埋め込まれたデータベースクライアントライブラリによってプライマリサーバ520に自動的に向けられる。受信された書込み要求を処理する過程中に、プライマリサーバ520は、書込み要求のレプリケーションログエントリを生成し、レプリケーション対応テーブルに任意の変更を加える。RTRは、必ずしもデータベース全体をレプリケートするのではなく、テーブルの選択されたリストにのみ適用できることに留意されたい。生成されたレプリケーションログエントリは、ネットワーク相互接続を介してレプリカ522に配布され、レプリカ522でリプレイされる。伝搬されたレプリケーションログエントリをリプレイすることによって、レプリカ522のインメモリデータベースのコピーは、クエリ可能なトランザクション的に一貫した状態に維持される。データベースクライアントライブラリは、レプリカデータベースの状態がクエリの所与の鮮度要件を満たす場合、読取り専用クエリを透過的にレプリカにルーティングする。
RTRは、高可用性または障害回復の目的で拡張することもできるが、RTRの1つの目的は、オンライン分析処理(「OLAP」)スタイルの分析ワークロードを、オンライントランザクション処理(「OLTP」)スタイルのトランザクションワークロードの処理用に予約されているプライマリサーバ520からオフロードすることである。加えて、同じプライマリテーブル520に複数のレプリカ522を有することによって、RTRは、OLAPスタイルの分析ワークロードの手頃なボリュームを柔軟にスケールアウトすることができる。さらに、プライマリテーブル520をOLTP優先インメモリ行ストアとして構成し、そのレプリカ522をデータプラットフォーム(たとえば、SAPから入手可能なHANA(商標)など)でOLAP優先インメモリ列ストアとして構成することによって、RTRは、共通データベーススキーマおよび単一トランザクションドメイン下でのOLTPとOLAPの混合ワークロードの処理の機能を最大にし得る。
図6Aは、いくつかの実施形態による、クロスランドスケープRTRを600で示す。特に、2つのテナントデータベースを有するソースクラウドシステム610は、オープンデータベースコネクティビティ(「ODBC」)接続を使用して2つのテナントデータベースを有するレプリカクラウドシステム620と通信する。ATRは同じランドスケープ内でテーブルをレプリケートし、RTRは2つの異なるデータプラットフォームシステム間でテーブルをレプリケートする。SAP(商標)ランドスケープトランスフォーメーション(「SLT」)と呼ばれる同様のレプリケーション手法がすでにあることに留意されたい。しかしながら、SLTは、トリガベースのレプリケーションであり、ソースシステムにかなりのオーバーヘッドをもたらす。RTRは、ATRのようなログ送信手法を使用して、より良い性能、およびより軽いオーバーヘッドを提供する。セキュリティ上の理由から、ソースシステム610からの更新ログは、(TrexNetプロトコルを使用する代わりに)直接ODBC接続によってレプリカシステム620に転送され得る。
システム600は、レプリケーション情報をシステムテーブルに記憶する。この情報は、インメモリ構造内にも記憶される(通常の状態ではシステムテーブルへの直接アクセスはない)。システムテーブルへのアクセスは、データをインメモリ構造およびDDLログリプレイにロードするために、サーバ起動時にのみ行われる。DMLログリプレイ中、インメモリ構造のみが使用される。初期化パラメータは、「metadata」(デフォルト値=false、レプリケーション前にソースシステムとレプリカシステムの両方でtrueに設定)、「metadata」および「crossdb_atr_ddl_test_mode」(Pythonおよび単体テストで、デフォルト値=false)などを含むindexserver.iniに関連付けられている可能性がある。
システムテーブルは、リモートテーブルのレプリケーションに関するレプリケーション情報を永続的に保存し得る。5つのシステムテーブルがあり得、1つはソースシステム用、残りはターゲットシステム用である。
・SYS.REMOTE_TABLE_REPLICA_SOURCES_(ソースシステムに保存されたレプリケーション関係情報)
・SYS.REMOTE_TABLE_REPLICA_TARGETS_(ターゲットシステムに保存されたレプリケーション関係情報)
・SYS.REMOTE_TABLE_REPLICA_COLUMNS_(ターゲットシステムに保存されたソーステーブルの列情報)
・SYS.REMOTE_TABLE_REPLICA_INDEXES_(ターゲットシステムに保存されたソーステーブルのインデックス情報)
・SYS.REMOTE_TABLE_REPLICA_PARTITIONS_(ターゲットシステムに保存されたソーステーブルのパーティション仕様情報)。
REMOTE_TABLE_REPLICA_SOURCES_テーブルは、RTR情報をソースシステムとして記憶し得る。これは、このシステムのどのテーブルがどのレプリカシステムにレプリケートされるかを示す。このテーブルのコンテンツにより、サーバの再起動時にインメモリRTR情報が回復される。REMOTE_TABLE_REPLICA_TARGETS_テーブルは、RTR情報をレプリカシステムとして記憶し得る。これは、このシステムのどのテーブルがソースシステムのどのテーブルのレプリカであるかを示す。このテーブルのコンテンツにより、サーバの再起動時にインメモリRTR情報が回復される。REMOTE_TABLE_REPLICA_COLUMNS_テーブルは、RTR情報をターゲットシステムとして記憶し得る。この情報は、DDLリプレイ中に使用される。このテーブルのコンテンツおよびソースシステムから受信されたメタデータredoログにより、RTR DDLリプレーヤは、ADD、ALTER、またはDROP COLUMNなど、列に関連するレプリカテーブルのDDLステートメントを生成する。
REMOTE_TABLE_REPLICA_INDEXES_テーブルは、RTR情報をターゲットシステムとして記憶し得る。この情報は、DDL再生中に使用される。このテーブルのコンテンツおよびソースシステムから受信されたメタデータredoログにより、RTR DDLリプレーヤは、ADDまたはDROP CONSTRAINTおよびCREATEまたはDROP INDEXなどのインデックスおよび制約に関連するレプリカテーブルのDDLステートメントを生成する。
REMOTE_TABLE_REPLICA_PARTITIONS_テーブルは、RTR情報をターゲットシステムとして記憶し得る。この情報は、DDL再生中に使用される。このテーブルのコンテンツおよびソースシステムから受信されたメタデータredoログにより、RTR DDLリプレーヤは、PARTITION BY、ADD PARTITION FROM OTHERS、DROP PARTITIONなどのテーブルパーティションに関連するレプリカテーブルのDDLステートメントを生成する。
いくつかの実施形態によれば、組込みプロシージャは、RTRの作成、アクティブ化、および非アクティブ化(DDLステートメントによってレプリカシステムでトリガされる)に関連付けられ得る。これは、レプリカシステムでのRTR関連のDDLステートメントの実行中に、リモートソースを介してソースシステムで実行される関連する組込みプロシージャを呼び出す。たとえば、レプリカシステムでの「CREATE REPLICA」DDLの実行中、ソース側でRTRを初期化するために、ソースシステムで「SYS.REMOTE_TABLE_REPLICA_CREATE_DEV」プロシージャが実行され得る。「SYS.REMOTE_TABLE_REPLICA_ENABLE_DEV」は、レプリカ側の「ENABLE REPLICA」DDLの場合はソース側で、「SYS.REMOTE_TABLE_REPLICA_DISABLE_DEV」は、「DISABLE REPLICA」DDLの場合に実行され得る。「SYS.REMOTE_TABLE_REPLICA_LOG_TRANSFER_DEV」は、ソースシステムからレプリカシステムにATRログを送信するためのものであり、したがって、これは、ソース側で呼び出され、レプリカ側で実行される。
いくつかの実施形態によれば、インメモリ構造は、システムテーブルに永続的に記憶されたRTR情報に関連付けられてもよい(および関連情報もインメモリで管理されてもよい)。このインメモリ情報は、MDR::ReplicationInfo下で管理されてもよく、RTR ReplicationManagerによってアクセスされる。この情報は、indexserverがMDR::ReplicationInfoHelperクラスで再起動されたとき、システムテーブルから回復される場合もある。ソースシステムで、テーブルに変更(DMLまたはDDL)がある場合、ReplicationManagerは、このテーブルがRTRレプリケートされているかどうかをチェックする。そうである場合、ReplicationManagerは、レプリカの位置を取得して、ATRログを送信する。また、ログを送信するために、関連するリモートソース名およびターゲットリモートソース名が取得される。ソーステーブルoidにより、ReplicationManagerによって以下の情報、レプリカ位置:レプリカの位置を取得する、リモートソース名:リモートソースを介してATRログを送信する、および(ターゲット)リモートソース名が取得され得る。RTRログは、リモートソース(TrexNetプロトコルではない)を介して送信されるので、ReplicationManagerは、m_logsender_mapから取得されたレプリカの位置からリモートソース名を取得する必要がある場合がある。ハッシュテーブルを使用して、レプリカの位置からリモートソース名を取得し得る(このハッシュテーブルは、レプリカ側でも使用され得る)。レプリカシステムでは、受信されたATRログは、ソーステーブルoidおよびターゲットリモートソース名を含む。ATRログをリプレイするために、ATRログリプレーヤは、ATRログリプレイのターゲットテーブルを見つける必要がある。
RTRセットアップ、アクティブ化、および/または非アクティブ化に関して、いくつかの実施形態は、リモートソースの準備を提供し得る。図6B～図6Hは、RTRセットアップ、アクティブ化、および非アクティブ化に関連付けられた方法である。RTRによりテーブルをレプリケートする前に、リモートソースをソースシステムとレプリカシステムの両方で相互に作成する必要がある。ソースシステムは、レプリカシステムへのスマートデータアクセス(「SDA」)リモートソースを有していてもよく、レプリカシステムは、ソースシステムへのSDAリモートソースを有する必要がある。これらのリモートソースは、ATRログ転送およびレプリケーションのアクティブ化/非アクティブ化に使用され得る。
以下のDDLステートメントを実行することによって、レプリカ側でRTRレプリケーションが開始され得る。
CsREATE TABLE <schema_name>.<table_name> LIKE <remote_source_name_at_target>.<remote_schema_name>.<remote_table_name> ASYNCHRONOUS REPLICA USING REMOTE SOURCE <remote_source_name_at_source>
図6Bは、いくつかの実施形態による、RTRテーブル作成DDL方法である。RTRテーブル作成DDL(void QueryExecutor::create_remote_table_replica())内のステップは、ターゲットリモートソース(remote_source_name_at_target)を介してSYS.REMOTE_TABLE_REPLICA_CREATE_DEV()を呼び出すためのS611を含む場合があり、したがって、この組込みプロシージャは、ソースシステムで実行される。この組込みプロシージャ内では、以下の内部ステップがソースシステムで実行され得る。
・ソーステーブルのメタデータ(json形式)およびテーブルグループ情報を取得する。
・このソーステーブルにビューを作成する。このビューの名前は、_SYS_REMOTE_REPLICA_SOURCE_{source_table_oid}であり得る。このビューは、RTRアクティブ化フェーズ中のテーブルデータの同期のためのものである。このデータ同期は、ソーステーブルとレプリカテーブルとの間の「$rowid$」の比較に基づいてSQLステートメントの「insert」および「delete」によって実行され、したがって、このビューは、ソーステーブルのすべての列+rowid列を含む。「$rowid$」構文は、レプリカ側のリモートソースにおける仮想テーブルでは使用できないので、レプリカ側の仮想テーブルをソーステーブル上に直接作成することはできない。したがって、このビューは、ソーステーブルの「$rowid$」列を選択する「_ROWID_FOR_REP」という名前の列を有し、レプリカ側の仮想テーブルは、直接ソーステーブルではなく、このビューに作成される。
・RTR情報をシステムテーブル(SYS.REMOTE_TABLE_REPLICA_SOURCES_)およびインメモリに挿入する。
・RTR情報をReplicationManagerに登録する(まだアクティブ化せず、登録するだけである)。
・このソーステーブルのAsyncPlanを無効にし、したがって、この新しく登録されたレプリケーションをソーステーブルにおけるDMLによって認識することができる。
S612で、システムは、レプリカテーブルを作成し、システムテーブルにRTRレプリケーションを挿入し得る。上記の組込みプロシージャによって取得されたメタデータにより、関連するDDLステートメントが生成され、実行され、したがって、空のレプリカテーブルが作成される(インポート-エクスポートコンポーネントAPIに基づいて)。システムはまた、システムテーブルにRTR情報を挿入し得る。レプリカシステムでは、SYS.REMOTE_TABLE_REPLICA_TARGETS_、SYS.REMOTE_TABLE_REPLICA_COLUMNS_、SYS.REMOTE_TABLE_REPLICA_INDEXES_だけでなく、SYS.REMOTE_TABLE_REPLICA_PARTITIONS_テーブルも埋められる。これらのシステムテーブルは、後のDDLリプレイのために必要である。
S613で、システムは、リモートソースにおけるソーステーブル上のビューのための仮想テーブルを作成し得る。仮想テーブルは、ソースシステムでの組込みプロシージャによって作成されたビュー上に作成され得る。「$rowid$」構文は、仮想テーブルでは許可されない場合があり、したがって、システムは、rowid列(_ROWID_FOR_REPの名前として)およびソーステーブルのすべての他の列を有する仮想テーブルをビューに作成する場合があることに留意されたい。S614で、システムは、インメモリRTRレプリケーション情報およびATR ReplicationManagerを設定し得る。
図6Cは、いくつかの実施形態によるRTRレプリケーションアクティブ化方法である。RTRのアクティブ化は、レプリカ側の以下のDDLステートメントによってトリガされる場合があることに留意されたい。
ALTER TABLE <schema_name>.<table_name> ENABLE ASYNCHRONOUS REPLICA
RTRレプリカをアクティブ化することは、RTR非アクティブ化期間のある時間の後に実行され得る。RTRの非アクティブ期間に、レプリケーションが切断され、したがって、DMLだけでなくDDLもソーステーブルに対してのみ実行することができる。したがって、ATRログ転送を再アクティブ化する前に、DMLとDDLの差を最初に同期する必要がある。
RTRアクティブ化DDL(void QueryExecutor::alter_table_enable_remote_table_replica())内のステップは、ソーステーブルおよびレプリカテーブルのスキーマを同期するためのS621を含み得る。ソーステーブルのメタデータが取得され(特別なオプションによりSYS.REMOTE_TABLE_REPLICA_CREATE_DEVを呼び出すことによって)、レプリカテーブルのメタデータと比較されることに留意されたい。メタデータの差が検出された場合、DDLステートメントが生成され、レプリカテーブルに対して実行され、したがって、テーブルスキーマが最初に同期される。
S622で、システムは、Xロックなしでソーステーブルとレプリカテーブルのデータ差を同期させ得る。いくつかの実施形態によれば、データ同期は、2つのSQLステートメントを実行することによって行われる。
(1)行の「$rowid$」を比較することによって、ソーステーブルにもはや存在しないレプリカテーブルから行を削除する
(2)行の「$rowid$」を比較することによって、ソーステーブルにのみ存在し、レプリカテーブルには存在しない行をレプリカテーブルに挿入する。
RTR非アクティブ化期間の時間が長い場合、このデータ差は大きくなる可能性がある。ソーステーブルにおいてXロックを長時間保持しないために、システムは、最初に、Xロックなしでデータを同期する場合がある。ソーステーブルおよびレプリカテーブルの列に変更がある場合、これらのSQLステートメントは仮想テーブル上にあるので(ソースシステムにおける関連するビューに対して)、上記のSQLの実行中にエラーが発生する可能性がある。次いで、ソースシステムでのビューおよびレプリカシステムでの関連する仮想テーブルがドロップされ、再作成され、データ同期が再試行される。
S623で、システムは、ターゲットリモートソースを介してSYS.REMOTE_TABLE_REPLICA_ENABLE_DEV()を呼び出し得、したがって、この組込みプロシージャは、ソースシステムで実行される。この組込みプロシージャ内では、ソースシステムで以下の内部ステップが実行される。ソーステーブルにおけるXロックは、第2のデータ同期の処理中にソーステーブルにおける任意のDML/DDLをブロックする可能性があることに留意されたい。システムはまた、ATRログをレプリカシステムに送信するようにソースシステムにおいてReplicationManagerを設定してもよい。S624で、システムは、ソーステーブルとレプリカテーブルのデータ差を再度同期させ得る。ソーステーブルにおけるXロックがソースシステムで保持されているので、ソーステーブルにいかなるDML/DDLもない。そのため、この第2のデータ同期の後、ソーステーブルおよびレプリカテーブルは完全に同じデータを有する。S622での最初のデータ同期により、データに大きな差はないはずであり、したがって、今回は、DELETE/INSERT SQLの実行は時間が長くはかからないことが予想される。S625で、システムは、ATRログを得る準備ができているレプリカシステムにおいてReplicationManagerを設定し得る。S626で、システムは、ソーステーブルにおけるXロックを解放する。このDDLトランザクションをコミットすることによって、ステップ3で取得されたXロックが解放され、ソーステーブルのDML/DDLのブロックが解除される。
いくつかの実施形態は、第2の差分同期を回避し、Xロック持続時間を最低限に抑えるために、アクティブ化論理を最適化し得る。たとえば、図6Dは、いくつかの実施形態による、ソーステーブルにおける短いXロックによるRTRレプリケーションを可能にし得るワークフロー630である。特に、ワークフロー630は、短い持続時間のxロックを使用して、スナップショットを取り、ステータスを更新する。いくつかの実施形態によれば、次いで、長い実行ジョブがIXロックで実行される。配布されたDMLログは、ENABLINGステータスで破棄されず、ログディスパッチャは、着信DMLログをブロックすることに留意されたい。最初の同期に関して、ロックがIXに降格された後、システムは、DDL変更をレプリカテーブルに適用する場合がある。さらに、JSONがソースから取得され、レプリカが更新され得る。加えて、DDLをソースにおいて実行しないものとする(取得されたIX-lockによってブロックされ、オンラインDDLは、ソーステーブルにおいてブロックされる)。いくつかの実施形態によれば、ログディスパッチャは、DMLログのディスパッチをブロックする必要がある。ロックをIXモードに降格した後、DMLログをレプリカに配布してもよい。DMLログリプレイ時、ログディスパッチャは、ReplicaTableInfo(レプリカテーブルメタデータによって生成される)により準備されたステートメントを構築してもよい。いくつかの実施形態によれば、システムは、(applyDDLChangeによって更新された)最新のテーブルメタデータを見る必要があり、次いで、ReplicaTableInfoキャッシュをクリーンアップし得るので、ENABLE REPLICAコミットを待つ必要がある場合がある。加えて、ログディスパッチャは、ENABLE REPLICA DDLがコミットされるまでディスパッチをブロックする場合がある。ENABLE REPLICA DDLが失敗した場合(たとえば、try/catchでの処理)、ENABLEDステータスは、ロールバックされる可能性があることに留意されたい。さらに、ステータスENABLINGは、ATRケースのステートメントルーティングに関連している可能性がある(すなわち、RTRは、このステータスを必要としない場合がある)。
図6Eは、いくつかの実施形態によるRTRテーブル非アクティブ化方法である。いくつかの実施形態によれば、RTR非アクティブ化は、レプリカ側で以下のDDLステートメントによってトリガされ得る。
ALTER TABLE <schema_name>.<table_name> DISABLE ASYNCHRONOUS REPLICA
RTR非アクティブ化DDL(QueryExecutor::alter_table_disable_remote_table_replica())内のステップは、ターゲットリモートソースを介してSYS.REMOTE_TABLE_REPLICA_DISABLE_DEV()を呼び出すためのS641を含む場合があり、したがって、この組込みプロシージャは、ソース側で実行される。このプロシージャ内では、以下の内部ステップがソース側で実行される。システムはまた、レプリカへのATRログの送信を停止するために、ソースシステムのReplicationManagerを設定し得る。このプロシージャがDISABLE REPLICAについて呼び出される場合、これはここに戻る。このプロシージャがDROP TABLEについて呼び出されると、追加のジョブが実行される可能性があり、これについては、「レプリカテーブルのドロップ」に関連して記載される。S642で、システムは、ATRログのリプレイを停止するために、レプリカシステムのReplicationManagerを設定し得る。
図6Fは、いくつかの実施形態による、RTRテーブルデータのエクスポート/インポート方法である。S651で、「CREATE replica」と「ENABLE replica」との間で、手動のエクスポート/インポートテーブルがサポートされている。ソーステーブルのコンテンツがかなり大きい場合、「insert into … select …」ステートメントによるデータ同期には時間がかかる場合がある。したがって、この場合、ソーステーブルをエクスポートし、レプリカテーブルにインポートすると、初期データの同期が効率的ではるかに高速になる。テーブルのエクスポートは、「AS BINARY」オプション(S652)で行われ、テーブルのインポートは、「DATA ONLY」オプション(S653)で行われる。ステップは、以下を含み得る。
・レプリカシステムで、最初にレプリカテーブルを作成する。
CREATE COLUMN TABLE … LIKE … ASYNCHRONOUS REPLICA USING REMOTE SOURCE …
・ソースシステムでは、
EXPORT schema.table AS BINARY INTO …
・(エクスポートされたファイルをレプリカシステムにコピーした後)
・レプリカシステムでは、
IMPORT schema.table AS BINARY FROM … WITH DATA ONLY
・レプリカシステムでは、ここで「enable replica」:
ALTER TABLE schema.table ENABLE REPLICA
いくつかの実施形態は、利用可能な場合、自動テーブルエクスポートおよび/またはインポートもサポートし得る。すなわち、いくつかの実施形態では、ENABLE REPLICAは、バイナリエクスポート、転送、および/またはインポートのステップを含み得る。
図6Gは、いくつかの実施形態による、RTRレプリカテーブルドロップ方法である。レプリカテーブルがドロップされると、ソースシステムとレプリカシステムの両方のRTR情報がクリアされることに留意されたい。DROP TABLE <schema_name>.<table_name>(QueryExecutor::alter_table_disable_remote_table_replica())は、DISABLE REPLICA DDLが呼び出されると、DROP TABLEにも再度使用される。しかし、この場合、引数「calledAtDropTable」はtrueであり、したがって、もう1つのジョブ、つまり、レプリカシステムとソースシステムの両方においてRTR情報をクリーンアップする。ステップは、ターゲットリモートソースを介してSYS.REMOTE_TABLE_REPLICA_DISABLE_DEV()を呼び出すためのS661を含む場合があり、したがって、この組込みプロシージャは、ソース側で実行される。このプロシージャの引数「calledForDropTarget」が「True」に設定され得ることに留意されたい。このプロシージャ内では、以下の内部ステップがソース側で実行される。
・ソースシステムのReplicationManagerからRTR情報を登録抹消する。
・RTR情報をシステムテーブル(SYS.REMOTE_TABLE_REPLICA_SOURCES_)およびインメモリからも削除する。
・ATR AyncPlanを無効にする。
・このレプリケーションがこのテーブルの最後のレプリケーションであり、したがって、レプリカがもはやない場合、DROP VIEW (_SYS_REMOTE_REPLICA_SOURCE_{source_table_oid}である。
レプリカテーブルがドロップされたとき、ソースシステムが利用可能でない場合、ソースシステム内のRTR情報をクリアし、ガベージデータとして残すことはできない。RTRは、戦略的に、反対側が利用できないときにテーブルのドロップを許可しないので、ソースシステム内のこのガベージRTR情報を作成することはできるが、回避方法によって後でクリアすることもできる。
S662で、システムは、レプリカシステムのReplicationManagerからRTR情報を登録抹消し得る。S663で、システムは、このテーブルに関するRTR情報をシステムテーブルおよびインメモリから削除し得る。最後に、S664で、システムは、このレプリケーションの仮想テーブルをドロップし得る。
図6Hは、いくつかの実施形態による、RTRソーステーブルドロップ方法である。ソーステーブルがドロップされると、ソースシステムとレプリカシステムの両方のRTR情報がクリアされることに留意されたい。
DROP TABLE <schema_name>.<table_name>
ソーステーブルがドロップされると、ソースシステムのRTR情報だけでなく、すべてのレプリカのRTR情報もクリーンアップされる。(QueryExecutor::drop_table_disable_remote_table_replicated())内のステップは、レプリカごとに、S671で、リモートソースを介して「ALTER TABLE replica_table DISABLE REPLICA」を実行することを含み得、したがって、このDDLは、すべてのレプリカ側で実行される。すべてのレプリカについて、RTRは、非アクティブ化される(たとえば、レプリカテーブルはドロップされない)。ソーステーブルがドロップされたとき、レプリカシステムの一部が利用可能でない場合、レプリカシステム内のRTR情報をクリアし、ガベージデータとして残すことはできない。RTRは、戦略的に、反対側が利用できないときにテーブルのドロップを許可しないので、ソーステーブルが最初にドロップされた場合、レプリカシステム内のこのガベージRTR情報を作成することができる。
レプリカごとに、S672で、SYS.REMOTE_TABLE_REPLICA_DISABLE_DEV()を呼び出し、したがって、このプロシージャがソース側で実行される。上記の「DISABLE REPLICA」DDLが正常に実行された場合、このプロシージャは、そのときすでに実行されている可能性があり、したがって、今回のプロシージャコールでは何も行われない可能性がある。しかし、レプリカシステムは利用可能でなく、したがって、上記の「DISABLE REPLICA」DDLが実行されなかった場合、このプロシージャコールは、少なくともソース側のRTR情報をクリアすることができる。
いくつかの実施形態は、スマートデータ統合(「SDI」)構文でRTRをさらにサポートし得る。RTRは、ATRから発生したものであり、リアルタイムダイレクト/プッシュレプリケーション用であったが、SDIは、代わりにサブスクリプションモデルであることに留意されたい。システムが異なる内部メカニズム(RTRおよびSDI)を保持し得る場合でも、いくつかの実施形態は、単一のエンドユーザ抽象化を提供するために、2つの間のSQLインターフェースを統合し得る。RTRインターフェースは、SDIスタイルのSQLインターフェースに切り替えられるので、ユーザは、同じインターフェースでRTRを使用し得る。RTRは、アダプタ名を除き、インターフェースに従い得る。ユーザは、レプリカシステムで{CREATE | ALTER | DROP} REMOTE SUBSCRIPTIONステートメントを実行することによって、リモートテーブルレプリケーションを作成、アクティブ化、非アクティブ化、および/またはドロップすることができる。リモートテーブルレプリケーションをセットアップするために、ユーザは、仮想テーブル、ターゲットテーブル、リモートサブスクリプションを作成し、レプリカシステムにおいてレプリケーションをアクティブ化し得る。
例外が発生した場合、それは、レプリカシステムでPROCESS REMOTE SUBSCRIPTION EXCEPTIONステートメントを実行することによって処理され得る。仮想テーブルからのリモートソースのアダプタタイプがhanaodbcであるとき、CREATE REMOTE SUBSCRIPTIONステートメントは、リモートテーブルレプリケーションを行う。
CREATE REMOTE SUBSCRIPTION [<schema_name>.]<subscription_name>
{
{ON [<schema_name>.]<virtual_table_name> } |
{AS (<subquery>)}
}
[ WITH SCHEMA CHANGES ]
{ TARGET TABLE <table_spec> <load_behavior> } |
{ TARGET TASK <task_spec> } |
{ PROCEDURE <proc_spec> }
RTRのCREATE REMOTE SUBSCRIPTIONは、以下の条件が満たされたときにサポートされる可能性がある。(1)ソースオブジェクトタイプは、ON節を使用した仮想テーブルである、および(2)ターゲットオブジェクトタイプはテーブルである。これらの条件が満たされていない場合、システムは、サポートされていない特徴のエラーが発生し得る。
CREATE REMOTE SUBSCRIPTION
[<schema_name>.]<subscription_name>
ON [<schema_name>.]<virtual_table_name>
TARGET TABLE [<schema_name>].<table_name>;
リモートテーブルレプリケーションでは、WITH SCHEMA CHANGESオプションは、常にtrueである可能性があることに留意されたい(スキーマ同期なしではRTRをアクティブ化できないので)。
アクティブ化レプリケーションは、レプリケーションをアクティブ化する場合がある。それは、最初にレプリケーションを無効にし、次いで、スキーマおよびレコードをソーステーブルと同期する。すべての同期が完了した後、それは、レプリケーションを有効にする。非アクティブ化レプリケーションは、ソースシステムとレプリカシステムの両方でテーブルレプリケーションを停止する場合がある。レプリケーションのステータスは、ビューM_REMOTE_TABLE_REPLICASで「DISABLED BY USER」としてマークされる。ドロップレプリケーションは、レプリカ情報をドロップし、それを通常のテーブルに変更する場合がある。PROCESS REMOTE SUBSCRIPTION EXCEPTIONステートメントによって、ユーザは、例外の処理方法を示し得る。
図7は、いくつかの実施形態による、RTRログリプレイに関連付けられたソースシステム710およびレプリカシステム720を含むアーキテクチャ700を示す。RTRソーステーブルにおけるDML/DDL変更は、リモートソースを介して組込みプロシージャ(SYS.REMOTE_TABLE_REPLICA_LOG_TRANSFER_DEV())を呼び出すことによって、ATRログ送信機によってレプリカシステムに転送されることに留意されたい。レプリカシステム720では、転送されたログがATRリプレーヤによって処理され、したがって、変更がレプリカテーブルに適用される。
DML変更の場合、ATRは、ログ転送およびログリプレイ内に拡張アプリケーションプログラムインターフェース(「EAPI」)層を追加した。図8は、いくつかの実施形態による、異なるバイナリバージョン間のクロスデータベースATR800である。ソーステーブル更新810の場合、EAPI層の後に、テーブルの更新、変更の適用、TUからの変換、およびEAPIベースのATRログが続く。レプリカテーブルレプリケート820の場合、EAPIレイヤの後に、テーブルの更新および変更の適用が続く。DDL変更の場合、ATRは、ソースシステムにおいて生成された生のMDRedoDataを送信するだけである。
レプリカシステムでは、これらのMDRedoDataは、レプリカテーブルに直接適用することができないので、それらは解析され、DDLステートメントに変換され、図9に示されるようにレプリカテーブル上で実行され、図9は、いくつかの実施形態による、レプリカテーブルをレプリケートする方法900を示す。特に、MDRedoLogの後に、DDLステートメントの生成およびDDLの実行が続く。
各MDRedoDataは、メタデータの変更を記述するJavaScript Object Notation(「JSON」)文字列を含み得ることに留意されたい。このJSON文字列により、システムは、DDLステートメントを逆に生成し得る。単一のDDLステートメントは、ソースシステムで複数のメタデータredoログを作成することができ、レプリカシステムにおいて正しいDDLを変換するには、関連するすべてのメタデータredoログを収集する必要がある。そのため、レプリカシステムのATRログハンドラでは、トランザクションコミットログが検出されるまで、受信されたDDLログは、まず、各テーブルのDDLログキューに入れられる。トランザクションコミットログが転送されると、キューに入れられたDDLログがDDLステートメントに変換される。
図10は、いくつかの実施形態による、データ定義言語ログのリプレイ1000を表す。特に、ATRログハンドラは、DDLログをDDLログハンドラ1020に送信し、DMLログをDMLログハンドラ1030に送信する。DDLログリプレイプロセスは、以下の通りであり得る。
・レプリカテーブルのログキューは、第1のDDLログが受信されたときに作成される。いくつかの実施形態によれば、MDR::LogQueue::getInstance()->register_queue()は、「void TransactionContainer::pushDDLLog()」で使用され得る。
・DDLログは、トランザクションコミットまで、このキューに入れられる。いくつかの実施形態によれば、MDR::LogQueue::getInstance()->push()は、「void TransactionContainer::pushDDLLog()」で使用され得る。
・トランザクションがコミットされると、DDLリプレーヤがこのキューで作成され、DDL:MDR::Replayer replayer(log_queue)およびreplayer.reply() in void TransactionContainer::replayDDLLog()をリプレイする。
・次いで、ログキューが破棄され得る。いくつかの実施形態によれば、MDR::LogQueue::getInstance()->unregister_queue()は、void TransactionContainer::replayDDLLog()で使用され得る。
DDL生成に関して、単一のDDLステートメントは、複数のDDLログ(メタデータredoログ)を作成することができる。たとえば、
・「alter table src add (b int)」は、単一のメタデータredoログを作成する。
・「alter table src add (識別としてデフォルトで生成されたc int(10 maxvalue 100から開始))」は、2つのメタデータredoログを作成する。
・「alter table src add (i int unique)」は、3つのメタデータredoログを作成する。
そのため、システムは、単一のメタデータredoログごとにDDLステートメントを生成することはできないが、キューからの次のメタデータredoログが前のメタデータredoログに関連しているかどうかをチェックする必要がある。
いくつかの実施形態によれば、スキーマ同期は、RTRが再アクティブ化されるときにDDLリプレイに関連付けられてもよい。たとえば、redoログを転送することによって、ソーステーブルにおけるDDLがレプリカテーブルにリプレイされ得る。しかし、RTRの非アクティブ化中にソーステーブルにおいてDDLが実行された場合、そのredoログは転送されない。また、RTRが再アクティブ化されると、システムは、ソーステーブルの古いメタデータredoログを選択的に得ることができない場合がある(その結果、システムは、この方法でテーブルメタデータの変更を同期することができない)。
したがって、RTRが再アクティブ化されると、ソーステーブルおよびレプリカテーブルの現在のメタデータが比較され、検出された変更がDDLとして生成され、レプリカテーブルにリプレイされる。図11は、いくつかの実施形態による、RTRアクティブ化およびDDLステートメントの生成1100を示す。特に、ソーステーブル1110のメタデータは、レプリカテーブル1120のメタデータと比較され得る。ソーステーブル1110およびレプリカテーブル1120のメタデータを比較することによって、スキーマの同期は以下のように行われる。
・ソーステーブルとレプリカテーブルの「_truncatedCount」が異なる場合、レプリカテーブルを切り捨てる(ソーステーブルの同じ「_truncatedCount」値をレプリカテーブルに設定する)。
・レプリカテーブルのインデックス(制約)をドロップ/リネームする。インデックスのoidを比較することによって、ソーステーブルに存在しないレプリカインデックスがドロップされる。インデックスの名前(_SYS_で始まるシステム生成の名前ではない)が異なる場合、インデックス名がリネームされる(インデックス/制約のドロップは、列のドロップよりも前に行われ、DDLのリプレイ時に例外は発生しない)。
・レプリカテーブルの列をドロップ/リネーム/変更する。列のoidおよび名前を比較することによって、ソーステーブルに存在しないレプリカ列がドロップされる。oidは同じであるが名前または列情報が異なるレプリカ列は、リネームされ、変更される。
・レプリカテーブルに列を追加する(ソーステーブルにのみ存在する列がレプリカテーブルに追加される)。
・レプリカテーブルにインデックスまたは制約を作成する。ソーステーブルにのみ存在するインデックス(制約)がレプリカテーブルに追加される(インデックス/制約の作成は、すべての列が同期された後で行われる必要がある)。
・ソーステーブルおよびレプリカテーブルのpartitionSpecが異なる場合、パーティションを変更する。
図12は、本明細書で記載されている任意の実施形態の要素の一部またはすべてによって実行され得る方法である。本明細書で記載されているフローチャートは、ステップへの固定順序を意味するものではなく、本発明の実施形態は、実施可能な任意の順序で実施されてもよい。本明細書に記載されている方法のいずれかは、ハードウェア、ソフトウェア、コマンドの自動スクリプト、またはこれらの手法の任意の組合せによって実行され得ることに留意されたい。たとえば、コンピュータ可読記憶媒体は、マシンによって実行されたときに、本明細書に記載されている実施形態のいずれかによる性能をもたらす命令を記憶し得る。
S1210で、システムは、レプリケーションログエントリおよび関連付けられたトランザクションコミットログエントリを受信し得る。レプリケーションログエントリおよび関連するトランザクションコミットログエントリは一緒に、レプリカテーブルの行にリプレイされるデータベーストランザクションを表し得る。いくつかの実施形態によれば、レプリケーションログエントリは、行ID値を有し、レプリカテーブルの行は、行ID値を有する。
S1220で、システムは、レプリケーションログエントリを並列ログリプレーヤにディスパッチし、関連するトランザクションコミットログエントリをトランザクションコミットログリプレーヤにディスパッチし得る。次いで、システムは、S1230で、レプリケーションログエントリの行ID値をレプリカテーブルの行の行ID値と比較し得る。S1240で、比較に基づいて、並列ログリプレーヤでレプリケーションログエントリをリプレイする。
S1250で、システムは、関連するトランザクションコミットログエントリをトランザクションログリプレーヤでリプレイすることによって、データベーストランザクションをレプリカテーブルにコミットし得る。いくつかの実施形態によれば、データベーストランザクションは、トランザクションの一貫性を有する行レベルの並列リプレイに関連付けられる。さらに、レプリカシステムでのDDLレプリケーションとDDLステートメントの再構築は、1つまたは複数のメタデータ更新ログエントリに関連付けられ得る。
図13は、いくつかの実施形態による、RTRディスプレイ1300である。ディスプレイ1300は、ソースシステムおよびレプリカシステムを含むRTRシステムのグラフィカル要素1310を含む。グラフィカル要素の選択(たとえば、タッチスクリーンまたはコンピュータのマウスポイント1390を介して)によって、オペレータまたは管理者は、その要素に関する追加情報(たとえば、ポップアップウィンドウを介して)を表示したり、および/またはその要素に関連付けられたパラメータ(たとえば、テーブルマッピングまたは選択、レプリカシステムの詳細など)を調整し得る。さらに、「セットアップ」アイコン1320の選択によって、ユーザは、システムの動作を構成し得る。
様々な実施形態は、たとえば、図14に示されるコンピュータシステム1400など、1つまたは複数のよく知られているコンピュータシステムを使用して実装され得る。コンピュータシステム1400は、本明細書に記載された機能を実行することができる任意のよく知られているコンピュータとすることができる。コンピュータシステム1400は、プロセッサ1404など1つまたは複数のプロセッサ(CPUとも呼ばれる)を含む。プロセッサ1404は、通信インフラストラクチャまたはバス1406に接続される。
1つまたは複数のプロセッサ1404は、各々グラフィックス処理ユニット(GPU)であり得る。一実施形態では、GPUは、数学的に集約的なアプリケーションを処理するように設計された特殊な電子回路であるプロセッサである。GPUは、コンピュータグラフィックスアプリケーション、画像、ビデオなどに共通する数学的に集約的なデータのような、大きいデータブロックの並列処理に効率的な並列構造を有し得る。
コンピュータシステム1400は、ユーザ入力/出力インターフェース1402を介して通信インフラストラクチャxx06と通信する、モニタ、キーボード、ポインティングデバイスなどのユーザ入力/出力デバイス1403も含む。
コンピュータシステム1400は、ランダムアクセスメモリ(「RAM」)などのメインメモリまたは1次メモリ1408も含む。メインメモリ1408は、1つまたは複数のレベルのキャッシュを含み得る。メインメモリ1408には、制御論理(すなわち、コンピュータソフトウェア)および/またはデータが記憶されている。
コンピュータシステム1400は、1つもしくは複数の2次記憶デバイスまたはメモリ1410も含み得る。2次メモリ1410は、たとえば、ハードディスクドライブ1412および/またはリムーバブルストレージデバイスもしくはドライブ1414を含み得る。リムーバブルストレージドライブ1414は、フロッピーディスクドライブ、磁気テープドライブ、コンパクトディスクドライブ、光ストレージデバイス、テープバックアップデバイス、および/または任意の他のストレージデバイス/ドライブであり得る。
リムーバブルストレージドライブ1414は、リムーバブルストレージユニット1418と対話し得る。リムーバブルストレージユニット1418は、コンピュータソフトウェア(制御論理)および/またはデータが記憶されたコンピュータ使用可能または可読記憶デバイスを含む。リムーバブルストレージユニット1418は、フロッピーディスク、磁気テープ、コンパクトディスク、DVD、光ストレージディスク、および/任意の他のコンピュータデータ記憶デバイスであってもよい。リムーバブルストレージドライブ1414は、よく知られている方法でリムーバブルストレージユニット1418から読み取り、および/またはリムーバブルストレージユニット1418に書き込む。
例示的な実施形態によれば、2次メモリ1410は、コンピュータプログラムおよび/または他の命令および/またはデータがコンピュータシステム1400によってアクセスされることを可能にするための他の手段(means)、手段(instrumentalities)、または他の手法を含み得る。そのような手段(means)、手段(instrumentalities)、または他の手法は、たとえば、リムーバブルストレージユニット1422およびインターフェース1420を含み得る。リムーバブルストレージユニット1422およびインターフェース1420の例は、プログラムカートリッジおよびカートリッジインターフェース(ビデオゲームデバイスに見られるものなど)、リムーバブルメモリチップ(EPROMまたはPROMなど)および関連するソケット、メモリスティックおよびUSBポート、メモリカードおよび関連するメモリカードスロット、ならびに/または任意の他のリムーバブルストレージユニットおよび関連するインターフェースを含み得る。
コンピュータシステム1400は、通信またはネットワークインターフェース1424をさらに含み得る。通信インターフェース1424によって、コンピュータシステム1400は、リモートデバイス、リモートネットワーク、リモートエンティティなど(個々に、および集合的に参照番号1428によって参照される)の任意の組合せと通信し、対話することが可能になる。たとえば、通信インターフェース1424は、コンピュータシステム1400が、ワイヤードおよび/またはワイヤレスであり、LAN、WAN、インターネットなどの任意の組合せを含み得る通信経路1426を介してリモートデバイス1428と通信することを可能にし得る。コンピュータシステム1400との間で通信経路1426を介して制御論理および/またはデータが送信されてもよい。
一実施形態では、制御論理(ソフトウェア)が記憶された有形のコンピュータ使用可能または可読媒体を含む有形の装置または製造品は、本明細書ではコンピュータプログラム製品またはプログラム記憶デバイスとも呼ばれる。これは、限定はしないが、コンピュータシステム1400、メインメモリ1408、2次メモリ1410、リムーバブルストレージユニット1418および1422、ならびに上記の任意の組合せを組み込む有形の製造品を含む。そのような制御論理は、(コンピュータシステム1400など)1つまたは複数のデータ処理デバイスによって実行されると、そのようなデータ処理デバイスに、本明細書で記載されているように動作させる。
本開示に含まれる教示に基づいて、データ処理デバイス、コンピュータシステム、および/または図14に示したもの以外のコンピュータアーキテクチャを使用して、本発明の実施形態を作成および使用する方法が当業者には明らかであろう。特に、実施形態は、本明細書に記載されているもの以外のソフトウェア、ハードウェア、および/またはオペレーティングシステムの実装で動作することができる。
したがって、実施形態は、安全で自動的で正確な方法で、リアルタイムのクロスランドスケープデータベーステーブルレプリケーションを提供し得る。さらに、オンプレミスシステムの弾性スケーリングは、ハイブリッドクラウドリソースで補完され得る。加えて、複数のリモートシステムおよび/またはテーブル(異なるバイナリソフトウェアバージョンに関連付けられている可能性がある)から効率的なデータ仮想化が提供され得る。
以下は、本発明の様々な追加の実施形態を例示する。これらはすべての可能な実施形態の定義を構成するものではなく、当業者は、本発明が他の多くの実施形態に適用可能であることを理解するであろう。さらに、以下の実施形態は、明快のために簡単に記載されているが、当業者は、必要に応じて、これらおよび他の実施形態および用途に対応するために上記の装置および方法に任意の変更を加える方法を理解するであろう。
本明細書では特定のハードウェアおよびデータ構成について記載されているが、本発明のいくつかの実施形態に従って任意の数の他の構成を提供できることに留意されたい(たとえば、本明細書に記載したデータベースに関連付けられた情報の一部は、外部システムに結合または記憶され得る)。さらに、いくつかの実施形態は、特定のタイプのアプリケーションおよびサービスに焦点を当てているが、本明細書に記載された実施形態のいずれも、他のタイプのアプリケーションおよびサービスに適用され得る。加えて、本明細書に示されている表示は、例としてのみ提供されており、任意の他のタイプのユーザインターフェースを実装することができる。
本発明について、単に例示の目的でいくつかの実施形態に関して記載してきた。当業者は、この記載から、本発明が記載した実施形態に限定されず、添付の特許請求の範囲の趣旨および範囲によってのみ制限される修正および変更を伴って実施され得ることを認識するであろう。
100 分散データベースシステム
102 データベース管理システム
104 分散データベース
106 ソースノード
108 レプリカノード
202 書込みセット抽出器
204 レプリケーションログ生成器
206 ログ送信バッファ
208 ログ送信機
210 トランザクションマネージャ
212 レプリケーションログ受信機およびディスパッチャ
214 並列ログリプレーヤ
216 トランザクションログリプレーヤ
300 システム
310 オンプレミスサーバ
320 クラウドリソース
330 グラフ
400 RTRシステム
410 ERP
420 CRM
430 クラウド環境
500 リアルタイムテーブルレプリケーションアーキテクチャ
510 アプリケーションプロセス
520 プライマリ
530 リカバリログ
540 チェックポイント
522 レプリカサーバ
550 リカバリログ
560 チェックポイント
610 ソースクラウドシステム
620 レプリカクラウドシステム
630 ワークフロー
700 アーキテクチャ
710 ソースシステム
720 レプリカシステム
800 クロスデータベースATR
810 ソーステーブル更新
820 レプリカテーブルレプリケート
1000 データ定義言語ログのリプレイ
1020 DDLログハンドラ
1030 DMLログハンドラ
1110 ソーステーブル
1120 レプリカテーブル
1300 RTRディスプレイ
1310 グラフィカル要素
1320 「セットアップ」アイコン
1390 マウスポイント
1400 コンピュータシステム
1402 ユーザ入力/出力インターフェース
1403 ユーザ入力/出力デバイス
1404 プロセッサ
1406 バス
1408 メインメモリまたは1次メモリ
1410 2次記憶デバイスまたはメモリ
1412 ハードディスクドライブ
1414 リムーバブルストレージデバイスもしくはドライブ
1418 リムーバブルストレージユニット
1420 インターフェース
1422 リムーバブルストレージユニット
1424 通信またはネットワークインターフェース
1426 通信経路
1428 リモートエンティティ

Claims (20)

  1. レプリカテーブルへのデータベーストランザクションのリアルタイムテーブルレプリケーション(「RTR」)のためのシステムであって、
    コンピュータメモリと、
    少なくとも1つのコンピュータプロセッサとを含み、少なくとも1つのコンピュータプロセッサが、前記メモリに結合され、
    レプリケーションログエントリおよび関連付けられたトランザクションコミットログエントリを受信することであり、前記レプリケーションログエントリおよび前記関連付けられたトランザクションコミットログエントリが一緒に、レプリカテーブルの行にリプレイされるデータベーストランザクションを表し、前記レプリケーションログエントリが行ID値を有し、前記レプリカテーブルの前記行が行ID値を有する、受信することと、
    前記レプリケーションログエントリを並列ログリプレーヤにディスパッチし、前記関連付けられたトランザクションコミットログエントリをトランザクションログリプレーヤにディスパッチすることと、
    前記レプリケーションログエントリの前記行ID値を前記レプリカテーブルの前記行の前記行ID値と比較することと、
    前記比較に基づいて、前記並列ログリプレーヤで前記レプリケーションログエントリをリプレイすることと、
    前記トランザクションログリプレーヤで前記関連付けられたトランザクションコミットログエントリをリプレイすることによって、前記データベーストランザクションを前記レプリカテーブルにコミットすることであり、前記データベーストランザクションが、トランザクションの一貫性を有する行レベルの並列リプレイおよびデータ定義言語(「DDL」)のレプリケーションに関連付けられており、レプリカシステムでのDDLステートメントの再構築が、1つまたは複数のメタデータ更新ログエントリに関連付けられている、コミットすることと
    を行うように構成されている、
    システム。
  2. (i)テーブルのセット、(ii)テーブル、(iii)サブテーブル、(iv)1つまたは複数の列、および(v)1つまたは複数のパーティション、のうちの少なくとも1つを含む、複数のレプリケーションオブジェクトの粒度がサポートされている、請求項1に記載のシステム。
  3. 複数の個別のソースシステムからのトポロジを有するレプリケーションが、N対1のレプリケーションとしてサポートされている、請求項1に記載のシステム。
  4. 複数の個別のリモートレプリカシステムへのトポロジを有するレプリケーションが、1対Nのレプリケーションとしてサポートされている、請求項1に記載のシステム。
  5. レプリカテーブルが別のレプリカテーブルのソースであるトポロジを有するレプリケーションが、チェーンレプリケーションとしてサポートされている、請求項1に記載のシステム。
  6. インメモリログレプリケーションがストアアンドフォワード機構に依存しない、請求項1に記載のシステム。
  7. プッシュベースの早期ログ配布が、前記ソースシステムと前記レプリカシステムとの間の伝搬遅延を低減する、請求項3に記載のシステム。
  8. 前記ソースシステムと前記レプリカシステムとの間に別個のトランザクションドメインが存在する、請求項3に記載のシステム。
  9. 前記ソースシステムと前記レプリカシステムとの間に別個のメタデータドメインが存在する、請求項3に記載のシステム。
  10. 前記ソースシステムと前記レプリカシステムとの間に異なるソフトウェアバイナリバージョンが存在する、請求項3に記載のシステム。
  11. データベーストランザクションのレプリカテーブルへのリアルタイムテーブルレプリケーションのためのコンピュータ実装方法であって、
    少なくとも1つのプロセッサによって、レプリケーションログエントリおよび関連付けられたトランザクションコミットログエントリを受信するステップであり、前記レプリケーションログエントリおよび前記関連付けられたトランザクションコミットログエントリが一緒に、レプリカテーブルの行にリプレイされるデータベーストランザクションを表し、前記レプリケーションログエントリが行ID値を有し、前記レプリカテーブルの前記行が行ID値を有する、受信するステップと、
    前記少なくとも1つのプロセッサによって、前記レプリケーションログエントリを並列ログリプレーヤにディスパッチし、前記関連付けられたトランザクションコミットログエントリをトランザクションログリプレーヤにディスパッチするステップと、
    前記少なくとも1つのプロセッサによって、前記レプリケーションログエントリの前記行ID値を前記レプリカテーブルの前記行の前記行ID値と比較するステップと、
    前記少なくとも1つのプロセッサによって、前記比較に基づいて、前記並列ログリプレーヤで前記レプリケーションログエントリをリプレイするステップと、
    前記少なくとも1つのプロセッサによって、前記トランザクションログリプレーヤで前記関連付けられたトランザクションコミットログエントリをリプレイすることによって、前記データベーストランザクションを前記レプリカテーブルにコミットするステップであり、前記データベーストランザクションが、トランザクションの一貫性を有する行レベルの並列リプレイおよびデータ定義言語(「DDL」)のレプリケーションに関連付けられており、レプリカシステムでのDDLステートメントの再構築が、1つまたは複数のメタデータ更新ログエントリに関連付けられている、コミットするステップと
    を含む方法。
  12. (i)テーブルのセット、(ii)テーブル、(iii)サブテーブル、(iv)1つまたは複数の列、および(v)1つまたは複数のパーティション、のうちの少なくとも1つを含む、複数のレプリケーションオブジェクトの粒度がサポートされている、請求項11に記載の方法。
  13. 複数の個別のソースシステムからのトポロジを有するレプリケーションが、N対1のレプリケーションとしてサポートされている、請求項11に記載の方法。
  14. 複数の個別のリモートレプリカシステムへのトポロジを有するレプリケーションが、1対Nのレプリケーションとしてサポートされている、請求項11に記載の方法。
  15. レプリカテーブルが別のレプリカテーブルのソースであるトポロジを有するレプリケーションが、チェーンレプリケーションとしてサポートされている、請求項11に記載の方法。
  16. インメモリログレプリケーションがストアアンドフォワード機構に依存しない、請求項11に記載の方法。
  17. プッシュベースの早期ログ配布が、前記ソースシステムと前記レプリカシステムとの間の伝搬遅延を低減する、請求項13に記載の方法。
  18. 前記ソースシステムと前記レプリカシステムとの間に別個のトランザクションドメインが存在する、請求項13に記載の方法。
  19. 前記ソースシステムと前記レプリカシステムとの間に別個のメタデータドメインが存在する、請求項13に記載の方法。
  20. 前記ソースシステムと前記レプリカシステムとの間に異なるソフトウェアバイナリバージョンが存在する、請求項13に記載の方法。
JP2020154565A 2019-11-18 2020-09-15 ハイブリッドクラウド弾性スケーリングおよび高性能データ仮想化のためのリアルタイムクロスシステムデータベースレプリケーション Active JP7263297B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/686,827 2019-11-18
US16/686,827 US11263236B2 (en) 2019-11-18 2019-11-18 Real-time cross-system database replication for hybrid-cloud elastic scaling and high-performance data virtualization

Publications (2)

Publication Number Publication Date
JP2021082257A JP2021082257A (ja) 2021-05-27
JP7263297B2 true JP7263297B2 (ja) 2023-04-24

Family

ID=72432731

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020154565A Active JP7263297B2 (ja) 2019-11-18 2020-09-15 ハイブリッドクラウド弾性スケーリングおよび高性能データ仮想化のためのリアルタイムクロスシステムデータベースレプリケーション

Country Status (4)

Country Link
US (1) US11263236B2 (ja)
EP (1) EP3822811A1 (ja)
JP (1) JP7263297B2 (ja)
CN (1) CN112818053A (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7392476B2 (ja) * 2020-01-07 2023-12-06 富士フイルムビジネスイノベーション株式会社 情報処理装置、及びコンピュータプログラム
CN113868292A (zh) * 2020-06-30 2021-12-31 华为技术有限公司 一种读数据的方法、写数据的方法、设备和***
US11474989B2 (en) * 2020-09-09 2022-10-18 International Business Machines Corporation Online reorganization of database tables with concurrent updates
CN112559459B (zh) * 2020-12-15 2024-02-13 跬云(上海)信息科技有限公司 一种基于云计算的自适应存储分层***及方法
US11657032B2 (en) * 2021-07-30 2023-05-23 Thoughtspot, Inc. Compacted table data files validation
US20230119834A1 (en) * 2021-10-19 2023-04-20 Sap Se Multi-tenancy using shared databases
US11574002B1 (en) * 2022-04-04 2023-02-07 Mindtech Global Limited Image tracing system and method
US11899645B1 (en) * 2022-09-09 2024-02-13 Sap Se Two phase move of database tables
CN115509694B (zh) * 2022-10-08 2024-04-30 北京火山引擎科技有限公司 一种事务处理方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010218219A (ja) 2009-03-17 2010-09-30 Nec Corp レプリカ表生成装置、レプリカ表生成方法、及びプログラム
US20160147859A1 (en) 2014-11-25 2016-05-26 Juchang Lee Transactional and Parallel Log Replay for Asynchronous Table Replication
US20170177658A1 (en) 2015-12-18 2017-06-22 Sap Se Table replication in a database environment
US20190325055A1 (en) 2018-04-19 2019-10-24 Sap Se Parallel Replication Across Formats

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4497149T1 (de) * 1993-09-24 1996-10-17 Oracle Corp Verfahren und Vorrichtung zum Replizieren von Daten
US7177866B2 (en) * 2001-03-16 2007-02-13 Gravic, Inc. Asynchronous coordinated commit replication and dual write with replication transmission and locking of target database on updates only
US20050289186A1 (en) * 2004-06-29 2005-12-29 Microsoft Corporation DDL replication without user intervention
US8301593B2 (en) 2008-06-12 2012-10-30 Gravic, Inc. Mixed mode synchronous and asynchronous replication system
US9110757B2 (en) * 2013-01-14 2015-08-18 Vmware, Inc. Techniques for performing virtual machine software upgrades using virtual disk swapping
US10642779B2 (en) * 2018-03-26 2020-05-05 Microsoft Technology Licensing, Llc Group-based data replication in multi-tenant storage systems
CN108932282B (zh) * 2018-05-18 2023-04-18 腾讯科技（深圳）有限公司 一种数据库迁移方法、装置和存储介质
CN108920698B (zh) * 2018-07-16 2020-11-03 京东数字科技控股有限公司 一种数据同步方法、装置、***、介质及电子设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010218219A (ja) 2009-03-17 2010-09-30 Nec Corp レプリカ表生成装置、レプリカ表生成方法、及びプログラム
US20160147859A1 (en) 2014-11-25 2016-05-26 Juchang Lee Transactional and Parallel Log Replay for Asynchronous Table Replication
US20170177658A1 (en) 2015-12-18 2017-06-22 Sap Se Table replication in a database environment
US20190325055A1 (en) 2018-04-19 2019-10-24 Sap Se Parallel Replication Across Formats

Also Published As

Publication number Publication date
US20210149915A1 (en) 2021-05-20
CN112818053A (zh) 2021-05-18
JP2021082257A (ja) 2021-05-27
EP3822811A1 (en) 2021-05-19
US11263236B2 (en) 2022-03-01

Similar Documents

Publication Publication Date Title
JP7263297B2 (ja) ハイブリッドクラウド弾性スケーリングおよび高性能データ仮想化のためのリアルタイムクロスシステムデータベースレプリケーション
KR102307371B1 (ko) 데이터베이스 시스템 내의 데이터 복제 및 데이터 장애 조치
US11263235B2 (en) Database management system and method of operation
Bichsel et al. A simple algorithm for shape from shading
US9069704B2 (en) Database log replay parallelization
EP3330869B1 (en) Write access control in a database
WO2018157602A1 (zh) 一种同步活动事务表的方法及装置
US20140279871A1 (en) System and method for providing near real time data synchronization
US20140101102A1 (en) Batch processing and data synchronization in cloud-based systems
Waqas et al. Transaction management techniques and practices in current cloud computing environments: A survey
Yang From Google file system to omega: a decade of advancement in big data management at Google
US11461201B2 (en) Cloud architecture for replicated data services
US11709809B1 (en) Tree-based approach for transactionally consistent version sets
Kraft et al. {Data-Parallel} actors: A programming model for scalable query serving systems
US20230289368A1 (en) Asynchronous data replication in a multiple availability zone cloud platform
Okardi et al. Overview of distributed database system
Georgiou et al. Hihooi: A database replication middleware for scaling transactional databases consistently
Saxena et al. Concepts of HBase archetypes in big data engineering
US11789971B1 (en) Adding replicas to a multi-leader replica group for a data set
Kim et al. Dynamic partition lock method to reduce transaction abort rates of cloud database
Bharati et al. A comprehensive survey on distributed transactions based data partitioning
Dobos et al. A comparative evaluation of NoSQL database systems
Krogh et al. Pro MySQL NDB Cluster
Martinez Study of resource management for multitenant database systems in cloud computing
US11106698B2 (en) Multi-master with ownership transfer

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210908

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221006

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221205

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230302

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: 20230320

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230412

R150 Certificate of patent or registration of utility model

Ref document number: 7263297

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150