Итак, небольшая предыстория. У нас есть настройка master-slave, и несколько раз в день мы видим что-то подобное в базе данных slave, пытаясь реплицировать то, что приходит от master.
Id User Host db Command Time State Info
------ ----------- ----------------------------------- ------ ------- ------ -------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 system user foodb Connect 59079 Locked UPDATE foo SET bar = 1 WHERE baz = 2;
2 system user (NULL) Connect 62730 Waiting for master to send event (NULL)
940 foouser ip-00-000-000-00.ec2.internal:55555 foodb Sleep 4 (NULL)
941 foouser ip-00-000-000-00.ec2.internal:55555 foodb Sleep 3 (NULL)
Запрос (который очень прост, требует <1 с для запуска вручную каждый раз), кажется, зависает от команды «Подключиться» и никогда не достигает команды запроса.
Кто-нибудь знает, зачем он здесь висит?
Стоит отметить еще одну вещь: запрос на обновление выполняется более 3000 раз в день, и в большинстве случаев запрос выполняется нормально и не блокируется.
Я знаю, что люди будут спрашивать об индексах, но, к сожалению, это конфиденциальная информация, и все, что я могу сказать, я почти уверен, что она проиндексирована правильно. Я несколько раз проверял планы объяснения и указатели.
настройки innodb
"Variable_name" "Value"
"innodb_adaptive_hash_index" "ON"
"innodb_additional_mem_pool_size" "1048576"
"innodb_autoextend_increment" "8"
"innodb_autoinc_lock_mode" "1"
"innodb_buffer_pool_size" "8388608"
"innodb_checksums" "ON"
"innodb_commit_concurrency" "0"
"innodb_concurrency_tickets" "500"
"innodb_data_file_path" "ibdata1:10M:autoextend"
"innodb_data_home_dir" ""
"innodb_doublewrite" "ON"
"innodb_fast_shutdown" "1"
"innodb_file_io_threads" "4"
"innodb_file_per_table" "OFF"
"innodb_flush_log_at_trx_commit" "1"
"innodb_flush_method" ""
"innodb_force_recovery" "0"
"innodb_lock_wait_timeout" "50"
"innodb_locks_unsafe_for_binlog" "OFF"
"innodb_log_buffer_size" "1048576"
"innodb_log_file_size" "5242880"
"innodb_log_files_in_group" "2"
"innodb_log_group_home_dir" "./"
"innodb_max_dirty_pages_pct" "90"
"innodb_max_purge_lag" "0"
"innodb_mirrored_log_groups" "1"
"innodb_open_files" "300"
"innodb_rollback_on_timeout" "OFF"
"innodb_stats_on_metadata" "ON"
"innodb_support_xa" "ON"
"innodb_sync_spin_loops" "20"
"innodb_table_locks" "ON"
"innodb_thread_concurrency" "8"
"innodb_thread_sleep_delay" "10000"
"innodb_use_legacy_cardinality_algorithm" "ON"
Сначала давайте посмотрим на SHOW PROCESSLIST;
Id User Host db Command Time State Info
------ ----------- ----------------------------------- ------ ------- ------ -------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 system user foodb Connect 59079 Locked UPDATE foo SET bar = 1 WHERE baz = 2;
2 system user (NULL) Connect 62730 Waiting for master to send event (NULL)
940 foouser ip-00-000-000-00.ec2.internal:55555 foodb Sleep 4 (NULL)
941 foouser ip-00-000-000-00.ec2.internal:55555 foodb Sleep 3 (NULL)
Как работает репликация, вы увидите два потока, принадлежащих system user: Поток ввода-вывода и поток SQL. Идентификатор процесса №1 - это поток SQL, поскольку он пытается выполнить инструкцию SQL и db является foodb.
Целевая таблица использует MyISAM, как вы указали в своем комментарии к вопросу.
При каких обстоятельствах таблица MyISAM будет заблокирована? Любые операции INSERT, UPDATE или DELETE в таблице MyISAM приводят к полной блокировке таблицы.
Поищите все задания crontab, которые выполняют умеренную запись в foo стол. Также проверьте ОС, чтобы увидеть, не происходит ли частая подкачка дисков.