bacula 备份速度非常慢，TCP 套接字处于“unkn-4”状态

Question

它是 SQL。

默认情况下，每次 bacula-fd 发送新文件时，bacula-sd 都会尝试（通过 bacula-dir）将文件属性插入 SQLbatch表。如果您有很多小文件，并且您的 SQL 速度不是很快，它就会插入小延迟。许多小延迟 = 速度受阻 = 由于Max Run Sched Time超出而取消备份。而且由于架构原因，即使您有多个备份正在运行，所有备份的速度都会变慢。

解决方案（有点）是添加：

Spool Data = no
Spool Attributes = yes

在JobDefs {...}部分bacula-dir.conf（请注意，我之所以使用它，Spool Data = no是因为它是磁盘存储，而不是磁带存储，因此它只会增加开销）。使用Spool Attributes = yesbacula 将文件属性写入文件，并且只有当作业完成时，文件才会发送到 SQL 服务器。请注意，在该连接中，bacula-fd一旦数据传输完成，就会释放（以及客户端上的磁盘/网络负载）（因此它不会等待 SQL 插入完成）。

一些说明：

“你的 SQL 速度不是很快”的意思是它每秒只能执行几十个查询。
在我的情况下，有问题的服务器有大约 300 万个文件和 350 GB 磁盘空间。它无法在4天，传输速度下降至200 Kbyte/sec。
使用属性假脱机，它设法在 2 天 13 小时内完成。乍一看，这并不是很大的改进（尽管原始备份从未完成，所以嘿，也许是），但是：数据传输本身只需要4.5 小时，平均速度约为 18 Mbytes/sec（对于大量小文件和压缩来说，这还不算太糟糕，而服务器则执行其他操作）。但是，从本地文件到 SQL 服务器的属性解压需要56.5 小时！两天多！！
有问题的 SQL 服务器是专用的 MySQL (5.5.40-0+wheezy1)，8 核 I7 @ 3.70GHz，64GB RAM，4 磁盘 RAID-10。它还执行其他操作并启用了 binlog，但在备份运行时大部分时间处于空闲状态。它在其他负载下工作得很好，并且 innodb_buffer_pool_size 比 bacula 的所有索引都大。它应该工作正常。
似乎即使启用了属性假脱机，bacula 也不会使用批量插入（也不会LOAD DATA LOCAL INFILE），而是逐个发送 300 万个插入，等待每个插入确认（属性数据存储在约 1GB 大小的紧凑二进制文件中。转换为 ASCII SQL INSERT 语句，它肯定会是这个大小的两倍）。因此，由于 MySQL 位于其他机器上而增加的延迟似乎完全破坏了性能。
我会尝试进一步研究 SQL 速度慢的原因，但我想最好的解决方案是将 MySQL 放在（性能低得多的）本地机器上。我可能会用首选的 PostgreSQL 替换它。

編輯1：将 bacula 升级到（手动创建包）5.2.13做包含对批量插入的支持（而不是 Debian wheezy/jessie 中打包的 5.2.6没有)，并调整 MySQL 数据库以便在 tmpfs 中创建临时表，将上述属性释放时间从 56.5 小时缩短至 30 分钟。我猜在本地机器上用 PostgreSQL 替换它（与 bacula-sd 和 bacula-dir 相同）可能会改善这一点，但这对我们来说已经足够了。

Answer 1