MySQL大表DDL工具gh-ost

最新推荐文章于 2023-12-25 12:58:48 发布
最新推荐文章于 2023-12-25 12:58:48 发布
阅读量1.1k 收藏 4
点赞数 2
分类专栏： 数据库 文章标签： 1024程序员节 mysql gh-ost DDL
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/oschina_41731918/article/details/120816598
版权

一、背景

丁奇大佬推荐的一个在线DDL工具，使用Go语言编写。gh-ost是一款无需添加触发器、可测试、可暂停、动态控制（再配置）、可审计的MySQL结构在线迁移工具。gh-ost github地址

二、原理详解

2.1 架构模式

三种工作模式

a 连接从库，在主库做迁移（默认）

  • 在主库上读写，创建_xxx_gho（目标表）、_xxx_ghc（记录 gh-ost 执行过程的表）。
  • 从库上读取二进制日志事件，将变更应用到主库上的_xxx_gho表；
  • 在主库上读源表的数据写入_xxx_gho表中:insert into igore…select；
  • 在主库上完成表切换；

b 在主库修改

  • 在主库上读写，创建_xxx_gho、_xxx_ghc。
  • 主库上读取二进制日志事件，将变更应用到主库上的_xxx_gho表；
  • 在主库上读源表的数据写入_xxx_gho表中:insert into igore…select；
  • 在主库上完成表切换；

c 在从库做迁移

  • 这种模式会在从库上做修改。gh-ost仍然会连上主库，但所有操作都是在从库上做的，不会对主库产生任何影响。

2.2 执行过程

gh-ost执行过程
图片来自于茁壮的小草

2.2 CentOS上安装

# 下载Github上的最新版本二进制包
wget https://github.com/github/gh-ost/releases/download/v1.1.2/gh-ost-binary-linux-20210617134741.tar.gz

# 解压
tar -zxvf gh-ost-binary-linux-20210617134741.tar.gz 

# 为方便后续操作，将其拷贝到系统的可执行目录
cp gh-ost /usr/local/bin/

# 校验安装成果
gh-ost -h

2.3选项说明

