gh-ost的概述说明（一）

一、概述
为了降低生产环境中数据库的DDL操作的风险，gh-ost工具采用的是基于binlog日志应用变更的技术，极大程度上降低了业务锁表的可能，并且加快了表 online DDL的无感操作。
gh-ost工具根据原始表创建ghost的表单，并通过应用binlog日志将增、删、改的sql操作应用到ghost表中，当ghost表的数据与原表数据同步后，暂停所有dml操作，并将ghost表切换为原始表的过程。其它产品均采用触发器的方式、触发器与changlog的方式。
二、gh-ost工具的使用注意事项
gh-ost工具默认使用binlog_format=row的格式，建议使用innodb引擎，且提供了master-slave、master/master on master、slave的三种方式。只针对主从拓扑结构master-slave与单主/双主拓扑结构master/master-master作说明。
master-salve方式：
访问replica库，并通过拓扑结构确认master库。

在master库中创建ghost表，并通过replica库的binlog日志，将变更数据应用到master库上的ghost表上。

在replica库中检查table的格式，字段，键值，行数。

在replica库中读取changlog events，主从ghost间的心跳检测等。

gh-ost工具当确认数据同步完成，会暂停指定表的dml操作，并将ghost表与原表进行切换

注意：需要监控磁盘IO，网络等负载情况，可以通过以下方式进行流量限制或暂停gh-ost的操作，一般情况下，并不会影响生产环境【大事务过程中除外】。
/tmp/gh-ost.test.sample_data_0.sock文件是ghost指定的sock通信方式
#限流/暂停
linux $] echo throttle | nc -U /tmp/gh-ost.test.sample_data_0.sock
#查看状态
linux $] echo status | nc -U /tmp/gh-ost.test.sample_data_0.sock

官网指导：
gh-ost
–max-load=Threads_running=25
–critical-load=Threads_running=1000
–chunk-size=1000
–throttle-control-replicas=“myreplica.1,mysqlreplica.2”
–max-lag-millis=1500
–user=“gh-ost”
–password=“123456”
–host=replica.with.rbr.com
–database=“my_schema”
–table=“my_table”
–verbose
–alter=“engine=innodb”
–switch-to-rbr
–allow-master-master
–cut-over=default
–exact-rowcount
–concurrent-rowcount
–default-retries=120
–panic-flag-file=/tmp/ghost/panic/flag
–postpone-cut-over-flag-file=/tmp/ghost.postpone.flag
–execute
master/master-master的方式：
连接master库， --assume-master-host=a.specific.master.com指定连接的master库或者通过同时配置—allow-master-master --assume-master-host=a.specific.master.com指定连接的master库

检查master库或者指定的master库的binlog_format=row格式，是否为row

并且指定gh-ost的交互命令–allows-on-master

注意：需要监控系统负载情况
go-ost
–max-load=Threads_running=25
–critical-load=Threads_running=1000
–chunk-size=1000
–throttle-control-replicas=“myreplica.1.com,myreplica.2”
–max-lag-millis=1500
–user=“gh-ost”
–password=“123456”
–host=master.with.rbr.com
–allow-on-master
–database=“my_schema”
–table=“my_table”
–verbose
–alter=“engine=innodb”
–switch-to-rbr
–allow-master-master
–cut-over=default
–exact-rowcount
–default-retries=120
–panic-flag-file=/tmp/ghost.panic.flag
–postpone-cut-over-flag-file=/tmp/ghost.postpone.flag
–execute
三、gh-ost 的命令工具说明
–aliyun-rds 当在Aliyun RDS上执行时，指定该参数

–allow-zero-in-date 当DDL的语句存在与mysql的sql_mode指定的日期值相冲突时，可以指定该参数

–azure 当在Azure Database for mysql上执行时，指定该参数。

–allow-master-master 当处于master-master的mysql拓扑结构时，指定该参数。

–approve-renamed-columns 当存在表字段更名时，可以指定该参数，没有可以指定–skip-renamed-columns。

–allow-on-master 当单master库是基于SBR的格式情况下，指定该参数 。使用SBR模式，需要评估可能存在的意外风险

