mysqldump работи ли надеждно с двоични данни?

Не, не винаги е надеждно, когато имате двоични петна. В този случай ТРЯБВА да използвате „--hex-blob ", за да получите правилни резултати.

Предупреждение от коментар по-долу:

Имам случай, в който тези обаждания се провалят (импортиране на различен сървър, но и двете работят Centos6/MariaDB 10):

mysqldump --single-transaction --routines --databases myalarm -uroot -p"PASSWORD" | gzip > /FILENAME.sql.gz
gunzip < FILENAME.sql.gz | mysql -p"PASSWORD" -uroot --comments

Той създава файл, който безшумно не успява да се импортира. Добавянето на „--skip-extended-insert“ ми дава файл, който е много по-лесен за отстраняване на грешки и откривам, че този ред е генериран, но не може да бъде прочетен (но не се отчита грешка нито при експортиране, нито при импортиране):

INSERT INTO `panels` VALUES (1003,1,257126,141,6562,1,88891,'??\\\?ŖeV???,NULL);

Имайте предвид, че в оригинала липсва крайната цитат на двоичните данни.

select hex(packet_key) from panels where id=1003;
--> DE77CF5C075CE002C596176556AAF9ED

Колоната е двоични данни:

CREATE TABLE `panels` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `enabled` tinyint(1) NOT NULL DEFAULT '1',
  `serial_number` int(10) unsigned NOT NULL,
  `panel_types_id` int(11) NOT NULL,
  `all_panels_id` int(11) NOT NULL,
  `installers_id` int(11) DEFAULT NULL,
  `users_id` int(11) DEFAULT NULL,
  `packet_key` binary(16) NOT NULL,
  `user_deleted` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  ...

Така че не, не само че не можете непременно да се доверите на mysqldump, но дори не можете да разчитате на него да докладва грешка, когато възникне такава.

Едно грозно решение, което използвах, беше mysqldump, изключвайки двете засегнати таблици, като добавих опции като тази към дъмпа:

--ignore-table=myalarm.panels 

Тогава този BASH скрипт хак. По принцип стартирайте SELECT, който произвежда стойности INSERT, където колоните NULL се обработват и двоичната колона се превръща в извикване UNHEX() по следния начин:

(123,45678,UNHEX("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"),"2014-03-17 00:00:00",NULL),

Поставете го в избрания от вас редактор, за да играете с него, ако трябва.

echo "SET UNIQUE_CHECKS=0;SET FOREIGN_KEY_CHECKS=0;DELETE FROM panels;INSERT INTO panels VALUES " > all.sql
mysql -uroot -p"PASSWORD" databasename -e "SELECT CONCAT('(',id,',', enabled,',', serial_number,',', panel_types_id,',', all_panels_id,',', IFNULL(CONVERT(installers_id,CHAR(20)),'NULL'),',', IFNULL(CONVERT(users_id,CHAR(20)),'NULL'), ',UNHEX(\"',HEX(packet_key),'\"),', IF(ISNULL(user_deleted),'NULL',CONCAT('\"', user_deleted,'\"')),'),') FROM panels" >> all.sql
echo "SET UNIQUE_CHECKS=1;SET FOREIGN_KEY_CHECKS=1;" > all.sql

Това ми дава файл, наречен "all.sql", който се нуждае от последната запетая във INSERT превърната в точка и запетая, след което може да се стартира както по-горе. Имах нужда от настройките за "голям буфер за импортиране", зададени както в интерактивната обвивка на mysql, така и в командния ред, за да обработя този файл, защото е голям.

mysql ... --max_allowed_packet=1GB

Когато съобщих за грешката, в крайна сметка бях насочен към флага "--hex-blob", който прави същото като моето заобикаляне, но по тривиален начин от моя страна. Добавете тази опция, петна ще бъдат изхвърлени като шестнадесетичен, край.