Any configuration to disable running of migrations on slave databases?

[dkumar431]

Hi All,

I am using heroku postgrees follower database on heroku. I just want to run my migrations on master database and not on slaves.

Any central configuration option in octopus that will disable the running of migration on slaves?

[PatrickTulskie]

I'm also having this issue right now. According to the documentation, it says:

If you don’t specify what shard to send the migration or Octopus isn’t configured to run in that environment, Octopus will send the migration to master database specified in database.yml.

If you look at the source code though, it sends your migrations to all shards regardless of what you specify. Am I missing something?

[Zeneixe]

I have the same problem

[knightq]

Same problem here, any news?

[thiagopradi]

Hi @dkumar431 / @PatrickTulskie / @Zeneixe / @knightq ,

Can you provide more information about your setups? Are you guys using replication or sharding? If you don't specify anything, Octopus should send your database migrations only to master.

If it is sending to your replicated database, them it's a bug.

Thiago

[PatrickTulskie]

@thiagopradi I don't have the exact setup handy since I had to tear everything out of our production systems shortly after reporting this.

We were only using replication though. We do not shard anything. With our setup, we were just trying to add read-only nodes and it mostly worked. The biggest issue we had was migrations attempting to go to the reader nodes instead of just the main node. When I was digging through the source code at the time, I couldn't figure out a clean fix for it so we wound up removing octopus.

[mstroming]

I'm seeing the same issue.

I'm set up for replication (replicated: true, fully_replicated: false) per the documentation.

Perhaps it has to do with the shard_agnostic value?

octopus/lib/octopus/migration.rb

Line 108 in 1c9a07f

def migrations_with_octopus(shard_agnostic = false)

Versions
octopus = 0.8.6
Rails = 3.2.22.5

[psylone]

We faced the same issue.

I suppose, this current issue is related with #353 and #345.

After some investigation we realized that this option may help: #345 (comment)

The other option is to use dynamic configuration during migration, something like this:

# config/initializers/octopus.rb

Octopus.setup do |config|
  config.environments = [] if ENV['DB_MIGRATE']
end

# And then pass this env variable on migration run:
# DB_MIGRATE=1 bin/rails db:migrate

Both options were tested with Rails 5.0 and Octopus 0.10.2.