Skip to content

Instantly share code, notes, and snippets.

@kuenishi

kuenishi/Riak-1.3-RELEASENOTE.md

Last active December 14, 2015 01:59
Show Gist options
  • Save kuenishi/5010318 to your computer and use it in GitHub Desktop.
Save kuenishi/5010318 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
Riak-1.3-RELEASENOTE.md

Riak 1.3 Release note translation

Riak 1.3.0 リリースノート

Riakの新機能と主な改善点

アクティブ・ アンチエントロピー(Active Anti-Entropy)

Riak 1.3の新機能です。 Riakは今回アクティブ・アンチエントロピー(AAE) サブシステムを組み込みました。これはRiakクラスター全体に渡るデータの検証と修復を行うものです。 AAEシステムはデータの欠落、不一致を確認するために、データレプリカ間で定期的に情報を交換します。不良レプリカが見つかると、これを直すためにAAEはread repairを実行します。AAEは完全に自動化されており、多くのデータ消失シナリオ（ディスク故障、古いバックアップからのリストア、bit不良など）を防ぐ新たなレイヤーとなります。

AAEはハッシュツリー交換を使って実装されています。これによりデータレプリカ間で交換されるデータ量は、Riakに保存された全データではなく、不整合となっているデータに比例します。すべてのデータが同期されている場合(通常の状態)、素早く、かつ極めて低いオーバーヘッドで情報を交換します。このためAAEは、クラスタへほぼ影響を与えることなく、１分間に複数回の交換を行えます。

AAEのハッシュツリーは通常のRiak K/Vデータとは分離されたLevelDBインスタンスに永続化されます。まっさらなRiak1.3クラスタを初めて起動すると（もしくは以前のリリースからアップグレードすると）各パーティションデータを参照することでハッシュツリー情報を生成します。デフォルトでRiakは各ノードで１時間毎にひとつのハッシュツリーを生成します。パーティションデータの参照に一時間以上かかる場合、Riakは必要に応じて次のハッシュツリー生成を開始します。ただしデフォルトでは同時に生成するハッシュツリーは2つまでです。

一度ハッシュツリーが作られると、Riakへ送られるwriteに従って最新の状態に保たれます。しかしK/Vデータとハッシュツリー間の乖離を防ぐために、ツリーは定期的に期限が切れて無効となり、再生成されます。ツリーの再生成はbit不良のような見えにくいデータ破損も防ぎます。デフォルトでツリーは１週間で期限が切れて再生成されます。

今まで述べた内容（およびその他の項目）は app.config にて設定できます。AAEに関する設定項目は riak_kv セクションにあり、どのようなオプションが選択可能かについてのコメントがついています。

AAEの動作状況を知るのに、Riakは riak-admin aae-status コマンドを提供します。AAEのステータス出力は、エクスチェンジ、エントロピーツリー、そして修復した鍵の3項目に分かれます。

================================== Exchanges ==================================
Index                                              Last (ago)    All (ago)
-------------------------------------------------------------------------------
0                                                  3.8 min       4.1 min
91343852333181432387730302044767688728495783936    3.3 min       7.8 min
182687704666362864775460604089535377456991567872   2.8 min       8.3 min
274031556999544297163190906134303066185487351808   2.3 min       6.3 min
365375409332725729550921208179070754913983135744   1.8 min       5.5 min
<snip>

エクスチェンジの項目では、各K/Vパーティション間のAAEによる情報の交換についての情報を示しています。 Last の列は、パーティションとそのsiblingレプリカのどれかの間で、いつ最も新しい情報の交換が行われたかについて示しています。 All の列では、パーティションがすべてのsiblingレプリカとやり取りを終えてからどれだけ経っているかについて示しています。簡単にいえば、All の列はそれぞれのパーティションがどれだけ古くなっているかについての時間の上限を示しています。具体的には、パーティションの中のデータについて、そのデータのすべてのレプリカが無効になっていない限り、 All で示された値よりも古いデータでは失われたり不整合が起こっていたりすることはないということです。

================================ Entropy Trees ================================
Index                                              Built (ago)
-------------------------------------------------------------------------------
0                                                  22.1 min
91343852333181432387730302044767688728495783936    22.6 min
182687704666362864775460604089535377456991567872   22.3 min
274031556999544297163190906134303066185487351808   22.9 min
365375409332725729550921208179070754913983135744   22.3 min
<snip>

エントロピーツリーの項目では、パーティション毎に、いつハッシュツリーが作られたかを示しています。AAEの情報の交換に参加する前に、各パーティションにはハッシュツリーが作られなければなりません。前述の通り、これらのツリーは作成後（デフォルトでは）1週間で無効となり再作成されます。

