Q:

how to db:migrate after restoring database from mysql dump in docker

I have two docker containers for mysql and ruby and the ruby container is dependent on mysql container.
In my docker-compose, I have volume-mounted an sql dump to the mysql container's /docker-entrypoint-initdb.d so that it gets executed upon starting the container for the first time and the database gets populated with some data.
The sql dump gets executed and the data gets restored to the db container as expected, but the problem is, while starting the ruby (with rails) container, it throws out a migration pending error. I understand that this is happening because there is no any schema migration versions recorded in the schema_migrations table as the data was deliberately restored from the sql dump.
But, even running docker-compose run <container> rake db:migrate wouldn't help because it throws out a table already exists error as the tables have already been created.
How do I sync the rails schema migration versions with the actual data in the database?
I've also tried by manually adding the latest schema version number to the schema_migrations table but still returns migration pending error. And, I cannot run docker-compose run <container> rake db:create db:migrate before restoring from sql dump because the files inside the container's /docker-entrypoint-initdb.d will only be executed if the database isn't created yet.

A:

I think you can dump all data inside schema_migrations along with your initial dump schema, so that it will contain the migration versions and it won't raise an exception upon running rails db:migrate.
Update:
The older version of rails actually checks all schema versions to decide whether it needs migration or not. You can check here for more info. 
      def needs_migration?(connection = Base.connection)
        (migrations(migrations_paths).collect(&:version) - get_all_versions(connection)).size > 0
      end

Hope this will help.

