DM Relay Log
DM (Data Migration) 工具的 relay log 由若干组有编号的文件和一个索引文件组成。这些有编号的文件包含了描述数据库更改的事件。索引文件包含所有使用过的 relay log 的文件名。
在启用 relay log 功能后,DM-worker 会自动将上游 binlog 迁移到本地配置目录(若使用 TiUP 部署 DM,则迁移目录默认为 <deploy_dir> / <relay_log>
)。本地配置目录 <relay_log>
的默认值是 relay-dir
,可在上游数据库配置文件中进行修改。自 v5.4.0 版本起,你可以在 DM-worker 配置文件中通过 relay-dir
配置本地配置目录,其优先级高于上游数据库的配置文件。
DM-worker 在运行过程中,会将上游 binlog 实时迁移到本地文件。DM-worker 的 sync 处理单元会实时读取本地 relay log 的 binlog 事件,将这些事件转换为 SQL 语句,再将 SQL 语句迁移到下游数据库。
注意:
Relay log 功能会额外使用磁盘 IO,导致同步延时上升。在部署环境的磁盘 IO 性能不佳时,开启 relay log 也可能会成为同步链路的瓶颈,导致同步速度变慢。
本文档介绍 DM relay log 的目录结构,初始迁移规则,以及如何暂停、恢复和清理 relay log。
目录结构
Relay log 本地存储的目录结构示例如下:
<deploy_dir>/<relay_log>/
|-- 7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001
| |-- mysql-bin.000001
| |-- mysql-bin.000002
| |-- mysql-bin.000003
| |-- mysql-bin.000004
| `-- relay.meta
|-- 842965eb-091c-11e9-9e45-9a3bff03fa39.000002
| |-- mysql-bin.000001
| `-- relay.meta
`-- server-uuid.index
subdir
:- DM-worker 把从上游数据库迁移到的 binlog 存储在同一目录下,每个目录都为一个
subdir
。 subdir
的命名格式为<上游数据库 UUID>.<本地 subdir 序列号>
。在上游进行 master 和 slave 实例切换后,DM-worker 会生成一个序号递增的新
subdir
目录。- 在以上示例中,对于
7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001
这一目录,7e427cc0-091c-11e9-9e45-72b7c59d52d7
是上游数据库的 UUID,000001
是本地subdir
的序列号。
- 在以上示例中,对于
- DM-worker 把从上游数据库迁移到的 binlog 存储在同一目录下,每个目录都为一个
server-uuid.index
:记录当前可用的subdir
目录。relay.meta
:存储每个subdir
中已迁移的 binlog 信息。例如,cat c0149e17-dff1-11e8-b6a8-0242ac110004.000001/relay.meta
binlog-name = "mysql-bin.000010" # 当前迁移的 binlog 名
binlog-pos = 63083620 # 当前迁移的 binlog 位置
binlog-gtid = "c0149e17-dff1-11e8-b6a8-0242ac110004:1-3328" # 当前迁移的 binlog GTID
也可能包含多个 GTID:
cat 92acbd8a-c844-11e7-94a1-1866daf8accc.000001/relay.meta
binlog-name = "mysql-bin.018393"
binlog-pos = 277987307
binlog-gtid = "3ccc475b-2343-11e7-be21-6c0b84d59f30:1-14,406a3f61-690d-11e7-87c5-6c92bf46f384:1-94321383,53bfca22-690d-11e7-8a62-18ded7a37b78:1-495,686e1ab6-c47e-11e7-a42c-6c92bf46f384:1-34981190,03fc0263-28c7-11e7-a653-6c0b84d59f30:1-7041423,05474d3c-28c7-11e7-8352-203db246dd3d:1-170,10b039fc-c843-11e7-8f6a-1866daf8d810:1-308290454"
初始迁移规则
Relay log 迁移的起始位置由如下规则决定:
从下游数据库 sync 单元 checkpoint 中,获取各同步任务需要该数据源的最早位置。如果该位置晚于下述任何一个位置,则从此位置开始迁移。
若本地 relay log 有效(有效是指 relay log 具有有效的
server-uuid.index
,subdir
和relay.meta
文件),DM-worker 从relay.meta
记录的位置恢复迁移。若不存在有效的本地 relay log,但上游数据源配置文件中指定了
relay-binlog-name
或relay-binlog-gtid
:在非 GTID 模式下,若指定了
relay-binlog-name
,则 DM-worker 从指定的 binlog 文件开始迁移。在 GTID 模式下,若指定了
relay-binlog-gtid
,则 DM-worker 从指定的 GTID 开始迁移。
若不存在有效的本地 relay log,而且 DM 配置文件中未指定
relay-binlog-name
或relay-binlog-gtid
:在非 GTID 模式下,DM-worker 从初始的上游 binlog 开始迁移,并将所有上游 binlog 文件连续迁移至最新。
在 GTID 模式下,DM-worker 从初始上游 GTID 开始迁移。
注意:
若上游的 relay log 被清理掉,则会发生错误。在这种情况下,需设置
relay-binlog-gtid
来指定迁移的起始位置。
启动、停止 relay log
enable-relay
设为 true
开启 relay log。自 v5.4.0 起,DM-worker 在绑定上游数据源时,会检查上游数据源配置中的 enable-relay
项。如果 enable-relay
为 true
,则为该数据源启用 relay log 功能。
具体配置方式参见上游数据源配置文件介绍
除此以外,你也可以通过 start-relay
或 stop-relay
命令动态调整数据源的 enable-relay
并即时开启或关闭 relay log。
bash
» start-relay -s mysql-replica-01
{
"result": true,
"msg": ""
}
enable-relay
项失效,你只能通过start-relay
和 stop-relay
命令开启和关闭 relay log。加载数据源配置时,如果 DM 发现配置中的 enable-relay
项为 true
,会给出如下信息提示:
>
> > Please use `start-relay` to specify which workers should pull relay log of relay-enabled sources.
>
start-relay
命令可以配置一个或多个 DM-worker 为指定数据源迁移 relay log,但只能指定空闲或者已绑定了该上游数据源的 DM-worker。使用示例如下:
bash
» start-relay -s mysql-replica-01 worker1 worker2
{
"result": true,
"msg": ""
}
bash
» stop-relay -s mysql-replica-01 worker1 worker2
{
"result": true,
"msg": ""
}
enable-relay
项。如果 enable-relay
为 true
,则为该数据源启用 relay log 功能。
具体配置方式参见上游数据源配置文件介绍
查询 relay log
query-status -s
命令可以查询 relay log 的状态。
» query-status -s mysql-replica-01
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "no sub task started",
"sourceStatus": {
"source": "mysql-replica-01",
"worker": "worker2",
"result": null,
"relayStatus": {
"masterBinlog": "(mysql-bin.000005, 916)",
"masterBinlogGtid": "09bec856-ba95-11ea-850a-58f2b4af5188:1-28",
"relaySubDir": "09bec856-ba95-11ea-850a-58f2b4af5188.000001",
"relayBinlog": "(mysql-bin.000005, 4)",
"relayBinlogGtid": "09bec856-ba95-11ea-850a-58f2b4af5188:1-28",
"relayCatchUpMaster": false,
"stage": "Running",
"result": null
}
},
"subTaskStatus": [
]
},
{
"result": true,
"msg": "no sub task started",
"sourceStatus": {
"source": "mysql-replica-01",
"worker": "worker1",
"result": null,
"relayStatus": {
"masterBinlog": "(mysql-bin.000005, 916)",
"masterBinlogGtid": "09bec856-ba95-11ea-850a-58f2b4af5188:1-28",
"relaySubDir": "09bec856-ba95-11ea-850a-58f2b4af5188.000001",
"relayBinlog": "(mysql-bin.000005, 916)",
"relayBinlogGtid": "",
"relayCatchUpMaster": true,
"stage": "Running",
"result": null
}
},
"subTaskStatus": [
]
}
]
}
暂停、恢复 relay log
pause-relay
与 resume-relay
命令可以分别暂停及恢复 relay log 的拉取。这两个命令执行时都需要指定上游数据源的 source-id
,例如:
» pause-relay -s mysql-replica-01 -s mysql-replica-02
{
"op": "PauseRelay",
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"source": "mysql-replica-01",
"worker": "worker1"
},
{
"result": true,
"msg": "",
"source": "mysql-replica-02",
"worker": "worker2"
}
]
}
» resume-relay -s mysql-replica-01
{
"op": "ResumeRelay",
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"source": "mysql-replica-01",
"worker": "worker1"
}
]
}
清理 relay log
因为存在文件读写的检测机制,所以 DM-worker 不会清理正在使用的 relay log,也不会清理当前已有数据迁移任务之后会使用到的 relay log。
Relay log 的数据清理包括自动清理和手动清理这两种方法。
自动数据清理
启用自动数据清理需在 source 配置文件中进行以下配置:
# relay log purge strategy
purge:
interval: 3600
expires: 24
remain-space: 15
purge.interval
- 后台自动清理的时间间隔,以秒为单位。
- 默认为 “3600”,表示每 3600 秒执行一次后台清理任务。
purge.expires
- 当前 relay 处理单元没有写入、或已有数据迁移任务当前或未来不需要读取的 relay log 在被后台清理前可保留的小时数。
- 默认为 “0”,表示不按 relay log 的更新时间执行数据清理。
purge.remain-space
- 剩余磁盘空间,单位为 GB。若剩余磁盘空间小于该配置,则指定的 DM-worker 机器会在后台尝试自动清理可被安全清理的 relay-log。若这一数字被设为 “0”,则表示不按剩余磁盘空间来清理数据。
- 默认为 “15”,表示可用磁盘空间小于 15GB 时,DM-master 会尝试安全地清理 relay log。
手动数据清理
手动数据清理是指使用 dmctl 提供的 purge-relay
命令,通过指定 subdir
和 binlog 文件名,来清理掉指定 binlog 之前的所有 relay log。若在命令中不填 -subdir
选项,则默认清理最新 relay log 子目录之前的所有 relay log。
假设当前 relay log 的目录结构如下:
tree .
.
|-- deb76a2b-09cc-11e9-9129-5242cf3bb246.000001
| |-- mysql-bin.000001
| |-- mysql-bin.000002
| |-- mysql-bin.000003
| `-- relay.meta
|-- deb76a2b-09cc-11e9-9129-5242cf3bb246.000003
| |-- mysql-bin.000001
| `-- relay.meta
|-- e4e0e8ab-09cc-11e9-9220-82cc35207219.000002
| |-- mysql-bin.000001
| `-- relay.meta
`-- server-uuid.index
cat server-uuid.index
deb76a2b-09cc-11e9-9129-5242cf3bb246.000001
e4e0e8ab-09cc-11e9-9220-82cc35207219.000002
deb76a2b-09cc-11e9-9129-5242cf3bb246.000003
在 dmctl 中使用 purge-relay
命令的示例如下:
以下命令指定的 relay log 子目录为
e4e0e8ab-09cc-11e9-9220-82cc35207219.000002
,该子目录之前的 relay log 子目录为deb76a2b-09cc-11e9-9129-5242cf3bb246.000001
。所以该命令实际清空了deb76a2b-09cc-11e9-9129-5242cf3bb246.000001
子目录,保留e4e0e8ab-09cc-11e9-9220-82cc35207219.000002
和deb76a2b-09cc-11e9-9129-5242cf3bb246.000003
子目录。» purge-relay -s mysql-replica-01 --filename mysql-bin.000001 --sub-dir e4e0e8ab-09cc-11e9-9220-82cc35207219.000002
以下命令默认
--sub-dir
为最新的deb76a2b-09cc-11e9-9129-5242cf3bb246.000003
子目录。该目录之前的 relay log 子目录为deb76a2b-09cc-11e9-9129-5242cf3bb246.000001
和e4e0e8ab-09cc-11e9-9220-82cc35207219.000002
,所以该命令实际清空了这两个子目录,保留了deb76a2b-09cc-11e9-9129-5242cf3bb246.000003
。» purge-relay -s mysql-replica-01 --filename mysql-bin.000001