DBA를 위한 MySQL 운영 기술 : 모니터링, 백업/복구, 이중화, 도구와 기법

DBA를 위한

MySQL 운영기술

책2.indb 1 2015-07-20 오후 4:37:28

불과 몇 년 전까지만 해도 “가장 보편적으로 사용되는 DBMS는 무엇인가?”라고 묻는다면

아마도 다수가 오라클이나 MS-SQL 서버라고 대답했을 것 같다. 이 책의 저자 또한 회사

에 입사해서 처음으로 접한 DBMS가 이 둘 중 하나였다.

그러나 최근에는 상용 DBMS를 사용하면서 발생하는 라이선스 비용을 줄이기 위해 오픈

소스인 MySQL 또는 MariaDB를 새롭게 도입하거나, 기존에 사용 중이던 상용 DBMS의

데이터를 MySQL로 이관하려는 요구가 늘고 있다. 그리고 이미 많은 사이트에서 주요 서

비스에 MySQL을 채택해서 사용하고 있다.

과거의 MySQL은 오라클이나 MS-SQL 서버와 같은 상용 DBMS와 비교해 안정성이 떨

어진다고 알려져 왔지만 현재의 MySQL(MySQL 5.5 이상 버전)은 과거보다 성능이나 기

능상으로 크게 발전했다. 또한 MySQL뿐만 아니라 MySQL 소스를 바탕으로 기능을 더

추가하거나 개선한 MariaDB와 Percona Server도 출시됐다. 그리고 이러한 상황에서 사

용자는 과거보다 더 많은 기술 자료와 사례 연구를 얻을 수 있게 됐다.

이처럼 MySQL을 사용하는 곳이 늘어나면서 MySQL에 관심을 가지고 사용해보려는 개발

자들은 기본적인 아키텍처와 개념을 이해하고 MySQL도 설치해봤을 것이다.

그런데 만약 MySQL 운영 경험이 전혀 없는 상황이라면, 당장 실 서비스에 투입하기 위해

MySQL 운영 환경을 구성해야 한다면 어디서부터 시작해야 할지 난감할 수 있다.

다수의 사용자가 동시다발적으로 서비스를 사용하는 환경이 됐을 때 성능상으로 문제는

없을까? 문제가 생긴다면 어디서 문제가 발생했는지 어떻게 확인할 수 있을까? 만약 장

애 상황으로 데이터가 유실된다면 어떻게 대처할 수 있을까?

실제로 서비스를 운영하는 중에는 여러 다양한 문제가 갑작스럽게 발생하기도 하지만

문제가 될 수 있는 상황에 대비하기 위해 미리 준비할 수 있는 기본적인 사항들도 있다.

이 책에서는 MySQL 운영에 필요한 기본적인 기술에 대해 크게 네 가지 범주로 나눠서

살펴본다.

/ 저 / 자 / 서 / 문 /4

책2.indb 4 2015-07-20 오후 4:37:28

1부, ‘MySQL 서버 모니터링’에서는 MySQL을 서비스에 투입하기 전에 문제가 발생할

수 있는 원인을 확인하고 대처하기 위해 모니터링 환경을 구성한다.

2부, ‘MySQL 백업 복구’에서는 DBA라면 반드시 숙지해야 할 백업 복구 방법을 익히

기 위해 백업에 사용하는 도구를 소개하고 사용법을 설명한다.

3부, ‘MySQL 이중화’에서는 장애로 인해 서비스가 중단되는 시간을 최소화하고 안정

적인 운영을 위한 MySQL 이중화 방법을 설명한다.

4부 ‘MySQL 운영 도구’에서는 기본적인 MySQL 운영 기술에서 한 단계 더 나아가 효

과적인 운영에 도움을 줄 수 있는 몇 가지 도구를 알아본다.

저자들은 이 책을 쓰면서 “MySQL을 쉽게 시작하려면 기본적으로 어떤 것들을 할 수 있

을까?”를 생각하면서 주제를 선택했다. 기술적인 내용을 깊게 분석하고 설명하는 책과 자

료는 이미 국내외에 많이 있다. 그래서 원론적인 내용은 아니더라도 내가 지금 당장 해볼

수 있는 실용적인 내용을 이 책에 담고자 했다. 그래서 이 책은 MySQL을 한번 사용해보

고 싶은, MySQL을 이용해 개발 또는 운영 환경을 구성하고 싶은데 어떻게 시작해야 할지

망설이는 분에게 일독을 권장한다.

MySQL 운영 환경을 어떻게 구축해야 할지, 어떤 도구가 있는지 알고 싶은 분들이라면

이 책에서 원하는 정보를 쉽게 얻을 수 있을 것이다. 더 나아가 이 책의 내용을 바탕으로

자신이 운영하는 서비스 환경에 맞춰 최적화된 방식으로 효율적으로 서비스를 운영할 수

있을 것이다.

5/ 저 / 자 / 서 / 문 /

책2.indb 5 2015-07-20 오후 4:37:29

MySQL 서버 모니터링의

필요성과 고려사항01

1.1 장애 대비와 장애 원인 분석 14

1.2 기간별 패턴 분석 16

1.3 용이한 가독성과 사용 편의성 18

1.4 다수의 서버에 대한 모니터링 효율성 21

1.5 전용 담당자가 없는 환경에서의 모니터링 효율성 22

MySQL 서버 모니터링 요소02

2.1 운영체제 모니터링 요소 23

2.2 MySQL 모니터링 요소 27

MySQL 서버 모니터링 방법 03

3.1 명령어 및 스크립트 이용 32

3.2 배치 스크립트와 템플릿(Excel) 이용 37

MySQL 서버 모니터링 도구 비교04

4.1 MySQL 엔터프라이즈 모니터 44

4.2 Monyog 49

4.3 Cacti 52

P A R T

MySQL서버 모니터링

01

/ 목 / 차 / 6

책2.indb 6 2015-07-20 오후 4:37:29

MySQL 서버 모니터링 방식 비교 05

5.1 에이전트/푸시 방식 55

5.2 비에이전트/팝 방식 57

MySQL 서버 모니터링 시스템 구축 06

6.1 Cacti 소개 59

6.2 Cacti 설치 61

6.3 Percona 모니터링 플러그인 95

6.4 Percona 모니터링 템플릿 적용 - 리눅스 98

6.5 Cacti 최적화 116

6.6 플러그인 설치와 적용 - Spine 118

6.7 플러그인 설치 및 적용 - Realtime 122

6.8 Percona 모니터링 템플릿 적용 - MySQL 127

6.9 플러그인 설치 및 적용 - Settings 134

6.10 플러그인 설치 및 적용 -Thold 138

MySQL 서버 튜닝 포인트 07

7.1 리눅스 튜닝 포인트 - 모니터링 결과 분석 154

7.2 MySQL 튜닝 포인트 - 모니터링 결과 분석 158

MySQL서버 모니터링

7 / 목 / 차 /

책2.indb 7 2015-07-20 오후 4:37:29

MySQL 백업 도구 소개08

8.1 mysqldump 208

8.2 Percona Xtrabackup 209

MySQL 백업 도구 사용법09

9.1 mysqldump 210

9.2 Percona Xtrabackup 225

상황별 백업과 복구10

10.1 mysqldump를 이용해 백업 및 복구하기 241

10.2 Percona Xtrabackup을 이용한 백업 및 복구 251

