Apakah mysqldump menangani data biner dengan andal?

Tidak, itu tidak selalu dapat diandalkan ketika Anda memiliki gumpalan biner. Dalam hal ini Anda HARUS menggunakan "--hex-blob " tandai untuk mendapatkan hasil yang benar.

Peringatan dari komentar di bawah:

Saya memiliki kasus di mana panggilan ini gagal (mengimpor pada server yang berbeda tetapi keduanya menjalankan 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

Ini menghasilkan file yang diam-diam gagal untuk diimpor. Menambahkan "--skip-extended-insert" memberi saya file yang jauh lebih mudah untuk di-debug, dan saya menemukan bahwa baris ini dibuat tetapi tidak dapat dibaca (tetapi tidak ada kesalahan yang dilaporkan saat mengekspor atau mengimpor):

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

Perhatikan bahwa kutipan pengakhiran pada data biner tidak ada di aslinya.

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

Kolomnya adalah data biner:

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

Jadi tidak, Anda tidak hanya tidak dapat mempercayai mysqldump, Anda bahkan tidak dapat mengandalkannya untuk melaporkan kesalahan saat terjadi.

Solusi buruk yang saya gunakan adalah dengan mysqldump mengecualikan dua tabel yang bermasalah dengan menambahkan opsi seperti ini ke dump:

--ignore-table=myalarm.panels 

Kemudian skrip BASH ini diretas. Pada dasarnya jalankan SELECT yang menghasilkan nilai INSERT di mana kolom NULL ditangani dan kolom biner diubah menjadi panggilan UNHEX() seperti:

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

Tempelkan ke editor pilihan Anda untuk memainkannya jika perlu.

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

Itu memberi saya file bernama "all.sql" yang membutuhkan koma terakhir di INSERT diubah menjadi titik koma, kemudian dapat dijalankan seperti di atas. Saya membutuhkan tweak "buffer impor besar" yang diatur di shell mysql interaktif dan baris perintah untuk memproses file itu karena ukurannya besar.

mysql ... --max_allowed_packet=1GB

Ketika saya melaporkan bug, saya akhirnya diarahkan ke flag "--hex-blob", yang melakukan hal yang sama dengan solusi saya tetapi sepele dari sisi saya. Tambahkan opsi itu, gumpalan akan dibuang sebagai hex, akhirnya.