[D34] Shared Nothingなのに、Active-Activeクラスタ？～高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術～ by Akito Wakisaka

Shared Nothingなのに、Active-Activeクラスタ？
～高いスケーラビリティを誇る日立国産ＤＢＭＳ「ＨｉＲＤＢ」のクラスタ技術～
2013/11/15
株式会社日立製作所情報・通信システム社
ITプラットフォーム事業本部開発統括本部
ソフトウェア開発本部 DB設計部

脇坂彰人（わきざかあきと）
© Hitachi, Ltd. 2013. All rights reserved.

技術が支えるビジネスの価値創出
教育

行政

健康／医療
製造／流通
情報活用がリードする
金融
ビジネスと社会

ビッグデータ利活用
高信頼クラウド
Hadoop
Hitachi
Advanced
Data Binder※

水
交通
エネルギー

スマート情報
セキュリティ

ストリーム
データ処理

インメモリ
データグリッド

並列DBMS

※『内閣府の最先端研究開発支援プログラム「超巨大データベース
時代に向けた最高速データベースエンジンの開発と当該エンジン
を核とする戦略的社会サービスの実証・評価」（中心研究者：喜連
川東大教授／国立情報学研究所所長）の成果を利用』


1

Ｃｏｎｔｅｎｔｓ
１．ＨｉＲＤＢは、「ＳｈａｒｅｄＮｏｔｈｉｎｇ」
２．ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ？
３．Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタの実力は？


2

１．ＨｉＲＤＢは、「ＳｈａｒｅｄＮｏｔｈｉｎｇ」


3

ＳｈａｒｅｄＮｏｔｈｉｎｇは、データベースを分割し、
ＤＢサーバが重複なく割り当てられたデータを
独立に処理するアーキテクチャ
■Shared Nothing
並列処理
■Shared Disk
ＤＢサーバ
ＤＢサーバ

ストレージ

ストレージ
パーティション（分割）表

完全独立

4

ＳｈａｒｅｄＮｏｔｈｉｎｇアーキテクチャ
□ＤＢをアクセスするＢＥＳ(*２)が、分割されたデータを独立に処理する。
□ＦＥＳ(*１)がＳＱＬを振り分け、業務ＡＰにデータの所在を意識させない。
完全独立

業務ＡＰ

ＡＰサーバ

ＦＥＳ１

ＦＥＳ２
ＦＥＳｎ

ＤＢサーバ

ＢＥＳ１

業務ＡＰは、
データの所在を意識しない

・データの所在位置はＦＥＳで自動認識。
・ＢＥＳが受け持つデータを並列に処理。
・ＢＥＳの処理結果をＦＥＳが纏めて返却。

ＢＥＳｍ

ＢＥＳ２

排他プール
ＤＢバッファ

ＤＢアクセスに必要なリソー
スが独立し、競合が無い

ストレージ
ＦＥＳ

*1 : ＳＱＬ受付サーバ
(Front End Server)

ＢＥＳ

パーティション
（分割）表

*2 : ＤＢアクセスサーバ
(Back End Server)

更新ログ


5

２．ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、
Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ？


6

ＤＢサーバの障害に備えるために
欠かせないクラスタ構成
切り換え

障害
ＤＢサーバ

ストレージ

ＳｈａｒｅｄＮｏｔｈｉｎｇで
構築するクラスタ構成は？

7

稼動中サーバごとに待機サーバを用意する
Ａｃｔｉｖｅ-Ｓｔａｎｂｙでのクラスタ構成
投資リソースを活用したい

障害
ＤＢサーバ
クラウド、従量課金

ストレージ


8

Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタは
どうなの？


9

障害サーバの処理を稼動中サーバで引き継ぐ
Ａｃｔｉｖｅ-Ａｃｔｉｖｅでもクラスタ構成
□障害サーバが担当していたデータを，他の稼働中サーバが分担する
■Shared Nothing
障害サーバに割り当てられて
いたデータの処理を引き継ぐ

投資リソースの
有効活用

■Shared Disk
障害

縮退

ＤＢサーバ

障害
ストレージ

ＤＢサーバ

ストレージ


10

ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、
□ 完全独立しているのに、障害サーバの処理をどう引き継ぐの？
□ 複数サーバの障害に対応はどうやるの？
障害
ＤＢサーバ

