Mysql Slave застрял в «Системной блокировке»

8

Мой ведомый MySQL проводит много времени в Slave_SQL_Running_State: System lock. Я вижу, что система в настоящее время привязана к записи ввода-вывода и что она обрабатывает журнал, хотя и медленно. Show processlistне показывает ничего, кроме «Ожидание главного для отправки события» и «Блокировка системы», когда он находится в этом состоянии.

Все мои таблицы (кроме системных таблиц) являются InnoDB, и внешняя блокировка отключена. Что делает раб в этом состоянии?

Вот некоторая информация, которая была запрошена:

Во-первых, это сообщество MySQL 5.6 на экземпляре Amazon EC2 со всем хранилищем на EBS.

mysql> show processlist;
+----+-------------+-----------+---------------+---------+--------+----------------------------------+------------------+
| Id | User        | Host      | db            | Command | Time   | State                            | Info             |
+----+-------------+-----------+---------------+---------+--------+----------------------------------+------------------+
|  1 | system user |           | NULL          | Connect |  26115 | Waiting for master to send event | NULL             |
|  2 | system user |           | NULL          | Connect | 402264 | System lock                      | NULL             |
| 14 | readonly    | localhost | theshadestore | Query   |      0 | init                             | show processlist |
+----+-------------+-----------+---------------+---------+--------+----------------------------------+------------------+
3 rows in set (0.00 sec)

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 184.106.16.14
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: bin-log.000764
          Read_Master_Log_Pos: 505452667
               Relay_Log_File: relay-log.000197
                Relay_Log_Pos: 345413863
        Relay_Master_Log_File: bin-log.000746
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 345413702
              Relay_Log_Space: 19834085375
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 402263
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 307009
                  Master_UUID: b1bf9a19-dac0-11e2-8ffa-b8ca3a5bce90
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
1 row in set (0.00 sec)
Greg
источник
1
Что-нибудь происходит с вашим хранилищем? Если это локальный диск, вы получаете какие-либо предупреждения SMART или это возможно в поврежденном массиве RAID?
Недм
Пожалуйста, предоставьте несколько релевантных записей о том, mysqld.logкогда репликация в первый раз прервалась, и опубликуйте вывод следующего: mysql> SHOW SLAVE STATUS \ G; mysql> ПОКАЗАТЬ ПОЛНЫЙ ПРОЦЕССЛИСТ;
alexus
Это том EC2 EBS. В dmesg нет ошибок.
Грег
1
обратите внимание, что это может быть просто ошибка 5.6, подумайте о проверке на другую версию (например, 5.5): forums.mysql.com/read.php?22,598354,598354
the-wabbit
1
Вот определение состояния блокировки системы. Похоже, это может быть связано с тем, что ваша система привязана к записи ввода / вывода. Системная блокировка - поток собирается запросить или ожидает внутренней или внешней системной блокировки для таблицы. Для SHOW PROFILE это состояние означает, что поток запрашивает блокировку (не ожидая ее). От: dev.mysql.com/doc/refman/5.6/en/general-thread-states.html
jbrahy

Ответы:

2

Базы данных, работающие на лицевой стороне распределенного хранилища . Я бы оценил файловую систему, работающую поверх системы хранения EC2 EBS. Вероятно, самый простой способ - использовать что-то подобное s=$(date +%s); dd if=/dev/zero of=<database-dir> bs=1M count=512; e=$(date +%s); echo "scale=4; 512 / ( $e - $s )" | bc. Это предполагает, что у вас есть 512 МБ, чтобы сэкономить. Проблема с этим сравнительным тестированием состоит в том, что (1) он не учитывает эффекты кэширования, и (2) разрешение не очень хорошее. Но если этот тест медленный, то проблема определенно с EC2 EBS. Если тест быстрый или номинальный, мы должны копать дальше и использовать более сложные методы.

Программа bonnie ++ несколько адекватна, но она (AFAIK) не сбрасывает буферы ОС между записью и чтением. Тем не менее, вы должны получить представление с чем-то вроде bonnie++ -u mysql -r 8 -s 16:512 -n 1 -b -d <mysql-data-directory>. Когда я делаю это на виртуальной машине, работающей в локальном хранилище, я получаю:

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine   Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test        16M:512  1173  99 +++++ +++ +++++ +++  3187  99 +++++ +++ +++++ +++
Latency              1553us      23us     330us     750us     173us    6372us
Version  1.96       ------Sequential Create------ --------Random Create--------
test                -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  1  1850  20 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency             27428us      24us    1188us   30258us      36us    1107us

Вот что я получаю при работе на ВМ через NFS:

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine   Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test        16M:512  1273  98 +++++ +++ +++++ +++  3053  99 +++++ +++ +++++ +++
Latency              1372us      28us     380us     832us      19us    9473us
Version  1.96       ------Sequential Create------ --------Random Create--------
test                -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  1   754  11 +++++ +++   728   8   751  12 +++++ +++   791   8
Latency             12695us      47us    5306us    3710us      30us    3278us
Otheus
источник
0

В этом случае ваш подчиненный экземпляр EC2 подобен размеру мастера?

Если вы работаете на меньшем экземпляре, чтобы сэкономить деньги, вы можете столкнуться там с бутылочным горлышком. Секунды позади - несколько дней. Была ли репликация автономной в течение длительного времени или она со временем росла во время некоторого всплеска ввода данных?

zaznet
источник
Раб определенно медленнее. Мне интересно, есть ли способ узнать, над каким запросом работает ведомое устройство, например, как 'show processlist' на главном показывает, какие запросы выполняются.
Грег
1
Это запись журнала. Вы можете видеть, где находятся ведомый и ведущий в ранее предоставленном выводе. Read_Master_Log_Pos: 505452667 Relay_Log_Pos: 345413863
зазнет