4

一見すると、このタイトルは、これまでに何百万回も尋ねられてきた質問のように聞こえると思いますが、そうではありません。

私のアプリケーションはデータベースを使用しますが、アプリケーションの一部の部分のみが実際にデータベースの稼働に依存しています。データベースに依存しないアプリケーションの一部が、データベースがダウンした場合でも正しく機能できるようにしたいと考えています。

問題は、Rails アプリがデータベース接続が失われたことを認識するとすぐに、アプリケーションのどの部分も (静的コンテンツを除いて) 機能しなくなることです。(つまり、例外は、実行フローがデータベースに依存しないコントローラーに到達する前にスローされます。コントローラーは、実行が許可されていれば問題ありません。)

私が探しているものを達成する方法はありますか? どんな助けでも大歓迎です！

アップデート：

慎重に検討した結果、問題は次のように要約されると思います。

データベース接続が絶対に必要になるまでプールからチェックアウトされないように、「遅延」データベース接続プーリング/処理を使用する手段はありますか? 可能であれば、これにより、データベースがダウンしている場合でも、データベースをまったく使用しないリクエストを続行できます。

考え？

更新 2:

スタック トレースの追加。これは、データベース接続が利用できない場合、制御がコントローラーに到達しないことを示しています。（データベースは明らかに意図的にダウンしているので、これをテストできます。）

PG::Error
could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/postgresql_adapter.rb:771:in `initialize'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/postgresql_adapter.rb:771:in `new'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/postgresql_adapter.rb:771:in `connect'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/postgresql_adapter.rb:493:in `initialize'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/postgresql_adapter.rb:41:in `new'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/postgresql_adapter.rb:41:in `postgresql_connection'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/abstract/connection_pool.rb:446:in `new_connection'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/abstract/connection_pool.rb:456:in `checkout_new_connection'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/abstract/connection_pool.rb:427:in `acquire_connection'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/abstract/connection_pool.rb:364:in `block in checkout'
/usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/abstract/connection_pool.rb:363:in `checkout'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/abstract/connection_pool.rb:273:in `block in connection'
/usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/abstract/connection_pool.rb:272:in `connection'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/abstract/connection_pool.rb:552:in `retrieve_connection'
activerecord (4.0.0.beta1) lib/active_record/connection_handling.rb:79:in `retrieve_connection'
activerecord (4.0.0.beta1) lib/active_record/connection_handling.rb:53:in `connection'
activerecord (4.0.0.beta1) lib/active_record/query_cache.rb:51:in `restore_query_cache_settings'
activerecord (4.0.0.beta1) lib/active_record/query_cache.rb:43:in `rescue in call'
activerecord (4.0.0.beta1) lib/active_record/query_cache.rb:32:in `call'
activerecord (4.0.0.beta1) lib/active_record/connection_adapters/abstract/connection_pool.rb:632:in `call'
actionpack (4.0.0.beta1) lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'
activesupport (4.0.0.beta1) lib/active_support/callbacks.rb:373:in `_run__2745032424595922925__call__callbacks'
activesupport (4.0.0.beta1) lib/active_support/callbacks.rb:78:in `run_callbacks'
actionpack (4.0.0.beta1) lib/action_dispatch/middleware/callbacks.rb:27:in `call'
actionpack (4.0.0.beta1) lib/action_dispatch/middleware/reloader.rb:64:in `call'
actionpack (4.0.0.beta1) lib/action_dispatch/middleware/remote_ip.rb:76:in `call'
actionpack (4.0.0.beta1) lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'
actionpack (4.0.0.beta1) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
railties (4.0.0.beta1) lib/rails/rack/logger.rb:38:in `call_app'
railties (4.0.0.beta1) lib/rails/rack/logger.rb:21:in `block in call'
activesupport (4.0.0.beta1) lib/active_support/tagged_logging.rb:67:in `block in tagged'
activesupport (4.0.0.beta1) lib/active_support/tagged_logging.rb:25:in `tagged'
activesupport (4.0.0.beta1) lib/active_support/tagged_logging.rb:67:in `tagged'
railties (4.0.0.beta1) lib/rails/rack/logger.rb:21:in `call'
actionpack (4.0.0.beta1) lib/action_dispatch/middleware/request_id.rb:21:in `call'
rack (1.5.2) lib/rack/methodoverride.rb:21:in `call'
rack (1.5.2) lib/rack/runtime.rb:17:in `call'
activesupport (4.0.0.beta1) lib/active_support/cache/strategy/local_cache.rb:72:in `call'
rack (1.5.2) lib/rack/lock.rb:17:in `call'
actionpack (4.0.0.beta1) lib/action_dispatch/middleware/static.rb:64:in `call'
railties (4.0.0.beta1) lib/rails/engine.rb:510:in `call'
railties (4.0.0.beta1) lib/rails/application.rb:96:in `call'
rack (1.5.2) lib/rack/lock.rb:17:in `call'
rack (1.5.2) lib/rack/content_length.rb:14:in `call'
rack (1.5.2) lib/rack/handler/webrick.rb:60:in `service'
/usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/webrick/httpserver.rb:138:in `service'
/usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/webrick/httpserver.rb:94:in `run'
/usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/webrick/server.rb:295:in `block in start_thread'
4

3 に答える 3

1

Rails 3 についての回答で申し訳ありませんが、少しでもお役に立てば幸いです。

少し異なる状況で同じ問題が発生したため、スタックトレースとレールコードを掘り下げて、2行で修正する方法を見つけました。

TL;DR:

# config/application.rb
# before your application declaration
ActiveRecord::Railtie.initializers.reject! { |i| i.name == 'active_record.set_reloader_hooks' }
# inside your application declaration
config.middleware.delete ActiveRecord::QueryCache

まず、Rails の起動時に呼び出されますActionDispatch::Reloader.prepare!(本番用に 1 回、開発用のリクエストごとに)。このメソッドは単体テストでのセットアップに似ており、多くのことをリセットします。とりわけ、接続プールから接続をクリアし、スキーマ キャッシュをクリアし、後者はプールから DB 接続をチェックアウトします。したがって、最初の行active_record/railtieは、そのコールバックを追加する初期化子を削除します。おそらく、本番環境でのみこれを行いたいと思うでしょうが、この変更は機能するapplication.rbかそれ以上である必要があります。

次に、Rails は実際にリクエストごとに DB 接続をチェックアウトしますが、これはActiveRecord::QueryCacheミドルウェアで行われます。私はそれなしでできると決めました。本当に必要な場合は、でキャッシュを有効にしてリセットできると思いますaround_filter。

于 2014-12-02T23:39:14.867 に答える