ストレージ


11

Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ構成
□ＢＥＳ単位で、稼動中サーバに切り替えて業務を継続。
□あらかじめ複数のＢＥＳを配置し、複数の稼働中サーバに負荷を
分散できる。
通常運用時

障害発生時

ＤＢサーバ１

ＤＢサーバ２

ＤＢサーバ３

ＢＥＳ１

ＢＥＳ３

ＢＥＳ５

ＢＥＳ１

ＢＥＳ３

ＢＥＳ５

ＢＥＳ２

ＢＥＳ４

ＢＥＳ６

ＢＥＳ２

ＢＥＳ４

ＢＥＳ６

ＢＥＳ１

ＢＥＳ２

ＤＢサーバ１

障害

ＤＢサーバ２

ＤＢサーバ３

ＤＢ及びシステムログ
引継ぎ＆継続使用
ＢＥＳ単位で
切り替え(移動)
⇒分散引継ぎ

ＤＢサーバ２、ＤＢサーバ３で
処理を分散して引き継ぐ。
サーバ間の負荷は平準化。

12

２台目もダウンしたら？
通常運用時

障害発生時

ＤＢサーバ１

ＤＢサーバ２

ＤＢサーバ３

ＢＥＳ１

ＢＥＳ３

ＢＥＳ５

ＢＥＳ１

ＢＥＳ３

ＢＥＳ５

ＢＥＳ２

ＢＥＳ４

ＢＥＳ６

ＢＥＳ２

ＢＥＳ４

ＢＥＳ６

ＢＥＳ１

ＢＥＳ２

ＤＢサーバ１

障害

ＤＢサーバ２

ＤＢサーバ３


13

複数サーバでの障害発生にも対応
□多点障害でも、第２、第３の稼動中のＤＢサーバに処理を
引き継げる。
１台目の障害発生時

さらに２台目の障害発生時

ＤＢサーバ１

ＤＢサーバ２

ＤＢサーバ３

ＢＥＳ１

ＢＥＳ３

ＢＥＳ５

ＢＥＳ３

ＢＥＳ５

ＢＥＳ２

ＢＥＳ４

ＢＥＳ６

ＢＥＳ４

ＢＥＳ６

ＢＥＳ１

ＢＥＳ２

ＢＥＳ１

ＢＥＳ２

障害

ＤＢサーバ１

ＤＢサーバ２

ＤＢサーバ３

ＢＥＳ３
ＢＥＳ４
ＢＥＳ１

ＤＢサーバ２の障害発生時は、
ＤＢサーバ３で処理を引き継ぐ。


14

Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ構成を実現するからくり
ＦＥＳ１

ＦＥＳ２

ＢＥＳ１
ＢＥＳ１
ＢＥＳ１

ＦＥＳ３

ＢＥＳ３
ＢＥＳ３
ＢＥＳ３

ＢＥＳ２
ＢＥＳ２
ＢＥＳ２
ＤＢバッファ
１関東

ＢＥＳ５
ＢＥＳ５
ＢＥＳ５

ＢＥＳ４
ＢＥＳ４
ＢＥＳ４
ＤＢバッファ

２東日本

ＢＥＳ６
ＢＥＳ６
ＢＥＳ６
ＤＢバッファ

３関西

４西日本

５中部

６海外

DBAREA1

DBAREA2

DBAREA3

DBAREA4

DBAREA5

DBAREA6

１関東

２東日本

３関西

４西日本

５中部

６海外


15

障害が発生したら？
ＦＥＳ１

ＦＥＳ２

障害ＢＥＳ１

ＦＥＳ３

ＢＥＳ３
ＢＥＳ３
ＢＥＳ３

ＢＥＳ１
ＢＥＳ１
ＢＥＳ２
ＢＥＳ２
ＢＥＳ２
ＤＢバッファ
１関東

ＢＥＳ５
ＢＥＳ５
ＢＥＳ５

ＢＥＳ４
ＢＥＳ４
ＢＥＳ４
ＤＢバッファ

２東日本

ＢＥＳ６
ＢＥＳ６
ＢＥＳ６
ＤＢバッファ

３関西

