Nie, nie zawsze jest to niezawodne, gdy masz binarne obiekty blob. W takim przypadku MUSISZ użyć „--hex-blob ", aby uzyskać prawidłowe wyniki.
Zastrzeżenie od komentarza poniżej:
Mam przypadek, w którym te wywołania kończą się niepowodzeniem (importowanie na innym serwerze, ale oba 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órego importowanie po cichu nie jest możliwe. Dodanie „--skip-extended-insert” daje mi plik, który jest znacznie łatwiejszy do debugowania i uważam, że ten wiersz jest generowany, ale nie można go odczytać (ale nie jest zgłaszany żaden błąd ani podczas eksportowania, ani importowania):
INSERT INTO `panels` VALUES (1003,1,257126,141,6562,1,88891,'??\\\?ŖeV???,NULL);
Zwróć uwagę, że w oryginale brakuje końcowego cytatu w 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 niekoniecznie możesz zaufać mysqldump, ale nie możesz nawet polegać na nim, aby zgłosić błąd, gdy się pojawi.
Brzydkim obejściem, którego użyłem, było mysqldump wykluczenie dwóch dotkniętych tabel przez dodanie takich opcji do zrzutu:
--ignore-table=myalarm.panels
Potem ten hack skryptu BASH. Zasadniczo uruchom SELECT, który generuje wartości INSERT, w których obsługiwane są kolumny NULL, a kolumna binarna zostaje przekształcona w wywołanie UNHEX(), jak na przykład:
(123,45678,UNHEX("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"),"2014-03-17 00:00:00",NULL),
Wklej go do wybranego edytora, aby się nim bawić, jeśli zajdzie taka potrzeba.
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 wymaga końcowego przecinka we INSERT zamienionego na średnik, a następnie można go uruchomić jak powyżej. Potrzebowałem ulepszeń „dużego bufora importu” ustawionych zarówno w interaktywnej powłoce mysql, jak i w wierszu poleceń, aby przetworzyć ten plik, ponieważ jest on duży.
mysql ... --max_allowed_packet=1GB
Kiedy zgłosiłem błąd, w końcu zostałem skierowany na flagę „--hex-blob”, która działa tak samo, jak moje obejście, ale z mojej strony jest trywialna. Dodaj tę opcję, plamy zostaną zrzucone jako szesnastkowe, koniec.
