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

Posted

技术标签:

【中文标题】使用 EF 迁移历史表中的二进制数据恢复 mysqldump【英文标题】:Restore mysqldump with binary data from EF migration history table 【发布时间】:2015-11-17 16:51:02 【问题描述】:

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

我为具有实体框架迁移历史表的数据库创建了mysqldump

mysqldump.exe --opt --user=root foo > dump.sql

此表有一个包含二进制数据 (longblob) 的列,它在尝试恢复时给我带来了问题。

我首先尝试通过 WorkBench 进行恢复,但失败了。然后我复制了工作台使用的命令并手动运行它。结果显然是一样的。

mysql.exe --protocol=tcp --host=localhost --user=root --port=3306 --default-character-set=utf8 --cmets --database=foo

错误:语句中出现 ASCII '\0',但除非启用选项 --binary-mode 并且 mysql 以非交互模式运行,否则这是不允许的。如果需要 ASCII '\0',则将 --binary-mode 设置为 1。查询:' ■-'。

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

mysql.exe --binary-mode=1 --protocol=tcp --host=localhost --user=root --port=3306 --default-character-set=utf8 --cmets --database=foo

ERROR 1064 (42000) at line 1:您的 SQL 语法有错误;检查与您的 MySQL 服务器版本相对应的手册,以在第 1 行的 '??-' 附近使用正确的语法

但它仍然不起作用。然后我试图在转储文件中找到??-,但找不到。我在某处读到我不应该更改字符集。所以我尝试从命令中删除--default-character-set=utf8

mysql.exe --binary-mode=1 --protocol=tcp --host=localhost --user=root --port=3306 --cmets --database=foo

ERROR 1064 (42000) at line 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',

【问题讨论】:

【参考方案1】:

找到问题了!

我通过 powershell 脚本运行 mysqldump,导致 dump.sql 文件编码不正确。

改为使用 bat 脚本,现在可以使用了

【讨论】:

【参考方案2】:

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

-r, --result-file=name 直接输出到给定文件。应该使用这个选项 在使用回车的系统(例如 DOS、Windows)中 换行对 (\r\n) 来分隔文本行。这个选项 确保只使用一个换行符。

OS IO 重定向会改变结果文件的编码。

【讨论】:

以上是关于使用 EF 迁移历史表中的二进制数据恢复 mysqldump的主要内容,如果未能解决你的问题,请参考以下文章

EF CodeFirst数据迁移与防数据库删除

迁移如何应用于数据库? [关闭]

EF核心不在迁移方法上创建表

EF架构~codeFirst从初始化到数据库迁移

EF架构~codeFirst从初始化到数据库迁移

EF 连接 mysq l数据库 code first模式 的实践