４西日本

５中部

６海外

DBAREA1

DBAREA2

DBAREA3

DBAREA4

DBAREA5

DBAREA6

１関東

２東日本

３関西

４西日本

５中部

６海外


16

稼動中サーバのリソースを有効活用
切り替え完了まで
キューイング
ＦＥＳ１

ＦＥＳ２

ＦＥＳ３

□自動でアクセス先を切り替え

□不足したプロセスは追加起動
待機中プロセスが
担当データを
成り変わって処理

障害ＢＥＳ１

ＢＥＳ３
ＢＥＳ３
ＢＥＳ１

ＢＥＳ１
ＢＥＳ１
ＢＥＳ２
ＢＥＳ２
ＢＥＳ２
ＤＢバッファ
１関東

ＢＥＳ５
ＢＥＳ５
ＢＥＳ２

ＢＥＳ４
ＢＥＳ４
ＢＥＳ１
ＤＢバッファ

２東日本

３関西

ＢＥＳ６
ＢＥＳ６
ＢＥＳ２
ＤＢバッファ

４西日本

１関東

５中部

６海外

２東日本

DBAREA1

DBAREA2

DBAREA3

DBAREA4

１関東

２東日本

３関西

４西日本

ＤＢバッファなどの
DBAREA5
DBAREA6
リソースを共有
５中部

６海外

□ＤＢバッファの占有もできます

17

Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタの切り替え先制御
□日立のクラスタソフトウェアＨＡモニタ※と連携して、
Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタを開発しました
□切り替え可能なサーバの情報を連携し、担当データの切り替え先を
制御
ＤＢサーバ１

障害

ＤＢサーバ２

ＤＢサーバ３

ＢＥＳ３

ＢＥＳ５

ＢＥＳ２

ＢＥＳ４

ＢＥＳ６

ＢＥＳ＊

ＢＥＳ１

ＢＥＳ２

ＢＥＳ＊

ＢＥＳ＊

ＢＥＳ＊

ＢＥＳ＊

ＢＥＳ＊

ＢＥＳ＊

ＢＥＳ＊

ＢＥＳ＊

ＢＥＳ＊

ＨＡモニタ

どのサーバの
受け入れも可能

ＢＥＳ１

ＨＡモニタ

ＢＥＳ3の
切り替えを指示

ＨＡモニタ

※Microsoft Failover ClusterやHP Serviceguardなどと組みあわせるには、HA Toolkit Extensionを使います。

18

３．Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタの実力は？


19

切り替え時間ってどれくらい？


20

数秒です！
デモでご体感ください。


21

Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタデモンストレーション
□ 数秒オーダでの切り替え
□ 多重障害への対応
稼働中サーバに負荷分散し、
安定した業務継続
切り替え中でも新規
トランザクションを受付可能

障害
DBサーバ1 DBサーバ2 DBサーバ3

数秒オーダで
切り替え

3台で稼動
2台で稼動
全面ダウン
期間ゼロ

DBサーバ CPU利用率

DBサーバ全体スループット

22

デモンストレーションで
数秒オーダの切り替えの様子を
ご覧ください。


23

数秒での切り替えのからくり
□『検知・引継ぎ・回復』の３つのポイントの高速化で、
数秒オーダでの切り替えを実現。

切替元（ａ）素早く検知切替先

（ｂ）素早く引継ぎ

障害
ＨｉＲＤＢ

ＨＡ
モニタ

ＨＡ
モニタ

Ａｌｉｖｅ監視

ＨｉＲＤＢ

（ｃ）素早く回復

フェイルオーバ時間

※1

Active-Active

HiRDB Version 7

ＨＡＢｏｏｓｔｅｒＰａｃｋ


▼障害検知

ＤＢ

▼リソース切り替え

ログ

数秒オーダ
時間
▼トランザクション決着
▼ＤＢ回復
▼回復準備

※2

※1：障害発生～新規トランザクション受付開始までの時間。
※2：トランザクション決着時間はシステムログ量に依存。

※ ＨＡモニタ、ＨＡＢｏｏｓｔｅｒＰａｃｋ：クラスタウェア

24

（ａ）素早く障害を検知する
□マシンダウン
□ＯＳパニック
□ＨｉＲＤＢダウン

