Jestem w trakcie migrowania kilku stron nowego klienta, i jak to w takich sytuacjach zazwyczaj bywa – jest to przygoda pełna niespodzianek. Poza błędem 1273 (HY000) podczas importowania bazy danych MySQL trafiłem dziś rano (a w sumie to jeszcze w nocy, bo takie migracje najczęściej wykonujemy około 4-5). Błąd o tyle ciekawy, że zapewne w internecie znajdziecie masę porad jak sobie z nim poradzić, i zapewne większość z nich nie zadziała…

MySQL: Row size too large (> 8126)

Z serwera źródłowego udało się wyeksportować (zapisać) bezę do pliku danych bez jakichkolwiek problemów. Szybki przerzut na nowy serwer (w tym czasie kopiowanie plików z wykorzystaniem programu Rsync i bezpiecznego połączenia SSH), i.. zaczęły się schody.

Nie będę zanudzał Was wszystkimi drobiazgami, bo one bez większego znaczenia, do tego nie było to coś, czego rozwiązanie wymagało by „porannej kawy” (której i tak nie pijam). Niespodzianką był za to błąd 1118 (42000), który pojawił się pomimo przenoszenia bazy między tymi samymi wersjami serwera MySQL (5.7).

Tak wyglądał w konsoli:

ERROR 1118 (42000) at line 619: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

A tak – dla przykładu – w phpMyAdmin:

#1118 - Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

W dużym skrócie – czegoś jest więcej niż powinno być wg standardu, i stąd problem. Nawet nie zaglądałem do internetu w poszukiwaniu rozwiązania, bo pamiętam, że już kiedyś ze znajomym szukaliśmy, i… szkoda czasu. Uznałem, że najlepiej (i najszybciej) będzie zerkną np. w phpMyAdmin, do którego momentu baza się importuje, dzięki czemu namierzymy problem i od razu go usuniemy (również na przyszłość).

W opisywanym przypadku proces importowania zwracał błąd podczas importowania jednej z tabel utworzonych przez wtyczkę do responsywnych galerii. A z racji tego, ze na stronie (WordPress) wtyczka ta była nieużywana już od jakiegoś czasu, to nawet nie wahałem się na bazie źródłowej usunąć powiązane z nią tabele, bez głębszej analizy, który to konkretnie element psuł transakcję:

DROP TABLE `wp_bwg_album`, `wp_bwg_album_gallery`, `wp_bwg_gallery`, `wp_bwg_image`, `wp_bwg_image_comment`, `wp_bwg_image_rate`, `wp_bwg_image_tag`, `wp_bwg_option`, `wp_bwg_shortcode`, `wp_bwg_theme`;

Po tej operacji zarówno eksport jak i import bazy przebiegł pomyślnie, więc można było iść… z psami na wczesnoporanny spacer… ;-)

(!) Zgłoś błąd na stronie
Potrzebujesz profesjonalnej pomocy? Skontaktuj się z nami!

Spodobał Ci się artykuł? Zapisz się do naszego Newslettera - ZERO SPAMu, same konkrety, oraz dostęp do dodatkowych materiałów przeznaczonych dla subskrybentów!

Na podany adres e-mail otrzymasz od nas wiadomość e-mail, w której znajdziesz link do potwierdzenia subskrypcji naszego Newslettera. Dzięki temu mamy pewność, że nikt nie dodał Twojego adresu przez przypadek. Jeśli wiadomość nie przyjdzie w ciągu najbliższej godziny (zazwyczaj jest to maksymalnie kilka minut) sprawdź folder SPAM.

Patryk

CEO Webinsider.pl, a do tego CTO, CIO, CFO, CMO, CSO, COO i CRO ;-)
Pasjonat nowych technologii - od sprzętu po oprogramowanie, od serwerów po smartfony i rozwiązania IoT. Potencjalnie kiepski bloger, bo nie robi zdjęć "talerza" zanim zacznie jeść.

Dumny przyjaciel swoich psów :-)
Envato Elements - pobieraj co chcesz, ile chcesz