0

クラスターに大きな問題があります。サーバーは不明な理由で切断され続け (ログには何もありません)、不明な理由でクラッシュします。クラスターのセットアップが間違っている可能性があると思います。

まずこれが最初です。私はシャーディングを理解しています。これは素晴らしい機能ですが、次のとおりです。

「シャードごとに n 個のレプリカ」?

それはどういう意味ですか？

2番目のこと。「n」台のサーバーでクラスタを構成するには? シャーディングのために 6 台のサーバーがあります (1,000 万件を超えるレコードを含むドキュメントはほとんどありません) が、クラスターを正しく構成したかどうかはわかりません。

私が書いたすべてのサーバーで：

for example (srv1.conf)
join=srv2:port
join=srv3:port
join=srv4:port
join=srv5:port
join=srv6:port

これはサーバーをクラスタに追加する正しい方法ですか?

ドキュメントには何もありません。「推奨される」クラスター構成を投稿できれば幸いです。

3 つ目はフェイルオーバーについてです。私の 6 クラスタ サーバーでは、すべてのテーブル
に 3 つのレプリカを持つ 6 つのシャードがあります。たとえば、サーバー1のアプリがダウンし、いくつかのクレイジーな書き込みがクラスター上にあると叫ぶと。他のサーバーがダウンした場合に冗長性がない場合、クラスターのポイントは何ですか?

サーバーが 1 つしかないときはアプリが常に機能していたので、誰かがこれを手伝ってくれることを本当に願っています。一部のサーバーが切断されるたびに、すべてがクラッシュします。私はnodejs rethinkdbdashを使用しています。

アップデート

たとえば、1つのテーブルに2milのレコードがあり、6つのサーバーに分散されています（私にとって、これは読み取り速度のために重要です）。「レプリカ」の意味がわかりません。すべてのテーブルはこのように構成され、シャードごとに 6 つのシャードと 3 つのレプリカが構成されます。あなたが言ったことから、一部のサーバーがダウンした場合、テーブルは読み取り可能になりますが、そうではありません（set read_mode = outdatedやアプリのクラッシュなどのことを言っています）。読み取りを行っているアプリのすべての部分を変更して、read_mode = 古いと言う方法はありません。それはただの貧弱なプログラミングです。

ログには何もありません。dmesg のすべてのサーバーには、次のものがあります。

TCP: TCP: Possible SYN flooding on port 28015. Sending cookies.  Check SNMP counters.
4

1 に答える 1

0

サーバーは不明な理由で切断され続け (ログには何もありません)、不明な理由でクラッシュします。

ログに何も記録されていない場合、クラッシュを解決するのは困難です。のような初期化マネージャーを使用している場合、初期化マネージャーは何と言っていますsystemdか? RethinkDB は終了しましたか、それとも応答しなくなりましたか? RethinkDB に使用できるメモリはどれくらいですか? dmesgまたはあなたのRethinkDB に関連するメッセージはありますsyslogか? 少なくとも、サーバーが切断されていることがログに示されていますか? Web インターフェイスで問題が報告されていますか?

「シャードごとに n 個のレプリカ」?

それはどういう意味ですか？

では、データベース内のデータを表すピザがあるとしましょう。シャードとは、ピザを小さなスライスにカットする場所です。たとえば、4 つのスライス (シャード) にカットするとします。nレプリカを作成するには、各スライスのコピーを作成するだけですn。= 3 とするnと、4 つのシャードと、各シャードに 3 つのレプリカがあり、合計で 12 個になります。今できることは、これらのピースを複数のサーバーに分散させることです。

したがって、あなたの場合、最小数の 3 つのレプリカ (したがって 3 つのサーバー) を必要とする高可用性を備えたシステムが必要なようですが、データベースが動作を継続するにはレプリカの大部分が利用可能である必要があるため、奇数が推奨されます。データベースが動作するには、各シャードのレプリカの大部分が利用可能である必要があります。2 つのシャードがあり、それぞれに 3 つのレプリカが 6 つのサーバーに分散されており、それぞれにシャードのレプリカが 1 つあるとします。1 つのサーバーがダウンしても問題ありません。別の 2 つのレプリカ (ダウンしたサーバーと同じデータを格納するサーバー) が存在し、2/3 のレプリカが利用可能 (大部分) であるため、データベースは動作を継続できます。

私が書いたすべてのサーバーで：...これはサーバーをクラスターに追加する正しい方法ですか？

サーバーの を指定する必要がありますcanonical-address。これは、他のサーバーが接続するために使用するアドレス (ポートを含まない) であり、結合引数を 1 つだけ指定する必要があります。クラスタに接続されたサーバー。クラスタ内のすべてのサーバは、を使用して相互に通信できる必要canonical-addressがあります。

ドキュメントには何もありません。「推奨される」クラスター構成を投稿できれば幸いです。

クラスターの構成ファイルは次のようになります。

bind=all
canonical-address=server.domain.com
driver-port=28015
cluster-port=29015
join=otherserver.domain.com:29015

cluster-tls-key=/path/to/key.pem
cluster-tls-cert=/path/to/cert.pem
cluster-tls-ca=/path/to/cert.pem

サーバーがインターネット経由で通信する必要があるため、クラスタ内通信用に TLS をセットアップしました。これを暗号化したいと考えています。クラスターの保護に関する情報については、 https://www.rethinkdb.com/docs/security/を参照してください。ドライバー接続を暗号化することもできます。

他のサーバーがダウンした場合に冗長性がない場合、クラスターのポイントは何ですか?

データベースのレプリカをセットアップできます。上記の概念のいくつかを説明しました。

レプリケーションに関する情報は、https ://www.rethinkdb.com/docs/sharding-and-replication/ にあります。

于 2016-09-22T09:59:47.200 に答える