クラスタウェア間でのＡｌｉｖｅ監視による検知
ＨＡＢｏｏｓｔｅｒＰａｃｋでの通知による瞬時検知
ＨｉＲＤＢ自らの申告によるゼロ秒検知
切替元

マシンダウン

切替先
監視

ＨｉＲＤＢ

ＨｉＲＤＢ障害
ＨｉＲＤＢスローダウン

ＯＳパニック

ＨＡ
モニタ

申告

Ａｌｉｖｅ監視

ＨＡ
モニタ

ＨｉＲＤＢ

監視

Time
Stamp



通知

・切替元のマシンダウンを、
切替先からのハートビートで検知。
・切替先から切替元のマシンをリセット。

ＤＢ

ＨｉＲＤＢのスローダウンを、生存監視
機能（Time Stampの定期更新/定期参照）に
より、ＨＡモニタが検知。
ログ

25

（ｂ）素早くリソースを引き継ぐ
□共有ディスクの数に依存しない、短時間でのディスク引継ぎ：
①ＨＡＢｏｏｓｔｅｒＰａｃｋがＨｉＲＤＢのＩ/Oに介在し、
切替元からのアクセスのみを許可。
②障害発生時、アクセス制御の変更のみで引継ぎを実現。
切替元

切替先
ＨＡ
モニタ

ＨＡ
モニタ
ＨｉＲＤＢ

ＨｉＲＤＢ



・・・

・・・

①I/O介在での
アクセス制御
常時オンライン
（活性）状態

ＤＢ
ＤＢログ
ＤＢログ
ＤＢログ
ログ


26

（ｂ）素早くリソースを引き継ぐ
□共有ディスクの数に依存しない、短時間でのディスク引継ぎ：
①ＨＡＢｏｏｓｔｅｒＰａｃｋがＨｉＲＤＢのＩ/Oに介在し、
切替元からのアクセスのみを許可。
②障害発生時、アクセス制御の変更のみで引継ぎを実現。
切替元

切替先
ＨＡ
モニタ

ＨＡ
モニタ
HA Booster Packあり

HA Booster Packなし

ＨｉＲＤＢ

ディスク

・・・

切
替
時
間

アクセス
許可

切替先
ディスク

アクセス
拒否

共有ディスク数

切替元
活性化

活性化

切
替
時
間

非活性化

シ
ー
ケ
ン
シ
ャ
ル
処
理

ＨｉＲＤＢ

一
括
処
理

・・・

②アクセス制御
の変更（引継ぎ）

ＤＢ
ＤＢログ
ＤＢログ
ＤＢログ

共有ディスク数

ログ


27

（ｃ）素早くＨｉＲＤＢを回復させる
□高速ＤＢ回復＆稼動中のリソースの利用で早期サービス再開
- 高速ＤＢ回復
①ディスク毎の並列ＤＢ回復
②新規トランザクションの早期受付開始
- 稼動中のリソースの利用 ③ＤＢ処理プロセスの成り代わり

□Ａｃｔｉｖｅ-ＡｃｔｉｖｅクラスタではＤＢ回復を稼動中サーバに分散して実施
ＢＥＳ３
ＢＥＳ４
切替指示

ＢＥＳ１
回復準備

②新規トランザクションの
早期受付開始
ＢＥＳ４

ＨＡモニタ

①ディスク毎の
ＨｉＲＤＢ並列ＤＢ回復
ＢＥＳ３

切替先

稼働中

ＢＥＳ１

ＤＢ回復

稼動中HiRDBへの

ＤＢ回復
（ディスク１）

③ＤＢ処理プロセスの
成り代わり

ＤＢ回復
（ディスク２）

時間

切替指示

ＢＥＳ６

ＨｉＲＤＢ
ＢＥＳ５
ＢＥＳ６
ＢＥＳ２
回復準備

稼働中
ＤＢ回復

ＢＥＳ２

ＨＡモニタ

ＢＥＳ５

切り替え

ＤＢ回復
（ディスク３）
ＤＢ回復
（ディスク４）

時間


ＤＢ回復

トランザクションの
決着

回復トランザクション
新規トランザクション
稼働中のトランザクション

28

