2013-05-15 25 views
13

Bazı alanlarda büyük ikili veriler içeren MySQL 5.6'da bazı tablolar var. mysqldump tarafından oluşturulan dökümlere güvenip güvenemeyeceğimi bilmek istiyorum ve bu ikili alanların, FTP, SCP ve benzeri gibi döküm dosyaları ya da dosyaları taşırken kolayca bozulmayacağından emin olun. Ayrıca, bu tür sistemleri döküm dosyalarını ascii yerine ikili aktarım olarak işlemek için mi zorlamalıyım?mysqldump, ikili verileri güvenilir şekilde yönetir mi?

Herhangi bir yorum için şimdiden teşekkür ederiz!

+2

http://forums.devshed.com/mysql-help-4/does-mysqldump-backs-up-blob-fields-of-tables-163361.html Her zaman tüm dosyalar için ikili ftp modunu kullanıyorum. Hiç bir yolsuzluk olmadı. – user4035

+1

Bir şekilde içe aktarmayı her zaman kontrol etmelisiniz. İdeal olarak bir veriyi karşılaştırarak yardımcı programı karşılaştırın, ancak bu genellikle aktarımın çoğunu çoğaltmayı içerir. Ancak, iki uçtan biriyle, her iki ucunda da checksum'lar bile, her şeyin yolunda gitmesini ummaktan daha iyidir. –

cevap

-3

Evet, mysqldump tarafından oluşturulan dökümlere güvenebilirsiniz.

Evet, aktarım sırasında herhangi bir kodlama dönüştürmesini önlemek için ikili aktarım kullanmalısınız. MySQL dökümü, dökümü kontrol komutları ekler, böylece sunucu yeniden adlandırırken belirli bir kodlamayla dosyayı yorumlar. Bu kodlamayı değiştirmek istemezsiniz.

+4

'mysqldump', denetim komutlarını varsayılan olarak eklemez,' --hx-blob' bayrağı, metin dosyasının içindeki ikili verilerin hiçbir garip yanlış anlaşılmamasını sağlamak için belirtilmelidir. –

+1

Üzgünüm, ama -1 benimle. Ayrıca linux kutuları arasında bir _dump/scp/restore_ yaparken 'hex-blob' bayrağı kullanmak zorunda kaldım. –

19

Hayır, ikili lekeleriniz olduğunda her zaman güvenilir değildir. Bu durumda, doğru sonuçları almak için "--hex blob" bayrağını kullanmanız GEREKİR. Sessizce içe başarısız bir dosya oluşturur

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

:

Ben bu aramalar başarısız bir dava (farklı bir sunucuda ithal ancak her iki çalışan Centos6/mariadb 10) sahiptir. "--skip-extended-insert" eklemek bana hata ayıklaması çok daha kolay olan bir dosya verir ve bu satırın üretildiğini ancak okunamadığını (ancak aktarma veya içe aktarma sırasında herhangi bir hata bildirilmediğini) bulurum:

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

İkili verilerdeki sonlandırma alıntılarının orijinalde eksik olduğunu unutmayın.

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

Yani hayır, sadece mutlaka mysqldump güvenemiyorum, hatta biri gerçekleştiğinde bir hatayı bildirmek için üzerine güvenemez:

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

sütun ikili veridir.


kullandığım Çirkin geçici çözüm dökümü için bu gibi seçenekler ekleyerek iki etkilenen tabloları hariç mysqldump oldu:

--ignore-table=myalarm.panels 

O zaman bu BASH komut kesmek.

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

Eğer gerekiyorsa onunla oynamak için seçtiğiniz düzenleyicisine yapıştırın: Temelde şöyle diyoruz) bir UNHEX (içine NULL sütunlar işlenir ve ikili sütun açık olur INSERT değerlerini üreten bir SEÇ çalıştırmak için. Bana INSERT son virgül gerekiyor "all.sql" adlı bir dosya verir

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 

, bir noktalı virgül dönüştü o zaman yukarıdaki gibi çalıştırılabilir. Hem etkileşimli mysql kabuğunda hem de bu dosyayı işlemek için komut satırında "büyük içe aktarma arabelleği" ayarlarına ihtiyacım vardı. Ben sonunda benim geçici çözüm olarak ama benim yan yoldan önemsiz de aynısını yapar "--hex-blob" bayrak, işaret edildi hata bildirdi

mysql ... --max_allowed_packet=1GB 

.Bu seçeneği ekle, lekeler, hex, sonu olarak boşaltılacak.

+0

Bunu bir hata olarak bildirdim: http://bugs.mysql.com/bug.php?id=77879 –

+1

Yeniden açmaya yönelik girişimlere rağmen bu hatanın hala iki yıl sonra "tekrarlanamadığını" işaret ettiğini unutmayın. ve MySQL kullanıcıları bunu düzeltmeye eğilimli görünmüyor. –

4

mysqldump'dan üretilen dökümler güvenilir olabilir.

Kodlamalar, ikili aktarımlar vb. Ile ilgili sorunları önlemek için, --hex-blob seçeneğini kullanın, böylece her baytı onaltılık bir sayıyla çevirir (örneğin, 'abc' 0x616263 olur). Çöpü daha büyük hale getirecektir, ancak bu bilgi sahibi olmanın en uyumlu ve güvenli yolu olacaktır (çünkü bu, salt metin olacak, bir metin dosyasında ikili verilerle oluşturulan özel sembollerden kaynaklanan garip yanlış yorumlamalar olmayacaktır).

Bir rar veya zip dosyasında paketleyen döküm dosyalarının bütünlüğünü (ve aktarım hızını artırarak) sağlayabilirsiniz. Bu şekilde, aktarımla bozulmadığını kolayca tespit edebilirsiniz.

Eğer sunucu üzerinde yüklemek deneyin check

sizin my.cnf sunucu yapılandırma dosyasında

[mysqld] 
max_allowed_packet=600M 

veya gerekirse daha fazla üzerinde atadınız.

BTW şu an sadece bir göç yaptım ve mysqldump ile çok sayıda ikili veri döktüm ve mükemmel bir şekilde çalıştı.

+2

MySQL ekibinin yukarıdaki hataya verdiği yanıt "düzeltmeyecek, --hx-blob geçici çözümünü kullanacak", bu yüzden en iyi çözüm gibi görünüyor. –

İlgili konular