爱可生测试团队成员，主要负责 DTLE 开源项目相关测试任务，擅长 Python 自动化测试开发，最近醉心于 Linux 性能分析优化的相关知识。
背景条件：
使用 sysbench 压力工具对 10 张 1 万记录表进行增改删操作
使用 TC 工具来模拟高延时，低带宽场景
工具准备：
1. tc # 模拟网络带宽受限以及增加延迟
https://man7.org/linux/man-pages/man8/tc.8.html
2. iperf3 # 验证网络带宽
https://github.com/esnet/iperf
3. sysbench # 制造数据压力
https://github.com/akopytov/sysbench
环境准备：
1. DTLE 版本
3.20.10.0
2. 服务器
| IP | 用途 |
|---|---|
| 10.186.18.123 | 源端数据库 |
| 10.186.18.117 | 目标端数据库 |
| 10.186.63.20 | 源端DTLE |
| 10.186.63.145 | 目标端DTLE |
3. 在两台 DTLE 服务器上添加网络带宽限制以及增加延迟（经测试网络延迟配置只对发送有效，故需要在源端和目标端同时添加 TC 规则，每端延迟配置为预期延迟的一半）。
#!/usr/bin/env bash
# Name of the traffic control command.
TC=`which tc`
# The network interface we're planning on limiting bandwidth.
IF=eth0 # Interface
# Download limit
DNLD=2mbit # DOWNLOAD Limit
# Upload limit
UPLD=2mbit # UPLOAD Limit
# IP address of the machine we are controlling
IP=10.186.63.145 # Host IP
#IP=10.186.63.20
# Network latency
DELAY=125ms
# Filter options for limiting the intended interface.
U32="$TC filter add dev $IF protocol ip parent 1:0 prio 1 u32"
$TC qdisc add dev $IF root handle 1: htb default 1
$TC class add dev $IF parent 1: classid 1:10 htb rate $DNLD
$TC class add dev $IF parent 1: classid 1:20 htb rate $UPLD
$TC qdisc add dev $IF parent 1:10 handle 10: netem delay $DELAY
$TC qdisc add dev $IF parent 1:20 handle 20: netem delay $DELAY
$U32 match ip dst $IP/32 flowid 1:10
$U32 match ip src $IP/32 flowid 1:20
4. 验证配置生效
DTLE 源端服务器 ping DTLE 目标端服务器
-
DTLE 目标端服务器 ping DTLE 源端服务器
DTLE 源端到 DTLE 目标端网络带宽
DTLE 目标端服务器
iperf3 -sDTLE 源端服务器
iperf3 -c 10.186.63.145
DTLE 目标端到 DTLE 源端网络带宽
DTLE 目标端服务器
iperf3 -sDTLE 源端服务器
iperf3 -c 10.186.63.145 -R
5. 分别在服务器 10.186.63.20 和 10.186.63.145 部署 DTLE 组成集群
场景一：不同网络延迟下数据库同步延迟
网络带宽 2Mbits/s、数据压力 300QPS(binlog 产生速率为 1.47Mbit/s(约 15GB/天))持续压测 120 秒
通过改变 TC 脚本来模拟不同网络延迟情况下对 DTLE 数据同步延迟的影响
job 配置中 GroupTimeout 的值为网络延迟的 2 倍减 10ms（例如：网络延迟为 100ms 则 GroupTimeout=190）
job 配置中 GroupMaxSize 的值为 512000 (500KB)
注：图中复制延迟为 120 秒压力测试中的最高复制延迟时间
小结：
1. 不同的网络延时，通过 DTLE 复制延迟在 2 秒内
2. 特殊限制场景：
网络带宽不足的场景下，复制延时会线性增长
场景二：极限带宽下，MySQL 原生复制和 DTLE 压力对比
网络带宽 2Mbits/s、网络延迟 250ms
在不产生线性递增复制延迟的条件下，所能支持的最大数据压力
job 配置中 GroupTimeout 的值为 490（网络延迟的 2 倍减 10ms）
job 配置中 GroupMaxSize 的值为 1024000 (1000KB)
jbo 配置中 ReplChanBufferSize 的值为 600
注：718QPS 相当于每秒产生 452KB binlog（3.6Mbit/s），367 QPS 相当于每秒产生 231KB binglog（1.8Mbit/s）。
小结：
1. 在网络受限的条件下，MySQL 原生复制在 1.8Mbit/s 的压力下，到达最高压力
2. 在网络受限的条件下，DTLE 复制在 2.7Mbit/s 的压力下，到达最高压力
3. DTLE 利用分组和压缩，在网络受限场景下，能承载更高的复制压力，更好的适应窄带宽的场景
场景三：带宽不受限，MySQL 原生复制和 DTLE 使用带宽对比
网络延迟 250ms、无带宽限制
在不同数据压力下，传输占用的网络带宽
job 配置中 GroupTimeout 的值为 490
job 配置中 GroupMaxSize 和 ReplChanBufferSize 的值随压力增加而增大
小结：
1. 完成同等数据量的传输复制，DTLE 相比 MySQL 原生复制提供更低的带宽占用；带宽占用率最高是 MySQL 原生复制的近 1/3。