ヒント
ヒントは、書き込み操作中に適用されるデータ修復技術です。レプリカノードが、障害またはより一般的な定期保守のためにミューテーションを受け入れることができない場合、それらのレプリカへの書き込みを試みるコーディネーターは、後で利用できないレプリカに適用するために、ローカルファイルシステムに一時的なヒントを保存します。ヒントは、データの一貫性のない期間を短縮するのに役立つ重要な方法です。コーディネーターは、利用できないレプリカノードがリングに戻った後、すぐにヒントを再生します。ただし、ヒントは最善の努力であり、アンチエントロピ修復のような最終的な一貫性を保証するものではありません。
ヒントは、Apache Cassandra がフォールトトレランス、高可用性、耐久性を提供するためにデータをレプリケートする方法のために役立ちます。Cassandra は、クラスタ全体にデータを分割し、その後、ハッシュリングに沿って複数のノードにキーをレプリケートします。可用性を保証するために、キーのすべてのレプリカはコンセンサスなしでミューテーションを受け入れることができますが、これは一部のレプリカがミューテーションを受け入れる一方で、他のレプリカが受け入れない可能性があることを意味します。このような場合、不整合が発生します。
ヒントは、リード修復と完全/増分アンチエントロピ修復に加えて、Cassandra がすべての更新が最終的にすべてのレプリカによって受信されるという最終的な一貫性保証を実装する 3 つの方法の 1 つです。ヒントは、リード修復と同様に、最善の努力であり、完全な修復を実行する代替手段ではありませんが、実際にはレプリカ間の不整合の期間を短縮するのに役立ちます。
ヒントハンドオフ
ヒントハンドオフとは、Cassandra が利用できないノードにヒントを適用するプロセスです。
たとえば、レプリケーション係数が 3 のキー空間に対して、一貫性レベルが LOCAL_QUORUM のミューテーションを行うことを検討してください。通常、クライアントはミューテーションを単一のコーディネーターに送信し、コーディネーターは 3 つのレプリカすべてにミューテーションを送信し、3 つのレプリカのうち 2 つがミューテーションを確認すると、コーディネーターはクライアントに正常にレスポンスします。ただし、レプリカノードが利用できない場合、コーディネーターは後で適用するためにローカルファイルシステムにヒントを保存します。新しいヒントは、最大 `max_hint_windowin_ms` のダウンタイム（デフォルトは 3 時間）まで保持されます。ウィンドウが期限切れになる前に利用できないレプリカがクラスタに戻ってきた場合、コーディネーターは保留中のヒント付きミューテーションをレプリカに適用して、最終的な一貫性が維持されるようにします。
-
(`t0`): クライアントによって書き込みが送信され、コーディネーターがそれを 3 つのレプリカに送信します。残念ながら、`replica_2` が再起動中で、ミューテーションを受信できません。
-
(`t1`): クライアントはコーディネーターからクォーラム確認を受け取ります。この時点で、クライアントは書き込みが永続的であり、読み取りに対して可視であると考えています（実際そうです）。
-
(`t2`): 書き込みタイムアウト（デフォルトは 2 秒）の後、コーディネーターは `replica_2` が利用できないと判断し、ローカルディスクにヒントを保存します。
-
(`t3`): 後で、`replica_2` が起動すると、コーディネーターを含むすべてのノードにゴシップメッセージを送信します。
-
(`t4`): コーディネーターは、`replica_2` に対して欠落していたミューテーションを含むヒントを再生します。
ノードが時間内に戻ってこない場合、リード修復または完全/増分アンチエントロピ修復がミューテーションを伝播するまで、宛先レプリカは永久的に同期されなくなります。
ヒントの適用
ヒントは、一度に 1 セグメントずつ、バルクでターゲットレプリカノードにストリーミングされ、ターゲットノードはローカルでそれらを再生します。ターゲットノードがセグメントを再生した後、セグメントを削除し、次のセグメントを受け取ります。すべてのヒントが排出されるまで、これが続きます。
ディスクへのヒントの保存
ヒントは、コーディネーターノードの `$CASSANDRA_HOME/data/hints` ディレクトリ内のフラットファイルに保存されます。ヒントには、ヒント ID、ミューテーションが保存されるターゲットレプリカノード、レプリカノードに配信できなかったシリアル化されたミューテーション（BLOB として保存）、ミューテーションタイムスタンプ、およびミューテーションのシリアル化に使用された Cassandra バージョンが含まれます。デフォルトでは、ヒントは `LZ4Compressor` を使用して圧縮されます。複数のヒントが同じヒントファイルに追加されます。
ヒントには元の変更されていないミューテーションタイムスタンプが含まれているため、ヒントの適用はべき等であり、将来のミューテーションを上書きすることはできません。
ヒントの設定
ヒントは、データの一貫性にとって重要であるため、デフォルトで有効になっています。`cassandra.yaml` 設定ファイルには、ヒントの設定に関するいくつかの設定があります。
表 1. ヒントの設定
| 設定 | 説明 | デフォルト値 |
|---|---|---|
|
ヒントハンドオフの有効/無効を切り替えます |
|
|
ヒントハンドオフが有効になっている場合でも、ヒントハンドオフを実行しないデータセンターのリスト。例 |
|
|
ノードが失敗した後、ヒントが生成される最大時間を定義します。 |
|
|
KiB/秒あたりの最大スロットル、配信スレッドごと。これは、クラスタ内のノードの数に比例して削減されます。（クラスタ内に 2 つのノードがある場合、各配信スレッドは最大レートを使用します。3 つのノードがある場合、2 つのノードが同時にヒントを配信することが予想されるため、それぞれ最大レートの半分にスロットルされます。） |
|
|
ヒントを配信するスレッドの数。マルチDC展開の場合、この数を増やすことを検討してください。クロスDCハンドオフは遅くなる傾向があるためです。 |
|
|
Cassandra がヒントを保存するディレクトリ。 |
|
|
内部バッファからディスクにヒントをフラッシュする頻度。`fsync` はトリガーしません。 |
|
`max_hints_file_size |
単一ヒントファイルの最大サイズ（メガバイト単位）。 |
|
|
ヒントファイルに適用する圧縮。省略した場合は、ヒントファイルは圧縮されずに書き込まれます。LZ4、Snappy、Deflate 圧縮がサポートされています。 |
|
nodetool を使用した実行時のヒントの設定
nodetool は、ヒントの設定またはヒント関連情報の取得のためのいくつかのコマンドを提供します。`nodetool` コマンドは、コマンドを実行しているノードの `cassandra.yaml` に設定がある場合、対応する設定を上書きします。
表 2. ヒントに関する Nodetool コマンド
| コマンド | 説明 |
|---|---|
|
ヒントの保存と配信を無効にします |
|
データセンターへのヒントの保存と配信を無効にします |
|
現在のノードでの将来のヒントの保存と配信を再開します |
|
以前に無効にされたデータセンターのヒントを有効にします |
|
最大ヒントウィンドウをミリ秒単位で表示します。Cassandra 4.0 で追加。 |
|
現在のヒントハンドオフウィンドウを表示します |
|
ヒント配信プロセスを一時停止します |
|
ヒント配信プロセスを再開します |
|
KiB/秒あたりのヒントハンドオフスロットルを設定します（配信スレッドごと） |
|
指定された最大ヒントウィンドウをミリ秒単位で設定します |
|
現在のノードでの将来のヒントの保存の状態 |
|
ローカルノードのすべてのヒントを切り捨てるか、指定されたエンドポイントのヒントを切り捨てます。 |
実行時にヒントの再生速度を上げる
デフォルトの1024 kbpsハンドオフスロットルは、最新のネットワークの大部分にとって保守的であり、ノードの単純な再起動で数ギガバイトものヒントが蓄積され、再生に数時間かかる可能性があります。たとえば、ノードごとに100 Mbpsのデータを取り込んでいる場合、10分間の再起動で10分 * (100メガビット/秒) ~= 7 GiBのデータが生成され、(1024 KiB/秒)で再生するには7.5 GiB / (1024 KiB/秒) = 2.03時間かかります。正確な計算は、ロードバランシング戦略（ラウンドロビンはトークン認識よりも優れている）、ノードあたりのトークン数（トークンが多い方が少ないよりも優れている）、そして当然ながらクラスタの書き込みレートによって異なりますが、いずれにせよ、このスロットルをランタイム時に増やすことを検討する必要があるかもしれません。
このような状況に遭遇した場合は、nodetool sethintedhandoffthrottlekbコマンドを使用して、hinted_handoff_throttleを動的に増やすことを検討してください。
ランタイム時のノードのダウンタイムを長くする
ノードが通常のmax_hint_window（デフォルトは3時間）よりも長くダウンしている場合がありますが、ハードウェアとデータ自体はアクセス可能です。このような場合は、Cassandra 4.0に追加されたnodetool setmaxhintwindowコマンド(CASSANDRA-11720)を使用して、max_hint_windowを動的に増やすことを検討してください。これにより、Cassandraはダウンしたエンドポイントのヒントをより長く保持するように指示されます。
このコマンドは、ヒントを保持している可能性のあるクラスタ内のすべてのノードに適用する必要があります。必要に応じて、cassandra.yamlでmax_hint_window設定を設定し、ローリング再起動を行うことで、設定を永続的に適用できます。
ヒント配信の監視
Cassandra 4.0には、ヒントの配信にかかる時間を理解するためのヒストグラムが追加されており、オペレータが問題をより適切に特定するのに役立ちます(CASSANDRA-13234)。
Hinted Handoff <handoff-metrics>およびHints Service <hintsservice-metrics>メトリクスを追跡するためのメトリクスも利用できます。