–assume-master-host=the.master.com 该参数可以指定master库，而无需gh-ost爬取mysql的拓扑架构进行确认，尤其是在Tungsten replica 的复制工具下，gh-ost工具无法确认master。

–assume-rbr 如果知道master使用的是RBR格式下，可以使用此参数跳过binlog_format格式的检测

–attempt-instant-ddl Mysql 8.0支持algorith=instant 瞬时DDL，gh-ost可以在mysql 8.0的模式下，指定该参数

–binlogsyncer-max-reconnect-attempts gh-ost重试连接binlog日志的次数

–conf 可以通过指定该参数，将该节的其它参数写入到指定文件中，格式如下：

比如：[client]
params
–concurrent-rowcount 默认为 true。无需配置

–critical-load 0~1之间，如果服务器的负载数到达该阈值，gh-ost将退出

–critical-load-hibernate-seconds gh-ost的负载超过阈值后，进行反复休眠并重试，直到成功。

–critical-load-interval-millis 为–critical-load提供两次检测的机会，间隔时间，两次后阈值还未下降，则退出。

–cut-over 默认为安全模式。

–cut-over-lock-timeout-seconds 在切换过程中，保持表锁的最大秒数，默认3秒。

–discard-foreign-keys 若原表存在外键的情况下，在ghost表上可以不存在外键，且切换后表也不会有外键存在，需要特别注意。

–dml-batch-size 1-100的值，1表示不进行批处理，默认值10。

–exact-rowcount 通过select count(*)的方式，统计表行数。

–execute 字面意思

–force-named-cut-over 您可以绕过延迟和一致性检测，立即执行表的命名操作

。
–force-named-panic 日常情况不会使用，不作介绍 。

–force-table-names

–table=mydb.mytable1,mydb.mytable2 --force-table-names 对指定的表进行操作。
–GCP Google Cloud Platform。

–

heartbeat-interval-millis 默认值10，在 gh-ost 中，心跳是一种用于监测数据库复制状态的机制。当执行数据库结构变更操作时，gh-ost 使用心跳来检查主数据库和副本数据库之间的同步状态。
–hooks-status-interval 跟java的切面概念相似，在程序运行过程中，可以执行指定的操作，比如发信息等。

–hooks-status-interval 用于设置检测hook的区间。

–initially-drop-ghost-table 字面意思，特殊情况下指定。

–initially-drop-old-table 字面意思，特殊情况下指定。

–initially-drop-socket-file 字面意思，特殊情况下指定。

–max-lag-millis 表示原始表与ghost表之间的最大数据延迟时间，延迟阈值超过时，gh-ost可能会暂停变更操作等待数据追赶上来后再继续操作。毫秒

–max-load 用于设置最大的负载阈值， 最大值为10，如果当前负载已超过设定的阈值，gh-ost 会等待负载降低到设定的阈值以下后再继续进行变更操作。

–migrate-on-replica 用于在第三种模式下进行。要确保从库与主库之间的数据同步是正常的，并且从库上不会有其他的写操作。此外，还应该在执行变更操作期间监控从库的状态，确保变更操作不会对从库的性能和可用性产生不利影响

–postpone-cut-over-flag-file 用于指定一个文件路径。当指定了该参数时，在切换到新表结构之前，gh-ost 会创建一个标志文件。
在进行表结构变更时，gh-ost 工具会执行一系列步骤，包括复制数据、应用变更、同步数据等等。当所有步骤都成功完成后，gh-ost 会将新表结构切换为主表，并删除旧表结构。通过设置 postpone-cut-over-flag-file 参数，您可以延迟切换到新表结构的操作，并在指定的文件路径下创建一个标志文件。这样可以给您留出时间来检查变更是否成功并满意，然后手动执行切换操作。

–replica-server-id 用于在主从复制环境中唯一标识每个从库。

–serve-socket-file 指定Unix Socket 的文件路径。

–skip-foreign-key-checks 确认没有外键的情况下，指定该参数，跳过检查。

–sql_mode gh-ost的参数，与mysql 的sql_mode 同样的作用。

–skip-renamed-columns 跳过对已重命名列的检查和操作。

