SolrCloud の復旧および耐書き込み性

各ノードのトランザクションログが作成されるので、コンテンツや構成の変更がすべて記録されます。ログは、ノード内のどのコンテンツをレプリカに含める必要があるかを判断するために使用されます。新しいレプリカが作成されると、リーダーとトランザクションログを参照して、含めるコンテンツを認識します。失敗した場合は、再試行します。

トランザクションログは更新の記録で構成されているので、インデックスが中断された場合にコミットされていない更新をやり直すので、より堅牢なインデックス作成が可能になります。

リーダーがダウンした場合、リーダーは一部のレプリカにはリクエストを送信しているが、他のレプリカには送信していない可能性があります。したがって、新しい潜在的なリーダーが特定されると、他のレプリカに対して同期プロセスを実行します。これが成功すると、すべてが整合し、リーダーはアクティブとして登録され、通常の動作が続行します。レプリカが同期からずれている場合、システムは完全なレプリケーション/再生ベースの復旧を求めます。

コアがスキーマを再ロードしており、一部は完了しているが、一部は完了していないために更新が失敗した場合、リーダーは更新が失敗したことをノードに通知し、復旧手順を開始します。

1 つより大きな複製係数を使用すると、アップデート要求はシャードリーダー上で成功しますが、1 つ以上のレプリカ上で失敗する場合があります。たとえば、1 つのシャードを持つコレクションと複製係数が 3 のものがあるとします。この場合、シャードリーダーと 2 つの追加レプリカがあります。何らかの理由によりリーダー上でアップデート要求が成功したが、両方のレプリカ上で失敗した場合でも、アップデート要求は依然としてクライアントの観点からは成功と見なされます。アップデートを逃したレプリカは、回復時にリーダーと同期されます。

舞台裏では、これは Solr がノードの 1 つ (現在のリーダー) にのみあるアップデートを受け入れたことを意味します。クライアントにこれを知らせるために、Solr は応答ヘッダーに「Achieved Replication Factor」(rf) を含めます。達成された複製係数は、実際アップデート要求を受信したシャードのレプリカの数です (リーダーを含む)。上記の例では 1 です。マルチシャード更新要求の場合、達成された複製係数は、すべてのシャードにおける最低達成複製係数です。

クライアント側で、達成された複製係数が許容レベル未満の場合、クライアントアプリケーションは、劣化状態に対処するために追加の対策を講じることができます。たとえば、クライアントアプリケーションは、コレクションの状態が劣化している間に送信されたアップデート要求のログを保持し、問題が解決したらアップデートを再送信できます。