☰

Percona XtraDB 클러스터에서 반복되는 잠금 및 속도 저하

tag-icon • tag-icon percona percona-xtradb-cluster xtradb
Percona XtraDB 클러스터에서 반복되는 잠금 및 속도 저하

Percona XtraDB Cluster로 구성된 5개의 전용 서버(동일한 시스템: 32개 코어, 96GB RAM, RAID의 SSD 드라이브 및 기가비트 이더넷 링크)가 있습니다.

일반적으로 30~60초 정도 클러스터의 심각한 속도 저하를 일으키는 문제가 반복적으로 발생하지만 최대 5~10분 동안 정체되는 경우도 있습니다.

이 시스템은 바쁜 웹사이트 네트워크에 사용되며 각 웹서버에서 mysql-proxy를 사용하여 데이터베이스에 대한 트래픽의 부하를 분산합니다.

노드가 하나만 활성화된 경우에는 문제가 발생하지 않습니다. 대신 노드가 추가될 때마다 문제는 4개의 노드가 활성화되어 견딜 수 없게 될 때까지(쿼리가 느려지거나 잠기는 시간) 강도가 증가합니다(이 시점의 클러스터는 더 이상 자동으로 복구할 수 없습니다).

자세한 증상은 다음과 같습니다.

  1. 5~15분마다 모든 쓰기 쿼리(INSERT/UPDATE)가 모든 노드의 대기열에 갇히게 됩니다. 일부 쿼리는 45~50초 후에 전달되지만 다른 쿼리는 완전히 중단됩니다.
  2. 대부분의 경우 30~60초 후에 클러스터는 어떻게든 따라잡을 수 있으며 1~2초 안에 쿼리를 신속하게 전달합니다.
  3. 때로는 클러스터가 이러한 중단된 쿼리를 자동으로 처리할 수 없기 때문에 가장 바쁜 웹 사이트를 수동으로 비활성화하여 로드를 낮추고 로드가 거의 없는 상태에서 30초 후에 클러스터가 다시 모든 쿼리를 발송할 수 있도록 해야 합니다.

  4. 오류 로그는 일반적으로 속도 저하가 발생하기 전후에 오류 메시지 없이 깨끗합니다. 다음과 같은 결과는 거의 발생하지 않습니다(10번 중 1번 정도).

    130906 9:53:27 [참고] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') 메시지 릴레이 요청 켜기, 비라이브 피어: tcp://IPOFONEOFTHENODES

    130906 9:53:27 [참고] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') 메시지 릴레이 요청 끄기

  5. 일반적으로 일반 로드에서는 wsrep_cert_deps_distance가 약 400입니다. 속도 저하가 시작되자마자 wsrep_cert_deps_distance는 2k-3k 범위까지 천천히 증가합니다(3k 표시에 도달하면 애플리케이션을 수동으로 비활성화해야 합니다. 그렇지 않으면 클러스터가 자체적으로 복구할 수 없습니다).

  6. mytop 및 top으로 모니터링하면 서버나 mysql 프로세스에 높은 로드가 없는 것으로 나타났습니다. CPU 사용량은 정상 작동 중과 속도 저하 중 모두 항상 합리적으로 낮습니다(최대값의 약 25%). I/O 사용량이 양호하고 RAM이 충분하며 vmcom이 제한 미만입니다.

myq_status를 사용하여 모든 노드의 클러스터를 실시간으로 모니터링하면 다음과 같은 일이 발생합니다.

  • wsrep_flow_control_paused 변수는 속도 저하가 발생하더라도 항상 0.0입니다.
  • wsrep_local_bf_aborts 또는 wsrep_local_cert_failures가 발생하지 않습니다.
  • 모든 노드에서 아웃바운드 복제는 일반적으로 0이며 속도 저하가 발생하면 최대 200-300까지 증가합니다.
  • 인바운드 복제는 모든 노드에서 항상 0입니다(1인 경우는 거의 없지만 일반 로드에서도 발생함). 클러스터에 느린 노드가 없는 것 같아서 이 점은 저를 당황하게 합니다.
  • 속도 저하가 시작된 후 10~15초가 지나면 모든 노드에서 전송 및 수신된 작업 및 바이트가 0이 됩니다. 1~2초 동안 0에 머물다가 다음 초에 증가된 양의 작업 및 바이트가 발생하고 많은 수의 "oooe" 작업(순서가 잘못된 실행)이 결합됩니다. 이는 서버가 다음으로 돌아갈 때까지 몇 초마다 반복됩니다. 정상.

다음은 문제를 해결하기 위해 수행한 테스트의 세부 사항입니다(운이 좋지 않았지만...).

  1. 먼저 네트워크를 확인했습니다. 서버는 전용 기가비트 네트워크가 있는 동일한 랙에 있고 패킷 손실이나 기타 명백한 네트워크 문제 없이 모든 것이 잘 작동하는 것 같습니다.
  2. 대역폭 사용량을 확인해 보니 모든 노드는 평균 30~100mbps(메가비트)의 대역폭을 사용합니다. "iftop"을 사용하여 실시간으로 확인했는데 문제가 발생하는 동안 대역폭 사용량은 대개 평균(15~30mbps)보다 낮습니다. 노드 대역폭을 동기화하는 동안 최대 800-900mbps까지 올라가므로(필요한 경우) 네트워크가 포화 상태라고 생각하지 않습니다.
  3. 하나의 특정 노드가 다른 모든 노드에 영향을 미치는지 확인하기 위해 모든 노드를 조합해 보았습니다. 어떤 노드를 비활성화하거나 사용하든 문제는 항상 존재합니다. 문제는 항상 동시에 활성화된 노드 수와 관련이 있습니다.

비슷한 문제를 겪은 사람이 있습니까? 미리 감사드립니다!

관련 정보