Deadlocks in SQL - Turning Fear Into Understanding (by Sergii Stets)

Editor's Notes

• #1: Дякую Ірино. Вітаю колеги, дякую усім, що приєднались. Тема у нас сьогодні цікава, хоч і складна. Буду розповідати про дедлоки в SQL. I як обіціяє сам title презитнації я намагатимусь позбавити страхів стосовно дедлоків, та надам достатньо інформації для розуміння.
• #2: Класичний слайд про мене…Хто я такий? шо я тут роблю? I чого це мене потрібно взагалі слухати? На даному етапі я лід в компанії GlobalLogic. Я iз тих лідів, що не тільки люблять тасочки роздать а й трохи покодити. Вважаю себе більше технічною людиной, аніж людиною-менеджером. Але якщо треба щось порішать з точки зору менеджменту, то мені здається, що це в мене також виходить. Загалом якщо взяти, то у IT сфері з 2013, починав як trainee. Тому я звичайно знаю такі страшні слова як web.xml, jsp, servlet-и, скреплети. Увійшов в IT, коли це ще не було mainstream-м. Маю наразі AWS сертифікацію. Сертифікацію по джаві. Також є трастид інтервьюером. Провожду інтервью для зовнішніх та внутрішніх кандидатів.
• #3: Agenda... Про що ми сьогодні поговоримо? 1. Що таке делок 2. причини дедлоків 3. локи 4. конфігурація 5. монітронг 6. що таке sql dump, як його читати 7. deadlock prevention technics 8. приклади делоків у вигляді демо 9. секція q/a, де можна і треба задавати мені питтаня.
• #4: Дедлок виникає тоді, коли два якихось різних потоки (thread-a) перехресно хочуть заволодіти двома різніими обьєктами (чи ресурсами). При тому, перший thread володіє першим обєктом і бажає отримати другой обєкт, а другий thread володіє другим обєктом і бажає володіти першим. І ніхто не хоче поступатися.
• #5: Чи трапляються дедлоки в реальному житті? Відповідь – так, звичайно. Перший малюнок (ліворуч), ви могли потенційно бачити, якщо готувались до екзамену по (правилам дорожнього руху) ПДР. Ну це якщо ви здавали цей екзамен. Бо в цілому бути водієм і вчити ПДР, то різні речі  Для тих, кто не памятає, то на нерегульованому перехресті у нас діє правило перешкода праворуч. Але в данній ситцації у кожного є така парешкода, тому ми знаходимось у deadlock ситацїї. Яке ж тоді вирішення? Хтось має бути першим, а хтось останнім. Ну а стосовно другої картини, то тут рішення ніякого немає, бо це Київ. Київ це пробки. Просто чекаєш в пробках  Що це за ранок без пробок у Києві? В реальному житті таку ситуацію с трафіком не називають deadlock, a викорстовують спецальний термін: англійскьою він звучить gridlock (або “затор” українською). Grid lock (image with the cars) - https://en.wikipedia.org/wiki/Gridlock
• #6: Повернімося до баз даних. В базах даних є процес який автоматично виявляє дедлоки і вирішує їх (resolve-ть). Яким чином? Процес обирає одну із транзакцій і відкатує її (rollback), таку транзакцію називають deadlock victim (або жертва). https://dev.mysql.com/doc/refman/8.4/en/glossary.html#glos_deadlock_detection
• #7: Яким чином MySQL InnoDB engine обираю собі жертву? Тобто яка саме тразанкція продовже виконання, а яка буде затермінована? InnoDB обирає найменшу транзакцію. Розмір визначається кількістю рядків, які ми всталяємо, апдейтимо чи видаляємо, а також розміром undo log-a, який викростовує транзакція. https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlock-detection.html
• #8: Чому розробники побоюються deadlock-ів. ....Тому що :) Якісь причини точно є, наприклад 1. Вони не розуміють чи deadlock це поломка, чи expected behaviour. Чи це погано? Здається, що погано, але наскільки? 2. Не розуміють, як моніторити 3. Як траблшутити/репродюстити 4. Як фіксити https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks-handling.html
• #9: Що нам каже документація? Дедлоки це страшно чи ні? Каже, що дедлоки це класина проблема системю які мають справу з транзакціями. Вони не є небезпечними, до тих пір поки це не впливає на вашу апку. В цілому, ви повинні завжди бути гото https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks-handling.html
• #10: Коли може виниктути дедлок? Він може виниктути як уже було сказано в момент, коли різні траназакції блокують рядки в таблиці або в таблицях але у протилежному порядку. (я покажу вам це на прикладі під час демо). Також дедлок може виниктиту коли транзакції блокуть діапазаони знову ж таки в протилежному порядку. Тут я виділив пару ключових слів, серед яких є lock (блокування). https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks.html
• #11: Ну і перед тим як йти далі, було б непогано згадати, що таке взагалі locks (локи), для чого вони потрібні. Локи потрібні для того, щоб гарантувати consistency (цілісність) та isolation (ізоляцію), що є частинию принципів ACID (atomacy, consistency, isolation, durability), яким слідує RDBMS. Хоча ACID необмежена RDBMS і може застосовуватись до любої системи, що працює з транзакціями. Links: https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html Gap locks deadlock - https://www.youtube.com/watch?v=vYQXpvy1Nm4&ab_channel=RoelVandePaar
• #12: Record Lock (Блокування рядка): Це блокування застосовується до конкретного рядка у таблиці. Використовується для запобігання одночасного доступу до одного й того ж рядка під час транзакцій. Table Locks (Блокування таблиці): Застосовується на рівні всієї таблиці. Може бути спільним (shared) або ексклюзивним (exclusive): Спільне: дозволяє одночасне читання таблиці. Ексклюзивне: блокує всі операції, окрім тієї, що встановила блокування. Gap Lock Блокує проміжки між записами у індексі, щоб запобігти вставкам у ці проміжки. Використовується для забезпечення узгодженості (consistency) у транзакціях, які потребують повторюваного читання (REPEATABLE READ). Наприклад, якщо транзакція читає певний діапазон даних, Gap Lock гарантує, що нові записи в цей діапазон не будуть вставлені до завершення транзакції. Next-Key Lock: Це комбінація Record Lock та Gap Lock. Блокує рядок і проміжок перед ним, щоб запобігти вставкам, які могли б порушити порядок у індексі. Використовується для запобігання фантомним читанням (phantom reads). Auto-Increment Lock Управляє значенням автоінкременту під час вставки нових рядків. Забезпечує унікальність і правильний порядок згенерованих значень. Це глобальне блокування, яке діє на всю таблицю. Intention Locks (Інтенційні блокування IS/IX): Це сигнали про намір отримати спільне або ексклюзивне блокування на рівні рядків. IS (Intention Shared): транзакція планує отримати спільне блокування на окремих рядках. IX (Intention Exclusive): транзакція планує отримати ексклюзивне блокування на окремих рядках. Ці блокування працюють на рівні таблиці та сигналізують про можливі дії, дозволяючи уникнути конфліктів при блокуваннях рядків. Insert Intention Lock (Блокування наміру вставки): Використовується під час вставки нового рядка у таблицю. Блокує проміжок, але не для читання чи оновлення, а щоб запобігти конфлікту між кількома транзакціями, які вставляють у той самий проміжок. Interesting fact: It is not recommended to mix locking statements (UPDATE, INSERT, DELETE, or SELECT ... FOR ...) with non-locking SELECT statements in a single REPEATABLE READ transaction, because typically in such cases you want SERIALIZABLE. This is because a non-locking SELECT statement presents the state of the database from a read view which consists of transactions committed before the read view was created, and before the current transaction's own writes, while the locking statements use the most recent state of the database to use locking. In general, these two different table states are inconsistent with each other and difficult to parse. Links: https://dev.to/eyo000000/a-straightforward-guide-for-mysql-locks-56i1
• #13: https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks-handling.html То як хендлити дедлоки? Перший пункт не викорстовувати базу даних. Напевно, він нам не підходить. Якщо без жартів. То перший пункт, я би сказав, це зрозумiти, чи є проблема взагалі. Для цього нам потрібно правильно сконфiгурувати базу даних, щоб мати можливість отримувати детальну iнформацiю про deadlocks. Також нам потрібно налаштувати монiторiнг та alerting. Стосовно того, як зменишити появу дедлоків, то тут рекомендують, звертати уваги на порядок ваших операцій, бути готовим до того, що траназкцію потрібно повторити, в деяках випадках використовувати менше блокувань.
• #16: https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlock-detection.html https://medium.com/geekculture/how-to-deal-with-deadlocks-in-mysql-58f4d830788b https://aws.amazon.com/blogs/database/monitor-errors-in-amazon-aurora-mysql-and-amazon-rds-for-mysql-using-amazon-cloudwatch-and-send-notifications-using-amazon-sns/ This option is used to disable deadlock detection. On high concurrency systems, deadlock detection can cause a slowdown when numerous threads wait for the same lock. At times, it may be more efficient to disable deadlock detection and rely on the innodb_lock_wait_timeout setting for transaction rollback when a deadlock occurs. (https://dev.mysql.com/doc/refman/8.4/en/innodb-parameters.html#sysvar_innodb_deadlock_detect)
• #18: https://aws.amazon.com/blogs/database/monitor-errors-in-amazon-aurora-mysql-and-amazon-rds-for-mysql-using-amazon-cloudwatch-and-send-notifications-using-amazon-sns/
• #20: https://dev.mysql.com/doc/refman/8.4/en/show-engine.html
• #21: https://severalnines.com/blog/understanding-deadlocks-mysql-postgresql/ https://medium.com/geekculture/how-to-deal-with-deadlocks-in-mysql-58f4d830788b Коли я вперше побачив перед собою такий дамп, я не зовсім чітко розумів, що переді мною, бо він містить досить багато extra інформації, яка скоріше всього не є цінною для вас у плані траблшутінгу. А також цей дамп містить дуже багато незрозумілих слів 
• #22: https://www.youtube.com/watch?v=-RmrOWNta6Q&ab_channel=BetweenJobs
• #23: Tips and tricks that are used on our project https://docs.spring.io/spring-data/jpa/docs/3.1.6/reference/html/ Query: <update id="update" parameterType="com.myapp.entity.UpdateUserEntity"> /* myapp.user.update */ UPDATE user SET phone = #{phone} # ... WHERE id = #{id} </update> SQL Dump: *** (1) TRANSACTION: TRANSACTION 450913541522, ACTIVE 0 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 7 lock structs), heap size 1136, 3 row lock(s), undo log entries 2 MySQL thread id 93608210, OS thread handle 47321957033728, query id 10802490531 10.0.64.165 db updating /* myapp.user.update */ UPDATE user SET phone = #{phone} WHERE id = 42
• #26: https://www.baeldung.com/spring-retry https://medium.com/@vmoulds01/springboot-retry-random-backoff-136f41a3211a Please remember to include spring-aop for the retry annotation to work.
• #29: https://www.youtube.com/watch?v=3EwDn9hqgkg&ab_channel=SQLBits DO SLEEP(5); - useful command to emulate hardware slowness Remember a deadlock may occur even if we have the same order of operations but we touch the same table TWICE.
• #33: Дякую усім за увагу, сподіваюсь, що було корисно, будуть питання, або пропозиції, пишіть на пошту.