NI
и поэтому больше пяти узлов ни у кого нет на галере
Size: a a a
2020 April 14
ЕО
на галере нет менеджера блокировок глобального. поэтому долбить в одну и ту же строчку с разных узлов нельзя из соображений производительности (будет много ролбеков). поэтому надо пользоваться блокировками одного узла (если все текущие изменения идут на текущий узел).
да это понятно из доки, режим оптимистичной блокировки, когда блокировка не распространяется на другие узлы
ЕО
т.к. все изменения надо применять на всех узлах одновременно и на всех узлах полная копия, не получается увеличить скорость за счёт применения DML одновременно на разных узлах. Поэтому надо делать rwsplit
апдейты на разных узлах бессмысленны, а селекты нужно распределять по всем
NI
в точку!
ЕО
у меня ситуация такая что сейчас я всё и селекты и апдейты направляю на один сервер
ЕО
и дедлоков на порядок больше чем было до галеры
NI
тогда проблема с дедлоками связана с тем что стало больше параллельных запросов
ЕО
вот что мне сделать чтобы с этим разобраться?
NI
скорее всего надо смотреть в сторону нормализации базы и выкидывания полей типа last_updated из mariadb чтобы избежать горячих строчек
NI
т.к. рано или подно оно завалит даже одиночный инстанс
ЕО
я читал что все таблицы должны быть с primary_key проверил - ок, движок innodb - ok, за исключением базы mysql, я так понимаю она вообще не учавствует никак
NI
не я не про это: вот есть у нас микросервисы, приходит запрос от клиента и параллельно уходит в 10 микросервисов. Каждый из микросервисов делает дело и выставляет дату в last_access_date
ЕО
даже query_cache отключил
NI
получаем в случае одного сервака всё более-менее мгновенно срабатывает, пока клиентов мало (не миллионы на инстанс в сутки).
NI
когда у нас появляется галера, даже с одним писателем каждая транзакция требует сертификации. Да сертификации приходят пачками, но у нас теперь дольше висят запросы и после точки синхронизации, следующие транзакции могут начать менять те же строчки в двух и более табличках в разном порядке, а это дедлок
NI
т.е. было^
a1 => a2 => a3 ; b1 => b2 => b3 используя один процессор.
а стало:
a1 зависло на сертификации в это время уже пошло b1, в результате a2 и b2 завершились одновременно и a3 и b3 заработали параллельно. а так как a3 обновляет сначала users а потом posts. а b3 обновляет сначала posts а потом users и это дедлок
a1 => a2 => a3 ; b1 => b2 => b3 используя один процессор.
а стало:
a1 зависло на сертификации в это время уже пошло b1, в результате a2 и b2 завершились одновременно и a3 и b3 заработали параллельно. а так как a3 обновляет сначала users а потом posts. а b3 обновляет сначала posts а потом users и это дедлок
ЕО
спасибо, ушел думать
ЕК
скорее всего надо смотреть в сторону нормализации базы и выкидывания полей типа last_updated из mariadb чтобы избежать горячих строчек
а как тогда быть когда надо знать когда строка была обновлена ?
NI
обязательно проверять ошибки и посылать повторно транзакцию. печатать дедлоки в error-log и разбираться как они произошли
AK
кто разговаривал с English native speakers, кто-либо из них произносил
MySql как Май сиквл?Американцы почти все говорят my-sequel, им так привычнее. И китайцы тоже так произносят, им так язык удобнее выворачивать. my-s-q-l произносит жалкая кучка старперов типа меня, которые знают, как Монти произносит )