MySQL x64 : УКМ-4

5.1.61.x64.7z

Что значит - не прокатило? То же самое при запуске ukmserver?

Вот это-то как раз противоестественно, т.к. MySQL в конфигурации по-умолчанию сильно отличается от конфигурации для УКМ.

А вот это вот ты как понял? У нас мускул использует инишник, который лежит в windows, а в папке data только auto.cnf с гуидом сервера.

У меня процесс установки MySQLx64 на винду был несколько иным

!!! Предварительно остановил службы УКМ и MySQL и скопировал папку с базой в потаенный уголок (так сказать, холодный бэкап) !!!

Версия: mysql-noinstall-5.1.69-winx64 (zip)

1.
Распакован в папку C:\MySQL64

2.
Установлен командой:
"C:\MySQL64\bin\mysqld" --install "MySQL64" --defaults-file="C:\MySQL64\my.ini"
(понятно, что в будущем my.ini должен существовать)

3.
Всем службам (MySQL, MySQL64, UkmService) присвоен статус "отключена", службы остановлены

4.
Папка C:\MySQL переименована в C:\MySQL32
Папка C:\MySQL64 переименована в C:\MySQL

5.
Библиотека C:\MySQL\bin\libmysql.dll скопирована в папку C:\PHP как libmysql64.dll
(Апач очень старый, но менять не стал, а библиотеку скопировал на будущее, httpd.conf не редактировал)

6.
Реестр (работал в regedit):
Раздел HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MySQL переименован в HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MySQL32
В пункте DisplayName прописал MySQL32
В пункте ImagePath прописал C:\MySQL32\bin\mysqld.exe MySQL32
Раздел HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MySQL64 переименован в HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\MySQL
В пункте DisplayName прописал MySQL
В пункте ImagePath прописал C:\MySQL\bin\mysqld --defaults-file=C:\MySQL\my.ini MySQL
обновил по F5, убедился, обрадовался

7.
Сервер перезагружен для принятия новых настроек

8.
Корректировка C:\MySQL\my.ini только для старта и захвата БД

9.
Запуск службы MySQL и проверка подключения к БД (бд mysql мы же не меняли, значит usr/пароли не поменяются)

10.
Запуск службы UkmService

11.
Проверка состояния конвертеров и адаптеров, смотр логов сервера и укм

12.
Смена параметра запуска служб MySQL и UkmService на "Авто"

Далее, настройка my.ini уже более точно под условия железа или потребности

забыл уточнить, если кто не обратил внимание, то активный my.ini теперь будет лежать в C:\MySQL\my.ini

Простите, опять забыл указать, что начинал с тестовой машинки
OS: Windows Server 2008 R2 Enterprise (x64)
CPU: Intel Xeon CPU E5-2620 (два ореха по 2.00Ghz)
ОЗУ: 16Гб
MySQL изначально: mysql-5.1.69-winx32
Размер тестовой БД: ~600 Gb

Далее эти действия повторил на рабочей СГО, все ускорилось значительно

Буквально через несколько недель будем собирать кластера
у нас будет 3 СГО - 1 мастер, 2 реплики, реплики будут по ночам поочередно уходить в бэкап (для уменшения времени опаздывания)

Если кому интересно, поделюсь

На самом деле всё гораздо проще:
0. резервная копия папки data;
1. в папке c:\mysql надо заменить папки bin и share прежней x86 версии на соответствующие от версии 5.1.69 x64;
2. в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MySQL отредактировать ImagePath с "C:\mysql\bin\mysqld-nt.exe MySQL" на "C:\mysql\bin\mysqld.exe MySQL";
3. при запуске следить за логами *.err и заменять устаревшие параметры (например, удалить параметр skip-bdb);
4. после устаканившейся работы сервера MySQL выполнить mysql_update.exe;
5. можно запускать ukmserver и проверять на отсутствие ошибок функционала.

В идеале, конечно, хорошо бы перезалить ukmserver через дамп (слить в 5.0, залить в 5.1). А если используется репликация БД master-slave (или master-master), то ещё до перехода на 5.1 надо допилить все хранимые процедуры и функции на deterministic или reads sql data.

я пробовал по подобному сценарию, но ввиду наличия эроров уже на начальных этапах, решил пойти по тому пути, что я рассказал, вот тогда все стартануло с первого раза и без проблем
да и пути в реестре пришлось менять обширнее, так как я люблю когда у меня все в одном месте лежит, потому и my.ini положил в папку мускула + я не брал старый, от него толку небыло, я настроил все заново и с нуля
а старую службу я не убивал оставляя записи в реестре, так как в случае серьезных проблем, я мог потратить минут 10 и вернуть все на круги своя, бдшники слово "откат" должны написать кровью на доске 100 раз)
я даже экспорт веток реестра сделал на всякий случай
и вопрос: боюсь показаться глупым, но
mysql-nt.exe - это наверное нечто особо раннее? просто не встречал(
если это 5.0 то этот вариант мне точно не подходит
я версионность не менял, это однозначно, мне в с+, скажем так, не рекомендовали
а портить отношения не хотелось...

Ну, я с десяток раз менял x86 на x64 тупой заменой папок bin и share и ни разу не было никаких эроров - им там просто неоткуда взяться, потому как вся функциональность остаётся той же самой (разумеется, когда замена папок идёт в пределах одной и той же версии). my.ini затем можно менять по своему вкусу и возможностям железа.

Откат в случае с СГО становится очень большой проблемой, если приходится откатываться к состоянию предыдущих суток и ранее, и проблема не в trm_out_* - они-то дойдут, а проблема, например, в local_auth_account_journal, записи в которой надо каким-то образом восстанавливать, а так же в таблицах кассовых документов.. Один раз мне приходилось откатываться - больше я стараюсь не допускать до такой необходимости, потратив больше времени на подготовку и отработку всех моментов на стенде.

Ну, во-первых, С+ до сих пор во всех дистрибутивах использует 5.0.86, а во-вторых, С+ самим интересен опыт работы пользователей УКМ 4 на других версиях MySQL, вот и для нас, например, они сделали доработку № 5285, чтобы УКМ 4 мог работать на используемой у нас 5.6.12 без допиливания в HEX-редакторе. А, в -третьих, ничто не мешает иметь стенд с родной версией MySQL и в случае возникновения проблем в функциональности УКМ сообщать об этом в С+ после подтверждения проблем на стенде.
И, кстати, замена libmysql.dll не требуется.

так я libmysql.dll и не менял
а вообще, по поводу версий помоложе - это интересно
пожалуй у меня будет тема для разговора с С+
спасибо