10.3 시점 복구하기 - Point in time 복구 297

백업 복구 시 주의 사항11

11.1 mysqldump 사용 시 주의 사항 300

11.2 Percona Xtrabackup 사용 시 주의 사항 302

P A R T

MySQL백업 복구

02MySQL

서버 이중화

/ 목 / 차 / 8

책2.indb 8 2015-07-20 오후 4:37:29

레플리케이션12

12.1 레플리케이션 개요 308

12.2 레플리케이션 설정 - 마스터 DB 310

12.3 레플리케이션 설정 - 슬레이브 DB 313

12.4 레플리케이션 구성 314

12.5 실무에서 사용하는 레플리케이션 모니터링 332

레플리케이션 응용13

13.1 개별 데이터베이스 레플리케이션 335

13.2 개별 테이블 레플리케이션 345

13.3 와일드카드를 이용한 테이블 레플리케이션 354

13.4 데이터베이스명을 변경한 레플리케이션 363

13.5 체인 레플리케이션 367

레플리케이션 구성 시 주의사항14

14.1 바이너리 로그 포맷 차이에 따른 주의사항 371

14.2 바이너리 로그 포맷이 STATEMENT일 경우 쿼리 주의사항 372

14.3 바이너리 로그 포맷이 ROW일 경우 쿼리 실행 시 주의사항 380

14.4 바이너리 로그 포맷이 MIXED일 경우 쿼리 실행 시 주의사항 385

14.5 DB 버전 간의 레플리케이션 호환과 관련된 주의사항 386

14.6 기타 주의사항 391

14.7 레플리케이션 문제 해결 398

MySQL백업 복구

P A R T

MySQL서버 이중화

03

9 / 목 / 차 /

책2.indb 9 2015-07-20 오후 4:37:29

세미 싱크 레플리케이션15

15.1 세미 싱크 레플리케이션 개요 414

15.2 세미 싱크 레플리케이션 구성 415

15.3 세미 싱크 레플리케이션 사용 시 주의사항 418

MySQL HA:

마스터-마스터 레플리케이션16

16.1 마스터-마스터 레플리케이션 개요 420

16.2 마스터-마스터 레플리케이션 구성 422

16.3 마스터-마스터 레플리케이션 응용 426

16.4 마스터-마스터 레플리케이션 사용 시 주의사항 434

MySQL HA: MHA17

17.1 MHA 개요 436

17.2 MHA 아키텍처 438

17.3 MHA 구성하기 444

17.4 MHA 모니터링 시작하기 461

17.5 기타 주의사항 505

/ 목 / 차 / 10

MySQL운영 도구

책2.indb 10 2015-07-20 오후 4:37:29

Percona Toolkit18

18.1 Percona Toolkit 소개 510

18.2 Percona Toolkit 설치 511

18.3 Percona Toolkit 사용 및 활용 513

Anemometer19

19.1 Anemometer 소개 및 사용법 549

19.2 Anemometer 설치 554

19.3 Anemometer 활용 562

MySQL 서버 모니터링 지표부록

A.1 리눅스 모니터링 지표 570

A.2 MySQL 모니터링 지표 580

11 / 목 / 차 /

P A R T

MySQL운영 도구

04

책2.indb 11 2015-07-20 오후 4:37:29

PART01MySQL 서버 모니터링

01. MySQL 서버 모니터링의 필요성과 고려사항

02. MySQL 서버 모니터링 요소

03. MySQL 서버 모니터링 방법

04. MySQL 서버 모니터링 도구 비교

05. MySQL 서버 모니터링 방식 비교

06. MySQL 서버 모니터링 시스템 구축

07. MySQL 서버 튜닝 포인트

책2.indb 12 2015-07-20 오후 4:37:29

IT 서비스 인프라는 애플리케이션 서버(웹 서버 등), 캐시 서버(이미지 캐

시, 데이터 캐시 등), 미디어 서버(동영상, 이미지, 음원 등의 모든 미디어

서버), 검색 서버, 데이터베이스 서버(MySQL 등의 DBMS) 등 다양하고 복

합적인 아키텍처로 구성돼 있다. 그러므로 IT 서비스 인프라가 안정적이

고 연속적으로 서비스되려면 각 인프라 요소별 특이사항과 현재 운영 상

태를 모니터링해야 한다. 특히 MySQL 서버 인프라를 상용(production)

서비스를 대상으로 운영한다면 서비스 투입 전, 투입 시, 투입 후 등 여러

시점마다 기능적 또는 성능적으로 정상적인 서비스를 저해할 수 있는 요

소를 파악하고 분석해야 한다.

이번 장에서는 MySQL 서버 운영에 필수적인 MySQL 서버 모니터링의

필요성과 어떠한 지표를 어떻게 모니터링할 것인가에 대해 개괄적으로

알아본다.

책2.indb 13 2015-07-20 오후 4:37:29

14 Part 01 _ MySQL 서버 모니터링

MySQL 서버를 운영한다면 운영 담당자는 성능 저하 없이 가능한 한 안정적으로 운영하기 위해 지속적

이고 주기적으로 관리할 것이다. 주기적인 관리와 모니터링을 수행하지 않는다면 현재 정상적으로 운영

하고 있다고 하더라도 불특정 시점에 발생할 수 있는 잠재적인 위험 요소를 파악하기 어려울 수 있다. 결

국 ‘적절한 운영’이 이뤄지려면 상시 모니터링을 통해 현재 MySQL 서버가 안정적으로 운영되고 있는지

를 객관적 지표를 기반으로 판단해야 할 것이며 주기적이고 반복적인 모니터링을 통해 잠재적인 위험 요

소를 미리 파악해서 관리해야 한다. 그렇다면 MySQL 서버 모니터링이 필요한 좀 더 상세한 이유와 몇

가지 대표적인 고려사항을 알아보자.

1.1 장애 대비와 장애 원인 분석

MySQL 서버를 운영할 때 MySQL 서버가 중단되는 등의 장애 상황은 다양한 원인에 의해 발생할 수 있

다. 예를 들면, 인입 쿼리 트래픽의 급증으로 인한 디스크 IO의 증가 때문에 성능 저하가 발생해 장애상

황이 유발될 수도 있고, 특정 세션에서 트랜잭션 처리가 정상적으로 되지 않는 현상이 발생해 이에 대한

영향으로 다른 세션들이 대기(blocked)하게 되어 장애가 발생할 수 있다. 사실 이처럼 하나하나 말로

설명할 수 없을 정도로 다양한 요인이 MySQL 서버 장애의 원인이 될 수 있다. 이러한 장애 상황이 발생

하지 않도록 미연에 방지한다면 서비스 관점의 안정성 면에서 상당히 유익한 ‘장애 예방 활동’이 된다. 그

러므로 적절한 MySQL 서버 운영을 위해서는 MySQL 서버 모니터링을 통해 장애를 유발할 가능성이 있

는 부분에 미리 대비해야 한다.

MySQL 서버 모니터링의

필요성과 고려사항

01

책2.indb 14 2015-07-20 오후 4:37:29

01. MySQL 서버 모니터링의 필요성과 고려사항 15

그러나 아무리 문제 발생 상황을 미리 예측 분석하고 대비했다고 하더라도 필연적으로 피할 수 없는 것

이 바로 장애 상황이다. 예상치 못한 각종 부하로 인한 성능 저하, 적절히 설정되지 않은 MySQL 서버의

