0

MongoDB の教義を使用して、ElasticSearch を symfony2 アプリケーションと統合する作業を行っています。
このチュートリアルでは、スタンドアロン インスタンスをレプリケート セットに変換する必要があると述べています
。基本的な概念は次のとおりです。アプリケーションは MongoDB プライマリ サーバーにデータを問い合わせ、検索機能は検索のためにセカンダリ サーバーに問い合わせる必要があります。私のレプリケートセットの構成は次のとおりです。

{
    "_id" : "rs0",
    "version" : 1,
    "members" : [
            {
                    "_id" : 0,
                    "host" : "localhost:27017"
            }
    ]

これはプライマリ サーバーだと思いますが、別のサーバーを作成する必要がありますか? はいの場合、2 番目のレプリケート サーバーを作成するにはどうすればよいですか?
タンクがいっぱい！

4

1 に答える 1

2

リンクしたチュートリアルに従って、ElasticSearch River を機能させるには、MongoDB をレプリカ セットとして構成する必要があります。レプリカ セット構成では、各ノードには、適用されたすべての操作 (挿入、更新、削除) のログである操作ログ (oplog) があります。oplog は、ElasticSearch River や MMS バックアップなどの機能を有効にするために、テーラブル カーソルを使用して読み取ることができます。

私の質問は、別のサーバーを作成する必要がありますか?

技術的には、レプリカ セットは単一のノードとして構成できます (既に完了しています)。推奨されるベスト プラクティスは、最低 3 つのノード (プライマリ、セカンダリ、およびアービター、またはプライマリと 2 つのセカンダリ) を持つレプリカ セットを用意することです。これにより、高可用性とデータ冗長性の追加の利点が得られます。詳細については、MongoDB マニュアルのレプリカ セットの概要を参照してください。

検索機能は、検索のためにセカンダリ サーバーに問い合わせる必要があります。

デフォルトでは、MongoDB ドライバーはすべての書き込みおよび読み取り要求をプライマリに送信し、データの読み取りに強い整合性を提供します。セカンダリから読み取る場合、データは最終的に一貫性があります。これは、プライマリからセカンダリへのレプリケーション ラグがある場合、セカンダリから古いデータを読み取る可能性があることを意味します。

通常、セカンダリでクエリを実行することはお勧めしません。シナリオでは、両方のマシンが最大容量で使用されており、障害が発生するか、マシンを停止する必要がある場合、アプリケーションにサービスを提供して検索を実行するための十分なリソースがありません。プライマリが両方の機能を実行するのに十分なリソースを持つように計画する必要があります。

スタンドアロン サーバーをレプリカ セットに移行する場合は、チュートリアルで説明されている手順に従うことができます:スタンドアロンをレプリカ セットに変換します。

于 2014-02-11T00:38:39.210 に答える