29.9 Performance Schema Tables for Current and Historical Events

29.9 현재 및 과거 이벤트를 위한 Performance Schema 테이블

wait, stage, statement, transaction 이벤트의 경우, Performance Schema는 현재 이벤트를 모니터링하고 저장할 수 있습니다. 추가로, 이벤트가 종료되면 Performance Schema는 이를 history 테이블에 저장할 수 있습니다. 각 이벤트 타입에 대해 Performance Schema는 현재 및 과거 이벤트를 저장하기 위해 세 개의 테이블을 사용합니다. 이 테이블의 이름 형식은 다음과 같으며, 여기서 _xxx_는 이벤트 타입을 나타냅니다 (waits, stages, statements, transactions):

• events_xxx_current: “current events” 테이블은 각 스레드에 대해 현재 모니터링 중인 이벤트를 저장합니다(각 스레드당 1 row).

• events_xxx_history: “recent history” 테이블은 스레드별로 종료된 가장 최근 이벤트를 저장합니다(각 스레드당 최대 row 수까지).

• events_xxx_history_long: “long history” 테이블은 전역적으로(모든 스레드를 통틀어) 종료된 가장 최근 이벤트를 저장합니다(각 테이블당 최대 row 수까지).

각 이벤트 타입에 대한 _current 테이블은 스레드당 하나의 row를 포함하므로, 최대 크기를 설정하기 위한 시스템 변수는 없습니다. Performance Schema는 history 테이블 크기를 자동으로 조정하거나, 서버 시작 시 테이블별 시스템 변수를 사용하여 명시적으로 크기를 설정할 수 있습니다. 개별 history 테이블을 설명하는 섹션에 해당 내용이 표시되어 있습니다. 일반적인 자동 크기 값은 _history 테이블의 경우 스레드당 10 rows, _history_long 테이블의 경우 전체 10,000 rows입니다.

각 이벤트 타입에 대해 _current, _history, _history_long 테이블은 동일한 컬럼을 가집니다. _current 및 _history 테이블은 동일한 인덱싱을 가집니다. _history_long 테이블에는 인덱싱이 없습니다.

_current 테이블은 현재 서버 내에서 무슨 일이 일어나고 있는지 보여 줍니다. 현재 이벤트가 종료되면, 해당 이벤트는 자신의 _current 테이블에서 제거됩니다.

_history 및 _history_long 테이블은 최근에 무슨 일이 일어났는지를 보여 줍니다. history 테이블이 가득 차면, 새로운 이벤트가 추가될 때 오래된 이벤트는 버려집니다. _history 및 _history_long 테이블은 서로 다른 용도를 가지므로 row가 만료되는 방식도 다릅니다:

• _history는 전역 서버 부하와 독립적으로 각각의 스레드를 조사하는 데 사용됩니다.

• _history_long는 각 스레드가 아니라 서버 전체를 조사하는 데 사용됩니다.

두 종류의 history 테이블 간 차이점은 데이터 보존 정책과 관련이 있습니다. 두 테이블 모두 이벤트가 처음 기록될 때는 같은 데이터를 포함합니다. 그러나 각 테이블 내의 데이터는 시간 경과에 따라 다르게 만료되므로, 각 테이블에서 데이터가 더 오래 또는 더 짧게 보존될 수 있습니다:

• _history의 경우, 특정 스레드에 대해 테이블이 최대 row 수를 포함하게 되면, 해당 스레드에 대해 새 row가 추가될 때 가장 오래된 스레드 row가 버려집니다.

• _history_long의 경우, 테이블이 가득 차면 어떤 스레드가 각 row를 생성했는지와 상관없이 새 row가 추가될 때 가장 오래된 row가 버려집니다.

스레드가 종료되면, 해당 스레드의 모든 row는 _history 테이블에서 버려지지만 _history_long 테이블에서는 버려지지 않습니다.

다음 예시는 두 종류의 history 테이블에 이벤트가 추가되고 제거되는 방식의 차이를 보여 줍니다. 이 원칙은 모든 이벤트 타입에 동일하게 적용됩니다. 이 예시는 다음 가정을 기반으로 합니다:

• Performance Schema는 _history 테이블에서 스레드당 10 rows, _history_long 테이블에서 총 10,000 rows를 유지하도록 구성되어 있습니다.

• 스레드 A는 초당 1개의 이벤트를 생성합니다.

스레드 B는 초당 100개의 이벤트를 생성합니다.

• 다른 스레드는 실행되지 않습니다.

5초가 경과한 후:

• A와 B는 각각 5개와 500개의 이벤트를 생성했습니다.

• _history에는 A에 대해 5 rows, B에 대해 10 rows가 포함되어 있습니다. 스레드당 저장 공간이 10 rows로 제한되어 있으므로, A의 경우 버려진 row가 없지만 B의 경우 490 rows가 버려졌습니다.

• _history_long에는 A에 대해 5 rows, B에 대해 500 rows가 포함되어 있습니다. 테이블의 최대 크기가 10,000 rows이므로 어느 스레드에 대해서도 row가 버려지지 않았습니다.

5분(300초)이 경과한 후:

• A와 B는 각각 300개와 30,000개의 이벤트를 생성했습니다.

• _history에는 A에 대해 10 rows, B에 대해 10 rows가 포함되어 있습니다. 스레드당 저장 공간이 10 rows로 제한되어 있으므로, A의 경우 290 rows가, B의 경우 29,990 rows가 버려졌습니다. A에 대한 row는 최대 10초 전까지의 데이터를 포함하는 반면, B에 대한 row는 최대 0.1초 전까지의 데이터만 포함합니다.

• _history_long에는 10,000 rows가 포함되어 있습니다. A와 B는 합쳐서 초당 101개의 이벤트를 생성하므로, 이 테이블은 대략 10,000/101 = 99초 전까지의 데이터를 포함하며, B에 대한 row와 A에 대한 row의 비율은 대략 100 대 1입니다.