如何限制mysqldump使用的带宽
我必须通过没有那么多带宽且其他人需要同时使用的网络管道转储大型数据库。 如果我尝试它，它会占用所有带宽，并且延迟会飙升，而其他人都会陷入困境。
我知道 mysqldump 的 --compress 标志有一定帮助。
如何在不占用此连接上的所有带宽的情况下执行此操作？
更新：
使用带有 -l 标志的 scp 复制转储文件的建议是一个很好的建议，但我应该注意，我没有 SSH 访问数据库服务器。
I have to dump a large database over a network pipe that doesn't have that much bandwidth and other people need to use concurrently. If I try it it soaks up all the bandwidth and latency soars and everyone else gets messed up.
I'm aware of the --compress flag to mysqldump which help somewhat.
How can I do this without soaking up all the bandwidth over this connection?
Update:
The suggestion to copy a dumpfile using scp with the -l flag is a good one, but I should note that I don't have SSH access to the database server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
trickle？您没有提到实际如何传输数据库转储，但如果传输通过 TCP/IP 进行，则rickle 应该可以工作。 例如，如果您使用
nc（例如：nc -L 1234 > backup.sql），以下命令将以不超过 20KB/s 的速度传输备份：trickle?You don't mention how you are actually transffering the DB dump, but if the transfer happens over TCP/IP, trickle should work. For example, if you use
nc(for example:nc -L 1234 > backup.sql) the following command will transfer the backup at no greater than 20KB/s:你必须能够访问 Linux 机器（抱歉我是一个喜欢 Linux 的人）。
入口策略可以减少传入流量，但另一端的服务器需要有一个性能良好的 TCP/IP 堆栈。
tc qdisc 添加 dev eth0 句柄 ffff：入口
tc 过滤器添加 dev eth0 父 ffff：协议 ip prio 50 \
u32 匹配 ip src server.ip.address/32 警察速率 256kbit \
爆发 10k 滴 flowid :1
tc qdisc 添加 dev eth0 root tbf \
速率 256kbit 延迟 25ms 突发 10k
您可以在高级路由指南中找到有关入口过滤器的更多信息。
http://www.linux.org/docs/ ldp/howto/Adv-Routing-HOWTO/index.html
如果您在 Linux 中执行此操作，则可以在本地转储文件，压缩它并使用 scp 复制文件，并使用 -l 开关来限制带宽使用：
-l限制
限制使用的带宽，以 Kbit/s 为单位指定。
例如
scp -l 16 转储文件远程主机：文件路径和名称
You will have to have access to a linux machine (sorry I'm a linuxy sort of person).
An ingress policy can decrease the amount of incoming traffic, but the server on the other side needs to have a farely well behaved TCP/IP stack.
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 \
u32 match ip src server.ip.address/32 police rate 256kbit \
burst 10k drop flowid :1
tc qdisc add dev eth0 root tbf \
rate 256kbit latency 25ms burst 10k
You can find more information on ingress filters in the advanced routing howto.
http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO/index.html
If you are doing it in linux, you can dump the file locally, compress it and use scp to copy the file with the -l switch to limit the bandwidth used:
-l limit
Limits the used bandwidth, specified in Kbit/s.
eg
scp -l 16 dumpfile remotehost:filepathandname
我使用的一个技巧是指定 CSV 格式而不是插入。 它不会改变您每单位时间使用的带宽量，但可以减少您拉出的字节总数。
One trick I've used is to specify CSV format rather than the insert. It doesn't change how much bandwidth you use per unit time, but it can reduce the total number of bytes you're pulling out.
如果通过 TCP 发送，带宽将在各方之间平均共享。 如果您想进一步降低速度，则需要调整设备以仅允许一定量的数据流出。
If you send it over TCP, the bandwidth will be shared equally between all parties. If you want to lower the speed even more, you need to shape your device to only allow a certain amount of data going out.
在客户端上，您可以运行代理来限制下载速度。
您还可以控制连接数等。
如果您使用的是 Windows，这应该可以很好地工作：
http: //www.youngzsoft.net/ccproxy/index.html
On the client, you can run a proxy that will limit the speed of the download.
You can also control # of connections etc.
If you are on windows, this should work nicely:
http://www.youngzsoft.net/ccproxy/index.html
您是否使用像 InnoDB 这样的事务表引擎？ 这是您的主数据库吗？ 要特别小心！ mysqldump 将持有表锁并中断数据库的生产使用。 减慢备份速度只会导致中断时间变得更长。 始终将 mysqldump 到本地磁盘，然后从那里复制转储。
另一种方法可能是在远程站点设置复制从站，并从中获取备份。 然后，数据库更新将慢慢地通过您的竞争链接，而不是一大堆。
另一种选择：在没有其他人使用网络时进行备份:)
Are you using a transactional table engine like InnoDB? Is this your master database? Be very careful! mysqldump will hold table locks and disrupt the production use of your database. Slowing down the backup will only cause this period of disruption to get longer. Always mysqldump to a local disc, and then copy the dump from there.
One other approach might be to set up a replication slave at your remote site, and take your backups from that. Then database updates will trickle over your contended link instead of coming down in one big lump.
Another alternative: do your backups when noone else is using the network :)