7

有谁知道为什么 MYSQLDUMP 在使用以下指令运行时只会执行数据库的部分备份：

"C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqldump" databaseSchema -u root --password=rootPassword > c:\backups\daily\mySchema.dump

有时会执行完整备份，有时会在仅包含数据库的一小部分后停止备份。这个分数是可变的。

该数据库确实有数千个表，总计约 11Gb。但是这些表中的大多数都很小，只有大约 1500 条记录，很多只有 150 - 200 条记录。由于存储的频率数据，这些表的列数可能有数百个。

但我被告知 MySQL 中模式中的表数量不是问题。在正常操作期间也没有性能问题。

并且使用单个表的替代方案实际上并不可行，因为所有这些表都有不同的列名签名。

我应该补充一点，数据库在备份期间正在使用中。

在使用指令集运行备份之后：

"C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqldump" mySchema -u root --password=xxxxxxx -v --debug-check --log-error=c:\backups\daily\mySchema_error.log > c:\backups\daily\mySchema.dump

我明白了：

mysqldump: Couldn't execute 'SHOW TRIGGERS LIKE '\_dm\_10730\_856956\_30072013\_1375194514706\_keyword\_frequencies'': Error on delete of 'C:\Windows\TEMP\#sql67c_10_8c5.MYI' (Errcode: 13) (6)

我认为这是一个权限问题。

我怀疑我的架构中的任何一张表都在 2GB 范围内。

我在具有 8 Gb 内存的 Windows 7 64 位服务器上使用 MySQL Server 5.5。

有任何想法吗？

我知道更改 MySQL 可以打开的文件数 open_files_limit 参数可能会解决这个问题。

另一种可能性是来自反病毒产品的干扰，如下所述：

如何修复 Windows 上的间歇性 MySQL Errcode 13 错误

4

1 回答 1

1

我遇到了这个问题的几种可能性，这是我的工作：

第一：启用错误/调试日志和/或详细输出，否则我们不会知道可能导致问题的错误：

    "c:\path\to\mysqldump" -b yourdb -u root -pRootPasswd -v --debug-check --log-error=c:\backup\mysqldump_error.log > c:\backup\visualRSS.dump

只要在您的发行版中启用了调试，您现在就应该能够将错误记录到文件中，以及在控制台上查看输出。这个问题在这里并不总是很清楚，但这是一个很好的第一步。

您是否查看过您的错误或一般日志？对于这个问题通常不是有用的信息，但有时会有，而且每一点都有助于追踪这些问题。

SHOW PROCESSLIST在运行此程序时也要注意。查看您是否看到如下状态列：WAITING FOR..LOCK/METADATA LOCK这表明该操作由于另一个操作而无法获取锁。

根据上面收集的信息：假设我什么也没找到并且不得不盲目射击，接下来我会针对我遇到的一些常见情况做以下事情：

  • Max Packet Size 错误：如果您收到有关 max-allowed-packet-size 的错误，您可以将其添加--max_allowed_packet=160M到您的参数中以查看是否可以使其足够大：

"c:\path\to\mysqldump" -b yourdb -u root -pRootPasswd -v --debug-check --log-error=c:\backup\mysqldump_error.log --max_allowed_pa​​cket=160M > c:\backup\视觉RSS.dump

  • 尝试使用 --compact 标志减少运行时间/大小。mysqldump 将添加创建模式所需的所有内容并插入数据以及其他信息：您可以通过只要求转储仅包含模式的 INSERTS 并避免创建模式的所有语句和ea 中的其他非关键信息。insert.This 可以缓解很多适合使用的问题，但是您将需要使用单独的转储--nodata来导出您的架构 ea。运行以允许您创建所有空表等。

/创建原始数据，排除添加删除表、注释、锁定和密钥检查语句/ "c:\path\to\mysqldump" -b yourdb -u root -pRootPasswd -v --debug-check --log-error= c:\backup\mysqldump_error.log --compact > c:\backup\visualRSS.dump

/创建dump没有数据的模式： / "c:\path\to\mysqldump" -b yourdb -u root -pRootPasswd -v --debug-check --log-error=c:\backup\mysqldump_error.log --nodata > c:\backup\visualRSS.dump

  • 锁定问题：默认情况下，mysqldump使用LOCK TABLE（除非您指定单个事务）在转储时读取表并希望在表上获取读锁，DDL 操作和您的全局锁类型可能会造成这种情况。如果没有看到挂起的查询，您通常会看到一个小的备份文件大小，如您所描述的，并且通常 mysqldump 操作将一直等待，直到您终止它，或者服务器关闭空闲连接。您可以使用该--single-transaction标志REPEATABLE READ为事务设置一个类型，以便在不阻塞操作或被阻塞的情况下拍摄表的快照，为一些在此模式下存在 ALTER/TRUNCATE TABLE 问题的旧服务器版本保存。

  • FileSize 问题：如果我读错了这个备份 之前没有成功运行，表明 2GB 文件大小的潜在问题，您可以尝试将 mysqldump 输出直接传送到类似 7zip 的内容中：

    mysqldump |7z.exe a -si name_in_outfile output_path_and_filename

如果您仍然有问题，或者有一个不可避免的问题禁止使用 mysqldump。Percona XtraBackup是我更喜欢的，或者有 Oracle 的 Enterprise Backup for MySQL。它是开源的，比 mysqldump 用途广泛得多，有一个非常可靠的开发人员团队正在开发它，并且有许多 mysqldump 没有的强大功能，比如流/热备份等。不幸的是，Windows 构建是旧的，除非你能从二进制编译或运行本地 linux VM 来为您处理。

非常重要的是我注意到您没有备份您的 information_schema 表，如果它对您的备份方案很重要，则需要专门提及。

于 2013-08-11T01:36:19.383 回答