First test GH-OST (transfer)

Recently, the boss asked to do a comparative test between gh-ost and pt-osc. This article will compare the two.

one. Principles and Instructions Used

	PT-OSC	GH-OST
principle	1. Create a new empty table structure that is the same as the table to perform the alter operation (the structure before the alter) 2. Execute the alter table statement in the new table 3. Create triggers in the original table Three triggers correspond to insert, update, delete operation 4. Copy data from the original table to the temporary table with a certain block size. During the copying process, the write operation on the original table through the trigger on the original table will be updated to the new temporary table 5. Rename the original table to the old table 6. If there is a foreign key that refers to the table , according to the value of the alter-foreign-keys-method parameter, detect the table related to the foreign key, and make corresponding settings. 7. By default, the last will be delete old table	1. Create a ghost table on the changed server ( _tbname_gho like tbname) 2. Change the _tbname_gho structure to a new table structure 3. Connect to the mysql server as a mysql slave, and record the new binlog event 4. Alternate execution: apply the new events To the ghost table and copy the records of the old table to the ghost table 5.table rename (ghost table replaces the old table) There are 2 common usages: 1. Connect the slave library, change the main library - the default method, the slave needs to open log-slave-update 2. Connect the main library, change the main library - must be in ROW format, with the parameter --allow-on -master"
usage restrictions	1. The original table must have a primary key or a unique index (excluding NULL) 2. There can be no triggers on the original table 3. Ensure that there is enough disk capacity before use, because copying the original table requires double the space 4. In The parameter no-version-check needs to be added to use on Ali RDS	1. The original table must have a primary key or a unique index (excluding NULL) 2. Foreign keys are not supported 3. Triggers are not supported 4. Virtual columns are not supported 5. 5.7 Point type columns are not supported 6. 5.7 JSON columns cannot be Primary key 7. There cannot be another table with the same name, but the case is different. 8. Multi-source replication is not supported. 9. MM double write is not supported. 10. FEDERATED engine is not supported.
Important parameter description	--max-load, the default threads_running=25, you can specify multiple indicators to limit the speed, each chunk will be checked after copying, and the replication will be suspended if the threshold is exceeded. If this parameter is not specified, the tool will check the current running value and increase it by 20% --critical-load, the default is threads_running=50, if not specified, the tool will check the current running value and exit the tool when it runs to 200% -- max-lag, the default is 1s, if the delay is found to be greater than this value, data replication will be suspended. --check-interval, used with max-lag, check how long the tool sleeps after the slave library exceeds the delay --recursion-method, specify the discovery mechanism of the slave library, processlist, dsn, none, etc. --chunk-time, default 0.5 seconds, in order to ensure that a chunk is copied within 0.5 seconds when copying data rows, dynamically adjust the size of the next chunk-size --[no]check-replication-filters, if the tool checks that there are any replication-related items in the server options Filter, the tool will report an error and exit, the default is yes --chunk-size, specify the block size, the default is 1000 lines.	--max-load=Threads_running=25 Indicates that if Threads_running=25 occurs during the execution of gh-ost, the execution of gh-ost will be suspended --critical-load=Threads_running=60 Indicates that Threads_running reaches 60 during the execution process and terminates gh -ost execution --chunk-size=1000 Set the number of rows copied from the original table to the ghost table each time --ok-to-drop-table delete the original table after execution --allow-on-master Connect directly to the main database implement
advantage	1.执行速度快，业界使用比较广泛，较稳定	1.读binlog可以放在从库执行，减少主库的压力 2.不需要创建触发器，对原表没有改动
风险点	1.需要创建触发器，对原表有改动 2.涉及主键的更改需要review	1.当系统负载极高时，gh-ost有可能无法跟上binlog日志的处理（未测试过该场景） 2.限制比较多，见上文 3.涉及主键的更改需要review
运行命令实例	pt-online-schema-change --user=db_monitor --password=xxx --host=127.0.0.1 --port=xxx --alter "add COLUMN c2 varchar (120) not null default ''" D=sbtest,t=sbtest1 --no-check-replication-filters --alter-foreign-keys-method=auto --recursion-method=none --print --execute	./gh-ost --assume-master-host=ip:port --master-user=db_monitor --master-password=xxx --user=db_monitor --password=yyy --host=10.xxx --port=port --alter="ADD COLUMN c2 varchar(120)" --database=sbtest --table="sbtest1" -execute --initially-drop-old-table --initially-drop-socket-file --initially-drop-ghost-table

二，性能测试对比

1. 测试场景

16core CPU，2G buffer pool的测试实例，5.5的MySQL版本异步主从，2kw行记录，4.8GB 测试表大小

2. 测试结果（不限速），复制延时用zabbix 监控seconds behind master 的值

3. 结果展示

三，最后说一下GH-OST的 cut over

