18.01.2013 06:53
Цитата:
OlegON Я бы, наверное, подумал на тему "оставить как есть" текущую винду с УКМ, а вот базу перенести на 64-битный Linux
Версия УКМ4 под Linux есть. Вполне работоспособная. Только я сейчас задумалась, 32 или 64-битный Linux там используется...
18.01.2013 08:14
Цитата:
Mtirt Версия УКМ4 под Linux есть. Вполне работоспособная. Только я сейчас задумалась, 32 или 64-битный Linux там используется...
Для установки и кассы, и сервера используется одни и те же установочные файлы Linux (ukm-root.tar.gz и проч.). Следовательно, смотрим, какой линух на кассе, соответственно, идём на кассу:

# uname -a
Linux localhost 2.6.35.7 #1 SMP PREEMPT Thu Sep 30 16: 13: 09 MSD 2010 i686 i686 i386 GNU/Linux

В соответствии с , выходит что 32..

В случае же раздельной установки сервера MySQL можно вообще какую угодно ОС использовать..
21.02.2013 22:29
Цитата:
Onesoft Первым шагом, который можно сделать в этом направлении - задать значение параметра innodb_buffer_pool_size равным примерно 2/3..3/4 от общего объёма ОЗУ. На 24 ГБ ОЗУ я ставил 18G - после этого bottom на обновлении с 48sp1 до 48sp3 стал работать раз в шесть быстрее.
Ну и сразу можно задрать переменную:
thread_cache_size=500
...
1. Подскажите какие значения в вашем случаи по всем остальным параметрам?
2. Так как на данный момент начинающий по MySql, подскажите методику просчета всех параметров в разрезе УКМ.

Заранее благодарю за ответы.

з.ы.: сейчас задача настроить оптимальную работу СГО под которым несколько десятков магазинов, порядка 4 сотен касс.
Версия MySql 5.1.61 x64. СГО: X5690, 32Гб ОЗУ (~12-15 занято), WinServer 2003 R2 x64
23.02.2013 12:43
Настройка MySQL - процесс творческий и в какой-то степени непрерывный. Выбор оптимальных настроек зависит не только от железа, но так же от структуры БД и характера работы приложений с БД. В соседней теме приводились примеры различной степени загруженности БД СГО, так что даже в рамках УКМ характер работы с БД может меняться.
Недавно нашёл интересный ресурс, где описан подход к процессу оптимизации работы MySQL. Всё описанное в избытке гуглится. Много об оценке производительности пишет Peter Zaitsev - основатель Percona (форка MySQL). Ресурсов много!
01.08.2013 11:30
Итак, купили новое железо.
Ставлю УКМ.
Стпим УКМ и МуСкуль.
Перевожу МуСкуль на порт 3307
Ставль Мускуль 64 разряда на порт 3306
На старом железе останавливаю УКМ
Делаю бэкап ukmserver-а
Разворачиваю его на новом железе в МуСкуль 64
Запускаю УКМ.
Получаю вот такое ругательство:
11:23:12: 0x00000a88: INFO: Global: ---------- Server v.49 Service Pack 8 started -----------
11:23:12: 0x00000a88: INFO: Global: database host:localhost db:ukmserver user:ukm_server
11:23:12: 0x00001274: INFO: sound#01d74d60: started
11:23:12: 0x00000b28: INFO: AsynchronousMachine#01d74dc0: started
11:23:12: 0x00000f80: INFO: NTLP#01d85b00: started
11:23:12: 0x00000a88: FATAL: Global: Query failed: Error(1264) Out of range value for column 'show_order' at row 1: SQL insert into mon_categories (parent_id, code, name, description, show_order) values(574,'3001','003 Елино','003 Елино',65535)
11:23:12: 0x00000a88: INFO: Global: Start terminating...
11:23:12: 0x00000a88: INFO: sound#01d74d60: Pending terminate request received
11:23:12: 0x00000a88: INFO: AsynchronousMachine#01d74dc0: Pending terminate request received
11:23:12: 0x00001274: INFO: sound#01d74d60: finished
11:23:12: 0x00000a88: INFO: NTLP#01d85b00: Pending terminate request received
11:23:12: 0x00000b28: INFO: AsynchronousMachine#01d74dc0: finished
11:23:12: 0x00000f80: INFO: NTLP#01d85b00: finished
11:23:12: 0x00000a88: INFO: Global: -------- Terminate complete ----------
11:23:12: 0x00000a88: FATAL: ServiceMain: Server initializing failed: 10
Попробовал delete from mon_categories.
Результат - тот-же.
01.08.2013 11:46
Цитата:
Aleks_Str На старом железе останавливаю УКМ
Делаю бэкап ukmserver-а
Разворачиваю его на новом железе в МуСкуль 64
Запускаю УКМ.
Получаю вот такое ругательство:
11:23:12: 0x00000a88: FATAL: Global: Query failed: Error(1264) Out of range value for column 'show_order' at row 1: SQL insert into mon_categories (parent_id, code, name, description, show_order) values(574,'3001','003 Елино','003 Елино',65535)

