2016-07-07 12 views
6

私は、ノードあたり3つのデータセンターと256のvノードを持つ24ノードクラスタでCassandra 3.7を実行しています。各ノードはcronジョブを使用して、1日に1回、nodetool repair-他のノードとは1日の時間が異なります。同時に修復すると修復が発生する

修復に1時間以上かかることがあり、修復が重複することがあります。これが発生すると、修復が始まり、不良状態でハングする可能性があります。これによりカスケード障害が発生し、別のノードが修復を開始しようとするたびにハングアップします。

これから回復するのは難しいです。私が見つけた唯一の方法は、修理が固まっているノードだけでなく、クラスタ内のすべてのノードを再起動することです。

これに対処する唯一のアイデアは、他のノードが修復を開始する前に修復を実行しているかどうか、修復が進行中のときにCassandraテーブルにパブリッシュして何らかのサービスを構築することです。

すべてのノードを1つずつ修復するのに十分な時間が間に合わないため、クラスタが大きくなった場合にどのようにすべてのノードを修復できるかわかりません。

私の主な質問は、私が修復を正しく実行していないことと、大規模なクラスタのすべてのノードを定期的に修復するための推奨される方法は何ですか?

一度に複数のノードを修復する方法はありますか?ドキュメンテーションにはそれがあることが示唆されていますが、それを行う方法が明確ではありません。一度に複数のノードで実行した場合、修復がクラッシュして焼損するのは正常ですか?すべてのノードを再起動するより簡単な方法で修復を終了できますか?

いくつかのものは、私が試した:

  1. は-prなし「nodetool修理」を実行しているが、一度に 複数のノード上で実行した場合、これはまた、ハングします。
  2. "nodetool repair -dcpar"を実行 - この は、すべてのデータセンターの で実行されているノードが所有するトークン範囲を修復しているようですが、同時に複数のノードで実行するとハングします。

私のキースペースはデータセンターごとに1つのレプリカしか保持しないため、-localオプションを使用することはできません。

私は修理ハングがあるときに表示例外のいくつか:

ERROR [ValidationExecutor:4] 2016-07-07 12:00:31,938 CassandraDaemon.java (line 227) Exception in thread Thread[ValidationExecutor:4,1,main] 
java.lang.NullPointerException: null 
     at org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.getActiveSSTables(ActiveRepairService.java:495) ~[main/:na] 
     at org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.access$300(ActiveRepairService.java:451) ~[main/:na] 
     at org.apache.cassandra.service.ActiveRepairService.currentlyRepairing(ActiveRepairService.java:338) ~[main/:na] 
     at org.apache.cassandra.db.compaction.CompactionManager.getSSTablesToValidate(CompactionManager.java:1320) ~[main/:na] 

ERROR [Repair#6:1] 2016-07-07 12:00:35,221 CassandraDaemon.java (line 227) Exception in thread Thread[Repair#6:1,5,RMI Runtime] 
com.google.common.util.concurrent.UncheckedExecutionException: org.apache.cassandra.exceptions.RepairException: [repair #67bd9b10-... 
]]] Validation failed in /198.18.87.51 
     at com.google.common.util.concurrent.Futures.wrapAndThrowUnchecked(Futures.java:1525) ~[guava-18.0.jar:na] 
     at com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1511) ~[guava-18.0.jar:na] 
     at org.apache.cassandra.repair.RepairJob.run(RepairJob.java:160) ~[main/:na] 
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_71] 
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_71] 
     at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_71] 
Caused by: org.apache.cassandra.exceptions.RepairException: [repair #67bd9b10... 
]]] Validation failed in /198.18.87.51 
     at org.apache.cassandra.repair.ValidationTask.treesReceived(ValidationTask.java:68) ~[main/:na] 
     at org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:183) ~[main/:na] 
     at org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:439) ~[main/:na] 
     at org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:169) ~[main/:na] 

