Håndterer mysqldump binære data pålideligt?

Nej, det er ikke altid pålideligt, når du har binære klatter. I så fald SKAL du bruge "--hex-blob " flag for at få korrekte resultater.

Advarsel fra kommentar nedenfor:

Jeg har et tilfælde, hvor disse opkald mislykkes (importerer på en anden server, men begge kører 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

Det producerer en fil, der lydløst mislykkes at importere. Tilføjelse af "--skip-extended-insert" giver mig en fil, der er meget nemmere at fejlfinde, og jeg opdager, at denne linje er genereret, men ikke kan læses (men der rapporteres ingen fejl, hverken ved eksport eller import):

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

Bemærk, at det afsluttende citat på de binære data mangler i originalen.

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

Kolonnen er binære data:

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`),
  ...

Så nej, ikke kun kan du ikke nødvendigvis stole på mysqldump, du kan ikke engang stole på, at den rapporterer en fejl, når en opstår.

En grim løsning, jeg brugte, var at mysqldump ekskludere de to ramte tabeller ved at tilføje muligheder som denne til dumpet:

--ignore-table=myalarm.panels 

Så dette BASH script hack. Kør grundlæggende en SELECT, der producerer INSERT-værdier, hvor NULL-kolonnerne håndteres, og den binære kolonne bliver omdannet til et UNHEX()-kald som sådan:

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

Indsæt den i din valgte editor for at lege med den, hvis du har brug for det.

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

Det giver mig en fil kaldet "all.sql", der skal have det sidste komma i INSERT omdannet til et semikolon, så kan den køres som ovenfor. Jeg havde brug for justeringerne af "stor importbuffer" indstillet i både den interaktive mysql shell og kommandolinjen for at behandle filen, fordi den er stor.

mysql ... --max_allowed_packet=1GB

Da jeg rapporterede fejlen, blev jeg til sidst peget på flaget "--hex-blob", som gør det samme som min løsning, men på en triviel måde fra min side. Tilføj den mulighed, klatter bliver dumpet som hex, slutningen.