选项说明
-user stringMySQL用户
-password stringMySQL密码
-host stringMySQL连接地址
-database string指定数据库名（强制）
-port intMySQL端口
-table string指定表名（强制）
-aliyun-rdstrue； 是否再阿里云的RDS上执行
-allow-master-master是否在双主架构上使用，一般与-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 rename语义是否正确 。默认不会执行，加上此选项才可以
-ask-pass提示输入MySQL密码
-assume-master-host string为gh-ost指定一个主库，格式为”ip:port”或者”hostname:port”。
-assume-rbr确认gh-ost连接的数据库实例的binlog_format=ROW的情况下，可以指定-assume-rbr，这样可以禁止从库上运行stop slave,start slave,执行gh-ost用户也不需要SUPER权限。
-check-flag检验其他标志
-chunk-size int1000；在每次迭代中处理的行数量(允许范围：100-100000)
-concurrent-rowcount该参数如果为True(默认值)，则进行row-copy之后，估算统计行数(使用explain select count(*)方式)，并调整ETA时间，否则，gh-ost首先预估统计行数，然后开始row-copy
-conf stringgh-ost支持将操作指令存储于文件，并通过此选项加载。类似于awk -f
-critical-load string一系列逗号分隔的status-name=values组成，当MySQL中status超过对应的values，gh-ost将会退出
-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的失败尝试之间等待的时间间隔呈指数级增长，最大等待exponential-backoff-max-interval的值
-exponential-backoff-max-interval int64；进行指数回退尝试的时候，最大的秒数
-cut-over-lock-timeout-seconds int3；尝试cut-over过程中持有表锁的最大时间（s）
-debug开启debug模式
-default-retries int60；异常之后默认的重试次数
-discard-foreign-keys丢弃表的外键（危险）
-dml-batch-size int10；单个事务批处理事件数（1-100）
-exact-rowcount真实计算表行数，会使得估算结果更加精准
-executegh-ost默认仅仅时做一些测试就退出了，可以用此选项执行真正的DDL操作
-force-named-cut-over如果为true，则’unpostpone
-force-named-panic如果为true，‘panic’ 交互式命令必须命名迁移的表
-force-table-names string临时表的前缀
-heartbeat-interval-millis int100； gh-ost心跳频率值，默认为500
-hooks-hint string任意消息通过 GH_OST_HOOKS_HINT 注入到钩子
-hooks-hint-owner string任意用户通过 GH_OST_HOOKS_HINT_OWNER 注入到钩子
-hooks-hint-token string任意token通过 GH_OST_HOOKS_HINT_TOKEN 注入到钩子
-hooks-path stringhook文件存放目录(默认为empty，即禁用hook)
-ignore-http-errors限流检测的时候忽略http错误
-initially-drop-ghost-tablegh-ost操作之前，检查并删除已经存在的ghost表。该参数不建议使用，请手动处理原来存在的ghost表。默认不启用该参数，gh-ost直接退出操作。
-initially-drop-old-table:gh-ost操作之前，检查并删除已经存在的旧表。该参数不建议使用，请手动处理原来存在的ghost表。默认不启用该参数，gh-ost直接退出操作。
-initially-drop-socket-filegh-ost强制删除已经存在的socket文件。该参数不建议使用，可能会删除一个正在运行的gh-ost程序，导致DDL失败。
-master-password stringMySQL主库 密码
-master-user stringMySQL主库 用户
-max-lag-millis int1500s；主从复制最大延迟时间，当主从复制延迟时间超过该值后，gh-ost将采取节流(throttle)措施。
-max-load string逗号分隔状态名称=阈值，如：‘Threads_running=100,Threads_connected=500’
-migrate-on-replicagh-ost的数据迁移(migrate)运行在从库上，而不是主库上。
-mysql-timeout float连接、读写的超时时间
-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-tablegh-ost操作结束后，删除旧表，默认状态是不删除旧表，会存在_tablename_del表。
-panic-flag-file string当文件被创建，gh-ost将会立即退出。
-postpone-cut-over-flag-file string当这个文件存在的时候，gh-ost的cut-over阶段将会被无限推迟，数据仍然在复制，直到该文件被删除。用来控制是否进行rename操作
–quiet静默模式
-replica-server-id uintgh-ost的server_id
-serve-socket-file stringgh-ost的socket文件绝对路径
-serve-tcp-port int默认disabled； 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添加错误堆栈追踪。
-skip-strict-mode忽略SQL严格模式
-ssl开启SSL连接MySQL
-ssl-allow-insecure忽略MySQL 证书链验证，要开启–ssl
-ssl-ca stringCA 证书 ，要开启–ssl
-ssl-cert证书，要开启–ssl
-ssl-key string证书密钥，要开启–ssl
-switch-to-rbr让gh-ost自动将从库的binlog_format转换为ROW格式。
-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默认"/tmp/gh-ost.throttle"；当该文件被创建后，gh-ost操作立即停止。该参数可以用在多个gh-ost同时操作的时候，创建一个文件，让所有的gh-ost操作停止，或者删除这个文件，让所有的gh-ost操作恢复。
-throttle-control-replicas string列出所有需要被检查主从复制延迟的从库，如：myhost1.com:3306,myhost2.com,myhost3.com:3307
-throttle-flag-file string当该文件被创建后，gh-ost操作立即停止。该参数适合控制单个gh-ost操作。-throttle-additional-flag-file string适合控制多个gh-ost操作。
-throttle-http string当给定URL之后，gh-ost会对其发出HEAD请求，响应码为200则会触发限流。确保该地址低延时
-throttle-query string给定查询语句之后会发送给数据库，再根据其结果，若返回0侧不限流，返回值大于0则触发限流。须确保语句足够轻巧，一面造成数据库压力

三、实践

3.1 数据模型

源表

