MySQL 슬레이브가 "시스템 잠금"에 멈춤


8

내 MySQL 슬레이브는에서 많은 시간을 보내고 Slave_SQL_Running_State: System lock있습니다. 시스템이 현재 I / O 쓰기 바운드이며 느리지 만 로그를 처리하고 있음을 알 수 있습니다. Show processlist이 상태 인 경우 "마스터가 이벤트를 보내기 위해 대기 중"및 "시스템 잠금"이외의 다른 것은 표시되지 않습니다.

시스템 테이블 이외의 모든 내 테이블은 InnoDB이며 외부 잠금은 비활성화되어 있습니다. 이 상태에서 노예는 무엇을하고 있습니까?

요청 된 정보는 다음과 같습니다.

첫째, 이것은 Amazon EC2 인스턴스의 MySQL 5.6 커뮤니티이며 모든 스토리지가 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)

1
저장 용량에 문제가 있습니까? 로컬 디스크 인 경우 SMART 경고가 표시됩니까, 아니면 저하 된 RAID 배열에 있습니까?
nedm

에서 몇 가지 관련 항목주세요 mysqld.log복제가 처음에 파산 때 다음에서 후 출력한다 : mysql> SHOW 노예 상태 \ G를; mysql> 전체 프로세스 목록 표시;
alexus

EC2 EBS 볼륨입니다. dmesg에는 오류가 없습니다.
Greg

1
이것은 단순히 5.6의 버그 일 수 있습니다. 다른 버전 (예 : 5.5)
비교해보십시오

1
시스템 잠금 상태의 정의는 다음과 같습니다. 시스템이 I / O 쓰기 바운드 인 것과 관련이있는 것 같습니다. 시스템 잠금-스레드가 테이블에 대한 내부 또는 외부 시스템 잠금을 요청하거나 대기 중입니다. SHOW PROFILE의 경우이 상태는 스레드가 잠금을 요청하고 있음을 의미합니다 (대기하지 않음). :에서 dev.mysql.com/doc/refman/5.6/en/general-thread-states.html
jbrahy

답변:


2

분산 스토리지 facepalm 에서 실행되는 데이터베이스 . 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입니다. 여분의 여유 공간이 512MB라고 가정합니다. 이제이 벤치마킹의 문제점은 (1) 캐싱 효과를 고려하지 않으며 (2) 해상도가 그리 좋지 않다는 것입니다. 그러나이 테스트가 느리면 EC2 EBS에 문제가있는 것입니다. 시험이 빠르거나 명목상이라면, 더 깊이 파고 더 정교한 기술을 사용해야합니다.

보니 ++ 프로그램은 다소 적합하지만 (AFAIK) 쓰기와 읽기 사이의 OS 버퍼를 플러시하지 않습니다. 그래도 같은 아이디어를 얻어야합니다 bonnie++ -u mysql -r 8 -s 16:512 -n 1 -b -d <mysql-data-directory>. 로컬 스토리지에서 실행되는 VM에서이 작업을 수행하면 다음과 같은 이점이 있습니다.

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를 통해 VM에서 실행할 때 얻을 수있는 내용은 다음과 같습니다.

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

0

이 경우 슬레이브 EC2 인스턴스가 마스터와 비슷한 크기입니까?

돈을 절약하기 위해 더 작은 인스턴스에서 실행중인 경우 병목이 발생할 수 있습니다. 몇 초 뒤입니다. 복제가 오랫동안 오프라인 상태였습니까? 아니면 일종의 데이터 입력 스파이크 중에 시간이 지남에 따라 증가 했습니까?


노예는 확실히 느립니다. 마스터의 'show processlist'가 실행중인 쿼리를 표시하는 것처럼 슬레이브가 어떤 쿼리를 사용하는지 알 수있는 방법이 있는지 궁금합니다.
Greg

1
로그 재생입니다. 이전에 제공된 출력에서 ​​슬레이브와 마스터가 어디에 있는지 확인할 수 있습니다. Read_Master_Log_Pos : 505452667 Relay_Log_Pos : 345413863
zaznet
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.