여러 전역 변숫값, 이중화되지 않은 하드웨어의 고장 및 운영 담당자의 적절치 못한 수동 작업(인재) 등

이 바로 장애 상황에 해당한다. MySQL 서버가 적절히 모니터링되고 있다면 불가피한 장애 상황에 대해

정확하고 빠르게 원인을 파악할 수 있다. 이를 통해 장애 상황의 원인 파악, 분석, 조치 및 복구(정상화)

에 걸리는 시간을 최소화할 수 있다.

[그림 1-1] MySQL 프로세스 리스트

[그림 1-2] MySQL 스레드

책2.indb 15 2015-07-20 오후 4:37:29


예를 들면 그림 1-1과 그림 1-2의 스레드 상태처럼 특정 세션의 트랜잭션이 정상적으로 처리되지 못하

고 특정 테이블 또는 행(row)에 락을 잡고 있는 상태(blocking)로 지속되는 경우 다른 세션의 쿼리가

동일 테이블의 데이터를 변경하기 위한 락 획득 대기(blocked) 시간이 길어질 수 있다. 빠른 서비스 정

상화가 최우선이라면 블록킹(blocking) 세션을 빠르게 중단(kill)시켜 대기 세션(Blocked Session)

을 정상화하는 방법을 선택할 수 있다. 또 다른 상황을 생각해보자. 서비스 중에 특정 테이블이 깨진

(crash) 경우 데이터 정합성이 최우선인 서비스라면 해당 서비스를 즉시 중단하고 깨진 테이블을 정상

적으로 복구해 다시 서비스를 재개하는 방법을 선택할 수 있다. 이러한 다양한 장애 상황을 해결하는 시

나리오에서 공통적인 사항은 장애 상황을 빠르게 인지하는 것과 해결해야 하는 부분을 명확히 알아야 한

다는 것이며, 이는 MySQL 서버 모니터링을 통해 객관적으로 판단할 수 있다.

이미 발생한 장애 상황을 적절한 방법으로 해결한 뒤 비슷한 장애 상황이 발생하지 않게 만들기 위한 사

후 조치는 더 큰 장애 상황을 방지하기 위해서라도 반드시 필요하다. MySQL 서버 장애의 경우 MySQL

서버에 어떤 부하가 발생했다면 그 자체가 장애의 원인일 수 있다. 반면 MySQL 서버가 아닌 프런트 레

벨에 있는 웹 서버 등의 다른 인프라 요소의 부하 탓에 MySQL 서버에 성능 병목이 발생한 것일 수도 있

다. 정확한 장애 원인 파악과 분석을 위해서는 인과관계를 명확히 판단하는 것이 무엇보다도 중요하며,

각 인프라 요소의 객관적인 모니터링 지표에 근거한 판단이 아니라면 사실상 불확실한 추측에 불과하다.

1.2 기간별 패턴 분석

MySQL 서버가 모니터링되고 모니터링의 결과 데이터가 저장되어 일정 기간 동안 유지된다면 운영상의

특이사항을 일간 또는 월간 등 기간별로 비교해서 분석할 수 있으며, 기간별로 발생하는 특정한 모니터

링 패턴도 확인할 수 있다. 기간별 패턴 분석이 가능하다는 것은 잠재적인 MySQL 서버의 장애를 예방

하는 측면에서 중요하며, 더 나아가 운영 관점에서 다양하게 활용할 수 있는 분석 결과를 도출할 수 있다

[그림 1-3] MySQL 바이너리/릴레이 로그

책2.indb 16 2015-07-20 오후 4:37:30


[그림 1-4] MySQL 핸들러

그림 1-3 그래프를 보자. 이 그래프는 MySQL의 바이너리 로그와 릴레이 로그 사용량의 최근 1개월간의

변화를 나타낸다(물론 그림과 같이 꼭 시각적인 그래프가 아닌 수치 기반으로 모니터링해도 무방하다).

예시의 MySQL 서버는 매일 자정마다 최근 7일 이전의 바이너리 로그를 자동으로 삭제하는 배치 작업을

수행한다. 이 그래프를 보면 현재 약 50GB의 바이너리 로그가 쌓여 있고, 일별로 약 10GB 규모의 로그

가 삭제됐으며, 최근 1개월 동안 전체적인 로그량이 점차 증가했음을 알 수 있다. 또한 추이를 분석한다

면 ‘현재 수준의 쿼리 트래픽이 유지된다면 로그 용량의 상승 폭은 크게 증가하는 일 없이 50GB 내외를

유지할 가능성이 크다’라고 분석할 수 있다. 그림 1-4의 그래프는 최근 1주일간의 MySQL 핸들러 사용

량을 모니터링한 결과 그래프다. 매일 특정 주기로 Handler Read Next 지표가 급증하는 양상을 보이

고 있다. 사실 이 MySQL 서버는 급증하는 시간대마다 애플리케이션에서 배치 형태의 데이터베이스 잡

이 주기적으로 실행되는 서버다. 그러므로 해당 급증 시간에 MySQL 서버의 다른 특이사항이 없다면 이

것은 이상 현상이 아닌 정상적인 연산을 수행하는 것으로 판단할 수 있다.

그림 1-5의 MySQL 커맨드 카운터 그래프는 최근 24시간 동안의 MySQL 서버가 실행한 초당 쿼리량

(QPS: Query Per Second)을 나타낸다. 이 그래프를 통해 MySQL 서버의 쿼리 트래픽량과 최저 트래

픽 기준으로 하루 중 최저 트래픽 시점(최한시)과 최고 트래픽 시점(최번시)을 파악할 수 있다. 또한 모

니터링 결과 데이터를 특정 기간 저장한다면 하루가 아닌 주간/월간/연간의 QPS 변화 패턴을 확인할 수

있으며, 여러 다른 지표와 비교해 의미 있는 추가 분석 결과(QPS 증가량에 따른 CPU/Memory 등의 하

드웨어 리소스 사용 증가량 비교 등)를 도출해 낼 수 있다.

책2.indb 17 2015-07-20 오후 4:37:30


[그림 1-5] MySQL 커맨드 카운터

1.3 용이한 가독성과 사용 편의성

MySQL 서버의 여러 모니터링 지표는 그 특성상 적절한 형태의 결과로 모니터링해야 한다. MySQL 서

버 에러 로그 파일(xxx.err)과 같이 서버에서 발생한 특이사항의 상세한 내용이 텍스트 로그 형태로 남

아야 분석하기 쉬운 지표가 있다. 반면 CPU 사용률이나 메모리 사용률과 같이 백분률로 모니터링해

서 그 추이를 확인할 수 있어야 분석하기 쉬운 지표가 있다. 또한 MySQL 서버의 초당 인입 쿼리 개수

(QPS) 등과 같이 절대적인 지표 값 자체로 모니터링해야 하는 지표도 있다. 앞에서 설명했듯이 MySQL

서버의 모니터링 결과로 장애 상황에 대한 원인 판단 및 장애 해결 결과를 분석할 수 있으며, 모니터링

결과를 빠른 시간 안에 명확하게 알수록 효과적이다.

시각 Call Select Update Insert Delete Replace

12:00:11 230 2238 192 80 71 3

12:00:21 231 2837 182 71 38 10

12:00:31 210 2293 293 62 21 8

12:00:41 213 2210 283 77 283 2

