нашел чел написал на stackoverflow Remember that UPDATE, DELETE, and SELECT ... FOR UPDATE will lock all rows they encounter, whether those rows match all WHERE conditions or not. однако в доках че-то не могу найти про "or not", вроде как лочить должно только те строки которые "match all WHERE"...

Ну ты полные транзакции покажи

все строки оно лочит если индекса нет по полям из where

Ну или SHOW ENGINE INNODB STATUS

вот http://pastebin.com/wVvz4Rti

я никак понять не могу, кажется что оно лочит все строки по второму индексу игнорируя AND...

а хде WE ROLL BACK TRANSACTION ;)

косяк...вроде как там было *** WE ROLL BACK TRANSACTION (1)...

толжен еще быть второй WAITING FOR THIS LOCK TO BE GRANTED

второй пишет мол *** (2) HOLDS THE LOCK(S): ...

Ну держит, один держит, другой ждет - никаких проблем ;) Для дедлока оба должы ждать друг друга, по-этому (2) waiting еще должен быть

И там в этой транзакции еще что-то есть? Возможно, работа с другими таблицами связанными с этой внешним ключем

мм user_id это внешний ключ к таблице пользователей (on delete cascade on update no action). В принципе запись пользователя может быть залочена FOR UPDATE но это вроде как не должно влиять на другую таблицу (т.к. on update no action)...

и в этой транзакции вообще только update один (без явного открытия транзакции begin)

поймал ещё 1 http://pastebin.com/taSGaf85 в прошлый раз криво скопировал, действительно там есть *** (2) WAITING FOR THIS LOCK TO BE GRANTED: там insert'ы ещё идут в эту таблицу, они делают gap-lock получается? (locks gap before rec insert intention waiting)

да, по-этому я и говорю, что нужны все запросы транзакции.... статус говорит о текущей ситуации, но не говорит о предшествующей.

но против гап локов можно понизить до READ COMMITTED изоляции, правда нужно подумать, не помешает ли это где-то в другом месте

но там где update, там больше ничего нет, insert'ы они в параллельных потоках...

ещё сделал комбинированный индекс (из двух которые во where), и вроде как это помогает, но не понимаю почему...

Привет всем. Подскажите пожалуйста, есть ли возможность глянуть как curl формирует данные при отправке запроса?

Как вариант, используй ngrok какой-нибудь, или промежуточный сервер который покажет какие запросы приходят

ммм спасибо

консольный курл может -vvv

а если php curl то http://php.net/manual/ru/function.curl-getinfo.php

Спасибо

А не подскажете ещё, как можно заставить curl отправлять post данные методом form-data а не x-www-form-urlencoded?

curl -d "tytData" http://example.com

я бы сказал он по умолчанию отправляет

просто данные

если постом

а если нужно сделать x-www-form-urlencoded - то нужно доп заголовок передавать

1.5 часа, нагрузка растет, дедлоков нет после добавления комбинированного индекса... получается на stack'е правильно написали Remember that UPDATE, DELETE, and SELECT ... FOR UPDATE will lock all rows they encounter, whether those rows match all WHERE conditions or not. Что оно лочит отдельно по индексам все строки, но в доках я этого не нашел что-то...

а с помощью чего вы делаете апдейт?

мм всмысле? php mysqli...

ORM используется какая-нибудь?

или mysqli_query('sql')

да ORM есть, но я отлажимаю по скомпилированным sql запросам, там получается чисто 1 update и никаких begin transaction

и на нем был дедлок http://pastebin.com/taSGaf85

а перед апдейтами есть select?

хотя в InnoDB блокировка при update автоматом ставится

то есть пока update не сработает второй апдейт будет ломаться изза блокировки

но опять же блокировки должны быть только в транзакциях

а тут их и не видно

select есть, но он простой, без FOR UPDATE, BEGIN TRANSACTION и пр. Я как понял, update ставит блокировку по всеи индексам во where индивиуально, а не только на строки которые попадают под all where condition... т.е. в моем случае он выбирал отдельно bh_is_new=1 со всем таблицы и ставил на них блокировку... Иначе я не знаю как объяснить факт пропажи дедлоков после добавления комбинированного индекса