ERROR [ValidationExecutor:3] 2016-07-07 12:42:01,298 CassandraDaemon.java (line 227) Exception in thread Thread[ValidationExecutor:3,1,main] 
java.lang.RuntimeException: Cannot start multiple repair sessions over the same sstables 
     at org.apache.cassandra.db.compaction.CompactionManager.getSSTablesToValidate(CompactionManager.java:1325) ~[main/:na] 
     at org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:1215) ~[main/:na] 
     at org.apache.cassandra.db.compaction.CompactionManager.access$700(CompactionManager.java:81) ~[main/:na] 
     at org.apache.cassandra.db.compaction.CompactionManager$11.call(CompactionManager.java:844) ~[main/:na] 
+0

の自動化された修理を実行するためのソフトウェアは、私が聞いてもいいですか?表面的には、これがいくつかの根底にある問題にパッチを当てているように思えます。 –

+0

私たちのネットワークではマシンを再起動する必要があることが多いため、Cassandraノードはデータを見失って矛盾してしまいます。場合によっては、ノードへのネットワーク停止もあります。 –

+0

ああ、そうです。再起動は常にバグです。 –

答えて

0

あなたのデータサイズとどのようにスキーマが鍵空間と、テーブルでデータを拡散し、トークンの数に応じてノードによって、複数の実行可能性これらのディメンションを対象に修復します。大きなキースペースとテーブルの場合は、修復時に開始/終了トークンオプションを使用することもできます。 nodetool ringコマンドを実行すると、ノードごとにトークンを見つけることができます。修復の範囲を狭めるもう1つの方法は、インクリメンタルと並列の修復を実行することです。

+0

私はあなたが解決策として提案していることを理解していません。あなたは、何とかnodetoolリングの出力を分析し、いくつかの修復を並行して実行する中央修復コントローラを作成する必要があると言っていますか?あなたはどうやってそれをしますか? 3.7のデフォルトはインクリメンタルと並列の修復用ですので、私はすでにこれらの設定を使用しています。一度に複数のノードで修復を実行すると、修復が妨げられることはありません。 –

0

@viorelはサブレンジ修理を提案していたと思います。 Here's the datastax doc for cassandra 3.0ここでは、それは速い修復として記述されています。そしてなぜそれが速くなるかもしれないのhere's an explanation。基本的に、Merkleツリー全体を計算するのではなく、パーティション範囲を複数の範囲に分割して比較します。その理由はHere's an explanationです

+0

修理のスピードは私にとって本当に問題ではありません。修理を避けて例外を投げたり、ぶら下げたりしたいだけです。私がカッサンドラにパッチを適用して、別の修復がすでに進行中であることが検出された場合、正常に終了するようにすれば、少なくとも手動でノードを再起動する必要はありません。 –

+0

重複修復を避けることを考えていました。私は最終的に負荷がこれを唯一の一時的な解決策にするのに十分な大きさになると思います。 – LHWizard

+0

はい、それは私の経験でした。私が最初にこの問題に遭遇したのは、ノードの1つが(同じマシン上で実行されているCassandra以外のアプリケーションのため)メモリを頻繁に呼び出していたためで、修復がかなり遅くなり、別のノードと重複してしまいました。したがって、ノードが同時に修理から身を守ることはないので、何らかの種類の調整メカニズムまたは中央プランナーが必要と思われる。 –

0

あなたは、カサンドラ・刈取機を試すことができます:「修理」は継続的に必要である理由カサンドラ https://github.com/spotify/cassandra-reaper

+0

それはツールがもう管理されていないように見えますが、未解決の問題の1つは、3.xのような新しいリリースでは機能しないということです。私は集中修理スケジューラを使用しないことを望むだろう。というのも、それは単一障害点になるからである。ドキュメントでは、「複数の並列修復を同時に複数のノードで同時に実行する」ことについて説明していますが、何が並行して修復できるのか、修復を引き起こして例外をスローしてハングするのかは不明です。修復は、複数のノードによって同じテーブルを修復しようとする試みに対して、それ自体を保護しないようです。 –

+0

答えのどれも私が探していたものではありませんでしたが、あなたの答えが最も有用だったので、私はあなたに賞金を授与します。情報のおかげで。 –

+0

私は2 DCで50以上のノードクラスタを維持しています。 1つのノードで修復タスクをセットアップし、毎日異なるキースペースを修復して、すべてのキースペースが1週間に1回修復されるようにします。私は-prフラグを使用せず、すべて正常に動作します。これが参考になることを願っています。 –

関連する問題