–ssl ssl参数有三个可选项，true:启用SSL连接，false:禁用SSL连接，skip-verify:启用SSL连接，但忽略对证书的验证。

–ssl-allow-insecure 允许 gh-ost 使用加密连接连接到 MySQL 服务器，但在连接过程中不验证服务器提供的证书的有效性。需要使用 --ssl 参数。

–ssl-ca 、–ssl-cert、–ssl-key

–storage-engine 此处使用innodb引擎，–storage-engine=innodb

–test-on-replica 在复制服务器上执行测试操作。

–test-on-replica-skip-replica-stop 在slave库上操作，会停止复制。指定该参数，则不会停止复制操作。

–throttle-control-replicas 该参数用于指定需要限制同步速度的复制服务器。将限制仅应用于复制服务器 replica1 和 replica2。

比如：gh-ost --host=<数据库主机>
–user=<用户名>
–password=<密码>
–database=<数据库名>
–table=<表名>
–alter “<要执行的变更操作>”
–ssl=true
–throttle-control-replicas=replica1,replica2
–throttle-http 可以设置 HTTP 请求的速率限制（以每秒请求数）。

比如：gh-ost --host=<数据库主机>
–user=<用户名>
–password=<密码>
–database=<数据库名>
–table=<表名>
–alter “<要执行的变更操作>”
–ssl=true
–throttle-http=50
–throttle-http-interval-millis 参数用于限制 gh-ost 工具在发送连续的 HTTP 请求时的时间间隔，以控制请求的速率。这可以确保在进行表重构操作期间不会过分加载目标服务器或消耗全部带宽。单位时间间隔毫秒数，默认是100毫秒。

比如：gh-ost --host=<数据库主机>
–user=<用户名>
–password=<密码>
–database=<数据库名>
–table=<表名>
–alter “<要执行的变更操作>”
–ssl=true
–throttle-http-interval-millis=100

–throttle-http-timeout-millis 默认值：1000毫秒。请求超时时间。

–timestamp-old-table 在原表被成功 migration后，会在原表的后面加上timestamp的后缀。

–tungsten 属于Tungsten replica 复制体系。

–verbose 模式用于详细输出执行迁移任务时的信息和日志。

----debug 输出执行迁移任务时的信息和日志

四、命令示例
查看状态
echo status | nc -U /tmp/gh-ost.test.sample_data_0.sock
可以通过下面的命令，动态的修改chunk-size的大小
echo “chunk-size=250” | nc -U /tmp/gh-ost.test.sample_data_0.sock
显示chunk-size的值

echo “chunk-size=?” | nc -U /tmp/gh-ost.test.sample_data_0.sock
限流或中断

echo throttle | nc -U /tmp/gh-ost.test.sample_data_0.sock
动态配置，与Mysql的set global varaibles 类似
echo “max-load=Threads_running=50,threads_connected=1000” | nc -U /tmp/gh-ost.test.sample_data_0.sock

