Prawidłowy my.cnf

[Davred 0]

Witajcie. jak powinien wyglądać prawidłowy my.cnf na moim vps:

 

aktualnie zawartość tego pliku u mnie to:

[mysqld]
local-infile=0

 

konfiguracja sprzętu:

 

 Serwery VPS 



Pojemność HDD-25 GB

Transfer miesięczny-5000 GB

Gwarantowana pamięć RAM-1024 MB

Pamięć BURST-2048 MB

Czas Pracy Procesora~3 GHz

Ilość Adresów IP-1

 

na serwerze gł będzie stało forum na skrypcie vB aktualnie jakieś 3 k odsłon / 24h ten współczynnik będzie rósł.

 

może ktoś ma już gotową zawartość pliku która by pasowała dla mnie, ważne jest tez aby było pod kodowanie Latin2_general_ci

[Gość N3T5kY]

Odpal forum na czystym pliku przez 48, i potem uruchom tuning primer.

 

http://genomewiki.ucsc.edu/index.php/Tuning-primer.sh

[Davred 0]

ale właśnie myslełem że poprawna konfiguracja pliku naprawie kodowanie forum które się popsuło po przeniesieniu na nowy serwer z zawartościa pliku podana wyżej...

[Gość N3T5kY]

poczytaj sobie o SET NAMES

 

http://webmade.org/porady/kodowanie-set-names-character-set.php

[guziec 109]

Witajcie. jak powinien wyglądać prawidłowy my.cnf na moim vps:

 

aktualnie zawartość tego pliku u mnie to:

[mysqld]
local-infile=0

 

konfiguracja sprzętu:

 

 Serwery VPS 



Pojemność HDD-25 GB

Transfer miesięczny-5000 GB

Gwarantowana pamięć RAM-1024 MB

Pamięć BURST-2048 MB

Czas Pracy Procesora~3 GHz

Ilość Adresów IP-1

 

na serwerze gł będzie stało forum na skrypcie vB aktualnie jakieś 3 k odsłon / 24h ten współczynnik będzie rósł.

 

może ktoś ma już gotową zawartość pliku która by pasowała dla mnie, ważne jest tez aby było pod kodowanie Latin2_general_ci

 

Ale po co? Zamiast kombinować z latinami przejdź na utf-a jak biały człowiek.

 

w sekcji [mysqld] ustaw:

 

default-character-set=utf8
default-collation=utf8_polish_ci
character-set-server=utf8
collation-server=utf8_polish_ci

 

plus ewentualnie:

skip-character-set-client-handshake

 

I jeszcze dodatkowo w [mysql] i w [mysqldump]

 

default-character-set = utf8

 

Zrzuć dumpa ze starej bazy w trybie utf-8 a jeśli już go zrzuciłeś w innym charsecie, to przekonwertuj na utf-8 (np iconv-em) i po zaimportowaniu będziesz miał polskie litery i spokój już na zawsze bez ustawiania "SET NAMES" i tym podobnych protez.

[regdos 1848]

Zrzuć dumpa ze starej bazy w trybie utf-8 a jeśli już go zrzuciłeś w innym charsecie, to przekonwertuj na utf-8 (np iconv-em) i po zaimportowaniu będziesz miał polskie litery i spokój już na zawsze bez ustawiania "SET NAMES" i tym podobnych protez.

 

 

Masz świadomość, że jeżeli jest cokolwiek serializowane i zapisywane w bazie danych i zawiera jakiekolwiek dwubajtowe znaki to przy wykorzystaniu iconv-a po prostu będzie nie do odczytania ponownie ?

 

"SET NAMES" nie jest jakąś protezą tylko normalną rzeczą, którą się stosuje, bo nie każdy musi używać UTF-a.

Przy mysql-u trzeba rozróżnić kilka rzeczy - kodowanie danych w bazie, kodowanie danych jako dane użytkownika, kodowanie danych podczas przesyłu danych pomiędzy aplikacjami (mysql-php) i kodowanie danych przy imporcie/eksporcie.

Import/eksport zawsze przez utf-a należy robić (co jest domyślne w np. phpmyadminie) przez co mamy pewność, że nic nie zgubimy podczas przenoszenia danych, to kodowanie nie ma wpływu na kodowanie danych.

Jeżeli jest to shared to posiłkujemy się SET NAMES, które odpowiada kodowaniu naszych danych, jeżeli mamy dostęp do my.cnf możemy sobie globalnie ustawić w tym pliku SET NAMES.

Jeżeli faktycznie robimy coś od samego początku to najwygodniej będzie tak jak napisał guziec od razu wszędzie zrobić UTF i mamy spokój.

[guziec 109]

Masz świadomość, że jeżeli jest cokolwiek serializowane i zapisywane w bazie danych i zawiera jakiekolwiek dwubajtowe znaki to przy wykorzystaniu iconv-a po prostu będzie nie do odczytania ponownie ?

