Разработка модуля MySQL

[Render_ 0]

шансы 50/50 - это как? Оборвется либо не оборвется? )))

да имеено так.

2. Оставить схему работы ту же и искать пути решения проблемы в подстановке костылей.

Например при соединении задать таймаут соединения в несколько минут. Сервер по истечении таймаута будет отключаться, а модуль будет тут же подключаться заново.

Или можно перед выполением запроса в БД делать проверку соединения контрольным запросом и в случае невозможности выполнения запроса рвать соединение и создавать заново.

вот что нам нужно.

[Колян 2]

шансы 50/50 - это как? Оборвется либо не оборвется? )))

 

Выскажу и свое имхо.

Уверен, что дампы - это то самое зло, уйти от которого и было целью при создании модуля. Мы уже проходили все проблемы с файлами, потерей данных и пр.

Вы же предлагаете вернуться к этому же.

 

Вариантов решения проблемы на сегодня два.

1. Полностью переделать схему работы с mysql-сервером по принципу "connect - query - answer - disconnect". Здесь возможны варианты. Можно, например, формировать очередь из запросов и выполнять запросы в БД с какой то периодичностью. Однако это тоже чревато потерей данных в случае аварийного завершения работы сервера или еще чего то.

 

2. Оставить схему работы ту же и искать пути решения проблемы в подстановке костылей.

Например при соединении задать таймаут соединения в несколько минут. Сервер по истечении таймаута будет отключаться, а модуль будет тут же подключаться заново.

Или можно перед выполением запроса в БД делать проверку соединения контрольным запросом и в случае невозможности выполнения запроса рвать соединение и создавать заново.

Это все нюансы. Главное определить принцип работы.

 

Однако дампы... файлы... - не тот путь! ИМХО.

Первое ИМХО более надежно чем второе.

[Ork Yason 8]

хм...

я конечно не силен в майскле

но не могу понят, а почему нельзя при коннекте пользователя открыть ему сессию и держать ее до его онконнекта? даже если учесть что база на 1000 абонентов, 30%онлайн, то 300соединений для нормального сервера не большое число

 

с учетом того, что данные срыгиваются раз в 10минут, отдельным процессом, а пользовательские делают то, что пишут остатки по счетам и какие-либо мелкие изменения, т.е. работают с таблицами размером, соизмеримым с кол-во поьзователей

 

по поводу дампов

СУДБ - дают реальный прирост в скорости. это факт, иначе оракла бы не придумали...

[Ork Yason 8]

стоп

 

сессия одна

это сессия модуля майскла к самому майсклу

в ней он делает все что ему нужно

а вот тайм-аут не нужен

оно должна жить всегда, пока жив модуль майскла+стг

 

можно еще одну создавать при сливе данных раз в 10минут

 

а вообще, хреново жить без транзакций...

 

биллинг на майскле... ой...

[vop 370]

Уверен, что дампы - это то самое зло, уйти от которого и было целью при создании модуля. Мы уже проходили все проблемы с файлами, потерей данных и пр.

Я прошу прощения, но проблема была не в файлах, а в программистах. Надо код писать надежный, а не искать проблемы с файлами. Если этого не понять -то будут проблемы и sql, и с чем угодно.

[Колян 2]

Ну посмотрим, что разработчик скажет. Я свое мнение насчет коннекта выразил, возможно учтут, возможно писал просто так, для себя. по крайней мере, пока модуль тестовый, нужно пробовать, по крайней мере так. И из двух зол выбрать лучшее.

[Max 0]

Уверен, что дампы - это то самое зло, уйти от которого и было целью при создании модуля. Мы уже проходили все проблемы с файлами, потерей данных и пр.

Я прошу прощения, но проблема была не в файлах, а в программистах. Надо код писать надежный, а не искать проблемы с файлами. Если этого не понять -то будут проблемы и sql, и с чем угодно.

хочу заметить что баг не в самом модуле, а в Сервер БД (MYSQL) это кстати признали и сами разработчики мускула, однако править отказались по неведомым причинам...

[Колян 2]

И кто теперь меня поддержит, раз на то пошло?

[platerx 0]

Итак по поводу схемы присоединился - записал/прочитал - отсоединился:

Сброс данных а базу происходит с определенным промежутком, по умолчанию 10 мин. Предположим у нас 200 пользователей. 10 мин = 600 сек. Т.е. на запись данных об одном пользователе выделяется 3 сек. Коннект с базой и закрытие соединения суммарно занимают 0.004 сек. (Я писал простейший тест. Кому надо могу выложить исходники.) для 200 коннектов время будет 1 сек. т.е. из 600 сек 1 сек будет тратиться на коннекты. По моему это приемлемо. Конечно это грубый подсчёт, необходимы более реальные тесты. Сейчас тестируется есть модуль в котором реализована именно эта схема.

 

