使用EF迁移历史表中的二进制数据恢复mysqldump

Question

我正在尝试从用mysqldump生成的转储恢复数据库。但是，它包含二进制数据。

我制作了一个数据库的mysqldump，其中有一个实体框架迁移历史表。

mysqldump.exe --选择--用户=根foo > dump.sql

这个表有一个包含二进制数据(longblob)的列，它在试图恢复时会引起问题。

我最初试图通过WorkBench进行恢复，但失败了。然后我复制工作台使用的命令并手动运行它。显然也有同样的结果。

mysql.exe --协议=tcp-主机=本地主机-用户=根-端口=3306-默认-字符集=utf8 8-注释-数据库=foo< dump.sql 错误: ASCII '\0‘出现在语句中，但这是不允许的，除非启用了选项-二进制模式，并且mysql在非交互模式下运行。如果期望ASCII '\0‘，则将二进制模式设置为1。查询：“再确认-”。

它告诉我添加--binary-mode=1，所以我做到了。

mysql.exe --二进制模式=1--协议=tcp-主机=本地主机-用户=根-端口=3306-默认-字符集=utf8 8-注释-数据库=foo< dump.sql 错误1064 (42000)在第1行:您的SQL语法有一个错误；检查与您的MySQL服务器版本对应的手册，以获得在第1行使用的正确语法

但还是没用。然后我试图在转储文件中找到??-，但是找不到，我在某个地方读到了不应该更改字符集的内容。因此，我尝试从命令中删除--default-character-set=utf8。

mysql.exe --二进制模式=1-协议=tcp-主机=本地主机-用户=根-端口=3306-注释-数据库=foo< dump.sql 错误1064 (42000)在第1行:您的SQL语法有错误；请检查与您的MySQL服务器版本对应的手册，以获得在第1行附近使用的正确语法。

现在我能够在转储文件中找到■-，但它对我没有什么帮助:/

dump.sql含量

-- MySQL dump 10.13  Distrib 5.7.7-rc, for Win64 (x86_64)
--
-- Host: localhost    Database: foo
-- ------------------------------------------------------
-- Server version   5.7.7-rc-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `__migrationhistory`
--

DROP TABLE IF EXISTS `__migrationhistory`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `__migrationhistory` (
  `MigrationId` varchar(100) NOT NULL,
  `ContextKey` varchar(200) NOT NULL,
  `Model` longblob NOT NULL,
  `ProductVersion` varchar(32) NOT NULL,
  PRIMARY KEY (`MigrationId`,`ContextKey`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `__migrationhistory`
--

LOCK TABLES `__migrationhistory` WRITE;
/*!40000 ALTER TABLE `__migrationhistory` DISABLE KEYS */;
INSERT INTO `__migrationhistory` VALUES ('123456789012345_InitialCreate',

Answer 1

发现问题了！

我是通过一个powershell脚本运行mysqldump的，该脚本导致dump.sql文件被错误地编码。

改为bat脚本，现在它可以工作了。

Answer 2

不使用 IO重定向，而是使用mysqldump选项。

-r，--结果- file =将直接输出命名为给定文件。此选项应用于使用回车-返回行提要对(\r\n)分隔文本行的系统(例如DOS、Windows)。此选项确保只使用单个换行符。

OS重定向将更改结果文件的编码。

Answer 3

如果您正在使用MySQL工作台，请检查以下选项以服从高级选项部分中的二进制数据。

​

​

​

​