2020年了，开始正文前，先说几句废话，2019年公众号开始正式更文，后期由于个人问题停更了，2020年开始重新开始更文，更文目的很简单，记录自己的学习，分享给大家，就这么简单；好啦，言归正传，下面开始今天的正文了；
Online DDL 一直都是 DBA 运维时比较头疼的事，一般都会选择在业务低峰期谨慎的操作，比较常用的几个工具比如 percona pt-online-schema-change , Facebook OSC, 本质上它们都是基于触发器的，简单来讲就是通过数据库的触发器把作用在源表的操作在一个事务内同步到修改后的表中，这在业务高峰期时会极大的加重主库的负载。
下面介绍的gh-ost 是由 Github 开发的 Online DDL 工具，使用 binlog 代替触发器来做增量数据同步，这样可以降低主库的负载，异步的执行。
一、安装步骤
1、安装go环境
下载go(我的当前目录是/data/work)
代码语言：javascript复制[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设置环境变量
代码语言：javascript复制[root@wjq ~]#vim /etc/profile
添加
export GOROOT=/data/work/go
export GOPATH=/data/work/gopath
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin2、安装gh-ost
下载二进制安装包：https://github.com/github/gh-ost/releases
[root@wjq mysql]# tar zxvf gh-ost-binary-linux-20190214020851.tar.gz解压完成之后，当前目录下就会出现gh-ost的可执行文件
代码语言：javascript复制[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、常用命令
代码语言：javascript复制gh-ost
--max-load=Threads_running=20
--critical-load=Threads_running=50
--critical-load-interval-millis=5000
--chunk-size=1000
--user="root"
--password="xxxxx"
--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.log
2、输出日志分析
GH-OST会输出一些关键详细信息，让你了解整个迁移过程。当然，你可以控制输出级别。
–verbose：常用，有用的输出，而不是一切。
–debug：输出所有一切。
日志信息如下：
代码语言：javascript复制2019-12-07 22:43:58 INFO starting gh-ost 1.0.48
2019-12-07 22:43:58 INFO Migrating `wjq`.`employees`
2019-12-07 22:43:58 INFO connection validated on 127.0.0.1:3306
2019-12-07 22:43:58 INFO User has ALL privileges
2019-12-07 22:43:58 INFO binary logs validated on 127.0.0.1:3306
2019-12-07 22:43:58 INFO Inspector initiated on wjq:3306, version 5.7.19-log
2019-12-07 22:43:58 INFO Table found. Engine=InnoDB
2019-12-07 22:44:01 INFO Estimated number of rows via EXPLAIN: 299387
2019-12-07 22:44:01 INFO Recursively searching for replication master
2019-12-07 22:44:01 INFO Master found to be wjq:3306
2019-12-07 22:44:01 INFO log_slave_updates validated on 127.0.0.1:3306
2019-12-07 22:44:01 INFO connection validated on 127.0.0.1:3306
2019-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:3306
2019-12-07 22:44:01 INFO connection validated on 127.0.0.1:3306
2019-12-07 22:44:01 INFO connection validated on 127.0.0.1:3306
2019-12-07 22:44:01 INFO will use time_zone='SYSTEM' on applier
2019-12-07 22:44:01 INFO Examining table structure on applier
2019-12-07 22:44:01 INFO Applier initiated on wjq:3306, version 5.7.19-log
2019-12-07 22:44:01 INFO Dropping table `wjq`.`_employees_ghc`
2019-12-07 22:44:01 INFO Table dropped
2019-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 created
2019-12-07 22:44:01 INFO Creating ghost table `wjq`.`_employees_gho`
2019-12-07 22:44:01 INFO Ghost table created
2019-12-07 22:44:01 INFO Altering ghost table `wjq`.`_employees_gho`
2019-12-07 22:44:01 INFO Ghost table altered
2019-12-07 22:44:01 INFO Intercepted changelog state GhostTableMigrated
2019-12-07 22:44:01 INFO Created postpone-cut-over-flag-file: /tmp/ghost.postpone.flag
2019-12-07 22:44:01 INFO Waiting for ghost table to be migrated. Current lag is 0s
2019-12-07 22:44:01 INFO Handled changelog state GhostTableMigrated
2019-12-07 22:44:01 INFO Chosen shared unique key is PRIMARY
2019-12-07 22:44:01 INFO Shared columns are emp_no,birth_date,first_name,last_name,gender,hire_date,testcol1,count
2019-12-07 22:44:01 INFO Listening on unix socket file: /tmp/gh-ost.wjq.employees.sock
2019-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 collected
2019-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相对自我解释，他们大多表示一切顺利。你将主要关注迁移并了解其是否顺利进行。一旦迁移实际开始，你将看到如下输出。
代码语言：javascript复制Copy: 0/299387 0.0%; Applied: 0; Backlog: 0/1000; Time: 3s(total), 0s(copy); streamer: mysql3306.000064:8257599; State: migrating; ETA: N/A
Copy: 0/299387 0.0%; Applied: 0; Backlog: 0/1000; Time: 4s(total), 1s(copy); streamer: mysql3306.000064:8258392; State: migrating; ETA: N/A
Copy: 7000/299387 2.3%; Applied: 0; Backlog: 0/1000; Time: 5s(total), 2s(copy); streamer: mysql3306.000064:8454005; State: migrating; ETA: 1m25s
Copy: 16000/299387 5.3%; Applied: 0; Backlog: 0/1000; Time: 6s(total), 3s(copy); streamer: mysql3306.000064:8704252; State: migrating; ETA: 53s
Copy: 32000/299387 10.7%; Applied: 0; Backlog: 0/1000; Time: 7s(total), 4s(copy); streamer: mysql3306.000064:9149375; State: migrating; ETA: 33s
Copy: 48000/299387 16.0%; Applied: 0; Backlog: 0/1000; Time: 8s(total), 5s(copy); streamer: mysql3306.000064:9593805; State: migrating; ETA: 26s
Copy: 64000/299387 21.4%; Applied: 0; Backlog: 0/1000; Time: 9s(total), 6s(copy); streamer: mysql3306.000064:10038647; State: migrating; ETA: 22s
Copy: 79000/299387 26.4%; Applied: 0; Backlog: 0/1000; Time: 10s(total), 7s(copy); streamer: mysql3306.000064:10455500; State: migrating; ETA: 19s
Copy: 95000/299387 31.7%; Applied: 0; Backlog: 0/1000; Time: 11s(total), 8s(copy); streamer: mysql3306.000064:10900454; State: migrating; ETA: 17s
Copy: 113000/299387 37.7%; Applied: 0; Backlog: 0/1000; Time: 12s(total), 9s(copy); streamer: mysql3306.000064:11400683; State: migrating; ETA: 14s
Copy: 128000/299387 42.8%; Applied: 0; Backlog: 0/1000; Time: 13s(total), 10s(copy); streamer: mysql3306.000064:11817995; State: migrating; ETA: 13s
Copy: 143000/299387 47.8%; Applied: 0; Backlog: 0/1000; Time: 14s(total), 11s(copy); streamer: mysql3306.000064:12262961; State: migrating; ETA: 12s
Copy: 157000/299387 52.4%; Applied: 0; Backlog: 0/1000; Time: 15s(total), 12s(copy); streamer: mysql3306.000064:12624284; State: migrating; ETA: 10s
Copy: 174000/299387 58.1%; Applied: 0; Backlog: 0/1000; Time: 16s(total), 13s(copy); streamer: mysql3306.000064:13096505; State: migrating; ETA: 9s
Copy: 189000/299387 63.1%; Applied: 0; Backlog: 0/1000; Time: 17s(total), 14s(copy); streamer: mysql3306.000064:13513590; State: migrating; ETA: 8s
Copy: 204000/299387 68.1%; Applied: 0; Backlog: 0/1000; Time: 18s(total), 15s(copy); streamer: mysql3306.000064:13931136; State: migrating; ETA: 7s
Copy: 214000/299387 71.5%; Applied: 0; Backlog: 0/1000; Time: 19s(total), 16s(copy); streamer: mysql3306.000064:14209235; State: migrating; ETA: 6s
Copy: 229000/299387 76.5%; Applied: 0; Backlog: 0/1000; Time: 20s(total), 17s(copy); streamer: mysql3306.000064:14626242; State: migrating; ETA: 5s
Copy: 246000/299387 82.2%; Applied: 0; Backlog: 0/1000; Time: 21s(total), 18s(copy); streamer: mysql3306.000064:15098735; State: migrating; ETA: 3s
Copy: 259000/299387 86.5%; Applied: 0; Backlog: 0/1000; Time: 22s(total), 19s(copy); streamer: mysql3306.000064:15460181; State: migrating; ETA: 2s
Copy: 277000/299387 92.5%; Applied: 0; Backlog: 0/1000; Time: 23s(total), 20s(copy); streamer: mysql3306.000064:15960640; State: migrating; ETA: 1s
Copy: 292000/299387 97.5%; Applied: 0; Backlog: 0/1000; Time: 24s(total), 21s(copy); streamer: mysql3306.000064:16377900; State: migrating; ETA: 0s
2019-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文件位置
状态提示
每隔一定时间会打印友好提示：
代码语言：javascript复制# 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、常用命令
代码语言：javascript复制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="xxxxx"
--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
四、测试模式
代码语言：javascript复制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="xxxxx"
--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线程。
代码语言：javascript复制#暂停
[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.sock
echo max-lag-millis=100 | socat - /tmp/gh-ost.wjq.employees.sock
echo max-load=Thread_running=23 | socat - /tmp/gh-ost.wjq.employees.sock
六、使用过程中遇到的问题记录
问题 1、对于主从结构 DB 集群，Binlog 日志格式必须是 ROW 模式，否则会有如下报错：
2019-12-07 22:44:01 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 虽然不再依赖触发器，但是依然不支持有触发器关联的表，如果修改有触发器关联的表，则会有如下提示：
2019-12-07 22:44:01 ERROR Found triggers on ndb.net_device_parts. Triggers are not supported at this time. Bailing out
问题 3、修改对象表不能被外键关联，否则如下报错：
2019-12-07 22:44:01 FATAL 2019-12-07 22:44:01 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参数
示例说明
上面是一个简单的案例，下面我们就来看一下在执行过程中产生的两张中间表：
代码语言：javascript复制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_ghcG;
*************************** 1. row ***************************
Table: _employees_ghc
Create 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=utf8mb4
1 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