Попробовал delete from mon_categories.
Результат - тот-же.
Нарушение целостности данных. Такое могло произойти из-за не(до)остановленного MySQL или копирования не всех файлов БД.
Между "останавливаю УКМ" и "Делаю бэкап" было "останавливаю MySQL"?
Точно было?
Прогони mysqlcheck, если будет ругаться на table not exist - это оно 100%.

Проверь ещё лог mysql и системный лог на предмет отсутствия какой-нибудь ругани на права доступа/записи и ругани вообще..

Кстати, таблицы монитора надо чистить сразу обе с отключённым foreign_key_checks и при остановленном ukmserver. Но вряд ли это поможет в случае нарушения целостности данных: скорее всего, проблема будет по всей БД. Лучше заново всё сбэкапь с полной остановкой ukmserver и mysql.
01.08.2013 11:46
импорт/экспорт какими командам делаешь? и версии mysql какие?
02.08.2013 08:16
БД источник: версия 5.1.61 от С+ 32 разряда
БД приемник: 5.6.12 64 разряда

Попробовал сделать еще раз дамп и развернуть его. Тоже самое. Задампил mon_* старом сервере, drop tables mon_* на новом, source на файли дампа. Съела нормально: данные и структура восстановились. Но УКМ все равно не запускается.
Полез ковыряться. Что вижу: Поле shw_order -имеет тип TINYINT(4). А запихнуть в это поле пытаются 65535. Оно и не лезет.
Попробовал "родной" mysql - заработало.
Но смысл на новом железе, и на 32-разрядном MySQL-е?
Не, конечно поставлю пока так, но ведь хочется "вкуснее".

дампил: c:\mysql\bin\mysqldump.exe --routines --opt --user=root --host=localhost --port=3306 --password=CtHDbCGK.C --databases ukmserver > e:\arhiv\ukmserver.sql
зарворачивал: или mysql -uroot -p < ФАЙЛ_ДАМПА
или в консоли mysql
cource ФАЙЛ_ДАМПА
02.08.2013 08:42
Цитата:
Aleks_Str БД источник: версия 5.1.61 от С+ 32 разряда
БД приемник: 5.6.12 64 разряда
Не правильно. Используй x64 той же версии - 5.1.61. Достаточно просто заменить папки bin и share. Если не найдёшь - могу тебе куда-нибудь закачать архив 5.1.61.x64.7z (16 МБ) с этими папками или целиком весь mysql-noinstall-5.1.61-winx64.zip (119 МБ).

Либо попробуй не дампить, а вместо этого папку data 5.1.61 источника скопировать вместо data приёмника 5.6.12, и при первом запуске MySQL выполнить mysql_update.exe.

Цитата:
Aleks_Str Полез ковыряться. Что вижу: Поле shw_order -имеет тип TINYINT(4). А запихнуть в это поле пытаются 65535. Оно и не лезет.
Попробовал "родной" mysql - заработало.
Это странно, потому как там не должно быть таких значений.. У нас у самих сейчас 5.6.12 х64 и значения там вот такие:

Код:
SGO> select * from mon_categories group by show_order;
+-----+-----------+-------------+--------------------+-----------------------------+------------+
| id  | parent_id | code        | name               | description                 | show_order |
+-----+-----------+-------------+--------------------+-----------------------------+------------+
|   1 |      NULL | GENERAL     | Общее              | Общая информация о сервере  |          1 |
|   2 |      NULL | CASHLINE    | Магазины           | Информация по магазинам     |          2 |
| 774 |       771 | LAST_FAILED | Неуспешный импорт  | Последний неуспешный импорт |          3 |
| 775 |       771 | STAT        | Статистика импорта | Статистика импорта          |          4 |
|   3 |         2 | 22001       | Дубна (S0014)      | Дубна (S0014)               |        127 |
+-----+-----------+-------------+--------------------+-----------------------------+------------+
5 rows in set (0.00 sec)
Перед тем, как запихнуть 65535 в это поле, УКМ откуда-то его берёт либо форматирует в соответствии с форматом внутренней переменной, не случайно же оно становится FFFFh.
Ещё момент: my.ini в 5.6.12 используешь тот же, что и в 5.1.61? Это тоже существенно.
02.08.2013 14:19
Цитата:
Onesoft Не правильно. Используй x64 той же версии - 5.1.61. Достаточно просто заменить папки bin и share. Если не найдёшь - могу тебе куда-нибудь закачать архив 5.1.61.x64.7z (16 МБ) с этими папками или целиком весь mysql-noinstall-5.1.61-winx64.zip (119 МБ).
Если не затруднит - то на любой файлообменник. Например Яндекс.Диск
Цитата:
Onesoft Либо попробуй не дампить, а вместо этого папку data 5.1.61 источника скопировать вместо data приёмника 5.6.12, и при первом запуске MySQL выполнить mysql_update.exe.
Попробовал. Не прокатило.
Цитата:
Onesoft Ещё момент: my.ini в 5.6.12 используешь тот же, что и в 5.1.61? Это тоже существенно.
Естественно разные. 5.1.61 инишник держит в WINDOWS, а 5.6 - в папке с data
Часовой пояс GMT +3, время: 09:38.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.