0

私の Symfony2 アプリは MongoDB レプリカ セット (2 つのフル ノードとアービター) に接続します。フェールオーバーが完了した後 (新しいプライマリが正常に選出された後)、多くの Web 要求でサーバー エラーが発生します。Apache を再起動すると (ただし、他に変更を加える必要はありません)、例外はなくなり、アプリは期待どおりに動作します (新しいプライマリをクエリしますが、問題ありません)。

Apache を再起動する前MongoCursorExceptionに、メッセージnot master and slaveOk=falseまたはcouldn't determine master. 一貫性がありません。ヒットした Apache ワーカーに依存しているようです。か何か。とにかく、Apache を再起動するとアプリがすぐに修正され、すべてのクエリが正常に成功するようです。

私のレプリカ セットはパフォーマンスではなく冗長性のためのものなので、slaveOk=true は使用しません。

これらのオプションは Mongo コンストラクターに渡されます。

  • connect => TRUE
  • replicaSet => foo

私は使用しています：

  • PHP 5.3.10
  • APC 3.1.7
  • モンゴ DB 2.2.1
  • Symfony2 バージョン 2.0.18

私のdepsファイルから：

  • 教義 2.1.7
  • doctrine-mongodb 1.0.0-BETA1
  • doctrine-mongodb-odm 1.0.0-BETA5
  • doctrine-common 2.2.0
  • doctrine-dbal 2.1.7

Symfony2 アプリが古くなった MongoDB 接続を再利用しようとしているようです。プライマリのログは、この推測を裏付けています。アプリの Web ページにアクセスしてクエリを作成すると、接続が追加され、Apache を再起動すると、多くの接続が解放されます。

関連している：

おそらく関連しています：

4

1 に答える 1

1

バージョン 1.2.12 の PHP ドライバーを使用していたというのは正しいですか? Apache を再起動すると問題が解決するようですが、ドライバーがプール内の間違った接続を単に再利用しているように見えます。Apache とそのワーカーを再起動すると、すべてのプールが効果的にクリアされます。これは、各ワーカーが独自の接続プールを持っており、その接続プールがその有効期間内に処理されるリクエスト間で共有されるためです。フェールオーバー後に一部のワーカーが接続を更新し、他のワーカーは更新しなかった可能性が非常に高いため、ヒットしたワーカーによっては例外が引き続き発生する可能性があります。

接続処理は 1.3.0 で見直されたため、アップグレードするとフェイルオーバーのサポートがいくらか改善されるはずです。PR #81がマージされたら、Doctrine MongoDB は 1.3.0 を適切にサポートする必要があります。ODMはその後すぐに続きます。

Doctrineのretry_オプションは、連続する試行間の遅延をサポートしていないため、10 ～ 30 秒かかる可能性があるフェイルオーバーの処理にはあまり適していません。Jon の最初の意図は、切断された接続とネットワーク ブリップに対処することだったと思います。

また、PHP ドライバー 1.3.0 までは、mongo.is_master_intervalINI 設定が実際に使用されることはありませんでした。これはPHP-576で修正されました。

于 2012-12-02T18:47:06.920 に答える