MySQL x64 : УКМ-4

Ты писал про 5.1.61
почему не 5.1.62 ?

Потому что 5.1.61 была протестирована в С+.
Но нами уже успешно протестирована даже 5.1.66 (тупая замена папки bin). Просто чё-то руки пока никак не дойдут до обновления бинарников.. СУБД днём и ночью нагружена, стопить надо..

Правильно-ли я понял, что алгоритм должен быть следующим:
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. запускаем УКМ
и в итоге получаем "быстрый" СГО?

Не так.

А вот так:

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

Но это только относительно 5.0.86!!!
У 5.1.х есть свои нюансы..

Первым шагом, который можно сделать в этом направлении - задать значение параметра 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 нафиг не надо.

Это в том случае, если стоит 64 винда. У меня, к сожалению, 32 разрядная.

Хм.. Ну тогда и 64-й MySQL не запустится, и дёргаться никакого смысла нет.

Но настройку

thread_cache_size=500

лучше попробовать сделать в любом случае - производительность должна уже ощутимо возрасти.

В том то и дело - хотю попробовать переустановить винду до 64 бит. Отсюда и "зондирование" вопроса про совместную жизнь УКМ-а и 64-битного MySQL-я.

Я бы, наверное, подумал на тему "оставить как есть" текущую винду с УКМ, а вот базу перенести на 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.. Пока не знаю, реальна ли такая схема.. Как-нибудь ещё один стенд соберу себе, буду пытаться в этом направлении..