12:00:51 253 2102 160 68 3 3

[표 1-1] 쿼리 실행량(1분 동안의 10초 평균 QPS 모니터링 결과)

책2.indb 18 2015-07-20 오후 4:37:30


[그림 1-6] 쿼리 실행량 - 15분 동안의 1초 평균 QPS 모니터링 결과)

표 1-1의 쿼리 실행량과 그림 1-6의 쿼리 실행량은 특정 기간 동안의 QPS 모니터링 결과를 각각 표와

그래프 형태로 보여준다. QPS 모니터링 결과와 같이 절대 수치값 형태로 의미 있는 모니터링 지표들은

변화량과 추이를 함께 볼 때 훨씬 더 분석하기 쉽고 직관적이다. 그림 1-6의 실행량과 같은 그래프 형태

의 결과는 절대 수치와 변화 추이를 직관적으로 알 수 있다. 반면 표 1-1의 쿼리 실행량과 같은 표 형태

의 결과는 그래프 형태의 결과에 비해 가독성이 크게 떨어진다. 모니터링 결과 조회 구간이 수 시간 또는

수일에 이를 경우 그 차이는 더욱 명확해진다. 결과적으로 수집된 MySQL 서버의 모니터링 데이터는 가

독성이 높고 낮음에 따라 그 결과를 확인하고 이해하는 담당자의 편의성이 크게 차이 날 수 있는 것이다.

[그림 1-7] 쿼리 실행량 - 실시간으로 생성하는 그래프로 조회(최근 1개월간의 평균 QPS)

책2.indb 19 2015-07-20 오후 4:37:30


[그림 1-8] MySQL 커맨드 카운터 - 미리 생성된 RRD 그래프로 조회(최근 1개월간의 평균 QPS)

그래프 형식으로 모니터링 결과를 보여주는 경우 일반적으로 긴 기간(수일/수개월 등)을 조회할 때는 그

래프를 그리는 방법에 따라 성능 차이가 발생한다. 모니터링 결과를 조회할 때 조회하는 순간마다 모니

터링된 원시 데이터(raw data)를 읽어 매번 그래프를 그리는 방법은 모니터링 결과량이 많다면 당연히

그래프를 불러오는 데 걸리는 시간이 길어질 수밖에 없다. 반면 결과 조회 시점이 아닌 모니터링 데이터

수집 시점에 결과 데이터를 기반으로 그래프 이미지를 미리 생성한다면 모니터링 결과 그래프를 부하 없

이 그릴 수 있다. 후자의 방식을 다시 말하자면 수개월 간의 모니터링 결과를 조회할 때마다 그래프를 생

성하는 부하를 줄일 수 있고, 조회 기간과 상관없이 결과 그래프를 빠르게 로딩할 수 있다. 그림 1-7은

전자의 방법으로 로딩되는 그래프이고, 그림 1-8은 후자의 방법으로 로딩되는 그래프다. 실제로 그림

1-7은 약 1개월간의 QPS 조회 시 약 10초가 소요됐다. 반면 그림 1-8은 같은 1개월간의 QPS를 조회했

음에도 그래프 조회 시 약 1초 미만의 시간으로 거의 즉시 로딩된다.

결론적으로 MySQL 서버 모니터링 결과를 보여주는 방식은 다양할 순 있지만 모니터링 데이터의 정확

성이 위배되지 않는 범위 내에서 각 지표의 특성에 맞게 적절한 가독성과 사용 편의성을 갖춰야 한다는

것이다.

책2.indb 20 2015-07-20 오후 4:37:30


1.4 다수의 서버에 대한 모니터링 효율성

모니터링해야 하는 대상 MySQL 서버가 수십 또는 수백대에 달한다면 모니터링 성능도 함께 고려해야

한다. 효율적인 MySQL 서버 모니터링을 위해서는 모든 모니터링 대상 MySQL 서버의 모니터링 지표를

가능한 한 ‘짧은 시간’ 안에 ‘안정적’으로 수집하는 것이 좋다. 여기서 말하는 ‘짧은 시간’이란 실시간에 가

까울수록 유리하며, ‘안정적’이란 것은 모니터링이 다른 부분에 미치는 영향을 최소화하며 적절한 수준의

수집 성능을 갖춘다는 것을 말한다.

모니터링 서버가 모니터링 대상 서버와 물리적으로 분리된 서버로 구성돼 있고 유휴상태라면 약 5% 미

만의 CPU 사용률을 보인다는 가정으로 아래의 몇 가지 시나리오를 설명한다.

시나리오 1

■ 모니터링 대상 서버 수 : 100대

■ 모니터링 수집 주기 : 5분

■ 모니터링 지표 수집 소요 시간 : 3분

■ 모니터링 지표 수집 시의 CPU 사용률 : 약 10%

모니터링 지표 수집 소요 시간이 3분이기 때문에 수집 주기는 최소 3분 이상인 5분으로 설정할 수밖에 없다. 5분이라는

평균값은 모니터링 지표로서 정확성이 다소 떨어지는 결과일 수 있다. MySQL 서버의 모니터링 지표 중 이전 수집 지표

와의 차이의 평균값으로 계산되는 지표의 수는 상당히 많다. 가능하다면 10% 정도의 낮은 CPU 사용률이 어느 정도 높

아질 수 있음을 감안하고 모니터링 지표를 수집하는 수집기의 성능을 향상시키는 방법을 찾아 개선할 필요가 있다.

시나리오 2



■ 모니터링 지표 수집 소요 시간 : 30초


모니터링 지표를 수집할 때 수집기가 사용하는 CPU 사용률은 40%로 다소 높게 보일 수 있지만 시나리오 1번과 동일한

수의 서버를 모니터링함에도 수집에 걸리는 소요시간은 30초밖에 되지 않는다. 결과적으로 모니터링 수집 주기는 1분

으로, 시나리오 1보다 높은 정확성을 가지고 모니터링 지표를 수집할 수 있다. 하지만 수집주기 1분 동안 CPU 사용률이

40%로 다소 높기 때문에 모니터링 서버의 수집 기능을 제외한 결과 데이터 조회 등의 다른 오퍼레이션에 지연이 생길

가능성이 있다.

책2.indb 21 2015-07-20 오후 4:37:30

시나리오 3



■ 모니터링 지표 수집 소요 시간 : 10초


모니터링 지표 수집에 약 70% 가량의 아주 높은 CPU 사용률을 보이는 반면 수집에 소요되는 시간은 단지 10초밖에 걸

리지 않는다. 많은 하드웨어 자원(CPU 등)을 이용해 짧은 시간 내에 모니터링 지표를 수집할 수 있는 환경이라면 이와

같이 모니터링 지표 수집의 성능을 높게 설정하는 것이 최선일 수 있다.

모니터링 대상 서버가 수십, 수백 대에 이르거나 혹은 현재는 적은 수의 서버를 모니터링하지만 점점 증

가할 수 있는 환경이라면 모니터링 서버는 성능 관점에서 갖가지 튜닝이 필요할 수 있다. 수집기가 병렬

처리가 가능하다면 하드웨어 자원과 적절한 균형을 맞춰 설정해야 한다. 수집기의 성능을 최적으로 튜닝

했음에도 단일 모니터링 서버의 하드웨어 자원으로 처리할 수 없는 많은 수의 MySQL 서버를 모니터링