По поводу первоначальной схемы: В версии модуле 0.63 есть серьёзные ошибки(в плане работы с функциями mysql), есть подозрения, что именно из за этих ошибок он работает неправильно, но что бы их исправить нужно переписать много кода, и возможно изменять сам stg. И нет 100% гарантии, что именно из за этого мы имеем потерю соединения. Может это проблемя самго mysql.

 

Поэтому если при тестировании модуля в котором реализована схема присоединился - записал/прочитал – отсоединился не будет серьёзных проблем с производительностью, то мы остановимся на ней. Иначе будем исправлять модуль с первоначальной схемой работы.

[Колян 2]

Итак по поводу схемы присоединился - записал/прочитал - отсоединился:

Сброс данных а базу происходит с определенным промежутком, по умолчанию 10 мин. Предположим у нас 200 пользователей. 10 мин = 600 сек. Т.е. на запись данных об одном пользователе выделяется 3 сек. Коннект с базой и закрытие соединения суммарно занимают 0.004 сек. (Я писал простейший тест. Кому надо могу выложить исходники.) для 200 коннектов время будет 1 сек. т.е. из 600 сек 1 сек будет тратиться на коннекты. По моему это приемлемо. Конечно это грубый подсчёт, необходимы более реальные тесты. Сейчас тестируется есть модуль в котором реализована именно эта схема.

 

По поводу первоначальной схемы: В версии модуле 0.63 есть серьёзные ошибки(в плане работы с функциями mysql), есть подозрения, что именно из за этих ошибок он работает неправильно, но что бы их исправить нужно переписать много кода, и возможно изменять сам stg. И нет 100% гарантии, что именно из за этого мы имеем потерю соединения. Может это проблемя самго mysql.

 

Поэтому если при тестировании модуля в котором реализована схема присоединился - записал/прочитал – отсоединился не будет серьёзных проблем с производительностью, то мы остановимся на ней. Иначе будем исправлять модуль с первоначальной схемой работы.

Ну что сказать, я рад! Жду с нетерпением релиза (с бубном)!

[Alferov 0]

FreeBSD 5.4

Mysql - 4.0.26

STG - последняя сборка

store_mysql 0.65 (принцип работы: connect-query-answer-disconnect)

пользователей - 212 (AlwaysOnline)

 

Час эксплуатации - полет нормальный.

Увеличения нагрузки не замечаю. Наблюдаем дальше.

[Колян 2]

Что, уже релиз есть???

[Alferov 0]

я бы назвал это RC

Что то при остановке стг в корку вывалился один раз.

[Колян 2]

Ну от офф разработчика подождем, увидим что будет. Я же знаю, что я говорю! Как видите, нагрузки больше не стало.

[Cell 7]

FreeBSD 5.4

Mysql - 4.0.26

STG - последняя сборка

store_mysql 0.65 (принцип работы: connect-query-answer-disconnect)

пользователей - 212 (AlwaysOnline)

 

Час эксплуатации - полет нормальный.

Увеличения нагрузки не замечаю. Наблюдаем дальше.

Ну что там после суток?

[Max 0]

http://www.opennet.ru/opennews/art.shtml?num=11405

касаемо мускул прокси

[Alferov 0]

Сутки эксплуатации - полет нормальный.

Никаких нареканий пока нет. Тьфу 3 раза. ))

[zulu_Radist 856]

Alf где взял RC? Почему бы не выложить на тест и остальным?

[Колян 2]

Это Альферова разработака, мало ли что... А вдруг заглючит оно у тебя в самый ответственный момент? Подождите уже наверное офф разработчика.

[Alferov 0]

Это оф.разработка. Я просто тестирую.

Думаю стоит подождать релиза. Бету не имеет смысл раздавать.

 

п.с. не альферов, а алферов. Мягкий знак лишний.

[Колян 2]

Это оф.разработка. Я просто тестирую.

Думаю стоит подождать релиза. Бету не имеет смысл раздавать.

 

п.с. не альферов, а алферов. Мягкий знак лишний.

А мне не дадите протестить? Все равно он валяется постоянно, я кстати уже и скрипт написал для поднятия СТГ.

[Alferov 0]

http://local.com.ua/forum/index.php?showto...=90entry63151

[Max 0]

доступна официальная стандартная версия, брать сдесь: http://www.v-lan.ru/projects/stargazer-2.4/Modules/

[Колян 2]

Теперь ждем патча от Альферова, чтобы работала его статистика.

[zulu_Radist 856]

Теперь ждем патча от Альферова, чтобы работала его статистика.

Уже пропатченный, судя по ответу Альфа, можно взять здесь:

 

http://alf.uzlovaya.ru/stg/stg-web/mod_sto..._STG-WEB.tar.gz

 

Я еще не проверял, завтра буду пробовать, я чуток не в трезвом состоянии =:-/