Dziś rano (okolice godziny 4-5 są najlepsze do takich prac ;-)) podczas wręcz rutynowego przerzucania strony z serwera na serwer wyskoczył nam błąd 1273 (HY000) podczas importu bazy danych na nowym serwerze. Niby nic nowego, bo to nie pierwszy taki przypadek, ale pomyślałem, że być może warto o tym napisać, bo jest to dość częsty błąd (problem), zwłaszcza, przy migracji stron, które swoje już przeżyły…

MySQL: Problem z metodą kodowania znaków przy imporcie bazy danych

Zazwyczaj bez problemu można wyeksportować bazę danych i następnie ją zaimportować. Nie ma nawet znaczenia, czy będzie to robione z poziomu PhpMyAdmin, czy z wiersza poleceń (konsoli). Czasem jednak taka operacja nie idzie tak gładko, zwłaszcza, gdy przenosimy bazy między różnymi wersjami MySQL, czy strona, której bazę przetwarzamy ma dłuższą historię, w trakcie której przechodziła z serwera na serwer…

Chyba najczęstszym błędem z jakim się w takiej sytuacji spotykam jest błąd w stylu:

ERROR 1273 (HY000) at line 910: Unknown collation: 'utf8mb4_unicode_520_ci'

U źródła mamy obsługę kodowania „utf8mb4_unicode_520_ci”, w miejscu docelowym nie. W takim przypadku zazwyczaj stosuję jedną z 3 metod:

Eksport (i import) z zachowaniem wstecznej kompatybilności

Pozornie najprościej jest podczas eksportu bazy danych np. z poziomu PhpMyAdmin zaznaczyć opcję wstecznej kompatybilności, np. „MYSQL40”:

Wybieramy kolejno:

  • Baza danych do eksportu > Eksport > Metoda eksportu: Dostosuj – wyświetli wszystkie możliwe opcje

Dalej:

  • Specyficzne opcje formatu > System bazy danych lub starszego serwera MySQL w celu maksymalizacji zgodności produkcji z: MYSQL40

Tak wyeksportowana baza danych (jej zrzut do pliku) powinna zostać „wykastrowana” ze wszelkich „nowinek” (w tym związanych z kodowaniem znaków), które potencjalnie mogą powodować problemy z zaimportowaniem jej na docelowym serwerze/systemie.

Podczas importu warto również zaznaczyć opcję kompatybilności wstecznej – dla porządku:

Tyle w teorii, bo z doświadczenia wiem, że czasem – zwłaszcza w przypadku „styranych życiem” baz danych – przy tej metodzie pojawiają się jakieś problemy.

Ręczna zmiana oznaczenia typu kodowania

Dlatego osobiście preferuję metodę trochę bardziej „barbarzyńską”, czyli bezpośrednią ingerencję w plik SQL, choć jest to już wariant raczej dla bardziej świadomych użytkowników. Głównie dlatego, że… trzeba wiedzieć co na co zmieniać. Ale co zamieniamy wydaje się oczywiste – mamy w końcu to w komunikacie błędu, a na co zmienić… hm… od tego jest choćby internet… ;-)

W opisywanym przypadku błąd powoduje taki oto zapis:

utf8mb4_unicode_520_ci

I mam w tym przypadku o tyle ułatwione zadanie, że wystarczy, że usunę „520”, czyli:

utf8mb4_unicode_ci

I wykorzystałem do tego zadania program, który od bardzo jest jednym z najczęściej przeze mnie używanych, czyli Notepad++:

Akurat w tym konkretnym przypadku nie powinny wystąpić żadne problemy, co nie oznacza, że nie mogą.

Może też się zdarzyć, że zadanie będzie trochę trudniejsze, choćby w przypadku jeszcze starszej wersji serwera MySQL, gdzie nie tylko nie będzie obsługi „520”, ale w ogóle może nie być formatu „utf8mb4” (format wykorzystywany choćby w przypadku nowszych wersji WordPressa, gdy wykryje nowszą wersję serwera MySQL). W takim przypadku może być wymagana dodatkowa konwersja znaków w pliku…

Tak zmodyfikowany plik można wgrać następnie przez PhpMyAdmin, lub bezpośrednio z konsoli, np. za pomocą takiego polecenia:

mysql -u root -p webinsider01 < /archiwum/webinsider01.sql

I choć lubię PhpMyAdmin nie tylko przez sentyment „hostingowych czasów”, to jednak jest to metoda dużo szybsza, a do tego bez problemu radzi sobie nawet z największymi plikami, gdzie w przypadku PhpMyAdmin mogą być już problemy (choć można wtedy próbować ratować sytuację korzystając z katalogu na serwerze do importu i eksportu bazy).

Aktualizacja serwera MySQL

Ostatnia metoda, która przy okazji zapewni najlepszą zgodność w opisywanym przypadku, to… aktualizacja serwera MySQL do najnowszej wersji. Oczywiście mam świadomość, że nie zawsze jest to możliwe, ale czasem na serwerze znajduje się stara wersja, choć można dokonać aktualizacji do nowszej wersji. Po prostu nikomu się nie chciało…

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.
Roztańczona Karolina dzięki motywowi Divi od Elegant Themes właśnie skończyła pierwszą stronę
WebInsider poleca księgowość wFirma
WebInsider korzysta z VPSa w HitMe.pl
WebInsider poleca VPSy DigitalOcean
WebInsider poleca serwis Vindicat
Napisz komentarz
wipl_napisz-komentarz_01Jeśli informacje zawarte na tej stronie okazały się pomocne, możesz nam podziękować zostawiając poniżej swój komentarz.

W tej formie możesz również zadać dodatkowe pytania dotyczące wpisu, na które – w miarę możliwości – spróbujemy Ci odpowiedzieć.
Linki partnerskie
Niektóre z linków na tej stronie to tzw. „linki partnerskie”, co oznacza, że jeśli klikniesz na link i dokonasz wymaganej akcji (np. zakup/rejestracja) możemy otrzymać za to prowizję. Pamiętaj, że polecamy tylko te produkty i usługi, z których sami korzystamy, i uważamy, że są tego na prawdę warte… :-)
Znaki towarowe i nazwy marek
W niektórych wpisach (oraz innych miejscach na stronie) mogą być przedstawione/użyte znaki towarowe i/lub nazwy marek, które stanowią własność intelektualną tych podmiotów, a zostały użyte wyłącznie w celach informacyjnych.
Roztańczona Karolina dzięki motywowi Divi od Elegant Themes właśnie skończyła pierwszą stronę