해야 한다면 모니터링 서버를 물리적으로 여러 대로 늘려서 구성하는 방법도 고려해야 한다.

1.5 전용 담당자가 없는 환경에서의 모니터링 효율성

현장에서는 MySQL 서버만 전담 운영하는 전문 DBA가 없는 인프라 환경도 생각보다 많다. 이런 환

경에서는 개발자나 시스템 엔지니어 등의 역할을 수행하는 사람이 부수적으로 DBA의 역할까지 담당

할 수밖에 없다. 이처럼 전담 DBA가 없는 환경이라면 자동화된 MySQL 서버 모니터링 인프라가 더욱

필수적으로 구성돼 있어야 한다. 왜냐하면 ‘MySQL 서버 모니터링’이란 행위는 기본적으로 많은 수의

MySQL 서버들의 고정된 특정 지표를 반복적으로 관제하는 것이기 때문이다. 이러한 이유로 여러 명의

사람이 모니터링하는 것보다 자동화된 모니터링 시스템을 활용하는 것이 비용과 효율성 측면에서 유리

하다. 또한 이러한 환경에서는 MySQL의 모든 모니터링 지표를 세부적으로 모니터링하기보다는 다음과

같은 중요 지표만 일부 선정해 모니터링하는 것이 효율적이다.

1. MySQL 서버 프로세스 정상 실행 여부 및 MySQL 서비스 포트 정상 여부 등

2. 중요 운영체제 모니터링 지표 모니터링(CPU, 메모리, 디스크 사용률 등)

3. 중요 MySQL 서버 모니터링 지표(QPS, 커넥션/스레드, 락 등)

2번과 3번은 안정적인 MySQL 서버 운영을 위해 필수적으로 모니터링해야 하는 요소이므로 ‘2장

MySQL 서버 모니터링 요소’에서 상세하게 설명한다. 아울러 이 같은 주요 모니터링 지표에 이상 현상

발생에 대한 자동화된 알림(이메일, SMS 등)을 연동한다면 관리 면에서 좀 더 효과적일 수 있다.

책2.indb 22 2015-07-20 오후 4:37:30

02. MySQL 서버 모니터링 요소 23

2.1 운영체제 모니터링 요소

운영체제의 모니터링 요소는 비단 MySQL 서버뿐 아니라 그 어떤 애플리케이션을 운영하더라도 기본

적으로 모니터링돼야 하는 중요 ‘필수’ 모니터링 지표다. 이 모니터링 지표는 일반적으로 CPU, 메모리,

디스크(저장공간), 네트워크 등의 운영체제 자원의 사용률을 말하며, 이러한 운영체제 자원 사용률은

MySQL 서버를 운영하는 경우 여러 성능 지표에 대한 기준점(임계점)이 될 수 있다. 만일 MySQL 서버

에 장애상황이 발생했을 경우, 운영체제 모니터링 결과는 MySQL 서버 모니터링 결과와 함께 분석해 장

애 원인과 인과성을 판단할 수 있는 객관적 근거가 된다. 또한 MySQL 운영에 대한 잠재적인 위험요소

가 있을 경우 이를 판단할 수 있는 성능적 근거로 활용할 수 있으며, 더욱이 서버 증설 등의 MySQL 서

버 아키텍처 전반에 걸친 검토가 필요한 경우에도 활용할 수 있다. 요컨대 운영체제 자원의 사용률을 반

드시 모니터링해야 한다는 것이다. 그럼 운영체제 모니터링 요소로는 어떤 것이 있는지 대표적인 요소를

확인해보자.

CPU 사용률

CPU 사용률은 필수적인 운영체제 모니터링 요소로서, 전체적인 CPU 사용률과 커널, 유저프로세스, IO

대기 시 CPU 사용률 등 유형별로 세분화된 사용률을 모니터링해야 한다. 다른 운영체제 모니터링 지표

와 함께 종합적으로 비교하고 분석한다면 하드웨어 자원 사용률(H/W Resource Usage)을 파악할 수

있다. 또한 실행 중인 MySQL을 비롯한 애플리케이션들이 사용하는 CPU 사용량을 모니터링한다면 이

MySQL 서버 모니터링 요소

02

책2.indb 23 2015-07-20 오후 4:37:30


용량이 가장 많은 시간대(최번시)에 CPU 사용량이 과도해서 발생할 수 있는 다양한 문제 상황을 예측할

수 있다.

[그림 2-1] CPU 사용률

메모리 사용량

메모리 사용량은 물리적 또는 논리적인 메모리 사용량을 나타낸다. 메모리 사용률은 전체 메모리 크기,

현 사용량, 캐싱된 사용량, 유휴( free) 사용량별로 모니터링해야 한다. 이러한 메모리 사용량 모니터링

을 통해 혹시나 메모리 확장이 필요한지 또는 특정 상황에서 메모리 누수( leak)가 발생하는지 등을 분석

할 수 있다.

[그림 2-2] 메모리 사용량

책2.indb 24 2015-07-20 오후 4:37:31


디스크 사용량

[그림 2-3] 디스크 공간 사용량

[그림 2-4] 디스크 입출력 오퍼레이션

저장 장치의 모니터링 요소는 저장 장치의 공간(space)에 대한 사용량과 저장 장치에서 발생하는 읽기,

쓰기 등의 오퍼레이션(operations) 횟수(빈도) 등 크게 두 가지로 나눌 수 있다.

그림 2-3은 저장 장치의 전체 공간( total size)과 그중에서 사용 중인 공간(used)의 양을 나타낸다. 저

장 장치의 사용 중인 공간의 양을 기간별로 모니터링한다면 평상시 대비 짧은 기간 동안 빠르게 사용량

이 증가하는 이상현상 등을 쉽고 빠르게 확인할 수 있다. 또한 기간별 사용량과 그 추이를 분석해 추후

전체 저장공간을 늘려야 하는 시점까지도 유추할 수 있다.

책2.indb 25 2015-07-20 오후 4:37:31


그림 2-4는 초당 발생한 저장 장치의 읽기, 쓰기 등의 오퍼레이션 횟수를 보여준다. 저장 장치의 평상시

읽기, 쓰기 오퍼레이션 횟수를 모니터링함으로써 대량의 오퍼레이션이 발생하는 시점과 추이 및 사용량

(부하)을 확인할 수 있다. 예측보다 과도한 오퍼레이션이 발생한다면 관리자는 이를 이상 징후로 판단하

고 다른 모니터링 요소와 함께 분석하는 등 적절한 대응을 할 수 있다. 만일 평상시 발생하는 오퍼레이션

이 저장 장치의 물리적인 성능 한계를 초과할 만큼 빈번하게 발생하고, 이로 인해 저장 장치의 쓰기 또는

읽기 지연과 CPU의 IO 대기가 지속적으로 발생한다면 저장 장치 자체를 고성능 저장 장치로 교체해야

한다. 이처럼 저장 장치의 오퍼레이션 횟수를 모니터링한 결과는 저장 장치의 업그레이드 필요성에 대한

객관적 판단 근거로 활용할 수 있다.

MySQL 서버의 데이터 저장 용도로 사용하는 저장 장치는 일반적으로 하드디스크, NAS(Network Attached

Storage), DAS(Direct Attached Storage), SAN(Storage Area Network), SSD(Solid State Drives) 등 다양하다.

각 저장 장치는 EXT3(third extended filesystem), EXT4(fourth extended filesystem), XFS(high-performance

64-bit journaling file system) 등의 파일시스템으로 포맷해서 사용한다.

