more doc

Author: Shlomi Noach

README.md

@@ -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
 

doc/cheatsheet.md

@@ -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`