================================ Keys Repaired ================================
Index                                                Last      Mean      Max
-------------------------------------------------------------------------------
0                                                     0         0         0
91343852333181432387730302044767688728495783936       87        21        87
182687704666362864775460604089535377456991567872      0         0         0
274031556999544297163190906134303066185487351808      0         0         0
365375409332725729550921208179070754913983135744      0         0         0
<snip>

修復した鍵の項目では、AEによって成された修復についての情報を示しています。これには最新の情報の交換で修復された鍵の数、またすべての情報の交換でなされた修復についての平均値と最大値が含まれています。

注: すべてのAAEの状態情報はメモリ中にあり、ノードの再起動でリセットされます。ツリーの作成情報のみが永続的に残ります。これはツリー自身が永続的だからです。

AAEに関する注意事項:

  1. ツリーは情報の交換が起こる前に作成されていなければなりません。ツリーはデフォルトでは1時間に1度作られるため、すべてのツリーが作られるまでには1.3について最初の起動またはアップグレードが起こってから 「ring_size / number_of_nodes 時間」かかります。そしてこの時間がAAEがすべてのデータを保護するまでにかかる時間となります。

  2. 一般にツリーの作成にはCPU一つを可能ならば100%使用しますが、Riakの性能には最小限の影響で済みます。BitcaskをK/Vデータに使う際、ツリーの作成中は list_keys, list_buckets, および Riak EEの fullsync 複製戦略にかかる遅延時間が増える可能性があります。一度ツリーができれば、1週間後にツリーが無効になり再作成されるまで、これらの問題は起こることはありません。

  3. データの不整合や損失のない正常なクラスタでも、AAEでは時々少量（1つか2つ）の鍵を修復することがあります。これはあるノードに対しての書き込みが発生している際に、AAEがその同じノードに同時に情報の交換をする際に起こります。例えば、ある書き込みがノードAに到達済みでノードBへ向かっている途中にAAEが実行されると、ノードAへの書き込みは見えてもノードBに対するものは見えないため、強制的に修復を行います。AAEは読み込み修復のための読み込みしか要求しませんから、この振る舞いは全く安全です。

  4. AAEはRiak K/Vの機能であり、Riak Searchのデータは保護しません。

MapReduce Sink バックプレッシャー

MapReduce には Riak Pipe によりステージ間バックプレッシャーが導入されました。Riak 1.3 より前は sink まではバックプレッシャーは適用されませんでした。PB/HTTP エンドポイントは pipe の出力レートをすべて捌けると仮定されていたためです。Riak 1.3 では、 sink までバックプレッシャーを拡張し、エンドポイントでも処理あふれがなくなりました。バックプレッシャーは sink バッファのソフト上限と、ワーカによる上限チェック間隔にてチューニング可能です。これらは Riak コンソールから application 環境変数を設定するか、app.config ファイルの riak_kv セクションで設定できます (以下、デフォルトを示します):

{riak_kv,
 ...
 %% Soft cap on the MapReduce sink's buffer,
 %% expressed as a positive integer number of messages
 %% (one message is used per MapReduce result)
 %% MapReduce sink バッファのソフト上限。
 %% メッセージ数を正整数で設定します。
 %% (MapReduce 結果ひとつがメッセージひとつに対応します)
 {mrc_sink_buffer, 1000},

 %% Period at which a MapReduce worker must check
 %% the sink's buffer cap, expressed as an integer
 %% number of messages to send before waiting on
 %% an clear-to-send acknowledgement
 %%   0 = wait for acknowledgement of each message
 %%   1 = wait every other message
 %%   'infinity' = never wait for acknowledgements
 %% MapReduce ワーカが sink のバッファ上限をチェックする間隔。
 %% 送信可能確認応答を待つまでのメッセージ数を整数で指定します。
 %%   0 = すべてのメッセージに対して確認応答をまちます
 %%   1 = メッセージひとつおきに確認応答を待ちます
 %%   ‘infinity’ = 確認応答を待ちません

 {mrc_sink_sync_period, 10}
}.

IPv6 サポート追加

Riak Handoff と Protocol Buffers インターフェイスは IPv6 アドレスで待受可能になりました(HTTP インターフェイスはすでに IPv6 をサポートしています)。アドレスの指定は "::1" (localhost を表します) のような文字列形式でも、{0,0,0,0,0,0,0,1} (同じく localhost を表します) のような 8-タプルによる 16 バイトアドレスの指定でも可能です。IPv4 アドレスもどちらの形式でも表せます(ただし後者の形式は 4-タプルで 4 バイトです)。 注意: Riak ノード名には適用されません。クラスタメンバー管理の IPv6 サポートについては、 inet_dist_* 設定を参照ください。 Erlang documentation