http://www.mysql.ru/docs/man/InnoDB_Locks_set.html

UPDATE ... SET ... WHERE ...: устанавливает эксклюзивную блокировку следующего ключа для каждой записи, по которой производится поиск.

но это только в транзакции должно быть

ну транзакция там автоматом создается при update. Но дело в том, что у меня поиск идет по index_1 AND index_2, а он получается ставил лок отдельно на все строки index_1, index_2 и из-за этого по index_2 получался дедлок...ну или как-то так...

короче при поиске оно AND игнорировало, как я понял..

а сколько в базе записей?

560к

1.5 часа, нагрузка растет, дедлоков нет после добавления комбинированного индекса... получается на stack'е правильно написали Remember that UPDATE, DELETE, and SELECT ... FOR UPDATE will lock all rows they encounter, whether those rows match all WHERE conditions or not. Что оно лочит отдельно по индексам все строки, но в доках я этого не нашел что-то...

так оно и в статусе написано было RECORD LOCKS space id 263 page no 12210 n bits 1576 index bh_is_new of table main.hp_balance_history trx id 9A512C4 lock_mode X

да, но я думал что может там что-то другое имеется ввиду... потому что вроде как лочить должно было строки где user_id=N AND is_new=1 ...

меня смущает mysql tables in use 2, locked 2

мм это значит типа 2 таблица используется при выборке?

угу.. хотя это может по вневшнему ключу затрагивается...

да, но я думал что может там что-то другое имеется ввиду... потому что вроде как лочить должно было строки где user_id=N AND is_new=1 ...

А инсерты у тебя тоже без транзакции идут? Что-то у меня подозрение, что там дедлок из трех транзакций

инсерты в транзакциях

пачка в одной транзакции, да?

не, просто разные другие операции и инсерт в историю

ясно, что не ясно... не складывается картина, но я в общем и не очень в этих гаплоках ;) столько подводных камней в этом иннодб ;)

вообще там есть такая штука innodb_locks_unsafe_for_binlog и многие вроде как её включают...

но я пока не разобрался стоит ли...тем более, кажется, объединение индексов помогло..

да объединение поможет, факт... мне просто механизм появления этого дедлока интересно понять

в иннодб запросто можно получить дедлок когда в одной транзакции просто select :)

ERROR: S client not available

ну если update лочило все is_new=1 и во время инсерта получается is_new=1...видимо как-то тут gap lock накладывается...

Ребят как правильно перенести базу с phpmyadmin (marinadb) в azure mysql server ?) я тут пытался обычный експорт, не катит.

nadezhdadb

А просто скачать дамп и загрузить его в azure не прокатывает?

Привет, ребят как перевести шаблон html в smarty?

зачем?

юзай php как шаблонизатор

прочитай документацию про смарти, переведи шаблон html в смарти

Видимо для этого достаточно переименовать .html в .tpl

хорошо спасибо

nfs для винды под ваграндом все же чуточку быстрее нативной виртаулбоксы

юзай php как шаблонизатор

с xss будешь вручную бороться?!

Почему такую ошибку выводит ? если выводить массив $record_db выводит все, а если заливать в таблицу выводит ошибку http://pastebin.com/kXWACsU5

это php глючит ;)

вообще в ошибке есть всё, чтобы ее исправить

Можешь подсказать?

берешь словарь и переводишь каждое слово

Я знаю что там написано

ожидала параметр 1

и что не так с первым параметром?

хз

Подскажи пожалуйста

Блин, не получается. Если делать tocuh файла внутри варанта, то шторм начинает ругаться про измененный файл... что бы такого сделать, что бы и шторм не заметил, и inotify сработало ;)

Все я решил проблему, спасибо, за небольшую помощь ?

а нет ли какого канала с телеграме... типа #plyat_kak_vy_jivete_s_etim_vagrantom

а мы с ним не живем

а тех, кто не живет - и не спрашиваем

и как же теперь не высказаться? это как вегетарианца спросить про вред мяса!

да твой докер не лучше... тут же проблема не в вагранте, а в виртуалбоксе

вагрант выкинули, запилили контейнеры, перестали мучаться с виртуалками - установили десктопный линукс, написали compose, задеплоили registry, прописали сертификаты