システムのＳＬＡを維持する
□切り換えタイミングで割り当てCPUを活性化し、ＳＬＡを維持する
障害サーバの担当データの処理性能を
確保するためにＣＰＵを活性化
CPU

CPU
CPU
ＤＢサーバ１

CPU

CPU

CPU
ＤＢサーバ２

CPU

ＤＢサーバ３

ＢＥＳ１

ＢＥＳ３

ＢＥＳ５

ＢＥＳ２

ＢＥＳ４

ＢＥＳ６

ＢＥＳ１

CPU

ＢＥＳ２

障害


29

ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、
□通常運用時、各ＤＢサーバが担当データを独立に処理。
□障害発生時、障害サーバの担当データを稼動中のサーバが引き継ぐ。
□独立しているのに、オンデマンドにシェアするＡｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ。
通常運用時

障害発生時

ＤＢサーバ１

ＤＢサーバ２

ＤＢサーバ３

ＢＥＳ１

ＢＥＳ３

ＢＥＳ５

ＢＥＳ１

ＢＥＳ３

ＢＥＳ５

ＢＥＳ２

ＢＥＳ４

ＢＥＳ６

ＢＥＳ２

ＢＥＳ４

ＢＥＳ６

ＢＥＳ１

ＢＥＳ２

ＤＢサーバ１

障害

ＤＢサーバ２

ＤＢサーバ３


30

いかがでしたでしょうか？
『ＳｈａｒｅｄＮｏｔｈｉｎｇなのに、Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタ？』
ＳｈａｒｅｄＮｏｔｈｉｎｇアーキテクチャでの
Ａｃｔｉｖｅ-Ａｃｔｉｖｅクラスタのからくりを
ご紹介しました。


31

これからも
Made in Japan DBMS,
極めていきます。

を

今後も、日立のデータベースに
ご期待ください。
HiRDB:Highly Scalable Relational DataBase

32

END
Shared Nothingなのに、Active-Activeクラスタ？
～高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術～

2013/11/15
株式会社日立製作所情報・通信システム社
ITプラットフォーム事業本部開発統括本部
ソフトウェア開発本部 DB設計部

脇坂彰人


33

他社所有名称等に関する表示
・
・
・
・
・

製品の内容・仕様は、改良のために予告なしに変更する場合があります。
Hadoop は，Apache Software Foundationの商標です。
Microsoftは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
HP Serviceguardは，Hewlett-Packard Development Company, L.P.の商品名称です。
本資料に記載の会社名，製品名は，それぞれの会社の商標もしくは登録商標です。


34

付録


日付と支店番号でＤＢを分割した例
□月単位に支店グループを２次元分割
□独立したＢＥＳで並列に処理
関東
集計業務

関西
集計業務

その他
集計業務

ＢＥＳ１

ＢＥＳ２

ＢＥＳ３

空間軸での
分割

支店売上管理表
第１次元
分割列

第２次元
分割列

＜関東地区＞＜関西地区＞＜その他地区＞
支店番号
～1999

支店番号
2000～2999

2011-07-30 関東東京 1001

DBAREA1

DBAREA2

DBAREA3

2011-07-30 関西大阪 2001

関東07

関西07

他07

・
・
2011-08-30 関東横浜 1010

DBAREA4

DBAREA5

DBAREA6

2011-08-30 東北仙台 4001

関東08

関西08

他08

・
・
2011-09-30 関東東京 1001

DBAREA7

DBAREA8

DBAREA9

2011-09-30 関西神戸 2015

関東09

関西09

他09

時間軸での
分割

支店番号
3000～

日付

地区支店

支店番号

売上・・・

＜７月＞

2011-07-30 九州福岡 3010

＜８月＞

2011-08-30 関西京都 2008

一定期間保管
＜９月＞

・
・


38

ＤＢ格納領域の簡単なローテーション運用
□ＤＢの格納領域を、月次で簡単に再利用。
■従来の運用

ＤＢ格納領域の
削除・追加が大変

＜７月＞
＜１０月＞

ローテーション運用を容易にす
る『月別ハッシュ分割』の利用

関東10

DBAREA1

＜９月＞

月別
ハッシュ
分割

関西07

他07

DBAREA4

