gh-ost/doc/testing-on-replica.md

39 lines
1.7 KiB
Markdown
Raw Normal View History

2016-05-20 14:10:02 +00:00
# Testing on replica
2016-05-20 14:22:28 +00:00
`gh-ost`'s design allows for trusted and reliable tests of the migration without compromising production data integrity.
Test on replica if you:
- Are unsure of `gh-ost`, have not gained confidence into its workings
- Just want to experiment with a real migration without affecting production (maybe measure migration time?)
- Wish to observe data change impact
2016-05-20 14:26:47 +00:00
### What testing on replica means
Apply `--test-on-replica --host=<a.replica>`.
- `gh-ost` would connect to the indicated server
- Will verify this is indeed a replica and not a master
- Will perform _everything_ on this replica. Other then checking who the master is, it will otherwise not touch it.
- All `INFORMATION_SCHEMA` and `SELECT` queries run on the replica
- Ghost table is created on the replica
- Rows are copied onto the ghost table on the replica
- Binlog events are read from the replica and applied to ghost table on the replica
- So... everything
`gh-ost` will sync the ghost table with the original table.
- When it is satisfied, it will issue a `STOP SLAVE IO_THREAD`, effectively stopping replication
- Will finalize last few statements
- Will terminate. No table swap takes place. No table is dropped.
You are now left with the original table **and** the ghost table. They _should_ be identical.
You now have the time to verify the tool works correctly. You may checksum the entire table data if you like.
- e.g.
`mysql -e 'select * from mydb.mytable' | md5sum`
`mysql -e 'select * from mydb._mytable_gst' | md5sum`
### Cleanup
It's your job to:
- Drop the ghost table (at your leisure, you should be aware that a `DROP` can be a lengthy operation)
- Start replication back (via `START SLAVE`)