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ą.

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…