プロジェクトについて
Cassandraを使用するサービスは、各ユーザーの最後のN個のイベントを保存する必要があります。 イベントはユーザーが読み取ることができるよりもはるかに頻繁に発生し、ほとんどの場合、記録されたデータは読み取られず、単に新しいイベントに取って代わられます。 書き込み集中型のタスクで適切に機能するデータベースは世界にはあまりありませんが、Cassandraもその1つです。 クラスターへの書き込み（一貫性の最小化）は、読み取りよりもはるかに高速です。 もちろん、主キー（ユーザーID）によってのみデータを選択する必要があります。
何が悪かった
サービスを開始した人は、ドキュメントを十分に真剣に受け取らず、リングのバランスを取りませんでした。 実際には、ノードの自動追加では、追加時に最大セグメントの半分が割り当てられます。 その結果、ほぼ同時に起動された5つのノードのうち、2つのサーバーが他の3つのサーバーよりもはるかに強力にロードされる非常に奇妙な構成になりました。
nodetool ring
161594151652226679147006417055137150248
X1 Up 106.92 GB 38459616957251446947579138011358024346 |<--|
X2 Up 261.58 GB 87228834825681839886276714150491220347 | ^
X3 Up 268.08 GB 136691754424709629435450736264931173936 v |
X4 Up 148.58 GB 151190524462851319585265604946253553766 | ^
X5 Up 72.71 GB 161594151652226679147006417055137150248 |-->|
5台のサーバーすべてのハードドライブのサイズは260GBでした。 ディスク領域が不足したために2つのノードが落ち、クラスター全体の負荷が低下しました。
ただし、ドキュメントでは、本番環境でリングセグメントの自動選択を許可することは不可能であると繰り返し警告しています。 トークンの手動計算のための式とPHPコードを提供します。
蘇生
まず、Cassandraをオフにすると、そのデータファイルで何でもできます。 重くて古いファイル（30GB）の1つをNFSに移動し、シンボリックリンクを配置しました。 クラスターを開始し、サービスを確認しました-動作します。 問題が検出された時点からの合計修復時間は15分です。 ほぼすべての時間で、ファイルをNFSに転送しました。
次に、データベースのキャッシュをすぐに有効にしました。 Cassandraには、ハードドライブアクセスを大幅に削減するかなり適切なキャッシュメカニズムがあります。 少なくともこのアプリケーションでは、キャッシュヒットは80〜90％でした。
nodetool setcachecapacity App Feeds 200000 1000000
注：キャッシュサイズは、バイトではなく「レコード」で設定されます。 見逃さないように、平均レコードのサイズを正しく想像する必要があります。 もちろん、私は逃し、利用可能なものよりも多くを割り当て、数時間後にメモリ不足からクラッシュした最初のノードを手に入れました。 単純な再起動とより慎重なキャッシュサイズで処理されます。
治療の試み
そのため、サービスは実現し、負荷に対処しましたが、もちろん、NFS上のデータの一部で不均衡なクラスターを持つことは不可能です。 ドキュメントを読んだ後、nodetool moveコマンドを使用しようとしました。 私は彼女をほぼ一週間働かせようとしました。 問題の本質は、ノード間のデータが移動しなかったことです。 転送用に準備されたデータが含まれるソースノードにストリームディレクトリが表示されましたが、転送自体（notedool streamsコマンドを使用して表示できます）は常にハングしていました。 場合によっては最初からです。
そのため、初めてバグ1221に遭遇しました。 修正を読んだ後、最新バージョンにアップグレードしようとしましたが、バグ1760が私を追い越しました。 その結果、クラスターを0.6.5に更新しましたが、あまり役に立ちませんでした。 クラスターは不均衡状態のままです。
クラスターを管理するためのツールは悲惨なだけでなく、初歩的なものだと言わなければなりません。 いくつかのコマンドを指定するだけで、間接標識によってプロセスを監視できます。 それだけです
私の大きな喜びに、この時点で経営陣はリプタノからトレーニングセミナーを分岐しました 。 この会社はCassandraであり、開発および有償サポートを提供しています。 このワークショップで、カサンドラタオは私に開かれました。
タオカサンドラ
何も扱わないでください。 フォールズ-仕上げ、きれいにし、新品同様にオンにします。 それがセミナーで言われたことです。 これは、クラスター管理ツールの基本的な性質を説明しています。 実際、著者の考えによれば、管理は2つの主要な操作で構成されています。1）ノードを追加します。 2）ノードを削除します。
このようにして、最終的にクラスターを修正することができました。 ノードはクラスターから次々に削除され、クリーンアップされ、正しくカウントされたトークンで開始されました。 もちろん、ダウンタイムなしで実行できる再起動の順序を考えて、ペーパーの後ろに座っていなければなりませんでした。 組み合わせの問題は、それほど難しくはありませんが、興味深いことが判明しました。
もちろん、いくつかのバグがありました。 私は1676年までずっと悩まされていました。 読み込みノードは50GBの新しいデータを受信し、静かに座っていました。 サービスを再起動すると、次の50GBになりました。 そして、すべてが来るまで。
おわりに
クラスターを修正することが判明しました。 Cassandraについての私の意見は、「学生の手仕事、ツールなし」から「驚くほど安定したデータベース」に変わりました。 実際、2か月間、クラスターは破損したサーバーで動作しました。2か月間、HDDへのアクセス速度はNFSの速度まで低下しました。 また、サービス全体が存続し、ユーザーからの苦情はあまりありませんでした。
この間、私はこのデータベースの内部について多くのことを学び、その作成者（驚くほど反応がよく賢い人）と話をしました。そして、プロセスの終わりに向かって、それを楽しみました。