[ТЕМА ЗАКРЫТА]
09.12.2008 14:31
XsevenBeta
 
В 42сп4 часто намертво лочится таблица отвечающая за продажи со счета клиента
( Error Code : 1213 Deadlock found when trying to get lock; Try restarting transaction (265 ms taken))

Запрос который не может выполнится:
insert into local_auth_account_journal(account_id,amount,date,source_type,source_id,cash_id,comment,balance,action_date)
(select '515200' as acc_id, '5808.89' as amount,case when '5808.89' = 0 then l.date else '2008-11-06 14:31:01' end as date,2 as source_type,
'1603' as source_id,0 as cash_id,'перенос с карты B29344' as comment,IFNULL(l.balance,0)+'5808.89' as balance,NOW() as action_date
from local_auth_account_journal l
where l.account_id = '515200' and
l.date <= '2008-11-06 14:31:01'
order by l.date DESC,l.id DESC)
UNION (select '515200' as acc_id, '5808.89' as amount,'2008-11-06 14:31:01' as date,2 as source_type,'1603' as source_id,0 as cash_id,'перенос с карты B29344' as comment, '5808.89' as balance, NOW() as action_date )
LIMIT 1

------------
Вопрос - как разлочить таблицу без перезагрузки мускул-сервера? Радченко Алексей сказал что разработчики это пофиксили в последних версиях 45ой, но мы 46ую ждём где для нас много вкусного наобещали реализовать...
В мануалах и факах не удалось найти :(.
09.12.2008 14:46
XsevenBeta
 
Вообще, поразительно настолько через жопу так считать баланс каждый раз.

И вот этот скрипт на сервере постоянно крутиться после дедлока начинает:
select a.id, t.type from trm_in_account_type t left outer join local_auth_account a on a.account_type_id = t.id and a.params = 'A01406' where t.id = 8 and t.global_id = 0 and t.deleted = 0
09.12.2008 15:02
OlegON
 
Стало интересно...
Может в InnoDB перевести?
Цитата:
InnoDB автоматически обнаруживает взаимоблокировку транзакций и производит откат транзакций, запрос на блокировку которых вызвал возникновение взаимоблокировки, то есть замкнутого цикла в графике ожиданий транзакций. InnoDB не может обнаружить взаимоблокировку, установленную оператором MySQL LOCK TABLES, или блокировку, установленную отличным от InnoDB обработчиком таблиц. Такие ситуации необходимо исправлять при помощи параметра innodb_lock_wait_timeout, который задается в `my.cnf'.
Когда InnoDB выполняет полный откат транзакции, все блокировки, установленные транзакцией, снимаются. Тем не менее, если в результате ошибки производится откат только одного оператора SQL, некоторые блокировки, установленные оператором, могут остаться в силе. Это происходит потому, что InnoDB хранит блокировку строк в формате, по которому впоследствии нельзя определить, каким оператором SQL была установлена блокировка.
09.12.2008 15:23
XsevenBeta
 
Таблица в InnoDB и так :(. В client_account_manage.php используется GET_LOCK().
А сделать RELEASE_LOCK() можно только зная стринг по которому делалась лочка...
09.12.2008 15:24
XsevenBeta
 
innodb_lock_wait_timeout=300 стоит..
09.12.2008 15:30
OlegON
 
А зачем ты ее разлочиваешь? Она же через 5 минут должна сама отваливаться...
09.12.2008 15:37
XsevenBeta
 
Она час может простоять и не разлочится.
10.12.2008 09:45
7fox7
 
А какое побочное действие этот лок вызывает?
10.12.2008 11:55
XsevenBeta
 
Очень серьёзные.
Не проходит расчёт с юр.лицами.
Не возможно зачислить деньги на безнальный счёт/завести новый безнальный счёт.
10.12.2008 13:10
7fox7
 
А сессия которая залочила таблицу в списках show process list висит?



Место лока конечно очень нехорошее и особо баловаться там чревато, появлением или недопоявлением сумм у клиента.



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

Хотя все это попахивает багами самого мускуля.

И еще, после чего происходит блокировка таблицы? Она постоянная или редкая? Может она происходит когда во время транзакции связь сервера с кассой рвется.
12.12.2008 03:17
isi
 
Оффтоп
Блин, ну кто придумал коммерческие продукты на mySql е делать... ну не для этого эта СУБД
12.12.2008 13:09
7fox7
 
Цитата:
isi Оффтоп
Блин, ну кто придумал коммерческие продукты на mySql е делать... ну не для этого эта СУБД
Позволю себе тоже оффтопнуть, хотя топик то все таки о mysql.

Отличная СУБД в своей нише маленьких БД, к тому же зародившийся на опенсурсе, с достаточно богатым инструментарием. Такие корпорации как Sun гавно покупать не будут.

К InnoDB присморелись многие производители коммерческих СУБД после того, как в тестах по скорости выборки данных, данная СУБД уделала в некоторых аспектах таких как MSsql, и Oracle.

Что касается использования в коммерческих проектах, то вопрос не простой. Кто виноват, любители-профессионалы, которые бесплатно это родили, или профессионалы которые сделали продукт с использование этой БД и недостаточно протестировали используемый функционал. Или вообще те люди, которые решили поставить себе это ПО.

Кстати от багов, ни одно ПО не застраховано. И если взглянуть на самые свежие версии, то там подобные вещи сплошь и рядом.

Коммерческое ПО гарантирует(относительно) вылизанность внешнюю. Упрощенную установку и удобство использования. У опенсурса вылизанность внутренняя, код, дыры. Но опять же, абсолютно никто не гарантирует на практике, что не вылезет что нибудь конкретно в условиях ваших, гарантии только на словах. А вот верить им или нет, уже от каждого конкретного индивидума зависит.

p.s. ух разнесло меня :)
16.12.2008 01:00
shebdim
 
Цитата:
isi Оффтоп
Блин, ну кто придумал коммерческие продукты на mySql е делать... ну не для этого эта СУБД
После ответа 7fox7 сложно что-то добавить. Я лишь напомню, что Open Source и халява тождественны только у нас на Родине. Речь идёт только о лицензировании. Коммерческое ПО существует за счёт продажи кода, а открытое ПО - за счёт сопровождения кода. То есть если вы в состоянии самостоятельно его сопровождать, то поддержку вы можете не покупать.

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

Что касается самого вопроса блокировки таблиц, то я предлагаю изучить ситуацию вдоль и поперёк уже на 46 версии, поскольку такой проблемы быть может там и не возникнет, плюс ко всему начиная с 46 версии мы берём курс на стабилизацию продукта и вылавливать поверхностные и глубинные проблемы будет для нас первоочередной задачей.
Опции темы


Часовой пояс GMT +3, время: 11:51.

 

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