Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/riywo/captheorem

Last synced: 28 days ago
JSON representation

Host: GitHub
URL: https://github.com/riywo/captheorem
Owner: riywo
Created: 2012-07-28T05:09:53.000Z (over 12 years ago)
Default Branch: master
Last Pushed: 2012-07-28T05:34:14.000Z (over 12 years ago)
Last Synced: 2024-10-21T20:05:34.019Z (3 months ago)
Size: 98.6 KB
Stars: 5
Watchers: 4
Forks: 2
Open Issues: 0
Metadata Files:
- Readme: README.md

Awesome Lists containing this project

README

クライントも繋がらないノード障害
クライアントは繋がるノード間障害

MySQLのslave(master-slave&sharding)
C型。故障検知してサービスアウトして他のslaveに任せるロジックがあれば短時間で復旧できる。
レプリ遅延やレプリが切れた場合：A型。レプリを何とかして追いつかせることでCを復旧させる。

MySQLのmaster(master-slave&sharding)
C型。但し故障検知してフェールオーバーさせるロジックがあれば短時間で復旧できる。
(ちょっと違うけど)複数masterへのcommit時に片方のみ失敗：A型。完全な一貫性保持は難しい。

MySQL Cluster
TODO
TODO

memcached
データロスト。オリジンが別にあれば故障ノードを外して再度キャッシュさせることでC型っぽい挙動。
ノード間通信が存在しないので起こり得ない

Cassandra
A型。どれかのノードに到達できればレプリカの存在する複数ノードを使って読み書きできる。一貫性は後で復旧させればよいという発想だが、実際は結構大変らしい。
A型。上と同じ感じ。一貫性の強度をquorumにするといくつかのレプリカノードから情報を確認して不整合あればそこで復旧させたりもできる。

HBaseのRegionServer
C型。データ自体はHDFSでレプリカがあるのでマスターノードが新しいRSの割り当てを行ったら復旧する。
C型。クラスタ分断の場合は、少数の側が自殺することでCを保つらしい。死んだ後は多分上と同じ。

HBaseのMasterServer
A型。RSの調停ができなくなるだけなので、早めに復旧できればいいっぽい。スタンバイへのバックアップとかは不明。
A型。左と同じ。

MongoDBのprimary(ReplicaSet)
C型だけどほぼAもカバー。primary障害の場合、どれかが昇格。クライアント側はどれかにつながりさえすれば今のprimaryを知ることができる。
primaryと他のreplicaが通信できなくなった場合：多分primary障害と判断されて左と同じ？

ZooKeeper
A型だけどほぼCもカバー。読み込みはどのノードでも可能だが、結果整合性。primaryの場合failoverの間は書けない(多分)。
A型？分断した場合どうなるの？