読者です 読者をやめる 読者になる 読者になる

oranie's blog

旧:iをgに変えると・・・なんだっけ・・・

Cassandra nodetool repairの挙動について教えて貰ったのでまとめ


題名そのまま。repairの挙動をdatastaxのドキュメント読んでも良く分からない、ヽ(`Д´#)ノ ムキー!!となっている所をまたも@yukimさんに教えて貰いました。
なので忘れないようにメモです。

nodetool repairとは

nodetool --helpで出力されている使い方は以下の通り

repair [keyspace] [cfnames] - Repair one or more column family (use -pr to repair only the first range returned by the partitioner)
直訳すると一つ以上のcolumn familyを修復します。-prオプションを付けて実行するとパーティショナーの初めのレンジだけrepairを実行します

この直訳だけではなんのこっちゃですね。

repairを実行する目的

repairを実行する目的は大きく二つです。まず一つは
・レプリカ間のデータの整合性を合わせるために実施
もう一つは
gc_grace_secondsを過ぎて完全に削除されたはずのデータが復活するのを防ぐ
http://wiki.apache.org/cassandra/Operations_JP#A.2BMM4w.2FDDJlpxbszB4MG5b.2FlHm-

http://www.datastax.com/docs/1.1/references/nodetool#nodetool-repair
為に実行する必要があります。

では、実際にどのような挙動で上記の処理を行うのでしょうか。僕はソース読んでいる訳ではないので、以下はあくまでも概念レベルの感じです。

簡単な動き

まず以下の様なクラスタがあったとします。考えやすいように
simple strategy
replica factor 3
9台
とします。

この時に1号機でrepairとrepair -prを実施した場合の各ノード間の動きは以下の通りです。

ただのrepair


画像だけ見るとなんのこっちゃかですが、簡単に言うとレプリカファクター3なので、1号機はそのtokenの2node前までのデータをレプリカとして貰い、逆に2node後にまで自分のデータをレプリカとして配布します。その為、
8-9-1(オレンジの範囲)
9-1-2(青の範囲)
1-2-3(黒の範囲)
という3つのrepairする為のセッションを生成して、このレプリカ間でハッシュツリー(Merkle hash tree)を交換して、違いがあるトークン範囲の部分だけをデータ送受信します。

repair -prの場合

では-prの場合の挙動はと言うと以下の画像の様な形になります。

あくまでも1号機のtokenレンジだけがrepairの対象となり
1-2-3
の組み合わせのみでrepairを実行します。1号機が持つべき他ノードのレプリカ分は対象となりません。

実際いつ使うのさ

ではどんな時に-prを使い-prを付けないrepairを実施するかと言うと

  • pr付ける→定期repair等で連続して各nodeのrepairを実行して修復と削除の喪失を防ぐ同期を実施する時
  • pr付けない→故障したノードの置き換えの場合、故障している間に他のレプリカ間でデータの不整合が発生する可能性があるため、ノードの置き換え後に実施

という形でしょうか。

クラスタを拡張する時(nodeを単純に追加した時)は、既に同期されたすべてのレプリカ(簡単に言うと周辺ノードね)からデータを受信するだけなので、クラスタ拡張直後にrepairをしなくても、定期的に運用で行っている repair -prで同期すれば問題が無い。

という事を@yukimさんから教えて貰い、やっとなんとかrepairした時の挙動やどういう時にrepair -prで良いのか、というのを覚えました。
@yukimさん、いつもありがとうございますm(_ _)m