octoleo/gh-ost
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c3d53cf419
gh-ost/doc/requirements-and-limitations.md

2.2 KiB
Raw Blame History

Requirements and limitations

Requirements

  • You will need to have one server serving Row Based Replication (RBR) format binary logs. gh-ost prefers to work with replicas. You may still have your master configured with Statement Based Replication (SBR).

  • gh-ost requires an account with these privileges:

    • ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE on the database (schema) where your migrated table is, or of course on *.*
    • SUPER, REPLICATION SLAVE on *.*

Limitations

  • Foreign keys not supported. They may be supported in the future, to some extent.
  • Triggers are not supported. They may be supported in the future.
  • MySQL 5.7 generated columns are not supported. They may be supported in the future.
  • The two before & after tables must share some UNIQUE KEY. Such key would be used by gh-ost to iterate the table.
    • As an example, if your table has a single UNIQUE KEY and no PRIMARY KEY, and you wish to replace it with a PRIMARY KEY, you will need two migrations: one to add the PRIMARY KEY (this migration will use the existing UNIQUE KEY), another to drop the now redundant UNIQUE KEY (this migration will use the PRIMARY KEY).
  • The chosen migration key must not include columns with NULL values.
    • gh-ost will do its best to pick a migration key with non-nullable columns. It will by default refuse a migration where the only possible UNIQUE KEY includes nullable-columns. You may override this refusal via --allow-nullable-unique-key but you must be sure there are no actual NULL values in those columns. Such NULL values would cause a data integrity problem and potentially a corrupted migration.
  • It is not allowed to migrate a table where another table exists with same name and different upper/lower case.
    • For example, you may not migrate MyTable if another table called MYtable exists in the same schema.
  • Amazon RDS and Google Cloud SQL are probably not supported (due to SUPER requirement)
  • Multisource is not supported when migrating via replica. It should work (but never tested) when connecting directly to master (--allow-on-master)