This commit is contained in:
Shlomi Noach 2016-07-16 06:57:22 -06:00
parent de2fba167f
commit b0c0049c76
2 changed files with 19 additions and 4 deletions

View File

@ -69,7 +69,9 @@ Note: in order to migrate a table on the master you don't need to _connect_ to t
Originally this was named `gh-osc`: GitHub Online Schema Change, in the likes of [Facebook online schema change](https://www.facebook.com/notes/mysql-at-facebook/online-schema-change-for-mysql/430801045932/) and [pt-online-schema-change](https://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html).
But then a rare genetic mutation happened, and the `s` transformed into `t`. And that sent us down the path of trying to figure out a new acronym. Right now, `gh-ost` (pronounce: _Ghost_), stands for:
- GitHub Online Schema Translator/Transformer/Transfigurator
- GitHub Online Schema Transmogrifier/Translator/Transformer/Transfigurator
Pronounce: _ghost_
## Authors

View File

@ -5,7 +5,7 @@
`gh-ost` operates by connecting to potentially multiple servers, as well as imposing itself as a replica in order to streamline binary log events directly from one of those servers. There are various operation modes, which depend on your setup, configuration, and where you want to run the migration.
##### a. Connect to replica, migrate on master
### a. Connect to replica, migrate on master
This is the mode `gh-ost` expects by default. `gh-ost` will investigate the replica, crawl up to find the topology's master, and will hook onto it as well. Migration will:
@ -46,7 +46,7 @@ gh-ost \
With `--execute`, migration actually copies data and flips tables. Without it this is a `noop` run.
##### b. Connect to master
### b. Connect to master
If you don't have replicas, or do not wish to use them, you are still able to operate directly on the master. `gh-ost` will do all operations directly on the master. You may still ask it to be considerate of replication lag.
@ -78,7 +78,7 @@ gh-ost \
[--execute]
```
##### c. Migrate/test on replica
### c. Migrate/test on replica
This will perform a migration on the replica. `gh-ost` will briefly connect to the master but will thereafter perform all operations on the replica without modifying anything on the master.
Throughout the operation, `gh-ost` will throttle such that the replica is up to date.
@ -92,6 +92,7 @@ Test on replica cheatsheet:
gh-ost \
--user="gh-ost" \
--password="123456" \
--host=replica.with.rbr.com \
--test-on-replica \
--database="my_schema" \
--table="my_table" \
@ -108,3 +109,15 @@ gh-ost \
--panic-flag-file=/tmp/gh-ost.panic.flag \
--execute
```
### cnf file
You may use a `cnf` file in the following format:
```
[client]
user=gh-ost
password=123456
```
You may then remove `--user=gh-ost --password=123456` and specify `--conf=/path/to/config/file.cnf`