Luke 削除

Riak 1.2 リリースで廃止予定とされた luke application は、このリリースで取り除かれました。

riak getpid 追加

riak stop にバグ(修正されたバグ一覧に入っています)があり、修正の際に Riak 自身の PID 取得方法を変更しました。バグを修正しているとき、Riakで提供されていないスクリプトに頼りたくないシステム管理者にとっては、getpidはとても便利に思えたためです。 riak getpid ではその名の通り実行中の Riak の PID を返すようにしました。失敗時には終了コード 1 で終了します。これは小さな機能ですが ps や、 grep, awk を使う時間を節約してくれるでしょう。

Riaknositic のデフォルト同梱

Riaknostic が Riak パッケージに含まれるようになり、利用しやすくなりました。1.3 より前のバージョンでは、ユーザは riaknostic を別途ダウンロードする必要がありましたが、1.3 では riak-admin diag がすぐに使えます。

SmartOS 1.8 の追加サポート

SmartOS 1.6 に加え、1.8 向けのパッケージが利用できるようになりました。

ヘルスチェック

Riak 1.3 で新規導入されました。Riak Core はヘルスチェックサブシステムを含むようになり、ノードを特定の条件で監視し、その条件に依ってサービスを無効化あるいは有効化します。

ヘルスチェックを有効化するには app.config の riak_core セクションに新しい設定を追加してください:

%% Health Checks
%% If disabled, health checks registered by an application will
%% be ignored. NOTE: this option cannot be changed at runtime.
%% To re-enable, the setting must be changed and the node restarted.
%% ヘルスチェック
%% 無効の場合、application が追加したヘルスチェックは無視されます。
%% 注意: このオプションは実行中に変更できません。
%% 有効化するには設定を変えた後にノード再起動が必要です。
{enable_health_checks, true},

Riak は KV vnode のメッセージキュー長をモニターするヘルスチェックを登録します。kv ヘルスチェックを設定するには app.config の riak_kv セクションに新しい設定を追加します:

%% This option configures the riak_kv health check that monitors
%% message queue lengths of riak_kv vnodes. The value is a 2-tuple,
%% {EnableThreshold, DisableThreshold}. If a riak_kv_vnode's message
%% queue length reaches DisableThreshold the riak_kv service is disabled
%% on this node. The service will not be re-enabled until the message queue
%% length drops below EnableThreshold.
%% このオプションで riak_kv vnode のメッセージキュー長のヘルスチェックを
%% 設定します。値は 2-タプルで {有効化しきい値、無効化しきい値}です。
%%  riak_kv vnode のメッセージキュー長が無効化しきい値に達すると riak_kv 
%% サービスが無効化されます。有効化しきい値より下に値が下がるまでは
%% サービスは再度有効化されません。

{vnode_mailbox_limit, {1, 5000}}

注意: kv ヘルスチェックは Riak Search や Riak Pipe vnode には適用されません。

バケットプロパティのリセット

HTTP インターフェイスを通じて、バケットプロパティをデフォルト設定へリセット出来るようになりました。バケットプロパティは、クラスタ内のゴシッププロトコルにより、 Riak のリング構造体として保存されます。すでに使われていないバケットのプロパティのリセットや、デフォルト設定で使われているバケットのリセットによりゴシップで転送されるデータを削減できます。

syslog へのログ出力サポート

Riak 1.3 では syslog へのログ出力をサポートします。有効にするには riak の app.config で lager の下にある handlers セクションへ次のような設定を追加します:

{lager_syslog_backend, ["riak", daemon, info]}

この設定では、info レベル以上のすべてのメッセージを、 daemon ファシリティへ向けて、 ‘riak’ アイデンティティでログ出力します。さらなる情報は lager_syslog ドキュメントをご覧ください。

https://github.com/basho/lager_syslog

Installation Notes

インストールの注意点

RHEL/CentOS/Fedora ユーザは、RPM ツールが expect への依存を追加したため、次のようなメッセージが出た場合には:

$ sudo rpm -i riak-1.3.0rc1-1.el5.x86_64.rpm
error: Failed dependencies:
    /usr/bin/expect is needed by riak-1.3.0rc1-1.x86_64

Riak RPM を yum からインストールすることで依存性を自動解決できます:

$ sudo yum -y install riak-1.3.0rc1-1.el5.x86_64.rpm
Preparing...                ########################################### [100%]
   1:expect                 ########################################### [100%]
   2:riak                   ########################################### [100%]

解決された issues/ PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment