вопрос по mysql
Додано: 9.11.06 13:27
Ребят, отзовитесь плз кто уверенно шарит в mysql, нужна консультация. Лучше в аську.
Сторінка 1 з 1
Додано: 9.11.06 13:34
Давай лучше сюда. У нас программеров валом - будет консилиум.
Додано: 9.11.06 14:02
да, давай тут, так интересней (тоже могу помочь)
Додано: 9.11.06 14:06
консилиум так консилиум
(хотя проблема и не нова)
Есть 2 сервера, на обоих linux.
На одном из них, в силу исторических причин, стоит mysql 3, на другом 5. Для удобства назовем сервера srv3 и srv5.
Подключаемся с srv3 к srv5 (например "[root@srv3]# mysql -h srv5 -u root -p")
При вводе данных с помошью INSERT INTO или LOAD DATA LOCAL INFILE (добавлено - а так же при их извлечении, SELECT) возникает ошибка вида
при этом данные, естественно, прекрастно вставляются.
Собственно, задача-минимум: избавиться от этого явления. Но сделать это надо с умом, поскольку обе базы активно юзаются, и их недекватное переконфигурирование может быть черевато последствиями.
Задача-максимум - понять как 3-й и 5-й mysql работают с кодировками, и когда какие траблы могут возникать при их совместной работе.
(хотя проблема и не нова)
Есть 2 сервера, на обоих linux.
На одном из них, в силу исторических причин, стоит mysql 3, на другом 5. Для удобства назовем сервера srv3 и srv5.
Подключаемся с srv3 к srv5 (например "[root@srv3]# mysql -h srv5 -u root -p")
При вводе данных с помошью INSERT INTO или LOAD DATA LOCAL INFILE (добавлено - а так же при их извлечении, SELECT) возникает ошибка вида
Код: Виділити все
mysql: File '/usr/share/mysql/charsets/?.conf' not found (Errcode: 2)
mysql: Character set '#33' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index' file
Собственно, задача-минимум: избавиться от этого явления. Но сделать это надо с умом, поскольку обе базы активно юзаются, и их недекватное переконфигурирование может быть черевато последствиями.
Задача-максимум - понять как 3-й и 5-й mysql работают с кодировками, и когда какие траблы могут возникать при их совместной работе.
Додано: 9.11.06 14:28
Мда...
Сам не сталкивался, может это поможет
(хотя ты и сам наверное нашел это)
http://bugs.mysql.com/bug.php?id=10818
Сам не сталкивался, может это поможет
(хотя ты и сам наверное нашел это)
http://bugs.mysql.com/bug.php?id=10818
Додано: 9.11.06 15:13
Находил не совсем это, но суть та же(хотя ты и сам наверное нашел это)
http://bugs.mysql.com/bug.php?id=10818
коду 33 соответствует кодировка UTF8-general-ci
файла UTF8.xml нету
В общем, я понимаю что чего-то не понимаю, но чего именно я не понимаю, я пока не понимаю™. Проводить нездоровые эксперименты стремно (повторюсь, базы активно юзаются). Сервера достались в наследство, поэтому спросить как и что ставилось, тоже не у кого.
Додано: 9.11.06 16:42
С таким не сталкивался.
Суть задачи? Репликация между 3 и 5? Как вариант выполнять шеловые команды через туннель с 3 на 5. Саму команду кормить как:
ssh user@my5 'mysql -h ... -u ... -ppass database -A -e "load data ..." '
Можно это дело запайпить. Например
cat dump.txt | ssh user@my5 'mysql -h ... -u ... -ppass database -A'
Это типа навскидку. Решение задачи через Ж..У
"There's more than one way to do it"
Суть задачи? Репликация между 3 и 5? Как вариант выполнять шеловые команды через туннель с 3 на 5. Саму команду кормить как:
ssh user@my5 'mysql -h ... -u ... -ppass database -A -e "load data ..." '
Можно это дело запайпить. Например
cat dump.txt | ssh user@my5 'mysql -h ... -u ... -ppass database -A'
Это типа навскидку. Решение задачи через Ж..У
"There's more than one way to do it"
Додано: 9.11.06 16:47
вариант поднять на тестовой тачке два сервера и экспериментировать на них?
Додано: 9.11.06 16:54
Леха, лажа может не получиться. Насетапленый антиквариант очень специфичен.
Колись в задаче, будем придумывать 1001 способ как обойти
Колись в задаче, будем придумывать 1001 способ как обойти
Додано: 9.11.06 17:24
Задача стоит в плавном и (главное) безболезненном (читать - незаметном) переходе с одного сервака на другой. Часть задачи заключается в переписывании скриптов, которые работают с базой, в т.ч. наполняют ее. Задача осложнена тем, что "Насетапленый антиквариант очень специфичен"™
Понятно, что можно поднять тестовый сервер, но я вряд смоделирую на нем имеющуюся картину ("Насетапленый антиквариант очень специфичен"™). Думаю над тем, чтобы действительно попробовать (кстати, ни у кого нету fedora core 3 с mysql 3 для полноты картины?).
Вообще, хотелось бы разобраться что к чему на имеющихся системах.
вот.
Понятно, что можно поднять тестовый сервер, но я вряд смоделирую на нем имеющуюся картину ("Насетапленый антиквариант очень специфичен"™). Думаю над тем, чтобы действительно попробовать (кстати, ни у кого нету fedora core 3 с mysql 3 для полноты картины?).
Вообще, хотелось бы разобраться что к чему на имеющихся системах.
вот.
Додано: 9.11.06 17:35
Hagall, я что-то не понял. Мускул используется консольный или в качестве модуля к Перлу-ПХП ? Если так - то никакой проблемы не вижу в переходе если ты просто вкомпилишь поддержку 5 мускула. У тебя проблема именно в том, что ты используешь консольный третий для базы на 5м. А тут совместимости не жди
Додано: 9.11.06 22:30
Не проще проапгрейдить мускул?
Додано: 10.11.06 09:20
Tibor
MySQL используется консольный, и проблема таки в совместимости клиента 3-й версии с сервером 5-й. Конкретно, проблема в том, что mysql версий 4.0- и 4.1+ по-разному юзают таблицы сортировок (или как там они называются). Собственно, в чем желательно разобраться.
lach
Конечно, проще, но мы не ищем легких путей ;-)
Но если нормально связать их не выйдет, так и сделаю.
MySQL используется консольный, и проблема таки в совместимости клиента 3-й версии с сервером 5-й. Конкретно, проблема в том, что mysql версий 4.0- и 4.1+ по-разному юзают таблицы сортировок (или как там они называются). Собственно, в чем желательно разобраться.
lach
Конечно, проще, но мы не ищем легких путей ;-)
Но если нормально связать их не выйдет, так и сделаю.
Додано: 10.11.06 09:48
Hagall, админские навыки растерялись за 5 лет. Наверное не подскажу как его правильно именно для этой задачи сетапить. 