참 고

네트워크 사용량

네트워크 사용량은 서버에서 사용하는 인바운드, 아웃바운드 네트워크 트래픽의 사용량을 나타낸다. 모

니터링 대상 서버의 네트워크 사용량을 모니터링하면 MySQL 서버의 QPS 대비 네트워크 트래픽의 사

용량을 비교, 분석할 수 있다. MySQL 서버 부하에 의한 장애 상황이 발생했다면 당시의 인바운드 트래

픽과 아웃바운드 트래픽 사용량은 장애 원인을 분석하는 데 유용한 지표로 활용할 수 있다. 아울러 모니

터링 대상 서버의 모든 네트워크 트래픽을 모니터링해서 해당 서버들의 네트워크 트래픽을 수용하는 네

트워크 스위치의 대역폭 증설 여부를 판단하는 데도 활용할 수 있다.

[그림 2-5] 네트워크 사용량

책2.indb 26 2015-07-20 오후 4:37:31


2.2 MySQL 모니터링 요소

MySQL 서버를 모니터링할 때 어떤 한 가지 요소의 모니터링 결과 지표만으로는 이상 징후나 MySQL

서버 장애의 원인을 판단하기 쉽지 않다. MySQL 서버의 모니터링 요소들은 인과관계를 적절히 판단해

종합적으로 분석해야 한다. 그중에서 일별 또는 상시적으로 체크해야 할 MySQL 서버의 중요 모니터링

요소는 다음과 같다. 다음의 모니터링 요소들은 최소한의 중요 모니터링 요소만 설명하는 것이며, 실제

상용 서비스를 위한 MySQL 서버라면 다음의 모니터링 요소를 포함해서 더 많은 모니터링 요소를 충분

히 모니터링해야 한다.

쿼리 실행량

쿼리 실행량은 MySQL 서버가 처리하는 쿼리의 양을 나타낸다. 일반적으로 QPS(초당 실행되는 쿼리의

양) 또는 QPM(분당 인입되는 쿼리의 양) 단위로 측정하는 이 모니터링 지표는 MySQL 서버 모니터링

결과를 분석할 때 일반적으로 다른 지표의 기준이 되는 요소라고 할 수 있다. 모니터링을 통해 운영 중인

MySQL 서버의 최대 쿼리 실행량 수치와 최대 쿼리 실행량이 발생하는 시점 또는 그 기간을 확인한다면

해당 시점에 잠재적으로 발생할 수 있는 위험요소(최대 트래픽 수치 급증에 따른 하드웨어 리소스 사용

률 증가 등)를 미리 파악할 수 있다.

[그림 2-6] 쿼리 실행량

책2.indb 27 2015-07-20 오후 4:37:31


커넥션 / 스레드

[그림 2-7] 커넥션

[그림 2-8] MySQL 스레드

커넥션(connections)은 MySQL 서버에 설정된 최대 연결 개수(max connections)와 실행 중인

(running) 그리고 캐싱된(cached) 커넥션 수를 나타낸다. 커넥션 수를 보고 MySQL 서버에 시스템 변

수로 설정된 최대 커넥션 수를 상향 또는 하향 조정할 필요가 있는지 판단할 수 있다. 스레드( threads)

는 MySQL 서버에 설정된 최대 스레드 캐시의 수( thread cache size)를 비롯해 사용 중인(running)

스레드 개수, 생성된(created) 스레드 개수, 캐싱된(cached) 스레드 개수 등을 나타낸다.

정상적으로 운영 중인 MySQL 서버에 실제 접속 사용자 수가 짧은 기간(수 초 또는 수 분 이내) 급증한

다면 사용 중인 커넥션 수와 스레드 수가 증가하는 것은 일반적으로 정상적인 결과라고 볼 수 있다. 반면

책2.indb 28 2015-07-20 오후 4:37:31


접속 사용자 수가 급증하지 않은 상태에서 사용 중인 커넥션 수나 스레드 수가 급증했다면 이는 비정상

적인 급증일 가능성이 크다. 예를 들면, 특정 커넥션에 락 경합에 의해 오랫동안 차단된(Blocked) 쿼리

가 발생하거나 실행 시간이 과도하게 소요되는 헤비쿼리(Heavy Query)가 지속적으로 발생한 것일 수

있다. 왜냐하면 이미 다른 스레드들이 기존 커넥션을 모두 점유하고 있으므로 새로운 커넥션 요청에 대

해 신규 커넥션을 추가적으로 생성할 수밖에 없는 것이다.

그러므로 이처럼 다양한 문제 상황에 대해 원인을 파악하고 종합적인 분석을 위해서는 커넥션 수와 스레

드 수는 필수적으로 모니터링해야 한다.

MySQL 서버에 접속하는 주체(웹 서버 또는 미들웨어 등)가 MySQL 서버와의 커넥션에 자체적인 커넥션 풀

(Connection Pool)을 사용하거나 또는 MySQL 서버가 1개의 커넥션당 동시에 여러 개의 스레드를 사용하는 환경에

서 커넥션 풀을 제대로 관리하지 않으면 그렇지 않은 환경에 비해 트랜잭션과 관련한 더 다양한 문제가 발생할 수도

있다.

참 고

락

[그림 2-9] 락

락 지표는 MySQL 서버에서 실행되는 쿼리의 락 획득 횟수와 락 획득을 위해 대기하는 횟수를 보여준다.

MySQL 서버뿐 아니라 모든 RDBMS에서도 락 관련 지표를 반드시 모니터링해야 한다. 그 이유는 트랜

잭션을 지원하는 RDBMS(MySQL의 경우 InnoDB 스토리지 엔진 등)에는 트랜잭션 보장을 위한 락 메

커니즘이 구현돼 있기 때문이다.

책2.indb 29 2015-07-20 오후 4:37:31


RDBMS는 락 획득을 통해 데이터 정합성을 유지해야만 데이터 변경이 가능하다. 그러므로 락 발생 자

체는 정상적인 오퍼레이션이라고 할 수 있다. 문제가 되는 것은 락 획득의 수가 정상적인 운영 시 모니터

링되는 횟수보다 급증 또는 급감한다거나 락 획득을 위해 대기하는 트랜잭션의 수가 늘어나며 대기 시간

이 길어지는 현상이 발생하는 경우다. 이럴 때는 MySQL 서버의 성능과 무관하게 잘못된 트랙잭션 처리

를 유발하는 애플리케이션 로직의 문제일 수도 있으며, 그 영향은 정상적으로 데이터베이스 서비스를 할

수 없을 지경에까지 이를 수 있다. 결론적으로 락 발생 횟수와 락 획득 대기 시간이 비정상적으로 나타난

다면 여러 가지 원인으로 인해 MySQL 서비스의 안정성 측면에서 큰 위험이 있는 상태라고 볼 수 있으

므로 락 지표는 필수 모니터링 요소라고 할 수 있다.

임시 테이블 사용량

[그림 2-10] 임시 테이블

MySQL 서버는 여러 경우에 임시테이블(Temporary Table)을 사용할 수 있다. 실행 중인 쿼리에서 정

렬이나 조인 등의 연산이 발생할 경우 때때로 임시 테이블이나 임시 파일을 사용해 처리한다. 이러한 임

