gh-ost

简介:

1. gh-ost工作模式

gh-ost有三种工作模式:

a:

连接到从库,在主库做迁移。

b:

连接到主库,迁移过程所有操作都在主上操作,包括读取binlog等等。

c:

在从库做迁移测试。



三种方法各有优缺点,先说a的缺点,a会在从上面读取binlog,但数据库主从数据为什么会造成不一致,一个很重要的原因是主库的binlog没有完全在从库执行。

所以感觉a方法有丢失数据的风险。b方法任何操作都会再主库操作,或多或少会对主库负载造成影响,但是可以通过调整一些参数降低和时刻关注这些影响.

至于c方法是偏向测试用的,这里不做过多介绍,但是c方法里有一个细节,cut-over阶段有会stop slave一个操作,其实这个操作风险特别高,

有时stop slave 时间会很长,务必会对线上数据库使用造成影响,所以如果使用c方法做测试也要在线下数据库。



2.参数介绍。

gh-ost参数很多,但我使用到的有限,这里只对使用到的参数进行介绍,再强调一下,这里测试的是b方法。

 

--max-load

迁移过程中,gh-ost会时刻关注负载情况,负载阀值是使用者自己定义,比如数据库的最大连接数,如果超过阀值,gh-ost不会退出,会等待到负载在阀值以下继续执行。

 --critical-load

这个指的是gh-ost退出阀值,当负载超过这个阀值,gh-ost会停止并退出

 

--chunk-size

迁移过程是一步步分批次完成的,这个参数是指事务每次提交的行数,默认是1000。

 

--max-lag-millis

会监控从库的主从延迟情况,如果延迟秒数超过这个阀值,迁移不会退出,等待延迟秒数低于这个阀值继续迁移。



--throttle-control-replicas

和--max-lag-millis参数相结合,这个参数指定主从延迟的数据库实例。

 

--initially-drop-ghost-table

gh-ost执行前会创建两张xx_ghc和xx_gho表,如果这两张表存在,且加上了这个参数,那么会自动删除原gh表,从新创建,

否则退出。xx_gho表相当于老表的全量备份,xx_ghc表数据是数据更改日志,理解成增量备份。

--initially-drop-socket-file

gh-ost执行时会创建socket文件,退出时不会删除,下次执行gh-ost时会报错,加上这个参数会删除老的socket文件,重新创建。

 

--ok-to-drop-table

go-ost执行完以后是否删除老表,加上此参数会自动删除老表。

--host

数据库实例地址。

 

--port

数据库实例端口。

 

--user

数据库实例用户名。

 

--password

数据库实例密码。

 

--database

数据库名称。

 

--table

表名。

 

-verbose


--alter

操作语句。

 

--cut-over

自动执行rename操作。

 

--debug

输出详细日志。

 

--panic-flag-file

这个文件被创建,迁移操作会被立即终止退出。

 

--execute

如果确定执行,加上这个参数。

 

--allow-on-master

整个迁移所有操作在主库上执行,也就是数的b方法。

 

--throttle-flag-file

此文件存在时操作暂停,删除文件操作会继续。


./gh-ost -host="192.168.15.104"  --max-load=Threads_connected=3000 

-port=3306 -user="dlan" -password="root123" -database="aaa" -table="team_member_20161109"  

--alter="add column yuhao2 char(11)" --allow-on-master --initially-drop-ghost-table --initially-drop-old-table  

-initially-drop-ghost-table --initially-drop-ghost-table --initially-drop-socket-file --initially-drop-socket-file

 --ok-to-drop-table --cut-over=default --execute

以上测试加的参数,测试的心碎,2事务就出问题


本文转自 DBAspace 51CTO博客,原文链接:http://blog.51cto.com/dbaspace/1891278

相关文章
|
存储 关系型数据库 MySQL
[ogg四] ogg Source Trail的理解
[ogg四] ogg Source Trail的理解
|
SQL 关系型数据库 MySQL
pt-online-schema-change使用说明、限制与比较
如果正在看这篇文章,相信你已经知道自己的需求了。 在 mysql 5.5 版本以前,修改表结构如添加索引、修改列,需要锁表,期间不能写入,对于大表这简直是灾难。从5.5特别是5.6里,情况有了好转,支持Online DDL,相关介绍见 这篇文章,而我在实际alter table过程中还是会引起 d
7699 0
|
SQL 关系型数据库 MySQL
|
监控 关系型数据库 MySQL
优雅地使用pt-archiver进行数据归档
一、引言 最近由于业务需求,需要将公有云RDS(业务库)的大表数据归档至私有云MySQL(历史库),以缩减公有云RDS的体积和成本。 那么问题来了,数据归档的方式有n种,选择哪种呢?经过一番折腾,发现使用percona的pt-archiver就可以轻松并优雅地对MySQL进行数据归档。
10054 0
truncate后恢复包---FY_Recover_Data.pck 包的内容
truncate后恢复包---FY_Recover_Data.pck 包的内容                                                 ...
1470 0
|
MySQL 关系型数据库
|
关系型数据库 MySQL SQL