[MEGOLDVA]Szerver felújítás - MySQL

Debian GNU/Linux

Van/volt egy gép Debian Etch(!) azaz 4.x - az lapalap szépen kezd kirohadni alóla. Új alaplap - új Debian - Squeeze.
A szerkezet egyik feladata, a MySQL - régi 5.0.51a-3 backport volt akkor - az új a Squeeze repóból, az 5.1.66-0+squeeze1.
A régi verzióban így mentettem ki az adatbázist:
mysqldump --password="jelszó" --all-datzabases > mysql-all-"dátum".sql
Illetve rendelkezésre áll a konkrét adatbázis:
mysqldump --pasword="jelszó" --databases db > db-"dátum".sql
A "db" adatbázist, egy XP -n futó program használja ODBC 3.51 interfészen keresztül.
A migrálásnál már az problémát okozott hogy a dump -ban a db nagybetűkkel volt írva, mire a mysql < db-"dátum".sql parancsnál kijelentette hogy nem ismeri!? Némi küzdelem árán (azért már több száz mega) átírtam kisbetűre - akkor megette. phpmyadmin alól láttam, hogy ott van. Kicsit masszíroznom kellet a hozzáférő felhasználók listáját, de végül az antik ODBC is tudott kapcsolódni és látta az adatbázist - furcsán lassan kezelte a "teszt" parancsot is. Elindítottam a programot az új szerverrel de SQL hibával leállt - a program szerencsére naplóz, egy az egyben az ODBC üzeneteit továbbítja, és ott azt mondta hogy a AEvt.acar tábla nem létezik :(
Valóban, a pphpmyadmin -ban látszik, hogy a táblát "aevt" -nek hívja, vagyis megint kisbetű/nagybetű gond van.
Tudja valaki mit kellene még bekonfigurálni?

Nem igen értem, biztos vagyok benne, hogy ilyen szintű inkompatibilitás nem lehet a MySQL -ben, úgy hogy 5.0.x - 5.1.x
Tény hogy az előző rendszer HU_hu azaz iso8859-2 volt, most a Squeeze -t en_utf8 -ra tettem, de a tábla definíciókban mindenütt benne van, hogy "default charset latin1" (mondjuk ezt sem igazán értem - latin2 kéne - de működött).

( andrej_ v | 2013. 01. 15., k – 13:24 )

Érdemes a leállított db alól file szinten migrálni és úgy nyomni egy mysql_upgrade scriptet. Azt nézd meg, hogy a SHOW VARIABLES LIKE '%char%'; és a %coll%' -ra mit mond mindkét szervernél. Ugyanis valami őrület folytán latin1_swedish-re állt be régen a Debian-os SQL és lehet, hogy az újabbat utf8-al fordították.

( tompos v | 2013. 01. 15., k – 13:25 )

Ha van lehetoseged, ne a dump-pal migralj, hanem a binaris file-okkal.

tompos

( tovis v | 2013. 01. 15., k – 14:24 )

Ez most komoly? Megőrülök :X

* Én egy indián vagyok. Minden indián hazudik.

( Tomee | 2013. 01. 15., k – 14:35 )

Tipp: a régi MySQL szerver nem volt érzékeny a kisbetű/nagybetűre, az új viszont az. Bár nem célszerű így használni, mivel nem minden platform (pl. Win) támogatja a case sensitive tábla és adatbázis neveket, problémás lehet a migrálás.

Ezen kívül én is a fájl szintű másolásra szavazok, ha működik, annál nincs biztosabb egyezés.

Valóban félreérthető, így bocsánat a bináris másolás mint tanács rendben van!
Nem a tanács a f'szság hanem, hogy ilyenhez kell nyúlni, AZ nem korrekt.

Egyébként, ha a konfigurációból hiányzó beállítás a hiba, akkor ez SEM oldja meg :( Minden telepítésemről igyekszem valamiféle jegyzetet készíteni - ez a fontos pont kimaradt - ez még nagyobb baj.

* Én egy indián vagyok. Minden indián hazudik.

Viszont akkor kiderul, hogy a configuraciobol van hiba.

Pont most van nalam egy mysql dump file. Minden tabla elejen van vmi binaris szar, emiatt az import nem ment. Kivancsi lennek pl. nyersen athozva hogy nezne ki ez az adat, de sajnos nem hozzaferheto.
Ezen kivul az adatbanyasz kolleganak van vmi tartalmi baja is a cuccal. Nem tudjuk, hogy amugy is van-e baja, vagy a javitgatas soran kerult bele.

tompos

( tovis v | 2013. 01. 15., k – 15:17 )

Ugyan még nem tudom megoldja-e vagy sem de találtam egy olyat, hogy [strong]lower_case_table_names[strong] és a régi (5.0.x -ben is be volt állítva).
A MySQL manual is említi:
http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html

Lehet hogy mégsem olyan sz'r ez csak én vagyok hülye?
Amint kipróbálhatom, jelzek!

* Én egy indián vagyok. Minden indián hazudik.

( petya | 2013. 01. 15., k – 17:28 )

2 dolog:
1. lowercase_table_names, szerintem a regin volt. MySQL-ben a case sensitivitas tabla es db szinten az alatta levo filerendszertol fugg, tehat linuxon case sensitive lesz windowson nem. Erre van ez az opcio. A columnok case sensitivitasa character settol es collationtol fugg.

2. A character set es collation problemak meregfoga mysqlben az, hogy character setje es collationja valojaban csak oszlopoknak van. A tabla szintu csak default, ha nincs oszlop szintu, a sema szintu default, ha nincs table es oszlopszintu, a szerver szintu (ezt allitod te konfiguraciobol) default, ha nincs oszlop, tabla es sema szintu. A tanulsag az, hogyha alsobb szinteken definialva van a character set es a collation, akkor hiaba konfiguralsz barmit.