gh-ost利用了MySQL的一个特性，就是原子性的rename请求，在所有被blocked的请求中，优先级永远是最高的。
gh-ost基于此设计了该方案：一个连接对原表加锁，另启一个连接尝试rename操作，此时会被阻塞住，当释放lock的时候，rename会首先被执行，其他被阻塞的请求会继续应用到新表。

参考资料：

https://github.com/github/gh-ost

https://m.aliyun.com/yunqi/articles/62928

http://www.tabdba.com/?p=175

Do not go gentle into that good night~

最近老板让做一个gh-ost和pt-osc 的对比测试，本文将对两者做对比。

一。原理和所用说明

	PT-OSC	GH-OST
原理	1.创建一个和要执行 alter 操作的表一样的新的空表结构(是alter之前的结构) 2.在新表执行alter table 语句 3.在原表中创建触发器3个触发器分别对应insert,update,delete操作 4.以一定块大小从原表拷贝数据到临时表，拷贝过程中通过原表上的触发器在原表进行的写操作都会更新到新建的临时表 5.Rename 原表到old表中，在把临时表Rename为原表 6.如果有参考该表的外键，根据alter-foreign-keys-method参数的值，检测外键相关的表，做相应设置的处理 7.默认最后将旧原表删除	1.在变更的服务器上创建 ghost table( _tbname_gho like tbname) 2.更改 _tbname_gho 结构为新表结构 3.作为mysql的slave连接mysql server，并记录新增binlog event 4.交替执行: 应用新增events到 ghost table 和复制老表的记录到 ghost table 5.table重命名(ghost table 替代老表) 其中有2种常用用法： 1.连接从库，变更主库 - 默认方式，slave需要开启log-slave-update 2.连接主库，变更主库 - 必须ROW格式，带上参数--allow-on-master"
使用限制	1.原表必须要有主键或者唯一索引（不含NULL） 2.原表上不能有触发器存在 3.使用前需保证有足够的磁盘容量，因为复制原表需要一倍的空间 4.在阿里RDS 上使用需要增加参数no-version-check	1.原表必须要有主键或者唯一索引（不含NULL） 2.不支持外键 3.不支持触发器 4.不支持虚拟列 5.不支持 5.7 point类型的列 6. 5.7 JSON列不能是主键 7.不能存在另外一个table名字一样，只是大小写有区别 8.不支持多源复制 9.不支持M-M 双写 10.不支持FEDERATED engine
重要参数说明	--max-load，默认threads_running=25,可以指定多个指标来限速,每个chunk拷贝完会检查，超过阀值会暂停复制。如果不指定该参数，工具会检查当前运行值并增加20% --critical-load,默认为threads_running=50,如果不指定，则工具检查当前运行值并当运行到200%是退出工具运行 --max-lag，默认1s，如果发现延迟大于该值，则暂停复制数据。 --check-interval,配合max-lag使用，检查从库超过延时后，该工具睡眠多久 --recursion-method，指定从库的发现机制,processlist,dsn,none 等 --chunk-time,默认0.5秒，拷贝数据行的时候为了保证0.5秒内拷贝完一个chunk，动态调整下一次chunk-size的大小 --[no]check-replication-filters，如果工具检查到服务器选项中有任何复制相关的筛选，工具会报错退出，默认为yes --chunk-size，指定块大小，默认1000行。	--max-load=Threads_running=25 表面如果在执行gh-ost的过程中出现Threads_running=25则暂停gh-ost的执行 --critical-load=Threads_running=60 表明执行过程中出现Threads_running达到60则终止gh-ost的执行 --chunk-size=1000 设置每次从原表copy到 ghost table的行数 --ok-to-drop-table 执行完之后删除原表 --allow-on-master 直连主库执行
优点	1.执行速度快，业界使用比较广泛，较稳定	1.读binlog可以放在从库执行，减少主库的压力 2.不需要创建触发器，对原表没有改动
风险点	1.需要创建触发器，对原表有改动 2.涉及主键的更改需要review	1.当系统负载极高时，gh-ost有可能无法跟上binlog日志的处理（未测试过该场景） 2.限制比较多，见上文 3.涉及主键的更改需要review
运行命令实例	pt-online-schema-change --user=db_monitor --password=xxx --host=127.0.0.1 --port=xxx --alter "add COLUMN c2 varchar (120) not null default ''" D=sbtest,t=sbtest1 --no-check-replication-filters --alter-foreign-keys-method=auto --recursion-method=none --print --execute	./gh-ost --assume-master-host=ip:port --master-user=db_monitor --master-password=xxx --user=db_monitor --password=yyy --host=10.xxx --port=port --alter="ADD COLUMN c2 varchar(120)" --database=sbtest --table="sbtest1" -execute --initially-drop-old-table --initially-drop-socket-file --initially-drop-ghost-table