五、其它
cut-over切换说明：
gh-ost通过使用原子的、两步的阻塞交换来解决这个问题：当一个连接持有锁时，另一个连接尝试进行原子的 RENAME 操作。通过放置一个哨兵表格来阻止 RENAME 操作过早执行，直到 gh-ost 确认所有情况都正常为止。
使用 --migrate-on-replica 参数会以与主数据库相同的方式执行切换。
使用 --test-on-replica 参数会首先停止复制；然后按照主数据库的方式执行切换，但之后会回滚（表格的重命名操作会再次执行，恢复到原来的状态）。
目前支持命令行参数 --cut-over，默认采用上述原子切换算法。也支持 --cut-over=two-step，它使用非原子的 Facebook 算法。我们建议使用经过我们的生产环境测试的默认切换方式。
hooks钩子说明：相当于异常抛出器，在程序运行过程中，可以获取需要得信息
Interactive commands[交互式命令]:
gh-ost 的设计目标是操作友好的。为此，即使在运行过程中，它也允许用户控制其行为。
交互式接口：
gh-ost 监听以下接口：
Unix socket 文件：可以通过 --serve-socket-file 参数提供，或由 gh-ost 确定，默认会一直开启。当使用自动确定时，在启动和整个迁移过程中，gh-ost 将公布 socket 文件的标识。
TCP：如果提供了 --serve-tcp-port 参数
这两个接口可以同时使用。都可以响应简单的文本命令，因此可以通过 shell 方便地进行交互。
已知命令：
help：显示可用命令的简要列表
status：返回迁移进度和配置的详细状态摘要
sup：返回迁移进度的简要状态摘要
coordinates：返回检查服务器的最近的（尽管不是最新的）二进制日志坐标
applier：返回 applier 的主机名
inspector：返回 inspector 的主机名
chunk-size=：修改 chunk-size；将在下一次运行复制迭代时生效
dml-batch-size=：修改 dml-batch-size；将在下一次应用二进制日志事件时生效
max-lag-millis=：修改最大复制延迟阈值（毫秒，最小值为100，即0.1秒）
max-load=：修改 max-load 配置；将在下一次运行复制迭代时生效
max-load 的格式必须为：some_status=[,some_status=…]’
例如：Threads_running=50,threads_connected=1000，然后您写入/回显 max-load=‘Threads_running=50,threads_connected=1000’ 到 socket。
critical-load=：修改 critical-load 配置（超过这些阈值将中止操作）
critical-load 的格式必须为：some_status=[,some_status=…]’
例如：Threads_running=1000,threads_connected=5000，然后您写入/回显 critical-load=‘Threads_running=1000,threads_connected=5000’ 到 socket。
nice-ratio=：更改 nice 比率：0 表示积极（不 nice，不休眠），正整数 n 表示：
对于每消耗 1ms 复制行的时间，花费 n*1ms 单位的时间进行休眠。
示例：假设一个单个行的块复制需要 100ms 完成。
nice-ratio=0.5 将导致 gh-ost 立即休眠 50ms。
nice-ratio=1 将导致 gh-ost 休眠 100ms，有效地将运行时间加倍。
值为 2 将有效地将运行时间增加三倍；依此类推。
throttle-http：更改限速的 HTTP 端点
throttle-query：更改限速的查询
throttle-control-replicas=‘replica1,replica2’：更改限速控制副本的列表，这些是 gh-ost 将检查的副本。这是一个以逗号分隔的副本列表，用于替换之前的列表。
throttle：进行限速，或者强制停止
no-throttle：取消强制暂停（尽管可能还有其他限速原因）
unpostpone：在 gh-ost 推迟切换阶段时，指示 gh-ost 停止推迟并立即执行切换。
panic：立即触发 panic 并中止操作
查询数据：
对于接受 value 作为参数的命令，传递 ?（问号）以获取当前值，而不是设置新值。
测试如下：
echo status | nc -U /tmp/gh-ost.test.sample_data_0.sock
可以通过下面的命令，动态的修改chunk-size的大小
echo “chunk-size=250” | nc -U /tmp/gh-ost.test.sample_data_0.sock
echo “chunk-size=?” | nc -U /tmp/gh-ost.test.sample_data_0.sock
echo throttle | nc -U /tmp/gh-ost.test.sample_data_0.sock
echo status | nc -U /tmp/gh-ost.test.sample_data_0.sock
echo “max-load=Threads_running=50,threads_connected=1000” | nc -U /tmp/gh-ost.test.sample_data_0.sock
throttle：可以帮助您在数据库迁移过程中控制对主服务器的负载，以避免影响正常的数据库操作。
throttle参数可以设置以下几种形式之一：
1、带单位的时间间隔：例如，”–throttle=1s“ 表示每秒迁移一批数据。
2、百分比：例如，”–throttle=50%“ 表示限制迁移速率为当前主服务器写入速率的50%
3、整数值：表示具体的每批迁移记录数，例如，”–throttle=1000“ 表示每批迁移1000条记录。
Migrating with Statement Based Replication
如果模式是SBR模式，需要更改为RBR模式。
ghost能创建一个bookkeeping，这个table是以_osc为后缀的
比如：select * from _sample_data_0_osc order by id desc limit 1 \G
Sub-second replication lag throttling[子秒级复制延迟限制]
当–max-lag-millis小于1000（即是小于1秒）时，gh-ost将进行子秒级的限制控制，复制延迟测试量时基于以下两个服务器上进行的：
被检查的服务器，通过–throttle-control-replicas列表中的服务器。
在这两种情况下，gh-ost使用内部心跳机制。它将心跳事件注入到实用的changelog表中，然后在副本中读取这些条目并比较时间，该测量默认开启，并且从定义上支持子秒级的精度。
原则上， heartbeat-interval-millis设置为<=max-lag-millis，在生产迁移中使用–heartbeat-interval-millis=100,–max-lag-millis=[300,500]
连接到副本，可以将副本设置为 binlog_format=row。
–throttle-http="http://1.2.3.4:6789/throttle"将启用HTTP检查/节流，但–throttle-http="1.2.3.4:6789/throttle"则不会启用。
可以随时掌控并节流操作。
–throttle-flag-file：当此文件存在时，节流将启动。只需触碰文件即可开始节流。
–throttle-additional-flag-file：与上述类似。当此文件存在时，节流将启动。
默认值：/tmp/gh-ost.throttle
基于无触发器的异步迁移
gh-ost的无触发器设计使用了一种异步方法。然而，它不需要触发器，因为它不需要像FB工具那样有一个changelog表。之所以不需要changelog表，是因为它在另一个地方找到了changelog：二进制日志。
具体而言，它读取行级别复制（RBR）条目（您仍然可以在语句级别复制下使用它！），并搜索适用于原始表的条目。
RBR条目非常方便完成这项工作：它们将复杂的语句（可能是多表）分解为单独的按表、按行的条目，易于阅读和应用。
gh-ost扮演了一个MySQL副本的角色：它连接到MySQL服务器，并开始请求binlog事件，就像它是一个真正的复制服务器一样。因此，它获得连续的二进制日志流，并过滤出适用于原始表的事件。
gh-ost可以直接连接到主服务器，但更倾向于连接到其中一个副本。该副本需要使用log-slave-updates并且设置binlog-format=ROW（gh-ost可以为您更改后者的设置）。
从二进制日志中读取，特别是在从副本上读取时，进一步强调了算法的异步性质。尽管根据配置，事务可能会与binlog条目写入同步，但gh-ost假装成一个副本，直到收到通知、复制事件并应用之前，这需要一些时间。
1、基于SBR的模式下，仍然用gh-ost,migrate tables。则需要连接到replica库，并配置 log_bin,log_slave_updates,binlog_format=row
2、如果gh-ost退出或被终止，没有紧急需要清理的事情。gh-ost创建了两个表，可以清理掉它们：
ghost表：_yourtablename_gho
changelog表：_yourtablename_ghc
3、如果由于锁定/超时问题，切换（表切换）无法进行怎么办？
切换操作明确与lock_wait_timeout相关联。如果您的表突然遇到长时间运行的查询，切换操作（涉及LOCK和RENAME语句）可能无法继续执行。有限次数的重试，如果没有成功，gh-ost会退出。
如果由于锁定/超时问题，切换（表切换）无法进行怎么办？
切换操作明确与lock_wait_timeout相关联。如果您的表突然遇到长时间运行的查询，切换操作（涉及LOCK和RENAME语句）可能无法继续执行。有限次数的重试，如果没有成功，gh-ost会退出。
4、如果迁移导致主服务器负载过高怎么办？
这就是gh-ost的亮点所在。与您可能熟悉的其他工具不同，没有必要终止它。您可以即时重新配置gh-ost以使其更友好。
您始终可以主动开始限制处理速度。只需触发throttle文件或向gh-ost发送throttle命令。另外，您可以重新配置max-load、nice-ratio和throttle-query，以获得更适合您需求的阈值。
5、如果我的副本没有使用二进制日志怎么办？
如果主服务器正在运行基于行的复制（RBR），请将gh-ost指向主服务器，并指定–allow-on-master参数。参考操作指南。
如果主服务器正在运行基于语句的复制（SBR），您只能通过重新配置副本来解决问题：
启用log_bin
启用log_slave_updates
设置binlog_format=ROW