mysqldump gestisce i dati binari in modo affidabile?

Question

Ho alcune tabelle in MySQL 5.6 che contengono grandi dati binari in alcuni campi. Voglio sapere se posso fidarmi dei dump creati da mysqldump e assicurarsi che quei campi binari non si corrompano facilmente durante il trasferimento dei file di dump attraverso sistemi come FTP, SCP e così via. Inoltre, dovrei forzare tali sistemi a trattare i file di dump come trasferimenti binari invece di ascii?

Grazie in anticipo per eventuali commenti!

Answer 1

Sì, ci si può fidare delle discariche generate da mysqldump.

Sì, è necessario utilizzare il trasferimento binario per evitare qualsiasi conversione di codifica durante il trasferimento. Il dump di MySQL aggiunge comandi di controllo al dump in modo che il server interpreti il ​​file in una codifica specifica durante la reimportazione. Non vuoi cambiare questa codifica.

Answer 2

No, non è sempre affidabile quando si dispone di blob binari. In tal caso è necessario utilizzare il flag "--hex-blob" per ottenere risultati corretti.

Ho un caso in cui queste chiamate non riescono (importazione su un server diverso, ma entrambi in esecuzione 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 

Si produce un file che non riesce in silenzio da importare. L'aggiunta di "--skip-extended-insert" mi dà un file che è molto più facile da eseguire e scopro che questa linea è generata ma non può essere letta (ma non viene segnalato alcun errore né esportandolo o importandolo):

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

Si noti che la virgoletta di terminazione sui dati binari manca nell'originale.

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

La colonna è dati binari:

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

Quindi no, non solo si può non necessariamente fidare di mysqldump, si può nemmeno contare su di esso per segnalare un errore quando si verifica.

---

Una soluzione brutta che ho usato è stato quello di mysqldump escludendo le due tabelle afflitti con l'aggiunta di opzioni come questo per la discarica:

--ignore-table=myalarm.panels 

Poi questo hack script bash. Fondamentalmente eseguire un SELECT che produce valori INSERISCI in cui le colonne NULL sono gestite e la colonna binaria viene trasformato in un UNHEX() chiamano in questo modo:

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

incollarlo nel vostro editor di scelta per giocare con lui se avete bisogno a.

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 

Questo mi dà un file chiamato "all.sql" che ha bisogno la virgola finale nella INSERT trasformato in un punto e virgola, allora può essere eseguito come sopra. Avevo bisogno dei tweak "large import buffer" impostati sia nella shell interattiva mysql sia nella riga di comando per elaborare quel file perché è grande.

mysql ... --max_allowed_packet=1GB 

Quando ho segnalato il bug che stavo finalmente indicò il flag "--hex-blob", che fa la stessa come la mia soluzione, ma in un banale dal mio modo di lato.Aggiungi questa opzione, i BLOB vengono scaricati come esadecimali, alla fine.

Answer 3

Le discariche generate da mysqldump possono essere attendibili.

Per evitare problemi con codifiche, trasferimenti binari, ecc., Utilizzare l'opzione --hex-blob, in modo che traduca ogni byte in un numero esadecimale (ad esempio, 'abc' diventa 0x616263). Renderà il dump più grande, ma sarà il modo più compatibile e sicuro di avere le informazioni (dato che sarà puro testo, nessuna strana interpretazione errata a causa di simboli speciali generati con i dati binari su un file di testo).

È possibile garantire l'integrità (e velocizzare il trasferimento) dei file di dettagli che lo comprimono su un file rar o zip. In questo modo puoi facilmente scoprire che non è stato danneggiato con il trasferimento.

Quando si tenta di caricarlo sul server, di controllare hanno assegnato sul my.cnf server di file di configurazione

[mysqld] 
max_allowed_packet=600M 

o più se necessario.

BTW in questo momento ho appena eseguito una migrazione e scaricato molti dati binari con mysqldump e ha funzionato perfettamente.