[ТЕМА ЗАКРЫТА]
08.02.2012 15:00
fbdp
 
Ставил ли кто MySQL 64-битную на СГО ?
15.02.2012 10:34
overlord
 
А что 32-х не работает?
15.02.2012 10:43
Сервис Плюс
 
Сейчас проводятся работы по адаптации УКМ 4 к 64-битной ОС. К июню механизм установки и апгрейда будет штатным. В настоящее время можно у техподдержки С+ запросить инструкцию по установке на 64-разрядную ОС.
15.02.2012 10:44
OlegON
 
А почему бы техподдержке не выложить эту инструкцию сюда? :(
15.02.2012 10:44
Mtirt
 
Установки УКм4 или использования 64-битной версии Mysql?
Это различные вещи.
15.02.2012 11:21
Сервис Плюс
 
Татьяна, был невнимателен. Речь не идет о 64-битном MySQL. :(
21.02.2012 13:18
fbdp
 
Интересует именно мускул 64 бит, планируется ли его поддержка ?
14.01.2013 18:13
Onesoft
 
Там никакой поддержки-то и не требуется.. 64ый идёт с настройками 32ой с БД без каких-либо доп.действий. И обновления УКМ ставятся абсолютно прозрачно. Проблемы могут возникнуть при переходе обратно на 32 - но за 3,5 года у нас ни разу не возникло в этом необходимости. Щас у нас 50сп1, на 64 переходили, когда у нас была 47сп3, с тех пор дважды обновлялись - до 48сп1 и до 49сп3.

Резервную крпию делать обязательно, мало ли в процессе перевода не на ту кнопу нажмёшь, типа как я сейчас со смартфона налажал тут
15.01.2013 01:23
AlexLog
 
Для перехода делаем импорт экспорт ?
15.01.2013 01:28
Onesoft
 
Цитата:
AlexLog Для перехода делаем импорт экспорт ?
Говорю же - ничего не надо делать. Тупая замена папки bin и вперёд к тонкой настройке my.ini под оптимальное использование ресурсов сервака!!
16.01.2013 10:45
AlexLog
 
Ты писал про 5.1.61
почему не 5.1.62 ?
16.01.2013 11:23
Onesoft
 
Цитата:
AlexLog Ты писал про 5.1.61
почему не 5.1.62 ?
Потому что 5.1.61 была протестирована в С+.
Но нами уже успешно протестирована даже 5.1.66 (тупая замена папки bin). Просто чё-то руки пока никак не дойдут до обновления бинарников.. СУБД днём и ночью нагружена, стопить надо..
16.01.2013 12:45
Aleks_Str
 
Правильно-ли я понял, что алгоритм должен быть следующим:
1. Стопим УКМ
2. mysqldump на ukmserver
3. копируем mysql\data (на всякий случай)
4. ставим Wim 64бит
5. Ставим УКМ
6. Стопим mysql
7. заменяем mysql\bin на mysql\bin от 64-рязрядного mysql
8. Запускаем mysql
9. mysql < файл_полученный_в_п.2
10. запускаем УКМ
и в итоге получаем "быстрый" СГО?
16.01.2013 14:37
Onesoft
 
Цитата:
Aleks_Str Правильно-ли я понял, что алгоритм должен быть следующим:
Не так.

А вот так:

1. Стопим УКМ
2. Стопим mysql
3. копируем mysql\data (на всякий случай)
4. заменяем mysql\bin на mysql\bin от 64-рязрядного mysql
5. Запускаем mysql
6. запускаем УКМ
7. если без проблем всё работает - приступаем к дооолгой процедуре тонкой настройки mysql под оптимальное использование имеющихся ресурсов сервера
и вот только потом в итоге получаем "быстрый" СГО. *132

Но это только относительно 5.0.86!!!
У 5.1.х есть свои нюансы..
16.01.2013 16:03
Onesoft
 
Цитата:
Onesoft Не так.
7. если без проблем всё работает - приступаем к дооолгой процедуре тонкой настройки mysql под оптимальное использование имеющихся ресурсов сервера
Первым шагом, который можно сделать в этом направлении - задать значение параметра innodb_buffer_pool_size равным примерно 2/3..3/4 от общего объёма ОЗУ. На 24 ГБ ОЗУ я ставил 18G - после этого bottom на обновлении с 48sp1 до 48sp3 стал работать раз в шесть быстрее.
Ну и сразу можно задрать переменную:
thread_cache_size=500

Ну а дальше настраивать кеш открытых таблиц, кеш ключей, кеш запросов, буфер транзакций, буфер временных таблиц и т.д... Каждый раз, изменив какую-либо настройку, следить за производительностью (SHOW STATUS; SHOW ENGINE INNODB STATUS) в течение нескольких суток и даже недель - ведь нагрузка на СГО нелинейная с ПН по ВС.. По результатам анализа - коррекция настроек или их сочетаний, снова анализ.. Даже после обновления на новую версию УКМ может возникнуть необходимость коррекции настроек.. Но результат стоит того.

У MySQL 5.1.x общая производительность с теми же настройками ниже, чем у 5.0.86 даже с использованием плагина (), и это тенденция всех веток MySQL (добавляются новые движки и прочие фичи, растёт стоимость повышения отказоустойчивости и т.п.) за исключением 5.6.x, но её всё никак не зарелизят, хотя анонсировался прирост производительности на операциях записи innodb в два и более раз. У всяких Percona и MariaDB производительность существенно выше, чем у MySQL тех же версий, но Percona под Windows нету, а под MariaDB надо малость допилить ukmserver.exe..

Нам переход на 5.1.61 потребовался для налаживания репликации БД на резервный сервер. Дело в том, что у 5.0.86 есть, по крайней мере, одна ошибка, из-за которой в УКМ версий 49 и далее на SLAVE не обеспечивается целостность данных. В 5.1 этой ошибки нет. Так что если репликация не используется (и не рекомендована сервисплюсом - из-за какой-то другой ошибки, у нас не проявлялась) - 5.1.61 нафиг не надо.
16.01.2013 18:26
Aleks_Str
 
Это в том случае, если стоит 64 винда. У меня, к сожалению, 32 разрядная.
16.01.2013 20:10
Onesoft
 
Цитата:
Aleks_Str Это в том случае, если стоит 64 винда. У меня, к сожалению, 32 разрядная.
Хм.. Ну тогда и 64-й MySQL не запустится, и дёргаться никакого смысла нет.

Но настройку

thread_cache_size=500

лучше попробовать сделать в любом случае - производительность должна уже ощутимо возрасти.
17.01.2013 09:12
Aleks_Str
 
В том то и дело - хотю попробовать переустановить винду до 64 бит. Отсюда и "зондирование" вопроса про совместную жизнь УКМ-а и 64-битного MySQL-я.
17.01.2013 20:00
OlegON
 
Я бы, наверное, подумал на тему "оставить как есть" текущую винду с УКМ, а вот базу перенести на 64-битный Linux
17.01.2013 21:15
Onesoft
 
Цитата:
OlegON Я бы, наверное, подумал на тему "оставить как есть" текущую винду с УКМ, а вот базу перенести на 64-битный Linux
Сам об этом подумываю, тем более, что ещё лет шесть назад, будучи сервисплюсовцем, исследовал эту тему по запросу от vdm.. Но тогда разработчики не поддержали данную инициативу, объяснив это тем, что усложнится управление, обновление, а главное - потребуется провести большую работу по обеспечению отказоустойчивости.. Конечно, если это, скажем, пара современных блейд-серверов с системой самодиагностики и прогнозирования сбоев, которые находятся в одной стойке и в одной корзине, то вероятность разрыва связи сравнительно мала.
Но в сервере УКМ постоянно работает куча процессов, обслуживающих кассы, WEB-интерфейс, систему защиты, конвертеры импорта-экспорта данных (каждый работает отдельным потоком), обработку поступающих чеков, обслуживание он-лайн сервисов, счетов клиентов, кассовых документов, системы видеоконтроля кассовых операций и т.п. Каждый из них работает с БД, и неизвестно, как поведут себя данные сервисы в случае разрыва связи с БД, что в этом случае будет с обслуживаемыми данными сервисами остальными компонентами системы, а также неизвестно, что может произойти после её восстановления, возобновят ли работу сервисы в полном объёме и не нарушится ли целостность данных в БД.. Кроме того, если налаживать резервирование БД методом репликации данных MASTER-SLAVE, то нужен третий сервер. Поэтому нас пока вполне устраивает более экономичная схема с двумя Windows x64 серверами с репликацией данных MASTER+SLAVE:
1. рабочий, УКМ сервер + MySQL MASTER;
2. резервный, УКМ сервер "ручного запуска" в состоянии "остановлен" + MySQL SLAVE.
Производительности такой системы вполне хватает.
Все устанавливаемые патчи, скрипты, принтеры для печати кассовых документов регулярно реплицируются специальным скриптом с рабочего на резервный, ключ защиты подключается через хаб AnywhereUSB, поэтому в случае дизастера на рабочем сервере время перевода резервного сервера в боевое состояние даже через удалённый доступ составляет не более пяти минут и включает в себя следующие операции:
1. деактивация SLAVE-настроек MySQL;
2. подключение ключа защиты к серверу;
3. активация служб ukmservice и apache в "автоматический" режим запуска;
4. смена IP-адреса, переименование сервера Windows, перезагрузка.

Можно ещё третий сервачок прицепить к этой связке, не очень производительный - только в качестве второго SLAVE-MySQL, реплицируемого с первого SLAVE, являющегося по отношению ко второму MASTERом ("каскадная" репликация), чтобы второй SLAVE продолжал реплицироваться как ни в чём ни бывало, и после восстановления работоспособности бывшего рабочего сервера можно будет сделать его первым SLAVE, скопировав БД со второго SLAVE.. Пока не знаю, реальна ли такая схема.. Как-нибудь ещё один стенд соберу себе, буду пытаться в этом направлении..
18.01.2013 06:53
Mtirt
 
Цитата:
OlegON Я бы, наверное, подумал на тему "оставить как есть" текущую винду с УКМ, а вот базу перенести на 64-битный Linux
Версия УКМ4 под Linux есть. Вполне работоспособная. Только я сейчас задумалась, 32 или 64-битный Linux там используется...
18.01.2013 08:14
Onesoft
 
Цитата:
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
forever
 
Цитата:
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
Onesoft
 
Настройка MySQL - процесс творческий и в какой-то степени непрерывный. Выбор оптимальных настроек зависит не только от железа, но так же от структуры БД и характера работы приложений с БД. В соседней теме приводились примеры различной степени загруженности БД СГО, так что даже в рамках УКМ характер работы с БД может меняться.
Недавно нашёл интересный ресурс, где описан подход к процессу оптимизации работы MySQL. Всё описанное в избытке гуглится. Много об оценке производительности пишет Peter Zaitsev - основатель Percona (форка MySQL). Ресурсов много!
01.08.2013 11:30
Aleks_Str
 
Итак, купили новое железо.
Ставлю УКМ.
Стпим УКМ и МуСкуль.
Перевожу МуСкуль на порт 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
Onesoft
 
Цитата:
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
whitewizard
 
импорт/экспорт какими командам делаешь? и версии mysql какие?
02.08.2013 08:16
Aleks_Str
 
БД источник: версия 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
Onesoft
 
Цитата:
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
Aleks_Str
 
Цитата:
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, время: 19:35.

 

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