有没有人知道为什么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参数，可以解决这个问题。
另一种可能性是来自此处所述的抗病毒产品的干扰：
答案 0 :(得分：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_packet = 160M ＆gt; C：\备份\ visualRSS.dump
--nodata的单独转储来导出你的模式ea。运行以允许您创建所有空表等。/ 创建原始数据，排除添加 - 删除表，注释，锁定和密钥检查语句/ “c：\ path \ to \ mysqldump”-b yourdb -u root -pRootPasswd -v --debug-check --log-error = c：\ backup \ mysqldump_error.log - compact ＆gt; C：\备份\ visualRSS.dump
/ 创建没有数据的架构
dump： / “c：\ path \ to \ mysqldump”-b yourdb -u root -pRootPasswd -v --debug-check --log-error = c：\ backup \ mysqldump_error.log - nodata ＆gt; C：\备份\ visualRSS.dump
锁定问题：默认情况下，mysqldump使用LOCK TABLE（除非您指定）
单个事务）在转储表时读取表并希望获取表上的读锁，DDL操作和全局锁类型可能会创建这种情况。如果没有看到挂起的查询，您通常会看到如您所述的小备份文件大小，并且通常mysqldump操作将一直持续到您终止它，或者服务器关闭空闲连接。您可以使用--single-transaction标志为事务设置REPEATABLE READ类型，以基本上获取表的快照，而不会阻止操作或阻塞，为某些与ALTER / TRUNCATE有问题的旧服务器保存在这种模式下表。
FileSize问题：如果我错误地读错此备份之前没有成功运行，请指示2GB文件大小 潜在的问题，你可以尝试直接管道mysqldump输出 就像7zip一样：
mysqldump | 7z.exe a -si name_in_outfile output_path_and_filename
如果您仍然遇到问题或者存在禁止使用mysqldump的不可避免的问题。 Percona XtraBackup是我更喜欢的，或者是来自Oracle的MySQL企业备份。它是开源的，比mysqldump更加通用，有一组非常可靠的开发人员，它有许多mysqldump没有的强大功能，比如流/热备份等。不幸的是，windows build很旧，除非你能做到从二进制文件编译或运行本地Linux VM来为您处理。
非常重要我注意到您没有备份您的information_schema表，如果它对您的备份方案有意义，则需要专门提及。