Hi, I have an issue where all READ requests are queried on Master DB and not queried on Slave DB.

Could you help me with setting up configuration so that by default the READ requests go to Slave DB. And also without using User.using. Or correct me if my understanding is wrong.

ruby 2.2.4

ar-octopus (0.8.6)

shards.yml:

octopus:
  environments:
    - development
    - staging
    - production
  replicated: true
  fully_replicated: true
  development:
    slave1:
      adapter: postgresql
      encoding: unicode
      database: test_slave1
      pool: 5
      host: localhost

User model:

class User < ActiveRecord::Base
  replicated_model
end

rails console:

user = User.find 1

user.current_shard
 => :master 

user = User.where(id: 1).first()

user.current_shard
 => :master 

user = User.using(:slave1).find 1

user.current_shard
 => :slave1 

I have the same problem. Did you manage to resolve?

Same issue here. Seems like you have to use Octopus.using(:slave) { User.first }, which is not what the readme says.

Hi @sushma-unii , @simonmorley, and @jamesfzhang - sorry for the late reply. I'm trying here, but I couldn't reproduce this issue. Can you provide more information? (like rails version). Thanks!

@thiagopradi We have the same issue. We couldn't manage to get this working. We have to explicitly use using in some queries to decrease a load on the master.

rails 4.1

@thiagopradi we're facing the same issue, using configuration just like the readme says.

Additionally to the posted before, when we query a model using Octopus.using(:slave1), it actually reads from slave, but when we query an ActiveRelation, it goes to master even using the Octopus.using(:slave1) clause.

rails 4.0.4

@thiagopradi Same issue going on in my application. Are there any plans to resolve this?

Environment

Rails 5.0.1
Ruby 2.3.3
Ar-Octopus 0.9.0

Shards.yml

octopus:
  replicated: true
  fully_replicated: true
  environments:
    - development
  development:
    shards:
      slave1:
        username: admin
        host: slave1.host.postgres
        password: somepassword
        adapter: postgresql
        database: main
      slave2:
        username: admin
        host: slave2.host.postgres
        password: somepassword
        adapter: postgresql
        database: main

User model

class User < ActiveRecord::Base
  replicated_model
  using(slave_group: :shards)
end

Examples

z = User.first
z.current_shard
=> :master

z = User.using(slave_group: :shards)
z.current_shard
=> {:slave_group=>:shards}

z = User.using(:slave1)
z.current_shard
=> :shard1

z = User.using(:slave2)
z.current_shard
=> :shard2

same issue with octopus 0.9.0. force rollback to 0.8.5 fixed the issue

hey Folks, I'll look at this issue this weekend and try to solve it. sorry for the delay.

@cyaconi Did you find any chance to resolve your issue? I have the same problem now.

hey all,

I've isolated the problem and I'm working to fix it. The problem here is that the query actually goes to the slave shard, but the #current_shard attribute is being setted as the master instead of slave where the query was executed. This is related to the after_initialize :set_current_shard logic, which works in a non-predictable way sometimes (I made a bad design decision when starting developing Octopus =( ).

I'm working on the fix right now, and hopefully it will be live this week. I'll keep you guys updated. Thanks for the patience.

Thiago

@thiagopradi Did you manage to resolve this in the end?

I was just alerted about this problem and was looking at this and other related issue discussions. It seems master now has a fix and working properly. Any plans to cut a release soon?

Actually, nvm. Seems there's a bug introduced. A delete call tried to use readonly slave.

same issue for me. When I add the .where is auto sent to master, rather than replicas

eg Octopus.using(:replicas) { Role.where("user_id = ?",id) }

Still happening to me?

Hey @thiagopradi any updates on this? We're seeing this issue and have to force use of the slave by wrapping our code in using blocks, which works, but it's not ideal. Thanks!

Just to clarify...it sounds like the query is going to the slave database correctly...but that the current_shard attribute is incorrectly getting :master. Is that correct, @thiagopradi ?

@dhempy I believe that was one symptom that @thiagopradi was trying to fix, but other issues have been opened around it actually connecting to master instead of the expected replicas. I can attest for our application the same is happening. Most reads are still going to master, although it is not consistent. One suspicion is that until it encounters it's first forced master read it uses the replicas on a per connection thread, but I can't examine the individual threads of a pool to understand if that's the culprit