CREATE TABLE `cms_test_ghost` (
  `id` int(10) NOT NULL AUTO_INCREMENT COMMENT "ID",
  `createtime` int(10) NOT NULL DEFAULT 0 COMMENT "createtime",
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='gh-ost test';

存储过程生成数据

# 生成模拟数据，入参n是多少就插入多少条数据
DELIMITER $$
CREATE PROCEDURE `idata`(IN n int)
 BEGIN
 DECLARE i INT DEFAULT 1;
 WHILE (i <= n) DO
  INSERT INTO cms_test_ghost(createtime) VALUES (unix_timestamp(now()));
  SET i = i + 1;
 END WHILE;
END $$
DELIMITER ;

# 调用存储过程
CALL idata(500000);

查看数据

mysql> desc cms_test_ghost;     
+------------+---------+------+-----+---------+----------------+
| Field      | Type    | Null | Key | Default | Extra          |
+------------+---------+------+-----+---------+----------------+
| id         | int(10) | NO   | PRI | NULL    | auto_increment |
| createtime | int(10) | NO   |     | 0       |                |
+------------+---------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> select * from cms_test_ghost limit 10;
+----+------------+
| id | createtime |
+----+------------+
|  1 | 1634559148 |
|  2 | 1634559148 |
|  3 | 1634559148 |
|  4 | 1634559148 |
|  5 | 1634559148 |
|  6 | 1634559148 |
|  7 | 1634559148 |
|  8 | 1634559148 |
|  9 | 1634559148 |
| 10 | 1634559148 |
+----+------------+
10 rows in set (0.00 sec)

3.2 工具运用


gh-ost \
--allow-on-master \
--max-load=Threads_running=20 \
--critical-load=Threads_running=50 \
--critical-load-interval-millis=5000 \
--chunk-size=1000 \
--user="root" \
--password="Lfc123654" \
--host='127.0.0.1' \
--port=3306 \
--database="mall" \
--table="cms_test_ghost" \
--verbose \
--alter="ALTER TABLE cms_test_ghost MODIFY COLUMN id bigint(20) UNSIGNED NOT NULL DEFAULT 0 COMMENT 'ID';" \
--assume-rbr \
--cut-over=default \
--cut-over-lock-timeout-seconds=1 \
--dml-batch-size=10 \
--allow-on-master \
--concurrent-rowcount \
--heartbeat-interval-millis=2000 \
--panic-flag-file=/tmp/ghost.panic.flag \
--postpone-cut-over-flag-file=/tmp/ghost.postpone.flag \
--execute

执行过程

2021-10-24 23:09:38 INFO starting gh-ost 1.1.2
2021-10-24 23:09:38 INFO Migrating `mall`.`cms_test_ghost`
2021-10-24 23:09:38 INFO inspector connection validated on 127.0.0.1:3306
2021-10-24 23:09:38 INFO User has ALL privileges
2021-10-24 23:09:38 INFO binary logs validated on 127.0.0.1:3306
2021-10-24 23:09:38 INFO Inspector initiated on Reseach:3306, version 5.7.35-log
2021-10-24 23:09:39 INFO Table found. Engine=InnoDB
2021-10-24 23:09:39 INFO Estimated number of rows via EXPLAIN: 499592
2021-10-24 23:09:39 INFO Recursively searching for replication master
2021-10-24 23:09:39 INFO Master found to be Reseach:3306
2021-10-24 23:09:39 WARNING log_slave_updates not found on 127.0.0.1:3306, but executing directly on master, so I'm proceeding
2021-10-24 23:09:39 INFO streamer connection validated on 127.0.0.1:3306
2021-10-24 23:09:39 INFO Connecting binlog streamer at mysql-bin.000002:171451370
[2021/10/24 23:09:39] [info] binlogsyncer.go:133 create BinlogSyncer with config {99999 mysql 127.0.0.1 3306 root    false false <nil> false UTC true 0 0s 0s 0 false}
[2021/10/24 23:09:39] [info] binlogsyncer.go:354 begin to sync binlog from position (mysql-bin.000002, 171451370)
[2021/10/24 23:09:39] [info] binlogsyncer.go:203 register slave for master server 127.0.0.1:3306
2021-10-24 23:09:39 INFO rotate to next log from mysql-bin.000002:0 to mysql-bin.000002
[2021/10/24 23:09:39] [info] binlogsyncer.go:723 rotate to (mysql-bin.000002, 171451370)
2021-10-24 23:09:39 INFO applier connection validated on 127.0.0.1:3306
2021-10-24 23:09:39 INFO applier connection validated on 127.0.0.1:3306
2021-10-24 23:09:39 INFO will use time_zone='SYSTEM' on applier
2021-10-24 23:09:39 INFO Examining table structure on applier
2021-10-24 23:09:39 INFO Applier initiated on Reseach:3306, version 5.7.35-log
2021-10-24 23:09:39 INFO Dropping table `mall`.`_cms_test_ghost_ghc`
2021-10-24 23:09:39 INFO Table dropped
# 创建_ghc表，记录执行过程
2021-10-24 23:09:39 INFO Creating changelog table `mall`.`_cms_test_ghost_ghc`
2021-10-24 23:09:39 INFO Changelog table created
# 创建_gho表，作为目标表（改了表结构后的表）
2021-10-24 23:09:39 INFO Creating ghost table `mall`.`_cms_test_ghost_gho`
2021-10-24 23:09:39 INFO Ghost table created
2021-10-24 23:09:39 INFO Altering ghost table `mall`.`_cms_test_ghost_gho`
2021-10-24 23:09:39 INFO Ghost table altered
2021-10-24 23:09:39 INFO Altering ghost table AUTO_INCREMENT value `mall`.`_cms_test_ghost_gho`
2021-10-24 23:09:39 INFO Ghost table AUTO_INCREMENT altered
2021-10-24 23:09:39 INFO Intercepted changelog state GhostTableMigrated
2021-10-24 23:09:39 INFO Created postpone-cut-over-flag-file: /tmp/ghost.postpone.flag
2021-10-24 23:09:39 INFO Waiting for ghost table to be migrated. Current lag is 0s
2021-10-24 23:09:39 INFO Handled changelog state GhostTableMigrated
2021-10-24 23:09:39 INFO Chosen shared unique key is PRIMARY
2021-10-24 23:09:39 INFO Shared columns are id,createtime
2021-10-24 23:09:39 INFO Listening on unix socket file: /tmp/gh-ost.mall.cms_test_ghost.sock
2021-10-24 23:09:39 INFO Migration min values: [1]
2021-10-24 23:09:39 INFO Migration max values: [500000]
2021-10-24 23:09:39 INFO Waiting for first throttle metrics to be collected
2021-10-24 23:09:39 INFO First throttle metrics collected
# Migrating `mall`.`cms_test_ghost`; Ghost table is `mall`.`_cms_test_ghost_gho`
# Migrating Reseach:3306; inspecting Reseach:3306; executing on Reseach
# Migration started at Sun Oct 24 23:09:38 +0800 2021
# 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.mall.cms_test_ghost.sock
Copy: 0/499592 0.0%; Applied: 0; Backlog: 0/1000; Time: 0s(total), 0s(copy); streamer: mysql-bin.000002:171453750; Lag: 0.01s, HeartbeatLag: 0.01s, State: migrating; ETA: N/A
Copy: 0/499592 0.0%; Applied: 0; Backlog: 0/1000; Time: 1s(total), 1s(copy); streamer: mysql-bin.000002:171455034; Lag: 1.01s, HeartbeatLag: 0.00s, State: migrating; ETA: N/A
Copy: 134000/499592 26.8%; Applied: 0; Backlog: 0/1000; Time: 2s(total), 2s(copy); streamer: mysql-bin.000002:173237838; Lag: 1.00s, HeartbeatLag: 1.00s, State: migrating; ETA: 5s
Copy: 279000/499592 55.8%; Applied: 0; Backlog: 0/1000; Time: 3s(total), 3s(copy); streamer: mysql-bin.000002:175167826; Lag: 1.00s, HeartbeatLag: 0.00s, State: migrating; ETA: 2s
Copy: 417000/499592 83.5%; Applied: 0; Backlog: 0/1000; Time: 4s(total), 4s(copy); streamer: mysql-bin.000002:176990571; Lag: 1.00s, HeartbeatLag: 1.00s, State: migrating; ETA: due
# 行数据已经复制完成，接下来时监听binlog的变化并应用，如果有binlog写操作，则"Applied"后面的值不为0。
2021-10-24 23:09:43 INFO Row copy complete
Copy: 500000/500000 100.0%; Applied: 0; Backlog: 0/1000; Time: 4s(total), 4s(copy); streamer: mysql-bin.000002:178103874; Lag: 1.00s, HeartbeatLag: 0.58s, State: migrating; ETA: due
Copy: 500000/500000 100.0%; Applied: 0; Backlog: 0/1000; Time: 5s(total), 4s(copy); streamer: mysql-bin.000002:178109672; Lag: 1.00s, HeartbeatLag: 0.00s, State: postponing cut-over; ETA: due
Copy: 500000/500000 100.0%; Applied: 0; Backlog: 0/1000; Time: 6s(total), 4s(copy); streamer: mysql-bin.000002:178110594; Lag: 1.00s, HeartbeatLag: 0.00s, State: postponing cut-over; ETA: due
以上输出部分字段说明
Copy拷贝源表中的数据的完成行数（百分比）
Applied在这个处理的时间段内，通过binlog重放到影子表的事件数。
Backlog用来衡量，处理的队列里边是否有事件堆积。0/100运行良好，100/100过载。
streamergh-ost正在处理的binlog文件

要进行cut-over，则需要删除 rm /tmp/ghost.postpone.flag

......
Copy: 500000/500000 100.0%; Applied: 0; Backlog: 0/1000; Time: 43s(total), 4s(copy); streamer: mysql-bin.000002:178145114; Lag: 1.00s, HeartbeatLag: 0.00s, State: postponing cut-over; ETA: due
2021-10-24 23:10:22 INFO Grabbing voluntary lock: gh-ost.6072.lock
2021-10-24 23:10:22 INFO Setting LOCK timeout as 2 seconds
2021-10-24 23:10:22 INFO Looking for magic cut-over table
2021-10-24 23:10:22 INFO Creating magic cut-over table `mall`.`_cms_test_ghost_del`
2021-10-24 23:10:22 INFO Magic cut-over table created
2021-10-24 23:10:22 INFO Locking `mall`.`cms_test_ghost`, `mall`.`_cms_test_ghost_del`
2021-10-24 23:10:22 INFO Tables locked
2021-10-24 23:10:22 INFO Session locking original & magic tables is 6072
2021-10-24 23:10:22 INFO Writing changelog state: AllEventsUpToLockProcessed:1635088222708249439
2021-10-24 23:10:22 INFO Intercepted changelog state AllEventsUpToLockProcessed
2021-10-24 23:10:22 INFO Handled changelog state AllEventsUpToLockProcessed
2021-10-24 23:10:22 INFO Waiting for events up to lock
Copy: 500000/500000 100.0%; Applied: 0; Backlog: 1/1000; Time: 44s(total), 4s(copy); streamer: mysql-bin.000002:178146676; Lag: 1.00s, HeartbeatLag: 1.00s, State: migrating; ETA: due
2021-10-24 23:10:23 INFO Waiting for events up to lock: got AllEventsUpToLockProcessed:1635088222708249439
2021-10-24 23:10:23 INFO Done waiting for events up to lock; duration=982.377851ms
# Migrating `mall`.`cms_test_ghost`; Ghost table is `mall`.`_cms_test_ghost_gho`
# Migrating Reseach:3306; inspecting Reseach:3306; executing on Reseach
# Migration started at Sun Oct 24 23:09:38 +0800 2021
# 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 
# panic-flag-file: /tmp/ghost.panic.flag
# Serving on unix socket: /tmp/gh-ost.mall.cms_test_ghost.sock
Copy: 500000/500000 100.0%; Applied: 0; Backlog: 0/1000; Time: 44s(total), 4s(copy); streamer: mysql-bin.000002:178147589; Lag: 1.00s, HeartbeatLag: 0.61s, State: migrating; ETA: due
2021-10-24 23:10:23 INFO Setting RENAME timeout as 1 seconds
2021-10-24 23:10:23 INFO Session renaming tables is 6077
2021-10-24 23:10:23 INFO Issuing and expecting this to block: rename /* gh-ost */ table `mall`.`cms_test_ghost` to `mall`.`_cms_test_ghost_del`, `mall`.`_cms_test_ghost_gho` to `mall`.`cms_test_ghost`
2021-10-24 23:10:23 INFO Found atomic RENAME to be blocking, as expected. Double checking the lock is still in place (though I don't strictly have to)
2021-10-24 23:10:23 INFO Checking session lock: gh-ost.6072.lock
2021-10-24 23:10:23 INFO Connection holding lock on original table still exists
2021-10-24 23:10:23 INFO Will now proceed to drop magic table and unlock tables
2021-10-24 23:10:23 INFO Dropping magic cut-over table
2021-10-24 23:10:23 INFO Releasing lock from `mall`.`cms_test_ghost`, `mall`.`_cms_test_ghost_del`
2021-10-24 23:10:23 INFO Tables unlocked
2021-10-24 23:10:23 INFO Tables renamed
2021-10-24 23:10:23 INFO Lock & rename duration: 1.008945264s. During this time, queries on `cms_test_ghost` were blocked
[2021/10/24 23:10:23] [info] binlogsyncer.go:164 syncer is closing...
[2021/10/24 23:10:23] [error] binlogsyncer.go:631 connection was bad
[2021/10/24 23:10:23] [error] binlogstreamer.go:77 close sync with err: Sync was closed
2021-10-24 23:10:23 INFO Closed streamer connection. err=<nil>
2021-10-24 23:10:23 INFO Dropping table `mall`.`_cms_test_ghost_ghc`
[2021/10/24 23:10:23] [info] binlogsyncer.go:179 syncer is closed
2021-10-24 23:10:23 INFO Table dropped
2021-10-24 23:10:23 INFO Am not dropping old table because I want this operation to be as live as possible. If you insist I should do it, please add `--ok-to-drop-table` next time. But I prefer you do not. To drop the old table, issue:
2021-10-24 23:10:23 INFO -- drop table `mall`.`_cms_test_ghost_del`
2021-10-24 23:10:23 INFO Done migrating `mall`.`cms_test_ghost`
2021-10-24 23:10:23 INFO Removing socket file: /tmp/gh-ost.mall.cms_test_ghost.sock
2021-10-24 23:10:23 INFO Tearing down inspector
2021-10-24 23:10:23 INFO Tearing down applier
2021-10-24 23:10:23 INFO Tearing down streamer
2021-10-24 23:10:23 INFO Tearing down throttler
# Done

暂停

#暂停
echo throttle | socat - gh-ost.mall.cms_test_ghost.sock
#恢复
echo no-throttle | socat - gh-ost.mall.cms_test_ghost.sock

修改限速

echo chunk-size=100 | socat - gh-ost.mall.cms_test_ghost.sock

echo max-lag-millis=200 | socat - gh-ost.mall.cms_test_ghost.sock

echo max-load=Thread_running=3 | socat - gh-ost.mall.cms_test_ghost.sock

四、总结

在日常的业务开发过程中，难免需要针对大数据量的表做字段的更改操作。为避免在源表上DDL导致的锁表，暂停业务。我们可以通过新建影子表并拷贝数据，最终切换表名的思路，做到平滑过渡，而gh-ost正是非常符合此场景的工具。

参考文章：

  1. gh-ost原理
  2. 爱可生数据库
  3. jyzhou
凡尘技术
关注
  • 2
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
MySQL在线大表DDL操作 （转）
weixin_34123613的博客
08-31 154
http://www.cnblogs.com/janehoo/p/5382474.html 线大表DDL操作的方法： 1、主从架构轮询修改 需要注意：　　 　　a、主库会话级别的记录binglog的参数关闭 　　b、500\502错误异常捕捉 　　c、检查备库的second behind master是否有延迟 　　d、varchar有页分裂的情况，尽量减少varchar的长度 2、在线工具onl...
mysql生产上如何进行大变ddl_MySQL在线大表DDL操作 （转）
weixin_32463071的博客
01-20 243
http://www.cnblogs.com/janehoo/p/5382474.html线大表DDL操作的方法：1、主从架构轮询修改需要注意：a、主库会话级别的记录binglog的参数关闭b、500\502错误异常捕捉c、检查备库的second behind master是否有延迟d、varchar有页分裂的情况，尽量减少varchar的长度2、在线工具online-schema-change需...
MySQL 在线模式迁移工具gh-ost用法
jkzyx123的博客
09-12 449
gh-ost 是 GitHub 开源的一款 MySQL 在线模式迁移工具。它允许你在数据库仍在运行并处理事务的同时，执行非阻塞的 ALTER TABLE 操作。
online-DDL详细原理介绍及gh-ost讲解
jiaona_chen123的博客
06-22 6475
1. MySQL online DDL 各版本介绍 1.1 online DDL in mysql 5.5 在mysql5.5版本中已经增加了in-place方式，但依然会阻塞insert,update,delete操作。 mysql 5.5 online ddl 原理： a. 按照原表的定义创建临时表； b. 对原表进行加写锁； c. 对新的临时表进行ddl操作； d. 将原表中的数据copy到临时表中； e. 释放原表的写锁； f. 将旧表删除，临时表重命名 存在的问题： a. 在进行copy da
【MySQL变更】gh-ost原理解读
DBA之路的博客
12-25 1351
所有现有的在线表结构变更工具都以相似的的原理：它们创建一个与原始表结构相同的幽灵表，在该表为空时进行表结构变更，缓慢并增量地将数据从原始表复制到幽灵表，同时将正在进行的更改（任何INSERT, DELETE,UPDATE应用于源表）应用到幽灵表。最后，在适当的时候，他们用幽灵表替换原表。gh-ost使用相同的模式。然而，它与所有现有工具的不同之处在于不使用触发器。因为触发器是许多限制和风险的来源。gh-ost 使用二进制日志流来捕获表数据变化，并将它们异步应用到ghost表上。
MySQL在线DDL gh-ost使用总结
09-09
MySQL在线DDL工具gh-ost是MySQL数据库中进行结构变更的一种高效、低影响的方式，它能够实现不停服地更新表的结构。这篇总结将详细介绍gh-ost的使用方法和相关知识点。 1. **gh-ost的工作原理** gh-ost通过模拟从库...
python小工具-sqlserver ddl转换为mysql规范ddl
02-14
图形化实现sqlserver转换为mysql ddl（需字段注释） 应用于数据库、新老系统迁移，提升开发效率。
sql-ddl-to-json-schema:SQL DDL到JSON模式转换器
05-17
SQL DDL至JSON模式转换器 将SQL DDL语句转换为JSON格式（JSON模式和紧凑格式）。 承诺中 了解内部 手边的脚本Visual Studio程式码 链接 概述 使用以下SQL： CREATE TABLE users ( id INT ( 11 ) NOT NULL AUTO_...
mysql 大表增加字段工具
04-11
MySQL大表增加字段是一项常见的数据库管理任务，但随着表数据量的增长，直接在表结构上进行修改可能会引发性能问题甚至导致长时间的服务中断。为了解决这个问题，Percona Toolkit提供了强大的工具，如`pt-online-...
mysql-connector-java-5.1.44-bin.jar
04-06
1. 添加依赖：将`mysql-connector-java-5.1.44-bin.jar`添加到项目的类路径中，无论是IDE如Eclipse或IntelliJ IDEA的构建路径，还是构建工具如Maven或Gradle的依赖管理。 2. 建立连接：使用`java.sql.DriverManager`...
2024最新DDL-DML-HM
03-20
2024最新DDL-DML-HM
plantuml2ddl:Intellij IDEA插件-MySQL DDL和PlantUML相互转换
05-24
PlantUML2DDL 用于Mysql DDL的Intellij IDEA插件和PlantUML转换。安装从插件市场和磁盘安装此插件定义符号象征解释例子＃ 首要的关键# ID：BIGINT（20） << pk>> 首要的关键id：bigint（20） <<pk>> * 非空*...
MySQL驱动 mysql-connector-net-6.4.3
11-26
7. 数据库对象操作：`MySqlCommand`还支持创建、修改和删除数据库对象，如表、视图、索引等，通过执行DDL（Data Definition Language）语句实现。 8. 高级功能：包括连接池、异步操作、性能优化等，提高应用程序的...
mysql代码-DDL语句测试
07-14
在MySQL中，DDL（Data Definition Language）语句是用于创建、修改或删除数据库结构的关键工具。本测试着重于理解和运用MySQL的DDL语句，包括但不限于创建表、修改表结构、删除表以及管理数据库对象。 在"main....
mysql-8.0.30-winx64 + mysql可视化查看工具.zip
最新发布
05-28
此压缩包“mysql-8.0.30-winx64 + mysql可视化查看工具.zip”包含两个主要部分，分别是MySQL服务器的Windows 64位版本和一个MySQL的可视化查看工具。 **MySQL 8.0.30 for Windows** MySQL 8.0.30是MySQL服务器的一...
gh-ost学习笔记 试验&&代码学习
qq_39570637的博客
01-07 999
gh-ost学习笔记 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-J7hhPnvg-1641550092432)(https://github.com/WQMysqlDBA/gh-ost/blob/master/doc/images/gh-ost-logo-light-160.png?raw=true)] "开始吧" gh-ost github开源的一个online ddl工具 某位业内不太知名，朋友圈内比较知名的同学，关于何时使用gh-ost，做了一个经典的描述 "
Mysql在线DDL工具
ljw714的专栏
04-14 1417
一 背景 在实际生产应用中，经常会有mysql表结构修改的场景，涉及到的表数据量大，如果直接修改，锁表时间过长，影响正常业务。因此，寻求通过在线DDL工具进行表结构修改。 这里选择了常用的2个在线DDL工具gh-ost 和pt-online-schema-change进行测试。 二 gh-ost 是github贡献的一款online DDL工具。大致原理如下 1 根据原表新建一个临时...
【MySQL运维】使用gh-ost工具实现大表在线DDL变更
weixin_42073629的博客
05-26 719
一、gh-ost介绍 作为MySQLDBA都会面临这样一个问题，就是当对大表（10G以上）进行DDL变更时会有长时间锁表问题，影响业务可持续性。目前解决这个问题的方案一个较为通用的使用Percona公司开源的pt-osc工具，还有一个就是github基于go语言开发的gh-ost。gh-ost和pt-osc类似都能对大表进行在线DDL，在表格存在高并发写的情况下由于gh-ost是模拟从库应用binlog，所以性能不如pt-osc并发操作，但是gh-ost更灵活，不依赖触发器，并能根据实际情况动态调整。 .
【MySQL】在线无锁无延迟DDL神器gh-ost
授人以鱼不如授之以渔
02-25 1244
工具简介 gh-ost是一款在线无锁的DDL神器，支持在主库，或者从库两种模式使用， 而且还可以根据系统的负载延迟来动态暂停启动DDL工作，避免主从延迟等 问题的出现。 官方地址:gh-ost官网 工作原理 gh-ost使用二进制日志流捕获表更改，并异步应用到幽灵表上，最后交换幽灵表和原表。 执行DDL的过程可分为三个阶段： 1. `校验`：是否有主键、外键、触发器；gh-ost连接的是主库还是从库，从库是否开启log_slave_updates；是否已经存在gho和del结尾的临时表等。 2. `迁移
gh-ost源码解读
07-28
感谢您的提问！对于gh-ost源码的解读，我可以给出一些基本信息。 gh-ost是一个由GitHub开发的开源工具，用于在MySQL数据库中执行在线DDL（数据定义语言）操作。它提供了一个方便的方式来进行表结构变更，而无需长时间停机或造成数据不可用。 在源码解读方面，您可以从以下几个方面进行深入学习： 1. 了解项目结构：从gh-ost的GitHub仓库中，您可以找到源代码。您可以浏览整个项目的目录结构，以及各个文件的功能和作用。 2. 阅读文档和注释：gh-ost的源码中应该包含有详细的文档和注释，这些可以帮助您理解代码的逻辑和实现细节。特别是关于核心算法和关键函数的注释，会对您的解读非常有帮助。 3. 调试和运行代码：通过在开发环境中编译和运行gh-ost的代码，您可以更深入地了解其工作原理。尝试在调试器中跟踪代码执行流程，查看变量的值和函数的调用关系，有助于对代码进行解读和理解。 4. 参考相关资料：除了源码本身，您还可以查阅与gh-ost相关的官方文档、技术博客、论坛帖子等。这些资源可能包含了开发者的解读、使用示例和常见问题等，对您理解源码会有所帮助。 需要注意的是，gh-ost是一个相对复杂的工具，源码解读可能需要一定的数据库和MySQL相关知识作为基础。如果您对MySQL的工作原理和相关技术有所了解，会更有助于您理解和解读gh-ost的源码。 希望这些信息对您有所帮助，如果您有更具体的问题，我将尽力为您解答！

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值