시적인 오브젝트들이 시스템 변수에 설정된 최대 크기(sort_buffer_size 등)를 넘어서는 크기로 발생할

때는 메모리 내에서 처리하지 못하고 디스크 영역을 사용하게 된다. 메모리 내에서 처리하지 못해 디스

크를 사용하는 임시 오브젝트가 빈번히 발생한다면 쿼리 실행 성능은 크게 저하될 수밖에 없다.

하지만 실행쿼리의 조건을 변경할 수 없거나 테이블 모델의 한계로 임시 테이블 생성 횟수를 줄이기 어

려운 상황은 생각보다 많다. 예를 들어, SELECT 쿼리의 ORDER BY 절에 정의된 정렬 칼럼에 인덱스가

없다면 정렬을 하기 위한 추가적인 오퍼레이션이 발생할 수 있다. 또한 스칼라 서브쿼리를 LEFT JOIN

으로 전환하면 스칼라 서브쿼리가 임시 테이블을 생성하지 않도록 개선할 수 있지만 쿼리 실행 결과가

책2.indb 30 2015-07-20 오후 4:37:32


달라지는 경우라면 이마저도 쉽지 않다. 그래서 더더욱 이 지표를 꾸준히 모니터링해서 MySQL 서버의

전체적인 성능을 함께 고려한 최적화나 관련 시스템 변수 설정값의 변경이 필요한지 검토해야 한다.

슬로우 쿼리

[그림 2-11] 슬로우 쿼리

슬로우 쿼리(slow query) 지표는 MySQL 서버에서 실행되는 모든 쿼리 중 시스템 변수로 정해진 특정

실행 시간( long_query_time)을 넘는 실행시간을 소요한 쿼리의 개수를 나타낸다. OLTP 성격의 데이

터베이스 서비스를 한다면 대부분의 쿼리는 1초 미만의 시간으로 실행될 것이다. 하지만 해당 쿼리가 최

적화되지 못했거나 데이터 변경을 위한 락을 획득하려는 대기시간이 길어지는 등의 아주 다양한 원인으

로 쿼리 실행시간이 길어질 경우가 있다면 쿼리 최적화나 부하 분산 등의 여러 가지 방법을 통해 쿼리 실

행시간이 길어지는 원인을 제거할 필요가 있다. 그러므로 Slow Query 지표를 자주 확인해 MySQL 서

버의 성능적 위험요소가 될 수 있는 슬로우 쿼리를 탐지하고 이를 최적화해야 한다.

책2.indb 31 2015-07-20 오후 4:37:32


‘2장 MySQL 서버 모니터링 요소’에서 설명한 MySQL 서버 운영을 위한 운영체제 모니터링 요소와

MySQL 서버 모니터링 요소를 확인하는 방법은 일일이 열거할 수 없을 만큼 다양하다. 이러한 모니터링

요소는 단순히 대상 서버에 접속해 셸에서 특정 명령어를 실행해 확인할 수도 있고, 특정 시간 동안 특정

주기별로 명령어를 실행하는 셸 스크립트를 만들어 실행하는 방법으로도 모니터링할 수 있다. 하지만 모

니터링해야 할 서버가 수십, 수백 대에 이를 경우 이 같은 단순한 모니터링 방법은 효율성이 크게 떨어진

다. 또한 모니터링 요소 중 특정 시점이 아닌 일별이나 월별 등의 기간별 변화량이 중요한 성격을 띠는

요소라면 모니터링 결과 데이터의 절대량은 예상보다 상당히 커질 수 있다. 이처럼 MySQL 서버 모니터

링 요소를 수집하고 가독성 있게 조회한다는 것은 여러 가변적인 요소를 고려해야 하고 모니터링 목적에

따라 그 방법을 달리해야 한다. 이번 장에서는 간단한 명령어 실행만으로 간단히 모니터링하는 방법과

수집 요소를 커스터마이즈해서 볼 수 있는 모니터링 방법, 그리고 수집한 모니터링 결과를 시각적으로

유리한 그래프 형태로 변환하는 방법을 설명한다.

3.1 명령어 및 스크립트 이용

운영체제 모니터링 요소는 운영체제에서 제공하는 여러 명령어로 모니터링할 수 있으며, 별도의 모니터

링 프로그램을 사용할 수도 있다. 리눅스 기반의 운영체제에서는 vmstat, iostat, netstat, dstat, top 등

의 다양한 명령어로 모니터링할 수 있으며, nmon 등의 모니터링 프로그램을 사용할 수 있다. 윈도우 운

영체제라면 Windows 성능 모니터(Windows Performance Monitor)를 이용해 대부분의 운영체제

모니터링 요소를 확인할 수 있다.

MySQL 서버 모니터링 방법

03

책2.indb 32 2015-07-20 오후 4:37:32

03. MySQL 서버 모니터링 방법 33

다음은 운영체제가 리눅스인 모니터링 대상 서버에 접속해 vmstat 명령어로 주요 하드웨어 자원 사용량

을 1초마다 모니터링한 내용이다. vmstat 명령어는 특정 시간별로 CPU, 메모리, 스왑공간, 디스크 입출

력 등의 사용량을 보여준다.

리눅스 자원 사용률 모니터링 - vmstat

[root@mysqlsvr ~]# vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

r b swpd free buff cache si so bi bo in cs us sy id wa st

1 0 200464 3950416 427956 7571924 0 0 1 36 0 0 5 1 93 1 0

3 0 200464 3948028 427956 7571936 0 0 0 980 15848 36487 5 1 94 1 0

2 0 200464 3952392 427956 7571952 0 0 0 76 15701 36477 5 1 94 0 0

0 0 200464 3949568 427964 7571960 0 0 0 1352 15688 36496 4 1 93 1 0

4 0 200464 3967196 427964 7571988 0 0 4 172 17045 34593 7 1 91 1 0

4 0 200464 3985108 427964 7572012 0 0 0 320 6176 10779 5 1 94 0 0

MySQL 서버는 MySQL 관리를 위한 전용 유틸리티인 mysqladmin을 기본적으로 제공하며,

mysqladmin을 이용하면 MySQL 서버의 주요 설정 값과 상태 정보를 손쉽게 확인할 수 있다.

mysqladmin의 기본적인 기능은 다음과 같다.

■ MySQL 서버 시작과 종료

■ MySQL의 root, 사용자 계정 암호 변경

■ MySQL의 상태 변수(Server Status Variables)와 시스템 변수(Server System Variables) 확인

■ MySQL에 접속한 클라이언트(Threads) 리스트 확인

■ 기타 MySQL 관리에 필요한 유용한 설정 및 정보 확인 등

mysqladmin을 ‘processlist’ 옵션과 함께 사용하면 현재 MySQL 서버의 DB 커넥션 현황과 각 커넥션

별 스레드 상태 등 데이터베이스 커넥션의 기본적인 정보를 모니터링할 수 있다. 다음은 mysqladmin을

이용해 현재 MySQL의 커넥션 중 유휴(Sleep) 상태가 아닌 커넥션을 1초마다 모니터링하는 예다.

MySQL 서버 커넥션 사용 현황 모니터링 - mysqladmin : processlist

[mysqluser@mysqlsvr ~]# mysqladmin -uroot -p -i1 processlist | grep -v Sleep

Enter password:

+----------+-----------+--------------------+-------+---------+------+------------+------------------------------

-------------------------------------------------------------------------+---------+

