 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||
|
||||||||||||||
| HinemosでPostgresForestを採用した理由について | ||||||||||||||
|
Hinemosでは前述したとおり、PostgresForestを利用することで、可用性の向上を実現しています。それでは何故、他のクラスタリングミドルウェアを採用せずに、PostgresForestを採用したのでしょうか。理由としては以下の通りになります。
表2：PostgresForestを採用した理由 |
||||||||||||||
| Hinemosで利用するPostgresForestのテーブル形式 | ||||||||||||||
|
PostgresForestにおけるテーブルのクラスタリングでは大きく分けて、多重化テーブルとパーティション化テーブルという2種類の方式があります。Hinemosではこのうち、可用性を求める要件と、基となるデータベースのテーブル構成をそのまま利用できるという点からミラーリングを行う多重化テーブルを採用しています（Hinemosで利用していないパーティション化テーブルについての詳細についてはここでは割愛します）。 多重化テーブルは、同じ内容のデータベースを複数のノードに複製してもち、その内容の同期をとります。一部のノードが障害を発生しても、そのノードを切り離して縮退運転を行うことで、サービスダウンを避けることが可能です。また、多数の検索要求を各ノードに振り分けて行うことによって、負荷を分散することができます。  図2：多重化テーブル |
||||||||||||||
| Hinemos内部におけるJBossとPostgresForestの連携 | ||||||||||||||
|
クラスタ環境のHinemosでは、マシンレベルではなく、各コンポーネントのレベルでそれぞれ障害に対処していることは「第5回：JBossのクラスタリング機能を活用した可用性向上について」で説明したとおりです。これはデータベースについても同様で、以降より関連するJBossとの障害パターンについて説明します。 |
||||||||||||||
| マスタ側のJBossは正常で、片系のPostgreSQLが障害を起こしたとき | ||||||||||||||
|
これはPostgresForestの機能をそのまま利用した通常想定されるパターンです。PostgresForestは障害を起こしたノードを切り離し縮退運転に移行しますが、正常にサービス提供を続けます。PostgresForestからみてクライアントとなるJBossはデータベースの障害を意識することなく動作を続けます。  図3：マスタ側のJBossは正常で片系のPostgreSQLで障害発生時の動作イメージ （簡略化のため、JBossとPostgresForest以外のコンポーネントについては省略しています） |
||||||||||||||
| マスタのJBossが障害を起こしたとき | ||||||||||||||
|
第5回で説明したとおり、マスタのJBossが障害を起こすとスレーブ側のJBossに処理を引き継ぎます。この時にスレーブ側のPostgresForestのドライバが使用されます。 データベース的にはクライアントであるJBossの障害なので、マスタ側のJBossで行われていたトランザクションはロールバックされます。そのため、新たにスレーブ側で処理が行われても、データに矛盾が生じることはありません。  図4：マスタノードのJBossで障害発生時の動作イメージ （簡略化のため、JBossとPostgresForest以外のコンポーネントについては省略しています） なお、この状態で片系の PostgresForestが障害を起こすと、先と同様に障害を起こしたノードを切り離しますが、正常にサービス提供を続けます。 このように、障害が各コンポーネントで発生しても可能な限りサービス提供をし続けようと動作します。 |
||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
