mysqldumpはバイナリデータを確実に処理しますか？

Question

いくつかのフィールドに大きなバイナリデータを含むテーブルがMySQL 5.6にあります。 mysqldumpによって作成されたダンプを信頼できるかどうかを知りたいし、FTP、SCPなどのダンプファイルトラフシステムを転送するときに、これらのバイナリフィールドが簡単に破損しないようにしてください。また、ダンプファイルをasciiの代わりにバイナリ転送として扱うようなシステムを強制するべきですか？

コメントありがとうございます！

Answer 1

はい、mysqldumpによって生成されたダンプを信頼できます。

はい、転送中にエンコードの変換が行われないようにするには、バイナリ転送を使用する必要があります。 MySQLダンプは、ダンプに制御コマンドを追加して、再インポート時にサーバが特定のエンコーディングでファイルを解釈するようにします。このエンコーディングを変更する必要はありません。

Answer 2

いいえ、バイナリブロブがある場合は、必ずしも信頼できるとは限りません。この場合、正しい結果を得るには、 "--hex-blob"フラグを使用する必要があります。それは静かにインポートするために失敗したファイルを生成します

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

：

は、私はこれらの呼び出しが失敗する場合（別のサーバーにインポートしますが、両方で実行Centos6/MariaDB 10）を持っています。 " - skip-extended-insert"を追加すると、デバッグがはるかに簡単なファイルが得られます。この行は生成されますが、読み込むことはできません（エクスポートまたはインポートのいずれのエラーも報告されません）。

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

バイナリデータの終了引用符は、元のものにはないことに注意してください。

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をを信頼することはできません、あなたも1が発生したときにエラーを報告するためにそれに頼ることはできません。

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

列はバイナリデータです。

--ignore-table=myalarm.panels 

そして、このBASHスクリプトハック：

---

私が使用醜い回避策はダンプに、このようなオプションを追加することによって、2つの被災テーブルを除くmysqldumpをすることでした。あなたが必要な場合は

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

はそれで遊ぶためにお好みのエディタに貼り付けます。基本的にはそうのように呼び出す）NULL列が処理され、バイナリ列がUNHEX（になってますINSERTの値を生成するSELECTを実行しますに。私のINSERTで、最終的なコンマが必要である「all.sql」と呼ばれるファイルを与える

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 

がセミコロンになって、それが上記のように実行することができます。大きなファイルであるため、対話型のmysqlシェルとコマンドラインの両方で設定された「大きなインポートバッファ」の調整が必要でした。私は最終的に私の回避策としてではなく、私の側道から些細で同じことを「--hex-ブロブ」フラグ、で指摘されたバグを報告し

mysql ... --max_allowed_packet=1GB 

。そのオプションを追加すると、ブロブは16進数でダンプされ、最後にダンプされます。

Answer 3

mysqldumpから生成されたダンプを信頼できます。

エンコードやバイナリ転送などの問題を避けるには、--hex-blobオプションを使用して、16進数の各バイトを変換します（たとえば、 'abc'は0x616263になります）。それはダンプを大きくしますが、それは情報を持つ最も互換性のある安全な方法です（純粋なテキスト、テキストファイル上のバイナリデータで生成された特別なシンボルのために間違った解釈がないため）。

rarファイルまたはzipファイルに梱包されたダンプファイルの完全性を保証し（転送速度を向上させる）ことができます。そうすれば、転送で壊れていないことを簡単に検出できます。

あなたのサーバー上でそれをロードしようとすると、必要であれば、あなたはmy.cnfサーバーの設定ファイルに

[mysqld] 
max_allowed_packet=600M 

以上を割り当てられているチェック。

私はちょうど移行を行い、多くのバイナリデータをmysqldumpでダンプし、完全に機能しました。