有没有办法确定,mysqldump
正在运行,有多少备份已完成或剩余多少?
答案 0 :(得分:59)
安装并使用pv
(它可作为CentOS的yum包提供)
http://www.ivarch.com/programs/pv.shtml
PV(" Pipe Viewer")是一种监控数据进度的工具 通过管道。它可以插入任何正常的管道 两个进程之间给出了数据快速的可视化指示 正在经过,已经花了多长时间,有多接近完成它 是,并估计完成前的时间。
假设生成的dumpfile.sql文件的预期大小为100米(100兆字节),pv
的使用将如下所示:
mysqldump <parameters> | pv --progress --size 100m > dumpfile.sql
控制台输出如下所示:
[===> ] 20%
查看手册页man pv
以获取更多选项。您可以显示传输速率,已经过了多长时间,传输了多少字节等等。
如果您不知道转储文件的大小,有一种方法可以从table_schema获取MySQL数据库的大小 - 它不会是您的转储文件的大小,但它可能足够接近您的需要:
SELECT table_schema AS "Database", ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "Size (MB)" FROM information_schema.TABLES GROUP BY table_schema;
<强>更新强>
根据我的经验,当转储整个MySQL服务器时,mysql转储的实际未压缩大小(使用mysqldump --hex-blob选项)大约是从MySQL数据获取的实时大小的75%到85%之间INFORMATION_SCHEMA。因此,对于一般解决方案,我可能会尝试以下方法:
SIZE_BYTES=$(mysql --skip-column-names <parameters> <<< 'SELECT ROUND(SUM(data_length) * 0.8) AS "size_bytes" FROM information_schema.TABLES;')
mysqldump <parameters> --hex-blob | pv --progress --size $SIZE_BYTES > dumpfile.sql
答案 1 :(得分:44)
是的,2010年3月27日patch was committed:
这个新补丁有一个额外的参数--show-progress-size by default设置为10,000。因此,当使用--verbose时,每10,000个 您将获得一行的常规状态输出行数 倾销的特定表。
请检查您的版本,根据需要进行更新并享受。
答案 2 :(得分:7)
Russell E Glaue答案的完整版本。 获取舍入的数据库大小,因为pv仅接受整数,并根据@mtoloo注释:
计算没有索引的数据长度db_size=$(mysql -h"$DB_HOST" \
-u"$DB_USERNAME" \
-p"$DB_PASSWORD" \
--silent \
--skip-column-names \
-e "SELECT ROUND(SUM(data_length) / 1024 / 1024, 0) \
FROM information_schema.TABLES \
WHERE table_schema='$DB_NAME';")
创建时间戳文件名的备份:
mysqldump -h"$DB_HOST" \
-u"$DB_USERNAME" \
-p"$DB_PASSWORD" \
--single-transaction \
--order-by-primary \
--compress \
$DB_NAME | pv --progress --size "$db_size"m > "$(date +%Y%m%d)"_backup.sql
答案 3 :(得分:2)
我一直在寻找一些类似的工具(PV),但我没有转储数据库。在合并两个带有一些额外计算和公式的大型数据库时,该过程未在TOP或HTOP实用程序中列出,而仅以io%的形式在标头上列出(仅在启动过程中显示在列表中,然后消失)。始终显示高使用率,但是在这种情况下,它在IO端,并且未在实用程序的主体列表中列出,因为其他进程确实在显示。我不得不使用IOSTAT来查看输出数据库的写入进度,但是无法确定是否实际在文件上进行写入(仅显示xfer速率)。我发现了一种旧方法,即使用Filezilla FTP比较源数据库的大小,并且由于Im进行了合并,因此在合并文件时必须显示输出文件。刷新filezilla目录内容时,直到过程成功结束为止,我能够看到增量,两个DB的总和的大小已按预期合并。 (您实际上可以每分钟刷新一次,并手动计算硬件的时间和处理速度)
我转到了MySQL目录(在我的情况下,实际数据库存储为文件。./mysql/database/tablename.MYD...(MYSQL中的文件与相应的.FRM文件一起保存,该文件包含表格格式的数据,以及一个.MYI文件(用作数据库索引)),只需刷新页面即可查看输出合并文件的实际大小,并且确实为我工作。
顺便说一句,TOP和HTOP仅显示MYSQLD在做一些后台处理,但是主力被转移到了IO端进行输出。我的两个合并DB大约有2000万行,每行大约5个演出,在我的CPU双核上需要花费数小时才能合并,并且任何地方都没有显示任何进度(即使phpmyadmin超时,但过程仍在继续)。尝试使用带有PID编号的PV,但由于Im不进行转储,因此无法传输到管道。无论如何,只要为正在寻找一种有效且简便的方法来检查输出文件创建进度的人写出来即可。它也应适用于转储和还原。请耐心等待,一旦开始,它将完成,那就可以肯定了,除非SQL sintax出错(以前发生在我身上,在以前的尝试中根本没有合并任何行,这花了很长时间,但最后没有任何反应,并且没有工具,不可能知道发生了什么,这是很长的时间),建议您先尝试一些小样本行,然后再执行耗时的实际操作,以验证SQL sintax。
没有完全回答c ++程序上进度栏上的问题,但是您可以借此获取已创建的MYD文件的文件大小,并使用源文件大小除以xfer比率来计算进度条,以计算剩余时间。最好的问候。
答案 4 :(得分:2)
在MySQL 5.7+之后,您可以使用mysqlpump。 尽管它没有显示进度条,但仍显示出如下所示的进度:
Dump progress: 1/1 tables, 0/191 rows
Dump progress: 16/17 tables, 19959/116836 rows
Dump progress: 18/19 tables, 22959/117032 rows
Dump progress: 19/21 tables, 24459/118851 rows
Dump progress: 19/22 tables, 26959/118852 rows
Dump progress: 21/23 tables, 28545/119020 rows
Dump progress: 22/23 tables, 30045/119020 rows
...
答案 5 :(得分:1)
刚刚创建了受MySQL / MariaDB Dump Helper和Russell E Glaue启发的Bash脚本pocheptsov。
有一个输出示例:
❯ ./bin/db/dump xxx
[2020-08-19 09:54:59+02:00] [INFO] Dumping database 'master' (≈5.4GiB) into ./bin/db/master.sql...
5.40GiB 0:07:56 [11.6MiB/s] [===========================================================================>] 100%
[2020-08-19 10:02:56+02:00] [INFO] Done.
[2020-08-19 10:02:56+02:00] [INFO] Dumping database 'second_db' (≈2.2GiB) into ./bin/db/second_db.sql...
905MiB 0:01:38 [1.34MiB/s] [==============================> ] 41% ETA 0:02:17