Tu zgoda, chociaż z doświadczenia wiem że do 90 procent baz mysql nie ładuje się danych binarnych, bo to niezbyt wydajne. W takim przypadku można przekonwertować za pomocą importu do lokalnej bazy na swoim komputerze i następnie zrzutu już w utf-ie.

 

"SET NAMES" nie jest jakąś protezą tylko normalną rzeczą, którą się stosuje, bo nie każdy musi używać UTF-a.

Ale jak jest powód do nieużywania UTF-a na swoim VPS-ie? SET NAMES to polecenie SQL służące do przestawienia zwracanych wyników na naszą stronę kodową. Po co ustawiać na serwerze bazy danych inne kodowanie a potem po każdym połączeniu do niej przestawiać na właściwe, jak można wszystko od razu zrobić w tym samym?

 

Przy mysql-u trzeba rozróżnić kilka rzeczy - kodowanie danych w bazie, kodowanie danych jako dane użytkownika, kodowanie danych podczas przesyłu danych pomiędzy aplikacjami (mysql-php) i kodowanie danych przy imporcie/eksporcie.

Import/eksport zawsze przez utf-a należy robić (co jest domyślne w np. phpmyadminie) przez co mamy pewność, że nic nie zgubimy podczas przenoszenia danych, to kodowanie nie ma wpływu na kodowanie danych.

Jeżeli jest to shared to posiłkujemy się SET NAMES, które odpowiada kodowaniu naszych danych, jeżeli mamy dostęp do my.cnf możemy sobie globalnie ustawić w tym pliku SET NAMES.

Jeśli mamy dostęp do my.cnf to sobie ustawiamy obsługę wszystkich baz na utf-8 i nie potrzebujemy przestawiania na jakieś starożytne pseudo-standardy. Mamy już rok 2010.

[regdos 1848]

Tu zgoda, chociaż z doświadczenia wiem że do 90 procent baz mysql nie ładuje się danych binarnych, bo to niezbyt wydajne. W takim przypadku można przekonwertować za pomocą importu do lokalnej bazy na swoim komputerze i następnie zrzutu już w utf-ie.

Mam na myśli przechowywanie w bazie danych tablic lub obiektów z php, które właśnie się serializuje żeby była możliwość ich zapisu do bazy. (dla przypomnienia dane serializowane są w formacie tekstowym a nie binarnym) Większość skryptów forów w ten sposób przechowuje jakieś dane.

 

Moim zamiarem było wskazanie, że skorzystanie z iconv-a jest bardzo złym pomysłem ponieważ może doprowadzić do zniszczenia danych. Niestety import do lokalnej bazy a potem zrzut do utf-a nie rozwiązuje problemu, bo import/export nie zmienia w żaden sposób danych, na których operuje.

 

SET NAMES nie przestawia zwracanych wyników na naszą stronę kodową tylko ustala sposób kodowania pomiędzy aplikacją (php) a bazą danych a dokładnie ustawia 3 zmienne mysql-a dla danego połącznie: character_set_client, character_set_results, character_set_connection

 

Masz rację z poziomu my.cnf ustawiamy sobie jak maja być dane przechowywane w plikach bazy danych jednak nic nie stoi na przeszkodzie żeby kodowanie tych danych było inne niż utf-8 np. iso-5589-2 czy to iso-5589-1, które nadal są obowiązującymi standardami.

[BlueMan 69]

iso-8859-2 jak już nie iso-5589-2

[regdos 1848]

Oczywiście myślałem tak jak npisałeś a źle klikałem w klawisze.

[Nmar 9]

w sekcji [mysqld] ustaw:

 

default-character-set=utf8
default-collation=utf8_polish_ci
character-set-server=utf8
collation-server=utf8_polish_ci

 

plus ewentualnie:

skip-character-set-client-handshake

 

I jeszcze dodatkowo w [mysql] i w [mysqldump]

 

default-character-set = utf8

 

 

Hmm u mnie to nie działa, a chce sobie właśnie ustawić mysql na utf-8 (najnowszą wersję). Przy restarcie pisze failed. Oczywiście umieszczam to w my.conf.

Edytowano Listopad 25, 2012 przez Nmar (zobacz historię edycji)

[czaczawik 8]

Hmm u mnie to nie działa, a chce sobie właśnie ustawić mysql na utf-8 (najnowszą wersję). Przy restarcie pisze failed. Oczywiście umieszczam to w my.conf.

 

 

Failed ale dlaczego? sprawdź w logach co jest nie tak.

[Gość cyferek]

A wy zauważyliście że odpisujecie na posty sprzed dwóch lat?

[Gość Kamikadze]

A wy zauważyliście że odpisujecie na posty sprzed dwóch lat?

 

A zauważyłeś że pisze z problemem dotyczącym tego tematu?