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 回答