synch/mutex/innodb/aurora_lock_thread_slot_futex - Amazon Aurora

synch/mutex/innodb/aurora_lock_thread_slot_futex

O evento synch/mutex/innodb/aurora_lock_thread_slot_futex ocorre quando uma sessão bloqueou uma linha para uma atualização e outra linha tenta atualizar a mesma linha. Para ter mais informações, consulte o tópico sobre Bloqueio InnoDB, na Referência do MySQL.

Versões compatíveis do mecanismo

Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:

  • Aurora MySQL versão 2

nota

Nas versões 3.01.0 e 3.01.1 do Aurora MySQL, esse evento de espera é relatado como io/table/sql/handler.

Possíveis causas do maior número de esperas

Várias instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas simultaneamente.

Ações

Recomendamos diferentes ações dependendo dos outros eventos de espera exibidos.

Localizar e responder às instruções SQL responsáveis por esse evento de espera

Utilize o Performance Insights para identificar as instruções SQL responsáveis por esse evento de espera. Considere as estratégias a seguir:

  • Se bloqueios de linha forem um problema persistente, considere reescrever a aplicação para utilizar o bloqueio otimista.

  • Utilize instruções de várias linhas.

  • Disperse a workload por objetos de banco de dados diferentes. É possível fazer isso por meio de particionamento.

  • Verifique o valor do parâmetro innodb_lock_wait_timeout. Ele controla quanto tempo as transações aguardam antes de gerarem um erro de tempo limite.

Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a Publicação no blog sobre como Analisar workloads do Amazon Aurora MySQL com o Performance Insights.

Localizar e responder à sessão de bloqueio

Determine se a sessão de bloqueio está ociosa ou ativa. Além disso, descubra se a sessão é proveniente de uma aplicação ou de um usuário ativo.

Para identificar a sessão que está mantendo o bloqueio, é possível executar SHOW ENGINE INNODB STATUS. O exemplo a seguir mostra uma saída.

mysql> SHOW ENGINE INNODB STATUS; ---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s) MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating UPDATE sbtest1 SET k=k+1 WHERE id=503 ------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0

Outra alternativa é utilizar a consulta a seguir para extrair detalhes sobre os bloqueios atuais.

mysql> SELECT p1.id waiting_thread, p1.user waiting_user, p1.host waiting_host, it1.trx_query waiting_query, ilw.requesting_trx_id waiting_transaction, ilw.blocking_lock_id blocking_lock, il.lock_mode blocking_mode, il.lock_type blocking_type, ilw.blocking_trx_id blocking_transaction, CASE it.trx_state WHEN 'LOCK WAIT' THEN it.trx_state ELSE p.state END blocker_state, il.lock_table locked_table, it.trx_mysql_thread_id blocker_thread, p.user blocker_user, p.host blocker_host FROM information_schema.innodb_lock_waits ilw JOIN information_schema.innodb_locks il ON ilw.blocking_lock_id = il.lock_id AND ilw.blocking_trx_id = il.lock_trx_id JOIN information_schema.innodb_trx it ON ilw.blocking_trx_id = it.trx_id JOIN information_schema.processlist p ON it.trx_mysql_thread_id = p.id JOIN information_schema.innodb_trx it1 ON ilw.requesting_trx_id = it1.trx_id JOIN information_schema.processlist p1 ON it1.trx_mysql_thread_id = p1.id\G *************************** 1. row *************************** waiting_thread: 3561959471 waiting_user: reinvent waiting_host: 123.456.789.012:20485 waiting_query: select id1 from test.t1 where id1=1 for update waiting_transaction: 312337314 blocking_lock: 312337287:261:3:2 blocking_mode: X blocking_type: RECORD blocking_transaction: 312337287 blocker_state: User sleep locked_table: `test`.`t1` blocker_thread: 3561223876 blocker_user: reinvent blocker_host: 123.456.789.012:17746 1 row in set (0.04 sec)

Ao identificar a sessão, suas opções incluem:

  • Entre em contato com o proprietário da aplicação ou o usuário.

  • Se a sessão de bloqueio estiver ociosa, considere encerrá-la. Essa ação pode desencadear uma reversão longa. Para saber como encerrar uma sessão, consulte Encerrar uma sessão ou consulta.

Para ter mais informações sobre como identificar transações de bloqueio, consulte o tópico sobre como Utilizar informações de transações e bloqueios do InnoDB, no Manual de referência do MySQL.