(注)前半は完全に無駄な迷走の記録です。結論は最後に書いてあるので、せっかちな人はもうそっちを読んでください。 HBaseと連携するZooKeeperのネタ。ZooKeeperのdataDirにはバイナリのログとスナップショットが保管されるが、ほったらかしにしていると、いつのまにかすごいことになる。古いファイルの削除等のメンテナンスは、ユーザー側で行う必要がある。 $ ls -lh /var/lib/zookeeper/version-2 -rw-r–r– 1 zookeeper zookeeper 65M Jan 15 00:08 log.1 -rw-r–r– 1 zookeeper zookeeper 65M Feb 17 10:51 log.13b -rw-r–r– 1 zookeeper zookeeper 65M Feb 17 15:29 log.19f : : -rw-r–r–
CassandraはCASやロックをサポートしていないため、複数のプロセス(またはノード) から参照して更新されるような一貫性のある共有変数が作れません。 例えばカウンターがその例です。RDBMSであればフィールドをauto incrementにしておけば 複数プロセスからinsertされても常に一意の値が得られます。 Cassandraを使用するアプリケーションでカウンターが必要になったら、そのためだけに 別途MySQL等を使う手もありますが、それではせっかく単一障害点のないCassandraを使って いても、アプリケーションからするとMySQLのカウンターが単一障害点になってしまいます。 そこで、複数ノードで一貫性と可用性を確保する共有変数領域としてZooKeeperを使ってみます。 ZooKeeperはそれ自体が何かを実行してくれるアプリケーションではなく、分散アプリケーション を構
ZooKeeperは分散アプリケーションにおけるサーバ間協調動作をコントロールしてくれるサービス、と言われてもよく分かっていなかったのが事実。HBaseに関連してちょっとかじってはいたが、「あ、そういうことだったの」と今さら知ったことなどもあるので、改めて書いておく。そして今回もほぼHadoop Hacks内の記述引用です。何度も図書館から借りてばかりいないで、いい加減買ったらどうなんだ、というひとりツッコミの声も聞こえなくはないが…。 ZooKeeper Hacks章の執筆は、飯田慎司氏、向井育正氏です。 (Hadoop Hacks以外のところからも若干追記しました) ちなみに記事内の「ZooKeeperアンサンブル」とは、サービスを提供する複数のZooKeeper(以下ZK)サーバの固まりを表す。通常3台、5台など奇数台用意する。これはプロセスの判定において、アンサンブル構成のうち過半
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く