俗话说：工欲善其事必先利其器；在日常的数据库工作中，优秀的工具可以让我们的工作事倍功半；下面笔者先给大家简单详细介绍MYSQL数据库在线DDL工具gh-ost，欢迎大家阅读分享；
一、安装步骤
1、安装go环境
下载go(我的当前目录是/data/work)
[root@wjq ~]# wget https://studygolang.com/dl/golang/go1.10.1.linux-amd64.tar.gz[root@wjq ~]#tar -xvf go1.10.1.linux-amd64.tar.gz设置环境变量
[root@wjq ~]#vim /etc/profile添加export GOROOT=/data/work/goexport GOPATH=/data/work/gopathexport PATH=$PATH:$GOROOT/bin:$GOPATH/bin2、安装gh-osh
下载二进制安装包：https://github.com/github/gh-ost/releases
[root@wjq mysql]# tar zxvf gh-ost-binary-linux-20190214020851.tar.gz解压完成之后，当前目录下就会出现gh-ost的可执行文件
[root@wjq mysql]# ll gh-ost-rwxr-xr-x 1 20649 users 9511528 Feb 14 2019 gh-ost常用参数解释：
Usage of gh-ost:
–aliyun-rds:是否在阿里云数据库上执行。true
–allow-master-master:是否允许gh-ost运行在双主复制架构中，一般与-assume-master-host参数一起使用
–allow-nullable-unique-key:允许gh-ost在数据迁移依赖的唯一键可以为NULL，默认为不允许为NULL的唯一键。如果数据迁移(migrate)依赖的唯一键允许NULL值，则可能造成数据不正确，请谨慎使用。
–allow-on-master:允许gh-ost直接运行在主库上。默认gh-ost连接的从库。
–alter string:DDL语句
–approve-renamed-columns ALTER:如果你修改一个列的名字，gh-ost将会识别到并且需要提供重命名列名的原因，默认情况下gh-ost是不继续执行的，除非提供-approve-renamed-columns ALTER。
–ask-pass:MySQL密码
–assume-master-host string:为gh-ost指定一个主库，格式为”ip:port”或者”hostname:port”。在这主主架构里比较有用，或则在gh-ost发现不到主的时候有用。
–assume-rbr:确认gh-ost连接的数据库实例的binlog_format=ROW的情况下，可以指定-assume-rbr，这样可以禁止从库上运行stop slave,start slave,执行gh-ost用户也不需要SUPER权限。
–check-flag
–chunk-size int:在每次迭代中处理的行数量(允许范围：100-100000)，默认值为1000。
–concurrent-rowcount:该参数如果为True(默认值)，则进行row-copy之后，估算统计行数(使用explain select count(*)方式)，并调整ETA时间，否则，gh-ost首先预估统计行数，然后开始row-copy。
–conf string:gh-ost的配置文件路径。
–critical-load string:一系列逗号分隔的status-name=values组成，当MySQL中status超过对应的values，gh-ost将会退出。-critical-load Threads_connected=20,Connections=1500，指的是当MySQL中的状态值Threads_connected>20,Connections>1500的时候，gh-ost将会由于该数据库严重负载而停止并退出。Comma delimited status-name=threshold, same format as –max-load. When status exceeds threshold, app panics and quits
–critical-load-hibernate-seconds int :负载达到critical-load时，gh-ost在指定的时间内进入休眠状态。 它不会读/写任何来自任何服务器的任何内容。
–critical-load-interval-millis int:当值为0时，当达到-critical-load，gh-ost立即退出。当值不为0时，当达到-critical-load，gh-ost会在-critical-load-interval-millis秒数后，再次进行检查，再次检查依旧达到-critical-load，gh-ost将会退出。
–cut-over string:选择cut-over类型:atomic/two-step，atomic(默认)类型的cut-over是github的算法，two-step采用的是facebook-OSC的算法。
–cut-over-exponential-backoff
–cut-over-lock-timeout-seconds int:gh-ost在cut-over阶段最大的锁等待时间，当锁超时时，gh-ost的cut-over将重试。(默认值：3)
–database string:数据库名称。
–debug:debug模式。
–default-retries int:各种操作在panick前重试次数。(默认为60)
–discard-foreign-keys:该参数针对一个有外键的表，在gh-ost创建ghost表时，并不会为ghost表创建外键。该参数很适合用于删除外键，除此之外，请谨慎使用。
–dml-batch-size int:在单个事务中应用DML事件的批量大小（范围1-100）（默认值为10）
–exact-rowcount:准确统计表行数(使用select count(*)的方式)，得到更准确的预估时间。
–execute:实际执行alter&migrate表，默认为noop，不执行，仅仅做测试并退出，如果想要ALTER TABLE语句真正落实到数据库中去，需要明确指定-execute
–exponential-backoff-max-interval int
–force-named-cut-over:如果为true，则’unpostpone | cut-over’交互式命令必须命名迁移的表
–force-table-names string:在临时表上使用的表名前缀
–heartbeat-interval-millis int:gh-ost心跳频率值，默认为500
–help
–hooks-hint string:任意消息通过GH_OST_HOOKS_HINT注入到钩子
–hooks-path string:hook文件存放目录(默认为empty，即禁用hook)。hook会在这个目录下寻找符合约定命名的hook文件来执行。
–host string :MySQL IP/hostname
–initially-drop-ghost-table:gh-ost操作之前，检查并删除已经存在的ghost表。该参数不建议使用，请手动处理原来存在的ghost表。默认不启用该参数，gh-ost直接退出操作。
–initially-drop-old-table:gh-ost操作之前，检查并删除已经存在的旧表。该参数不建议使用，请手动处理原来存在的ghost表。默认不启用该参数，gh-ost直接退出操作。
–initially-drop-socket-file:gh-ost强制删除已经存在的socket文件。该参数不建议使用，可能会删除一个正在运行的gh-ost程序，导致DDL失败。
–master-password string :MySQL 主密码
–master-user string:MysQL主账号
–max-lag-millis int:主从复制最大延迟时间，当主从复制延迟时间超过该值后，gh-ost将采取节流(throttle)措施，默认值：1500s。
–max-load string:逗号分隔状态名称=阈值，如：’Threads_running=100,Threads_connected=500′. When status exceeds threshold, app throttles writes
–migrate-on-replica:gh-ost的数据迁移(migrate)运行在从库上，而不是主库上。
–nice-ratio float:每次chunk时间段的休眠时间，范围[0.0…100.0]。0：每个chunk时间段不休眠，即一个chunk接着一个chunk执行；1：每row-copy 1毫秒，则另外休眠1毫秒；0.7：每row-copy 10毫秒，则另外休眠7毫秒。
–ok-to-drop-table:gh-ost操作结束后，删除旧表，默认状态是不删除旧表，会存在_tablename_del表。
–panic-flag-file string:当这个文件被创建，gh-ost将会立即退出。
–password string :MySQL密码
–port int ：MySQL端口，最好用从库
–postpone-cut-over-flag-file string：当这个文件存在的时候，gh-ost的cut-over阶段将会被推迟，数据仍然在复制，直到该文件被删除。
–quiet：静默模式。
–replica-server-id uint : gh-ost的server_id
–replication-lag-query string:弃用
–serve-socket-file string：gh-ost的socket文件绝对路径。
–serve-tcp-port int:gh-ost使用端口，默认为关闭端口。
–skip-foreign-key-checks:确定你的表上没有外键时，设置为’true’，并且希望跳过gh-ost验证的时间-skip-renamed-columns ALTER
–skip-renamed-columns ALTER：如果你修改一个列的名字(如change column)，gh-ost将会识别到并且需要提供重命名列名的原因，默认情况下gh-ost是不继续执行的。该参数告诉gh-ost跳该列的数据迁移，让gh-ost把重命名列作为无关紧要的列。该操作很危险，你会损失该列的所有值。
–stack:添加错误堆栈追踪。
–switch-to-rbr:让gh-ost自动将从库的binlog_format转换为ROW格式。
–table string:表名
–test-on-replica：在从库上测试gh-ost，包括在从库上数据迁移(migration)，数据迁移完成后stop slave，原表和ghost表立刻交换而后立刻交换回来。继续保持stop slave，使你可以对比两张表。
–test-on-replica-skip-replica-stop:当-test-on-replica执行时，该参数表示该过程中不用stop slave。
–throttle-additional-flag-file string:当该文件被创建后，gh-ost操作立即停止。该参数可以用在多个gh-ost同时操作的时候，创建一个文件，让所有的gh-ost操作停止，或者删除这个文件，让所有的gh-ost操作恢复。
–throttle-control-replicas string:列出所有需要被检查主从复制延迟的从库。
–throttle-flag-file string:当该文件被创建后，gh-ost操作立即停止。该参数适合控制单个gh-ost操作。-throttle-additional-flag-file string适合控制多个gh-ost操作。
–throttle-http string
–throttle-query string:节流查询。每秒钟执行一次。当返回值=0时不需要节流，当返回值>0时，需要执行节流操作。该查询会在数据迁移(migrated)服务器上操作，所以请确保该查询是轻量级的。
–timestamp-old-table:在旧表名中使用时间戳。 这会使旧表名称具有唯一且无冲突的交叉迁移
–tungsten：告诉gh-ost你正在运行的是一个tungsten-replication拓扑结构。
–user string :MYSQL用户
–verbose
–version
二、主库模式
1、常用命令
gh-ost \--max-load=Threads_running=20 \--critical-load=Threads_running=50 \--critical-load-interval-millis=5000 \--chunk-size=1000 \--user="root" \--password="qcloud@2018" \--host='127.0.0.1' \--port=3306 \--database="wjq" \--table="employees" \--verbose \--alter="engine=innodb" \--assume-rbr \--cut-over=default \--cut-over-lock-timeout-seconds=1 \--dml-batch-size=10 \--allow-on-master \--concurrent-rowcount \--default-retries=10 \--heartbeat-interval-millis=2000 \--panic-flag-file=/tmp/ghost.panic.flag \--postpone-cut-over-flag-file=/tmp/ghost.postpone.flag \--timestamp-old-table \--execute 2>&1 | tee /tmp/rebuild_employees.log2、输出日志分析
GH-OST会输出一些关键详细信息，让你了解整个迁移过程。当然，你可以控制输出级别。
–verbose：常用，有用的输出，而不是一切。
–debug：输出所有一切。
日志信息如下：
2019-12-07 22:43:58 INFO starting gh-ost 1.0.482019-12-07 22:43:58 INFO Migrating `wjq`.`employees`2019-12-07 22:43:58 INFO connection validated on 127.0.0.1:33062019-12-07 22:43:58 INFO User has ALL privileges2019-12-07 22:43:58 INFO binary logs validated on 127.0.0.1:33062019-12-07 22:43:58 INFO Inspector initiated on wjq:3306, version 5.7.19-log2019-12-07 22:43:58 INFO Table found. Engine=InnoDB2019-12-07 22:44:01 INFO Estimated number of rows via EXPLAIN: 2993872019-12-07 22:44:01 INFO Recursively searching for replication master2019-12-07 22:44:01 INFO Master found to be wjq:33062019-12-07 22:44:01 INFO log_slave_updates validated on 127.0.0.1:33062019-12-07 22:44:01 INFO connection validated on 127.0.0.1:33062019-12-07 22:44:01 INFO Connecting binlog streamer at mysql3306.000064:8255879[2019/12/07 22:44:01] [info] binlogsyncer.go:133 create BinlogSyncer with config {99999 mysql 127.0.0.1 3306 root false false false UTC true 0 0s 0s 0 false}[2019/12/07 22:44:01] [info] binlogsyncer.go:354 begin to sync binlog from position (mysql3306.000064, 8255879)[2019/12/07 22:44:01] [info] binlogsyncer.go:203 register slave for master server 127.0.0.1:33062019-12-07 22:44:01 INFO connection validated on 127.0.0.1:33062019-12-07 22:44:01 INFO connection validated on 127.0.0.1:33062019-12-07 22:44:01 INFO will use time_zone='SYSTEM' on applier2019-12-07 22:44:01 INFO Examining table structure on applier2019-12-07 22:44:01 INFO Applier initiated on wjq:3306, version 5.7.19-log2019-12-07 22:44:01 INFO Dropping table `wjq`.`_employees_ghc`2019-12-07 22:44:01 INFO Table dropped2019-12-07 22:44:01 INFO Creating changelog table `wjq`.`_employees_ghc`2019-12-07 22:44:01 INFO rotate to next log from mysql3306.000064:0 to mysql3306.000064[2019/12/07 22:44:01] [info] binlogsyncer.go:723 rotate to (mysql3306.000064, 8255879)2019-12-07 22:44:01 INFO Changelog table created2019-12-07 22:44:01 INFO Creating ghost table `wjq`.`_employees_gho`2019-12-07 22:44:01 INFO Ghost table created2019-12-07 22:44:01 INFO Altering ghost table `wjq`.`_employees_gho`2019-12-07 22:44:01 INFO Ghost table altered2019-12-07 22:44:01 INFO Intercepted changelog state GhostTableMigrated2019-12-07 22:44:01 INFO Created postpone-cut-over-flag-file: /tmp/ghost.postpone.flag2019-12-07 22:44:01 INFO Waiting for ghost table to be migrated. Current lag is 0s2019-12-07 22:44:01 INFO Handled changelog state GhostTableMigrated2019-12-07 22:44:01 INFO Chosen shared unique key is PRIMARY2019-12-07 22:44:01 INFO Shared columns are emp_no,birth_date,first_name,last_name,gender,hire_date,testcol1,count2019-12-07 22:44:01 INFO Listening on unix socket file: /tmp/gh-ost.wjq.employees.sock2019-12-07 22:44:01 INFO Migration min values: [10001]2019-12-07 22:44:01 INFO Migration max values: [499999]2019-12-07 22:44:01 INFO Waiting for first throttle metrics to be collected2019-12-07 22:44:01 ERROR parsing time "" as "2006-01-02T15:04:05.999999999Z07:00": cannot parse "" as "2006"2019-12-07 22:44:01 INFO First throttle metrics collected# Migrating `wjq`.`employees`; Ghost table is `wjq`.`_employees_gho`# Migrating wjq:3306; inspecting wjq:3306; executing on wjq# Migration started at Sat Dec 07 22:43:58 +0800 2019# chunk-size: 1000; max-lag-millis: 1500ms; dml-batch-size: 10; max-load: Threads_running=20; critical-load: Threads_running=50; nice-ratio: 0.000000# throttle-additional-flag-file: /tmp/gh-ost.throttle # postpone-cut-over-flag-file: /tmp/ghost.postpone.flag [set]# panic-flag-file: /tmp/ghost.panic.flag# Serving on unix socket: /tmp/gh-ost.wjq.employees.sock这些信息是GH-OST相对自我解释，他们大多表示一切顺利。你将主要关注迁移并了解其是否顺利进行。一旦迁移实际开始，你将看到如下输出。
Copy: 0/299387 0.0%; Applied: 0; Backlog: 0/1000; Time: 3s(total), 0s(copy); streamer: mysql3306.000064:8257599; State: migrating; ETA: N/ACopy: 0/299387 0.0%; Applied: 0; Backlog: 0/1000; Time: 4s(total), 1s(copy); streamer: mysql3306.000064:8258392; State: migrating; ETA: N/ACopy: 7000/299387 2.3%; Applied: 0; Backlog: 0/1000; Time: 5s(total), 2s(copy); streamer: mysql3306.000064:8454005; State: migrating; ETA: 1m25sCopy: 16000/299387 5.3%; Applied: 0; Backlog: 0/1000; Time: 6s(total), 3s(copy); streamer: mysql3306.000064:8704252; State: migrating; ETA: 53sCopy: 32000/299387 10.7%; Applied: 0; Backlog: 0/1000; Time: 7s(total), 4s(copy); streamer: mysql3306.000064:9149375; State: migrating; ETA: 33sCopy: 48000/299387 16.0%; Applied: 0; Backlog: 0/1000; Time: 8s(total), 5s(copy); streamer: mysql3306.000064:9593805; State: migrating; ETA: 26sCopy: 64000/299387 21.4%; Applied: 0; Backlog: 0/1000; Time: 9s(total), 6s(copy); streamer: mysql3306.000064:10038647; State: migrating; ETA: 22sCopy: 79000/299387 26.4%; Applied: 0; Backlog: 0/1000; Time: 10s(total), 7s(copy); streamer: mysql3306.000064:10455500; State: migrating; ETA: 19sCopy: 95000/299387 31.7%; Applied: 0; Backlog: 0/1000; Time: 11s(total), 8s(copy); streamer: mysql3306.000064:10900454; State: migrating; ETA: 17sCopy: 113000/299387 37.7%; Applied: 0; Backlog: 0/1000; Time: 12s(total), 9s(copy); streamer: mysql3306.000064:11400683; State: migrating; ETA: 14sCopy: 128000/299387 42.8%; Applied: 0; Backlog: 0/1000; Time: 13s(total), 10s(copy); streamer: mysql3306.000064:11817995; State: migrating; ETA: 13sCopy: 143000/299387 47.8%; Applied: 0; Backlog: 0/1000; Time: 14s(total), 11s(copy); streamer: mysql3306.000064:12262961; State: migrating; ETA: 12sCopy: 157000/299387 52.4%; Applied: 0; Backlog: 0/1000; Time: 15s(total), 12s(copy); streamer: mysql3306.000064:12624284; State: migrating; ETA: 10sCopy: 174000/299387 58.1%; Applied: 0; Backlog: 0/1000; Time: 16s(total), 13s(copy); streamer: mysql3306.000064:13096505; State: migrating; ETA: 9sCopy: 189000/299387 63.1%; Applied: 0; Backlog: 0/1000; Time: 17s(total), 14s(copy); streamer: mysql3306.000064:13513590; State: migrating; ETA: 8sCopy: 204000/299387 68.1%; Applied: 0; Backlog: 0/1000; Time: 18s(total), 15s(copy); streamer: mysql3306.000064:13931136; State: migrating; ETA: 7sCopy: 214000/299387 71.5%; Applied: 0; Backlog: 0/1000; Time: 19s(total), 16s(copy); streamer: mysql3306.000064:14209235; State: migrating; ETA: 6sCopy: 229000/299387 76.5%; Applied: 0; Backlog: 0/1000; Time: 20s(total), 17s(copy); streamer: mysql3306.000064:14626242; State: migrating; ETA: 5sCopy: 246000/299387 82.2%; Applied: 0; Backlog: 0/1000; Time: 21s(total), 18s(copy); streamer: mysql3306.000064:15098735; State: migrating; ETA: 3sCopy: 259000/299387 86.5%; Applied: 0; Backlog: 0/1000; Time: 22s(total), 19s(copy); streamer: mysql3306.000064:15460181; State: migrating; ETA: 2sCopy: 277000/299387 92.5%; Applied: 0; Backlog: 0/1000; Time: 23s(total), 20s(copy); streamer: mysql3306.000064:15960640; State: migrating; ETA: 1sCopy: 292000/299387 97.5%; Applied: 0; Backlog: 0/1000; Time: 24s(total), 21s(copy); streamer: mysql3306.000064:16377900; State: migrating; ETA: 0s2019-12-07 22:44:23 INFO Row copy complete进度提示说明：
Copy: 7000/299387 2.3%;299387指需要迁移总行数，7000指已经迁移的行数，2.3%指迁移完成的百分比。
Applied: 0，指在二进制日志中处理的event数量。在上面的例子中，迁移表没有流量，因此没有被处理日志event。
Backlog: 0/1000，表示我们在读取二进制日志方面表现良好，在二进制日志队列中没有任何积压（Backlog）事件。
Backlog: 7/1000，当复制行时，在二进制日志中积压了一些事件，并且需要应用。
Backlog: 1000/1000，表示我们的1000个事件的缓冲区已满（程序写死的1000个事件缓冲区，低版本是100个），此时就注意binlog写入量非常大，gh-ost处理不过来event了，可能需要暂停binlog读取，需要优先应用缓冲区的事件。
streamer: mysql3306.000064:8454005;表示当前已经应用到binlog文件位置
状态提示
每隔一定时间会打印友好提示：
# Migrating `wjq`.`employees`; Ghost table is `wjq`.`_employees_gho`# Migrating wjq:3306; inspecting wjq:3306; executing on wjq# Migration started at Sat Dec 07 22:43:58 +0800 2019# chunk-size: 1000; max-lag-millis: 1500ms; dml-batch-size: 10; max-load: Threads_running=20; critical-load: Threads_running=50; nice-ratio: 0.000000# throttle-additional-flag-file: /tmp/gh-ost.throttle # postpone-cut-over-flag-file: /tmp/ghost.postpone.flag [set]# panic-flag-file: /tmp/ghost.panic.flag# Serving on unix socket: /tmp/gh-ost.wjq.employees.sock三、从库模式
1、常用命令
gh-ost \ --max-load=Threads_running=16 \ --critical-load=Threads_running=32 \ --chunk-size=1000 \ --initially-drop-old-table \ --initially-drop-ghost-table \ --initially-drop-socket-file \ --ok-to-drop-table \ --host="10.249.5.39" \ --port=3307 \ --user="dbadmin" \ --password="12345" \ --assume-rbr \ --allow-on-master \ --assume-master-host=10.249.5.39:3306 \ --database="gh_ost" \ --table="gh_01" \ --alter="add column c4 varchar(50) not null default ''" \ --panic-flag-file=/tmp/ghost.panic.flag \ --serve-socket-file=/tmp/ghost.sock \ --verbose \ --execute四、测试模式
gh-ost \ --test-on-replica \ --max-load=Threads_running=16 \ --critical-load=Threads_running=32 \ --chunk-size=1000 \ --initially-drop-old-table \ --initially-drop-ghost-table \ --initially-drop-socket-file \ --host="10.249.5.39" \ --port=3307 \ --user="dbadmin" \ --password="12345" \ --assume-rbr \ --database="gh_ost" \ --table="gh_01" \ --alter="add column c4 varchar(50) not null default ''" \ --panic-flag-file=/tmp/ghost.panic.flag \ --serve-socket-file=/tmp/ghost.sock \ --verbose \ --execute参数说明
–test-on-replica：在从库上执行迁移，但不进行最后的cut-over，并最后会停止复制线程，供测试人员进行数据对比
–migrate-on-replica：直接在从库上迁移并cut-over，复制线程不会停止
五、暂停、恢复、终止、延迟切换
gh-ost的–serve-socket-file文件用来监听请求，比如可以动态调整性能方面参数，也可以进行暂停、恢复gh-ost线程。
#暂停[root@wjq tmp]# echo throttle | socat - /tmp/ghost.sock #恢复[root@wjq tmp]# echo no-throttle | socat - /tmp/ghost.sock #终止对应panic-flag-file参数文件，当tmp目录存在该文件立即停止[root@wjq tmp]# touch /tmp/ghost.panic.flag 日志中就会出现如下的信息：2019-12-07 22:44:54 FATAL Found panic-file /tmp/ghost.panic.flag. Aborting without cleanup 注意：停止gh-ost操作会有遗留表 xxx_ghc, xxx_gho 还有socket文件，管理cut-over的文件,如果你需要执行两次请务必检查指定目录是否存在这些文件，并且清理掉文件和表 #延迟切换(cut-over阶段)--postpone-cut-over-flag-file=/tmp/ghost.postpone.flag当设置该参数时cut-over一直延迟切换，直到你删除该文件才进行切换 #动态调整性能参数[root@wjq tmp]# echo chunk-size=100 | socat - /tmp/gh-ost.wjq.employees.sock #打开限流[root@wjq tmp]# echo throttle | socat - /tmp/gh-ost.wjq.employees.sock #关闭限流[root@wjq tmp]# no-throttle | socat - /tmp/gh-ost.wjq.employees.sock 改变执行限速参数: chunk-size= 1024, max-lag-millis=100, max-load=Thread_running=23 这些参数都可以在运行时动态调整。echo chunk-size=1024 | socat - /tmp/gh-ost.wjq.employees.sockecho max-lag-millis=100 | socat - /tmp/gh-ost.wjq.employees.sockecho max-load=Thread_running=23 | socat - /tmp/gh-ost.wjq.employees.sock 六、使用过程中遇到的问题记录
问题 1、对于主从结构 DB 集群，Binlog 日志格式必须是 ROW 模式，否则会有如下报错：
2018-03-20 19:51:08 FATAL 192.168.1.1:3306 has MIXED binlog_format, but I’m too scared to change it to ROW because it has replicas. Bailing out
解决办法：
执行 gh-ost 之前，先将 binlog 格式动态改为 ROW 模式（不会影响主从同步）：
SET GLOBAL binlog_format = ‘ROW’;
然后，再执行 gh-ost 就可以了，如果后面需要 MIXED 模式，可以再次动态修改回来即可。
问题 2、修改对象表不能被触发器关联，gh-ost 虽然不再依赖触发器，但是依然不支持有触发器关联的表，如果修改有触发器关联的表，则会有如下提示：
2018-03-21 08:22:48 ERROR Found triggers on ndb.net_device_parts. Triggers are not supported at this time. Bailing out
问题 3、修改对象表不能被外键关联，否则如下报错：
2018-03-21 08:20:21 FATAL 2018-03-21 08:20:21 ERROR Found 7 parent-side foreign keys on ndb.net_device. Parent-side foreign keys are not supported. Bailing out
问题 4、FATAL Unexpected database port reported
该问题主要发生在主主模式，且使用自定义端口的情况，
解决办法：在-assume-master-host 参数后面添加主机的端口号，比如：-assume-master-host=192.168.1.1:3307
如果是云数据库的话，需要加上–aliyun-rds参数
示例说明
上面是一个简单的案例，下面我们就来看一下在执行过程中产生的两张中间表：
root@localhost:mysql3306.sock [wjq]>show tables like '%employees%';+-----------------------------+| Tables_in_wjq (%employees%) |+-----------------------------+| _employees_ghc || _employees_gho || employees |+-----------------------------+3 rows in set (0.00 sec) root@localhost:mysql3306.sock [wjq]>show create table _employees_ghc\G;*************************** 1. row *************************** Table: _employees_ghcCreate Table: CREATE TABLE `_employees_ghc` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `hint` varchar(64) CHARACTER SET ascii NOT NULL, `value` varchar(4096) CHARACTER SET ascii NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `hint_uidx` (`hint`)) ENGINE=InnoDB AUTO_INCREMENT=311 DEFAULT CHARSET=utf8mb41 row in set (0.00 sec)_employees_ghc是用于记录中间执行过程记录表
_employees_gho就是目标表，也就是应用ddl语句的幽灵表
参考连接
https://www.cnblogs.com/mysql-dba/p/9901583.html
https://cloud.tencent.com/developer/article/1072238
https://mp.weixin.qq.com/s?__biz=MzI4NjExMDA4NQ==&mid=2648451747&idx=1&sn=5dad442397fbe9b2410c5e13fd8ade16&chksm=f3c97249c4befb5fe76379cadb9f3204c268ff0b051312f29cefc6ca3270d67a6072de522f79&scene=21#wechat_redirect