Czy mysqldump obsługuje dane binarne niezawodnie?

Question

Mam kilka tabel w MySQL 5.6, które zawierają duże dane binarne w niektórych polach. Chcę wiedzieć, czy mogę ufać zrzutom utworzonym przez mysqldump i upewnić się, że te pola binarne nie zostaną łatwo uszkodzone podczas przesyłania plików zrzutu przez takie systemy, jak FTP, SCP i inne. Ponadto, czy powinienem zmusić takie systemy do traktowania plików zrzutu jako transfery binarne zamiast ascii?

Z góry dziękujemy za wszelkie uwagi!

Answer 1

Tak, można ufać zrzutom wygenerowanym przez mysqldump.

Tak, należy użyć transferu binarnego, aby uniknąć konwersji kodowania podczas przesyłania. Zrzut MySQL dodaje polecenia sterujące do zrzutu, aby serwer zinterpretował plik w określonym kodowaniu podczas ponownego importu. Nie chcesz zmieniać tego kodowania.

Answer 2

Nie, to nie zawsze jest wiarygodne, gdy masz binarne obiekty blob. W takim przypadku MUSISZ użyć flagi "--hex-blob", aby uzyskać poprawne wyniki.

Mam przypadek gdzie te połączenia nie powiedzie (importowanie na innym serwerze, ale zarówno z systemem 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 

Tworzy plik, który dyskretnie zawiedzie importować. Dodanie "--skip-extended-insert" daje mi plik, który jest znacznie łatwiejszy do debugowania, i stwierdzam, że linia ta jest generowana, ale nie można jej odczytać (ale nie zgłoszono błędu ani eksportowania ani importowania):

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

Należy zauważyć, że w oryginale brakuje oferty końcowej danych binarnych.

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

kolumna to dane binarne:

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

Więc nie, nie tylko można zaufać niekoniecznie mysqldump, nie można nawet liczyć na to, aby zgłosić błąd występuje, gdy jeden.

---

Jest brzydki obejście Kiedyś było mysqldump wyjątkiem dwóch poszkodowanych tabel przez dodanie opcji jak ten na wysypisko:

--ignore-table=myalarm.panels 

Następnie skrypt BASH Hack. Zasadniczo uruchomić SELECT, który wytwarza wartości INSERT gdzie NULL kolumn są obsługiwane i kolumna binarna zostaje przekształcony w UNHEX() nazywają tak:

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

wkleić do edytora wyboru bawić się z nim, jeśli trzeba do.

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 

To daje mi plik o nazwie „all.sql”, który potrzebuje końcowy przecinek we wkładce zamienił się średnikiem, a następnie można go uruchomić jak wyżej. Potrzebowałem ustawień "dużego bufora importu" ustawionych zarówno w interaktywnej powłoce mysql, jak iw linii poleceń, aby przetworzyć ten plik, ponieważ jest duży.

mysql ... --max_allowed_packet=1GB 

Kiedy zgłosiłem błąd I w końcu wskazał na flagę „--hex-blob”, który robi to samo jak mój obejście ale w trywialny sposób z mojej strony.Dodaj tę opcję, bąble są rzucane jako heks, koniec.

Answer 3

wysypisk generowane z mysqldump można zaufać.

Aby uniknąć problemów z kodowaniem, transferami binarnymi itp., Należy użyć opcji --hex-blob, aby tłumaczyć każdy bajt w postaci liczby szesnastkowej (na przykład "abc" staje się 0x616263). To spowoduje, że zrzut będzie większy, ale będzie to najbardziej kompatybilny i bezpieczny sposób na uzyskanie informacji (ponieważ będzie to czysty tekst, bez dziwnych błędnych interpretacji ze względu na specjalne symbole generowane z danymi binarnymi w pliku tekstowym).

można zapewnić integralność (i przyspieszyć transfer) plików zrzutu pakowania go na plik rar lub zip. W ten sposób możesz łatwo wykryć, że nie został uszkodzony przez transfer.

Podczas próby załadowania go na serwerze, należy sprawdzić masz przydzielony na pliku konfiguracyjnym serwera my.cnf

[mysqld] 
max_allowed_packet=600M 

lub więcej w razie potrzeby.

BTW teraz ja właśnie zrobiłem migrację, i wrzucili dużo danych binarnych z mysqldump i to działało idealnie.