Technical questions and answers. This document will be updated as we go
### What if I'm using Statement Based Replication?
You can still migrate tables with `gh-ost`. We do that. What you will need is a replica configured with:
-`log_bin`
-`log_slave_updates`
-`binlog_format=ROW`
Thus, the replica will transform the master's SBR binlogs into RBR binlogs. `gh-ost` is happy to read the binary logs from the replica. [Read more](migrating-with-sbr.md)
### What if gh-ost crashes halfway through, or I kill it?
Unlike trigger-based solutions, there's nothing urgent to clean up in the event `gh-ost` bails out or gets killed. There are the two tables creates by `gh-ost`:
- The _ghost_ table: `_yourtablename_gho`
- The _changelog_ table: `_yourtablename_ghc`
You may instruct `gh-ost` to drop these tables upon startup; or better yet, you drop them.
### What if the cut-over (table switch) is unable to proceed due to locks/timeout?
There is a `lock_wait_timeout` explicitly associated with the cut-over operation. If your table suddenly suffers from a long running query, the cut-over (involving `LOCK` and `RENAME` statements) may be unable to proceed. There's a finite number of retries, and if none of these succeeds, `gh-ost` bails out.
### What if the migration is causing a high load on my master?
This is where `gh-ost` shines. There is no need to kill it as you may be used to with other tools. You can reconfigure `gh-ost` [on the fly](https://github.com/github/gh-ost/blob/master/doc/interactive-commands.md) to be nicer.
You're always able to actively begin [throttling](throttle.md). Just touch the `throttle-file` or `echo throttle` into `gh-ost`. Otherwise, reconfigure your `max-load`, the `nice-ratio`, the `throttle-query` to gain better thresholds that would suit your needs.
