読み取り前に読み取り修復をスケジュールする

私はCassandraからデータを読み取るレポート作成ツールを用意しています。構成は一貫性レベルがLOCAL_QUORUM、圧縮戦略がサイズが階層化され、RF = 3です。読み取り前に読み取り修復をスケジュールする

レポート作成ツールからCassandraにプルリクエストを送信すると、Cassandraの設計に従って、データの一貫性のためにリード修復がトリガーされます。これは実際には良いデザインです。しかし、リード修復は高価で、レポートにはより長い時間がかかります。

レポートユーザーは、午前6時以降のみレポートの生成を開始します。ユーザーがレポートを使用する前に修復スケジュールを設定する方法はありますか。たとえば、私は午前6時前に修理を予定し、修理します。そのため、午前6時以降、すべてのデータはクラスタ全体で構成されます。

このケースでは、Cassandraからのデータの読み取りが開始されると、読み込み修復がスケジュールされたジョブとして終了したため、読み込み修復が再開されません。私は、午前6時にISTが発生した後、一貫性のないデータ書き込み/更新でうまくいく。修理のスケジュールを立てるのにどの技法が良いのですか？また、修理が最近完了した場合は、修理を実際には避けていますか？ -Suyodha

出典

2016-07-31 Madhu Mohan Kommu

伝統的なアンチエントロピー修復を使用すると、一貫性レベルで読み取ることができます。

は、最も明白なは（nodetool repair -par -incまたは類似のコマンドラインスイッチで可能性）nodetool repairである、またはそのような維持Cassandra Range Repairツールとしての小さな範囲を、修復するサードパーティ製のツールのいくつかを用いて抗エントロピー修復を行うには多くの方法がありますBrian GallewまたはSpotify's Cassandra Reaper。

出典

2016-07-31 02:29:05

こんにちはクリスとJeff..Basedに機会を設定することにより、テーブルの上に読み取り修理を無効にすることができた場合は

...私は私の質問には答え持っています。君たちありがとう。 –

あなたは読書修理がそれを遅くしていると思いますか？修理が行われているかどうかを確認するには、（jmx）org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBackgroundとorg.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlockingを確認してください。読み込み修復は、データが読み込みに矛盾する場合にのみ一般的であるはずがありません。その本当に問題は、あなたの入力に0

ALTER TABLE yourtable WITH read_repair_chance = 0;

出典

2016-07-31 03:48:32

こんにちはクリスとジェフ、それを調べてくれてありがとう。私はできるだけ早くあなたにこれに戻ってきます。どうもありがとう。 –

ALTER TABLEを使用した読み取り修復を無効にすると、ブロックされていないバックグラウンド読み取り修復のみが保護されます。フォアグラウンド読み取り修復は、より低い一貫性レベルを使用することによってのみ無効にすることができます。 –

実際、CL.ONEと 'read_repair_chance = 0'の両方が必要になります。 1つだけ行うことは、まだ他のものを起こさせるでしょう。私はまだ、これがかなり長い時間を取っている報告書の本当の原因ではないと考えている –

読み取り前に読み取り修復をスケジュールする

答えて

関連する問題