DBAREA5

DBAREA6

関東08

関西08

他08

DBAREA7

DBAREA8

DBAREA9

関東09

＜８月＞

DBAREA3

関東07

＜７月＞

DBAREA2

関西09

他09

＜７月＞⇒＜１０月＞

＜８月＞

＜９月＞

＜１０月＞
支店番号
～1999

支店番号
2000～2999

支店番号
3000～


39

今や、ストレージ仮想化技術で対処できる時代
□ＤＢ格納領域の見積もり、運用がどれだけ必要？大変？
■従来の運用

■ストレージ機能と連携した
シン・プロビジョニングでの運用
DBAREA1

支店番号
～1999

支店番号
2000～2999

支店番号
3000～

DBAREA1

DBAREA2
予備

DBAREA3

DBAREA3

予備

DBAREA2

最大

オンデマンド
仮想Voｌ(ディスク)

ディスク追加

見積もり、設計が大変
・データ増加を予測した見積もり設計。
・それに伴う拡張・運用設計の立案。
・ＤＢエリアのパンク回避のための余裕値設計。

監視、運用が大変
・個々のＤＢエリアの監視。
・ディスク追加によるＤＢエリア拡張。

ストレージ
プール

ＨＤＤ

・仮想ディスクに最大サイズでＤＢ
エリアを確保でき、ＤＢ容量設計
が容易。
・ＤＢエリアの自動拡張に伴い、
オンデマンドでストレージを割り
当てられる。
・ストレージプール全体で枯渇
監視でき、監視、拡張運用が容易。

ストレージプールを活用した
資源共有により負担を軽減

40

マスタ表の効率的な共有アクセス
□マスタ系データの配置は？
関東
集計業務

関西
集計業務

その他
集計業務

ＦＥＳ１

ＦＥＳ２

ＦＥＳ３

ＡＰサーバ

ＢＥＳ１

ＤＢサーバ
ＤＢバッファ

マスタ

関東

ＢＥＳ２
ＤＢバッファ

マスタ

関西

商品マスタ

・全ＢＥＳから参照できる表属性。
・各ＢＥＳのバッファで独立して参照できる。
・複数のＢＥＳから参照する場合でも、
ＢＥＳ間での通信はおこなわない。

ＢＥＳ３
ＤＢバッファ

マスタ

その他

特定ＢＥＳへのアクセス
集中を回避できる

DBAREA10

ストレージ

全ＢＥＳから参照できる
『共用表』属性を利用

共用表属性

DBAREA1

DBAREA2

DBAREA3

関東

関西

他


41

じゃあ、「共用表」を更新したら、どうする？
□更新要求をＦＥＳが受け、全ＢＥＳに配布。バッファを更新。
□受け持ちＢＥＳだけがストレージ上のデータを更新。
関東
集計業務

関西
集計業務

その他
集計業務

ＦＥＳ１

ＦＥＳ２

ＦＥＳ３

ＢＥＳ１

更新

ＢＥＳ２

ＢＥＳ３

ＡＰサーバ
受け持ちＢＥＳ

ＤＢサーバ
ＤＢバッファ

マスタ

関東

ＤＢバッファ

マスタ

関西

ＤＢバッファ
その他

DBAREA10

ストレージ

商品マスタ

共用表属性

DBAREA1

DBAREA2

DBAREA3

関東

関西

マスタ

ＤＢサーバの独立性を
確保する
・共用表の更新要求を全ＢＥＳに配布。
・バッファヒットしない場合はストレージから
読み込んでバッファを更新。
・受け持ちＢＥＳだけがストレージ上の
データを更新。
・更新ログは全ＢＥＳで出力。

他


42

[D34] Shared Nothingなのに、Active-Activeクラスタ？～高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術～ by Akito Wakisaka

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [D34] Shared Nothingなのに、Active-Activeクラスタ？～高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術～ by Akito Wakisaka

Ähnlich wie [D34] Shared Nothingなのに、Active-Activeクラスタ？～高いスケーラビリティを誇る日立国産DBMS「HiRDB」のクラスタ技術～ by Akito Wakisaka (20)

Mehr von Insight Technology, Inc.

Mehr von Insight Technology, Inc. (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)