Replies: 5 comments 3 replies
-
|
I should add—when I set proxy_delay to 0 everything worked perfectly (but that seems rather unsafe given the replica isn't guaranteed to have zero lag). 0.1 delay once again did not work. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, we figured it out! All is fine. Rails wraps a lot of stuff automatically in BEGIN … COMMIT, a busy app is almost always inside that 2-second window. Makara never treated BEGIN/COMMIT as writes. So that's why the difference in behavior for us when we switched to this gem instead. WRITE_STATEMENT_MATCHERS = [ I removed it for us and now everything is routing properly... I wonder is there a reason to not just rely on insert, update, delete, drop solely? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @jackcb123. Sorry for the late reply, I'm only seeing this now. You need to provide a lot more info for me to be able to help you. You should always start with at least this info (but the more you provide, the better):
There are too many variables that could interfere with the expected behaviour and that helps narrowing down the investigation scope. Internally, active record sends The proxy would only kick in if you had, for example, any explicit calls to a hijacked method such as to So if the behaviour you're facing is that the proxy is hijacking a regular Thanks |
Beta Was this translation helpful? Give feedback.
-
|
Patches released: |
Beta Was this translation helpful? Give feedback.
-
|
@jackcb123 @OskarEichler this is what I used to find and fix the issue using the repo's docker compose file.
# frozen_string_literal: true
load "Rakefile"
Rake::Task["environment"].invoke
require "active_record_proxy_adapters/log_subscriber"
ActiveRecord::Base.logger = Logger.new($stdout)
ActiveRecord::LogSubscriber.detach_from(:active_record)
ActiveRecordProxyAdapters.configure do |config|
config.proxy_delay = 2.seconds
config.checkout_timeout = 2.seconds
end
class User < TestHelper::PostgreSQLRecord
endAfter creating the databases with Then (v0.6.0)ActiveRecord 7.0.xActiveRecord 7.1.xActiveRecord 7.2.xActiveRecord 8.0.xAs you can see, the only version that had an unexpected behaviour was AR 7.0.x. Now (v0.6.1)ActiveRecord 7.0.xActiveRecord 7.1.xActiveRecord 7.2.xActiveRecord 8.0.xAll versions behave the same way now. I think that is sufficient evidence to say the issue has been resolved. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi again!
Would Transactional Pooling on PgBouncer mess this up w/ proxy_delay? This is what we use. We have zero writes before some reads in controllers, but we do write AFTER. I notice that many of these reads are still going to the primary unless explicitly wrapped in the connected_to :reading block.
Wouldn't it work like this with tons of concurrent requests:
Request A: performs read, then write (switching to primary, for 2 seconds)
Request B: PgBouncer may assign a connection that was previously used (in this case, by request A) that performed a write, and therefore has a last_write timestamp set, so the read goes to the primary?
Beta Was this translation helpful? Give feedback.
All reactions