使用EF迁移历史记录表中的二进制数据还原mysqldump

Question

I'm trying to restore a database from a dump generated with mysqldump . However it contains binary data.

I made an mysqldump of a database which have an entity framework migration history table.

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

This table has a column with binary data (longblob) and it's causing me issues when trying to restore.

I first tried to restore via WorkBench, but it failed. I then copied the command that workbench used and ran it manually. It obviously had the same result.

mysql.exe --protocol=tcp --host=localhost --user=root --port=3306 --default-character-set=utf8 --comments --database=foo < dump.sql

ERROR: ASCII '\\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\\0' is expected. Query: ' ■-'.

It tells me to add --binary-mode=1 , so I did.

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

ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '??-' at line 1

But it still doesn't work. Then I tried to find ??- in the dump file but couldn't. I read somewhere that I shouldn't change the charset. So I tried removing --default-character-set=utf8 from the command.

mysql.exe --binary-mode=1 --protocol=tcp --host=localhost --user=root --port=3306 --comments --database=foo < dump.sql

ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' ■-' at line 1

Now I'm able to find ■- in the dump file, but it doesn't really help me :/

---

Content of 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

Found the problem!

I was running mysqldump via a powershell script which was causing the dump.sql file to be encoded incorrectly.

Switched to a bat script instead and now it works

Answer 2

do not use IO redirect, use mysqldump option instead.

-r, --result-file=name Direct output to a given file. This option should be used in systems (eg, DOS, Windows) that use carriage-return linefeed pairs (\\r\\n) to separate text lines. This option ensures that only a single newline is used.

the OS IO redirect will change the encoding of the result file.