我正在尝试从Azure Database for MySQL Server
自动化所有数据库的mysql转储。当前数据库的大小:
mysql> SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
FROM information_schema.tables GROUP BY table_schema;
+--------------------+---------------+
| DB Name | DB Size in MB |
+--------------------+---------------+
| db1 | 278.3 |
| db2 | 51.8 |
| information_schema | 0.2 |
| mysql | 8.9 |
| performance_schema | 0.0 |
| db3 | 43.3 |
| sys | 0.0 |
+--------------------+---------------+
7 rows in set (31.80 sec)
我在另一个VM上有一个python脚本,它调用mysqldump
将所有这些转储到一个文件中。但是,我遇到了db1
的问题。它被转储到一个文件但它很慢,在30分钟内不到〜4MB。但是,db2
和db3
几乎可以在几秒钟内立即转储。
我已经尝试了以下所有选项和组合,以查看写入速度是否发生变化,但事实并非如此:
--compress
--lock-tables (true / false)
--skip-lock-tables
--max-allowed-packet (512M)
--quick
--single-transaction
--opt
我目前甚至没有使用脚本,只是在shell中运行命令,结果相同。
mysqldump -h <host> -P <port> -u'<user>' -p'<password>' db1 > db1.sql
db1
有500张桌子。
我知道它比db2
和db3
大,但它不是那么多,我想知道是否有人知道这里可能出现什么问题?
修改
在这些有用的答案和谷歌研究显示数据库很可能正常后,我通过将服务器上的db1
数据库复制到测试数据库然后逐个删除表来减小大小来运行测试。大约50MB的写入就像其他数据库一样瞬间完成。这让我相信Azure中存在一些限制,因为数据库很好,我们将与他们的支持团队一起讨论。我还发现谷歌上有很多关于抱怨Azure数据库速度的帖子。
与此同时,我更改了脚本以忽略大型数据库。我们将尝试将数据库移动到Azure提供的SQL Server
或者带有mysql服务器的简单VM,以查看我们可以在哪里获得更好的性能。
答案 0 :(得分:3)
它可能在MySQL服务器端缓慢,但似乎不太可能。您可以打开第二个shell窗口,连接到MySQL并使用SHOW PROCESSLIST
或SHOW ENGINE INNODB STATUS
来检查卡住的查询或锁定。
如果存储速度很慢,也可能无法将数据写入db1.sql。但4MB是30分钟。太荒谬了。确保您正在保存到运行mysqldump的实例的本地存储。不要保存到远程存储。如果您正在写入转储的存储卷有其他繁重的I / O流量使其饱和,也要小心,这可能会减慢写入速度。
您可以测试慢速数据写入的另一种方法是尝试mysqldump ... > /dev/null
,如果速度很快,那么这是一个非常好的线索,缓慢是磁盘写入的错误。
最后,网络可能导致速度缓慢。如果将转储文件保存到/ dev / null仍然很慢,我会怀疑网络。
答案
https://serverfault.com/questions/233963/mysql-checking-permission-takes-a-long-time表明,“检查权限”的缓慢可能是由于MySQL授权表中包含过多数据(例如mysql.user
)引起的。如果您有数千个用户凭据,这可能是原因。您可以尝试删除这些条目(之后运行FLUSH HOSTS
)。
答案 1 :(得分:2)