MYSQLDUMP失败.无法执行'SHOW TRIGGERS LIKE错误,如(错误代码:13)(6)和(1036)

Question

有谁知道为什么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错误

Answer 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_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转储

• 尝试使用 --compact 标志减少运行时间/大小。mysqldump 将添加创建模式所需的所有内容并插入数据以及其他信息：只需要求转储仅包含模式的插入并避免创建模式和的所有语句，即可显着减少运行时间和文件大小。 ea 内的其他非关键信息。insert.这可以缓解很多问题，适合使用，但是您将需要使用单独的转储来--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 问题的旧服务器版本保存。

• 文件大小问题：如果我错误地认为此备份之前未 成功运行，则表明 2GB 文件大小存在潜在问题，您可以尝试将 mysqldump 输出直接直接传输到 7zip 之类的文件中：

  mysqldump |7z.exe a -si name_in_outfile 输出路径和文件名

如果您仍然遇到问题，或者存在不可避免的问题，禁止使用 mysqldump。Percona XtraBackup是我更喜欢的，或者有 Oracle 的 Enterprise Backup for MySQL。它是开源的，比 mysqldump 更通用，有一群非常可靠的开发人员正在研究它，并且具有 mysqldump 没有的许多强大功能，例如流/热备份等。不幸的是，Windows 版本很旧，除非您可以从二进制编译或运行本地 Linux VM 来为您处理该问题。

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