• 欢迎访问DBA的辛酸事儿,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站
  • 欢迎大家关注博主公众号:DBA的辛酸事儿
  • 博文中若有错误的地方,请大家指正,大家的指正是我前进的动力

Online DDL 工具 gh-ost实战(一)

MySQL SEian.G 5年前 (2019-12-12) 3043次浏览 已收录 0个评论
文章目录[隐藏]

一、安装步骤

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/go
export GOPATH=/data/work/gopath
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

2、安装gh-osh

下载二进制安装包:https://github.com/github/gh-ost/releases

Online DDL 工具 gh-ost实战(一)

[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.log

2、输出日志分析

GH-OST会输出一些关键详细信息,让你了解整个迁移过程。当然,你可以控制输出级别。

–verbose:常用,有用的输出,而不是一切。

–debug:输出所有一切。

日志信息如下:

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相对自我解释,他们大多表示一切顺利。你将主要关注迁移并了解其是否顺利进行。一旦迁移实际开始,你将看到如下输出。

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文件位置

状态提示

每隔一定时间会打印友好提示:

# 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.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 模式,否则会有如下报错:

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

https://mp.weixin.qq.com/s?__biz=MzI4NjExMDA4NQ==&mid=2648451747&idx=1&sn=5dad442397fbe9b2410c5e13fd8ade16&chksm=f3c97249c4befb5fe76379cadb9f3204c268ff0b051312f29cefc6ca3270d67a6072de522f79&scene=21#wechat_redirect

Online DDL 工具 gh-ost实战(一)


如果您觉得本站对你有帮助,那么可以收藏和推荐本站,帮助本站更好地发展,在此谢过各位网友的支持。
转载请注明原文链接:Online DDL 工具 gh-ost实战(一)
喜欢 (6)
SEian.G
关于作者:
用心去记录工作,用心去感受生活,用心去学着成长;座右铭:苦练七十二变,笑对八十一难
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址