gh-ost has been developed at GitHub in recent months to answer a problem we faced with ongoing, continuous production changes requiring modifications to MySQL tables. gh-ost changes the existing online table migration paradigm by providing a low impact, controllable, auditable, operations friendly solution.
#输出 -allow-master-master explicitly allow running in a master-master setup -allow-nullable-unique-key allow gh-ost to migrate based on a unique key with nullable columns. As long as no NULL values exist, this should be OK. If NULL values exist in chosen key, data may be corrupted. Use at your own risk! -allow-on-master allow this migration to run directly on master. Preferably it would run on a replica -alter string alter statement (mandatory) -approve-renamed-columns ALTER in case your ALTER statement renames columns, gh-ost will note that and offer its interpretation of the rename. By default gh-ost does not proceed to execute. This flag approves that gh-ost's interpretation si correct -chunk-size int amount of rows to handle in each iteration (allowed range: 100-100,000) (default 1000) -conf string Config file -critical-load --max-load Comma delimited status-name=threshold, same format as --max-load. When status exceeds threshold, app panics and quits -cut-over string choose cut-over type (default|atomic, two-step) (default "atomic") -cut-over-lock-timeout-seconds int Max number of seconds to hold locks on tables while attempting to cut-over (retry attempted when lock exceeds timeout) (default 3) -database string database name (mandatory) -debug debug mode (very verbose) -default-retries int Default number of retries for various operations before panicking (default 60) -exact-rowcount actually count table rows as opposed to estimate them (results in more accurate progress estimation) -execute actually execute the alter & migrate the table. Default is noop: do some tests and exit -help Display usage -host string MySQL hostname (preferably a replica, not the master) (default "127.0.0.1") -initially-drop-ghost-table Drop a possibly existing Ghost table (remains from a previous run?) before beginning operation. Default is to panic and abort if such table exists -initially-drop-old-table Drop a possibly existing OLD table (remains from a previous run?) before beginning operation. Default is to panic and abort if such table exists -initially-drop-socket-file Should gh-ost forcibly delete an existing socket file. Be careful: this might drop the socket file of a running migration! -max-lag-millis int replication lag at which to throttle operation (default 1500) -max-load string Comma delimited status-name=threshold. e.g: 'Threads_running=100,Threads_connected=500'. When status exceeds threshold, app throttles writes -migrate-on-replica Have the migration run on a replica, not on the master. This will do the full migration on the replica including cut-over (as opposed to --test-on-replica) -nice-ratio float force being 'nice', imply sleep time per chunk time; range: [0.0..100.0]. Example values: 0 is aggressive. 1.5: for every ms spend in a rowcopy chunk, spend 1.5ms sleeping immediately after -ok-to-drop-table Shall the tool drop the old table at end of operation. DROPping tables can be a long locking operation, which is why I'm not doing it by default. I'm an online tool, yes? -panic-flag-file string when this file is created, gh-ost will immediately terminate, without cleanup -password string MySQL password -port int MySQL port (preferably a replica, not the master) (default 3306) -postpone-cut-over-flag-file string while this file exists, migration will postpone the final stage of swapping tables, and will keep on syncing the ghost table. Cut-over/swapping would be ready to perform the moment the file is deleted. -quiet quiet -replication-lag-query string Query that detects replication lag in seconds. Result can be a floating point (by default gh-ost issues SHOW SLAVE STATUS and reads Seconds_behind_master). If you're using pt-heartbeat, query would be something like: SELECT ROUND(UNIX_TIMESTAMP() - MAX(UNIX_TIMESTAMP(ts))) AS delay FROM my_schema.heartbeat -serve-socket-file string Unix socket file to serve on. Default: auto-determined and advertised upon startup -serve-tcp-port int TCP port to serve on. Default: disabled -skip-renamed-columns ALTER in case your ALTER statement renames columns, gh-ost will note that and offer its interpretation of the rename. By default gh-ost does not proceed to execute. This flag tells gh-ost to skip the renamed columns, i.e. to treat what gh-ost thinks are renamed columns as unrelated columns. NOTE: you may lose column data -stack add stack trace upon error -switch-to-rbr let this tool automatically switch binary log format to 'ROW' on the replica, if needed. The format will NOT be switched back. I'm too scared to do that, and wish to protect you if you happen to execute another migration while this one is running -table string table name (mandatory) -test-on-replica Have the migration run on a replica, not on the master. At the end of migration replication is stopped, and tables are swapped and immediately swap-revert. Replication remains stopped and you can compare the two tables for building trust -throttle-additional-flag-file string operation pauses when this file exists; hint: keep default, use for throttling multiple gh-ost operations (default "/tmp/gh-ost.throttle") -throttle-control-replicas string List of replicas on which to check for lag; comma delimited. Example: myhost1.com:3306,myhost2.com,myhost3.com:3307 -throttle-flag-file string operation pauses when this file exists; hint: use a file that is specific to the table being altered -throttle-query string when given, issued (every second) to check if operation should throttle. Expecting to return zero for no-throttle, >0 for throttle. Query is issued on the migrated server. Make sure this query is lightweight -user string MySQL user -verbose verbose -version Print version & exit