책2.indb 33 2015-07-20 오후 4:37:32


| Id | User | Host | db | Command | Time | State | Info

| Progress |

+----------+-----------+--------------------+-------+---------+------+------------+------------------------------

------------------------------------------------------------------------+---------+

| 25583302 | cactiuser | 192.168.0.10:35193 | cacti | Query | 0 | statistics | SELECT count(*)

FROM poller_time WHERE poller_id=0 AND end_time>'0000-00-00 00:00:00' | 0.000 |

| 25583658 | root | localhost | | Query | 0 | | show processlist

| 0.000 |

+----------+-----------+--------------------+-------+---------+------+------------+------------------------------

---------------------------------------------------------------------+---------+

+----------+-----------+--------------------+-------+---------+------+------------+------------------------------

---------------------------------------------------------------------------------------+----------+


| Progress |

+----------+-----------+--------------------+-------+---------+------+------------+------------------------------

---------------------------------------------------------------------------------------+----------+


| 0.000 |

| 25583687 | cactiuser | 192.168.0.10:35831 | cacti | Query | 0 | query end | INSERT INTO

poller_time (poller_id, pid, start_time, end_time) VALUES (0, 31327, NOW(), '0000-00-00 | 0.000 |

+----------+-----------+--------------------+-------+---------+------+------------+------------------------------

---------------------------------------------------------------------------------------+----------+

+----------+-----------+--------------------+-------+---------+------+------------+------------------------------

---------------------------------------------------------------------------------------+----------+


| Progress |

+----------+-----------+--------------------+-------+---------+------+------------+------------------------------

---------------------------------------------------------------------------------------+----------+

| 25583302 | cactiuser | 192.168.0.10:35193| cacti | Query | 0 | query end | DELETE FROM poller_output WHERE

local_data_id IN (463,464,465,466,467,468,469,470,471,472,473,474,47 | 0.000 |


| 0.000 |

| 25583743 | cactiuser | 192.168.0.10:35928| cacti | Query | 0 | query end | UPDATE host SET status='3',

status_event_count='0', status_fail_date='0000-00-00 00:00:00', status_r | 0.000 |

+----------+-----------+--------------------+-------+---------+------+------------+------------------------------

---------------------------------------------------------------------------------------+----------+

또 다른 옵션인 ‘status’ 옵션을 주고 mysqladmin을 실행하면 다음과 같은 기본적인 상태 값을 모니터

링할 수 있다.

책2.indb 34 2015-07-20 오후 4:37:33

03. MySQL 서버 모니터링 방법 35

■ Uptime: MySQL 서버가 가장 최근에 시작된 시각부터 현재까지의 시간을 초 단위로 보여줌

■ Threads: 현재 실행 중인 스레드 수

■ Questions: MySQL 서버가 가장 최근에 시작된 시각부터 현재까지 누적된 MySQL 명령어 실행 개수

MySQL 서버 기본 상태 정보 모니터링 - mysqladmin : status

[mysqluser@mysqlsvr ~]# mysqladmin -uroot -p -i1 status

Enter password:

Uptime: 7774893 Threads: 65 Questions: 2060217396 Slow queries: 2061431772 Opens: 432690 Flush

tables: 92 Open tables: 137 Queries per second avg: 264.983







mysqladmin을 ‘status’ 옵션만으로 모니터링한 결과는 시간별값이 아닌 누적값을 보여준다. 이 경

우 급증 또는 급감하는 형태의 처리량이 나타날 경우에는 그 차이를 직관적으로 알기 어렵다. 요약하

면 mysqladmin에서 제공하는 ‘status’ 옵션에 의한 결과는 MySQL 서버 운영에 필요한 아주 기본적

인 상태 값만 모니터링할 수 있으며 가독성 면에서 상당히 제한적이다. 이러한 단점을 극복하기 위해

mysqladmin에서는 ‘extended-status’ 옵션을 제공한다. 이 옵션은 MySQL 서버의 모든 서버 상태 변

수(Server Status Variables) 값을 보여준다.

다음 예제에서는 ‘extended-status’ 옵션을 주고 실행한 mysqladmin의 결과를 모니터링에 필수적인

요소만을 필터링해서 나타내는 셸 스크립트와 그 실행 결과를 볼 수 있다.

■ mysqladmin을 ‘extended-status’ 옵션을 주고 1초 주기로 실행.

■ 서버 상태 변숫값 중 SELECT, INSERT, UPDATE, DELETE 쿼리 실행 수 등 기본적인 모니터링 요소만을 필터링

■ 필터링한 모니터링 결과 값을 누적값(기본 서버 상태 변숫값)이 아닌 1초 단위의 증가 값으로 변환

MySQL 서버 초당 실행 쿼리 수(QPS) 등 모니터링 - mysqladmin : extended-status

-- query_per_sec.sh 파일 생성

[mysqluser@mysqlsvr ~]# touch query_per_sec.sh

책2.indb 35 2015-07-20 오후 4:37:33


[mysqluser@mysqlsvr ~]# chmod 750 query_per_sec.sh

[mysqluser@mysqlsvr ~]# vi query_per_sec.sh

#!/bin/bash

/home/mysql/3306/mysql/bin/mysqladmin -uroot --password="password" -i1 extended-status | awk '

/Queries/{qu=$4-qup;qup=$4}

/Questions/{qs=$4-qsp;qsp=$4}

/Com_call_procedure/{ccp=$4-ccpp;ccpp=$4}

/Slow_queries/{slq=$4-slqp;slqp=$4}

/Com_select/{cs=$4-csp;csp=$4}

/Com_insert/ && $2 !~ /Com_insert_select/{ci=$4-cip;cip=$4}

/Com_update/ && $2 !~ /Com_update_multi/{cu=$4-cup;cup=$4}

/Com_delete/ && $2 !~ /Com_delete_multi/{cd=$4-cdp;cdp=$4}

/Com_replace/ && $2 !~ /Com_replace_select/{cr=$4-crp;crp=$4}

/Threads_connected/{tc=$4}

/Threads_running/{printf "Queries: %5d Questions: %5d Call_SP: %5d Slow_queries: %5d Com_select:

%5d Com_insert: %5d Com_update: %5d Com_delete: %5d Com_replace: %5d Threads_connected: %5d

Threads_running: %5d\n",qu,qs,ccp,slq,cs,ci,cu,cd,cr,tc,$4}'

-- query_per_sec.sh 스크립트 실행

[mysqluser@mysqlsvr ~]# sh query_per_sec.sh

Queries: 2060475307 Questions: 2060464822 Call_SP: 0 Slow_queries: 2061690406 Com_select:

1971203227 Com_insert: 22024354 Com_update: 13191329 Com_delete: 9212611 Com_replace: 1520281

Threads_connected: 23 Threads_running: 1

Queries: 127 Questions: 127 Call_SP: 0 Slow_queries: 129 Com_select: 114 Com_

insert: 2 Com_update: 0 Com_delete: 2 Com_replace: 0 Threads_connected: 22

Threads_running: 1



Threads_running: 1



Threads_running: 2



Threads_running: 3



Threads_running: 2

Queries: 1168 Questions: 1167 Call_SP: 0 Slow_queries: 1161 Com_select: 1049

……….

책2.indb 36 2015-07-20 오후 4:37:35

Documents

DBA를 위한 MySQL 운영 기술 : 모니터링, 백업/복구, 이중화, 도구와 기법