Define alter cli flag

This flag not really documented, hopefully this clears up the intent.

doc/command-line-flags.md

@@ -16,6 +16,10 @@ By default, `gh-ost` would like you to connect to a replica, from where it figur
 
 If, for some reason, you do not wish `gh-ost` to connect to a replica, you may connect it directly to the master and approve this via `--allow-on-master`.
 
+### alter
+
+This manadatory flag is the `ALTER` statement migrated to the ghost table.
+
 ### approve-renamed-columns
 
 When your migration issues a column rename (`change column old_name new_name ...`) `gh-ost` analyzes the statement to try and associate the old column name with new column name. Otherwise the new structure may also look like some column was dropped and another was added.

doc/rds.md

@@ -5,7 +5,9 @@
 ## Limitations
 
 - No `SUPER` privileges.
+  - Editing `binlog_format` not allowed, see next bullet.
 - `gh-ost` runs should be setup use [`--assume-rbr`][assume_rbr_docs] and use `binlog_format=ROW`.
+  - See [this tip](#binlog_format) on how to change the `binlog_format`.
 - Aurora does not allow editing of the `read_only` parameter. While it is defined as `{TrueIfReplica}`, the parameter is non-modifiable field.
 
 ## Aurora
@@ -28,9 +30,9 @@ This tool requires binlog_format=STATEMENT, but the current binlog_format is set
 
 #### Binlog filtering
 
-In Aurora, the [binlog filtering feature][aws_replication_docs_bin_log_filtering] is enabled by default. This becomes an issue when gh-ost tries to do the cut-over, because gh-ost waits for an entry in the binlog to proceed but this entry will never end up in the binlog because it gets filtered out by the binlog filtering feature.  
-You need to turn this feature off during the migration process.  
-Set the `aurora_enable_repl_bin_log_filtering` parameter to 0 in the Parameter Group for your cluster.  
+In Aurora, the [binlog filtering feature][aws_replication_docs_bin_log_filtering] is enabled by default. This becomes an issue when gh-ost tries to do the cut-over, because gh-ost waits for an entry in the binlog to proceed but this entry will never end up in the binlog because it gets filtered out by the binlog filtering feature.
+You need to turn this feature off during the migration process.
+Set the `aurora_enable_repl_bin_log_filtering` parameter to 0 in the Parameter Group for your cluster.
 When the migration is done, set it back to 1 (default).
 
 
@@ -52,4 +54,11 @@ Before trying to run any `gh-ost` migrations you will want to confirm the follow
 [percona_toolkit_patch]: https://github.com/jacobbednarz/percona-toolkit/commit/0271ba6a094da446a5e5bb8d99b5c26f1777f2b9
 [ghost_hooks]: https://github.com/github/gh-ost/blob/master/doc/hooks.md
 [ghost_rds_issue_tracking]: https://github.com/github/gh-ost/issues/163
-[aws_replication_docs_bin_log_filtering]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.html#AuroraMySQL.Replication.Performance
+[aws_replication_docs_bin_log_filtering]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.html#AuroraMySQL.Replication.Performance
+
+## Other Tips & Tricks
+
+## binlog_format
+
+On a normal RDS instance, if you need to switch to `binlog_format=ROW`, you can do so by creating a [RDS Parameter Group](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html).
+During the Parameter Group creation process, set `binlog_format` to `ROW`. After creating the Parameter group, you can modify you RDS instance to use it.