안녕하세요.

기존 사내 업무 환경이 기존에는 구글 엑셀을 통해 업무를 많이 봤는데 최근에 rdbms를 통한 업무가 상당히 많아졌다.기존에도 rdbms를 쓰긴 했지만(사내 디비 환경은 도커 컨테이너 기반의 master+slave 환경으로 서비스를 하고 있었다.) 웹+디비등의 환경에서만 쓰였는데 최근에는 대부분의 임직원이 디비를 활용하여 업무를 하고 있다.

어쨌든 업무환경이 디비를 통한 업무가 증가하면서 기존에는 원활하게 돌아가던 DB(mariadb)가 원인불명의 다운이 발생한다. 아마 사용량이 많아지면서 잘못된 사용?이 있었거나.. 여튼 원인을 파악해야 하기에 모니터링 툴을 찾아봤고 pmm 이 나왔다.

pmm 이란 페르소나 모니터링 엔드 메니지먼트로 여러 오픈소스 디비의 모니터링을 지원(오라클은 지원X)하고 있다. 클라우드 디비들까지.

pmm은 클라이언트-서버로 구성 돼 있다. 클라이언트에서 수집된 데이터들을 서버로 보내면 서버에서 웹UI를 통한 대시보드, 그래프등으로 표시된다.

PMM 서버는 쿼리 분석을 위한 [QAN API, QAN web app] / DB저장 및 시각화하기 위한[그라파나, 프로메테우스, 클릭하우스]로 이루어져 있고 이것들로 유저는 PMM 서버의 엔진엑스/pgsql을 통해 웹 UI제공/설정저장이 가능하다.

PMM 클라이언트는  pmm-admin 과 pmm-agent, db-expoter로 이루어져있고 클라이언트의 데이터를 수집하고 서버로 전송하기위한 과정들을 할 수 있게끔 한다.

즉 쉽게 설명하자면

pmm 모니터링을 하기 위해서는 3가지가 필요하다.

pmm 서버 / pmm 클라이언트 / 수집대상 데이터베이스

pmm 서버는 당연히 아무곳에나 해도 되고 pmm 클라이언트도 아무곳에나 해도된다. 꼭 수집대상 데이터베이스에 안해도 된다. 

따라서 나같은 경우는 pmm서버/클라이언트를 한곳에 설치해줬다. 클라이언트라길래 꼭 수집대상 데이터베이스가 있는 서버내에 설치해야하나 헷갈렸어서 적어준다. 물론 데이터베이스 있는 서버에 설치해주면 서버의 리소스까지도 모니터링이 되는 이점은 있다.

설치 진행

현재 인프라 운영환경이 전부 도커 컨테이너 기반이기 떄문에 설치도 도커(도커 컴포즈)를 통해 진행할꺼고 순서는 다음과 같다.

1. 모니터링 호스트 서버에 PMM-server를 도커컴포즈로 설치하고
2. PMM-client가 디비에서 데이터 수집을 할 수 있도록 디비 계정 생성 및 추가 설정 진행 해주고
3. 디비 컨테이너가 있는 도커 컴포즈에 PMM-client를 추가하고

4. 

1. 모니터링 호스트 서버에 PMM-server 설치

version: '2'

services:
  pmm-data:
    image: percona/pmm-server:latest
    container_name: pmm-data
    volumes:
      - ./prometheus/data:/opt/prometheus/data
      - ./consul-data:/opt/consul-data
      - ./mysql:/var/lib/mysql
      - ./grafana:/var/lib/grafana
    entrypoint: /bin/true

  pmm-server:
    image: percona/pmm-server:latest
    container_name: pmm-server
    ports:
      - '11180:80'
    restart: always
    environment:
      - SERVER_USER=admin
      - SERVER_PASSWORD=pmmadmin
      - METRICS_RETENTION=720h
      - METRICS_MEMORY=4194304
      - METRICS_RESOLUTION=1s
      - QUERIES_RETENTION=30
    volumes_from:
      - pmm-data

docker-compose up -d 하고 웹으로 접속하면 초기 아이디/패스워드는 admin/admin 인것같다. 컴포즈에서 설정하는건 적용이 안되는것으로 보임 기본 아이디 패스워드는 admin/admin 이다. 패스워드는 로그인 한 뒤 패스워드 변경해야 하고 변경된 상태로 컨테이너 스탑 한 뒤 컨테이너 이미지를 새로 만들어야 한다.(각종 설정정보는 위에 기술한것처럼 pmm-server 내 pgsql에 저장 되는데 pgsql은 컴포즈 설정상 바인딩마운트를 하지 않기 때문에 도커 컴포즈 재시작하면 설정 다 날라간다. 그래서 초기 설정한 뒤 이미지 새로 떠놓던가 아니면 pgsql도 바인딩 마운트 추가하던가 해야함)

2. 수집할 데이터가 있는 디비에 pmm-client가 접근할 수 있도록 계정 생성 및 데이터 권한 추가

MariaDB [(none)]> create user 'pmm'@'192.168.226.%' identified by '패스워드';
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> grant select, process, replication client, reload on *.* to 'pmm'@'192.168.226.%';
Query OK, 0 rows affected (0.001 sec)

3. pmm-client가 디비서버에서 쿼리데이터를 수집 할 때 슬로우쿼리/퍼포먼스스키마 둘중 하나에서 수집하는데 뭘로할지 정해야함.

아래 설명 보는것처럼 슬로우쿼리는 디테일한 정보(즉 더 많은 정보)를 볼 수 있지만 시스템 성능에 영향을 줄 수 있고 로그 용량 관리등을 해줘야 한다. 반면 퍼포먼스 스키마에서 가져올 경우 디테일하지 않다는 단점만 있다. 일단 퍼포먼스 스키마로 설정해주고 내가 필요한 데이터(즉 현재 다운되는 원인을 파악 할 수 있는 데이터)가 없다면 슬로우 쿼리로그로 바꾸는게 맞을것같은데...

그러나 현재 디비 구성이 퍼포먼스 스키마는off이고 슬로우 쿼리가 on이다. 
우선 퍼포먼스 스키마/슬로우 쿼리에 대해 좀 더 알아볼 필요가 있겠다. 슬로우쿼리는 우리가 지정한 타임 이상 걸린 쿼리에 대한 정보를 남기는것이고 퍼포먼스스키마에 대한 설명:http://cloudrain21.com/everything-of-mysql-performance-schema 

말 그대로 성능에 대한 정보가 담긴 디비(스키마)라고 생각하면 됨.

정리하자면 
슬로우쿼리 : 내가 설정해둔 시간보다 많이 걸리는 쿼리들 로깅 됨
퍼포먼스 스키마 : 여러 수집 가능한 정보들이 있는데 항목별로 on/off하여 수집 가능
앞서 PMM에서 알려준(슬로우쿼리가 좀 더 디테일한 장점이 있고 반대로 퍼포먼스스키마는 정보가 많지 않다는 단점이 있다는) 것과 반대로 디비 운영 관점에서 보자면 슬로우쿼리(슬로우쿼리에 쌓이는 데이터들은 단순히 어떤 쿼리가 느렸는지 정도만 파악 가능)보다 퍼포먼스 스키마가 더 많은(더 디테일한)정보를 볼 수 있다고 이해가 된다. 

근데 왜 PMM에서는 슬로우쿼리가 좀 더 디테일하다고 설명하는걸까 ? 슬로우쿼리 안에 데이터로 뭐가 분석이 되나...? 이부분 이해가 안가는데... 단순히 슬로우 쿼리는 쿼리 전체가 다 찍히니... 그래서 디테일 하다는건가 ? 일단 설치해보고 슬로우쿼리/퍼포먼스스키마 각각 수집되는 항목들 직접 보고 비교해봐야겠다.

아래와 같이 performance_chema를 on등을 설정해주고 mysql을 재시작한다.
performance_schema=ON
performance-schema-instrument='statement/%=ON'
performance-schema-consumer-statements-digest=ON
innodb_monitor_enable=all
#query_response_time_stats=ON   ###이건 mysql에 플러그인 추가로 설치해줘야 한다. 
userstat=ON

퍼포먼스 스키마 실행 확인 완료

퍼포먼스 스키마DB에 데이터가 쌓이고 있음도 확인

4. pmm-client install

https://docs.percona.com/percona-monitoring-and-management/details/commands/pmm-agent.html 참고하였다.

우선 아래의 내용으로 docker-compose.yaml 생성
version: '2'
services:
  pmm-client:
    image: percona/pmm-client:2
    hostname: pmm-client-myhost
    container_name: pmm-client
    restart: always
    ports:
      - "42000:42000"
      - "42001:42001"
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "5"
    volumes:
      - ./pmm-agent.yaml:/etc/pmm-agent.yaml
      - pmm-client-data:/srv
    environment:
      - PMM_AGENT_CONFIG_FILE=/etc/pmm-agent.yaml
      - PMM_AGENT_SERVER_USERNAME=admin
      - PMM_AGENT_SERVER_PASSWORD=admin
      - PMM_AGENT_SERVER_ADDRESS=X.X.X.X:443
      - PMM_AGENT_SERVER_INSECURE_TLS=true
    entrypoint: pmm-agent setup
volumes:
  pmm-client-data:

      - PMM_AGENT_SERVER_ADDRESS=X.X.X.X:443
    hostname: pmm-client-myhost
위 두개를 수정해준다

그리고 콘피그 파일 touch pmm-agent.yaml && chmod 0666 pmm-agent.yaml 수정 될 수 있또록 생성/권한 수정 해주고

docker-comose up(설정파일 생성을 위해 임시로 실행하는것임)해주면 아래와 같이 pmm-agent.yaml이라는 설정파일이 생성된다.

여기서 중요한점 두가지
첫번째는 해당 설정파일에는 인증정보가 있으니 외부로 노출하면 안되고 두번째는  docker-compose.yaml 에서 수정했던
    hostname: pmm-client-myhost
위 부분을 각 사용자에 맞게 수정을 해줘야 그에 맞춰서 pmm setup 명령어를 통해 agent.yaml이 생성된다. 만약 hostname을 기존에 쓰던 네임일 경우 agent 설정파일이 생성되지 않는다.
agent.yaml 생성 됐으면 마지막으로 다시한번 도커 컴포즈 야믈파일에서     entrypoint: pmm-agent setup 이부분 주석하고 다시한번 마지막으로 docker-compose up -d 으로 실행해주면 컨테이너가 잘 실행 될것이다.pmm-agent.yaml 파일에 데이터가 씌어져 있어야 한다.

여기서 발생한 에러 

위와같이 pmm.mycompanydomain.co.kr로 연결이 안됨.

원인 : pmm-client가 pmm-server로 연결 할 때 pmm.mycompanydomain.co.kr 주소로 연결하는데 
회사 구성은 도메인 연결시 nginx.proxy 구성이 돼 있기에 pmm.mycompanydomain.co.kr:443 은 nginx proxy 로 intra.mycompany.co.kr:11443으로 포워딩 해주고 있는데
https://forums.percona.com/t/pmm-agent-can-not-connect-to-pmm-server-when-using-reverse-proxy/8435/10
이 과정에서 문제가 있었던것 같고 그냥 intra.마이콤파니닷컴 명시해주었다.

마지막으로 pmm.url.com 대쉬보드로 접속해서 

아까 pmm 계정 생성했던(즉 모니터링 할 디비)서버 정보 입력해주고 몇분 기다려보면 아래와같이 데이터가 수집된다.

모니터링 하는 방법은

그래프 쌓아서 보다보면 이건 쫌 이상한데 ? 싶은 튀거나 이가 빠지는 그런 그래프가 있을꺼다. 딱봐도 수상해보이는 그래프들이 있을꺼니까 

위와 같이 해당 그래프의 panel json을 들어가보면 

각 그래프들의 설명을 자세하게 적어줬다. 심지어 URL까지.

목표 : isms 관점에서 법령에 맞게끔 DB로깅을 하고 분석을 한다.
필요 로그정보 : "누가,언제,어디서,무엇을,어떻게" 의 5개 정도 나오면 된다고 본다.

general로그에는 모든 쿼리가 전부 쌓이고 있으니 확인이 가능하지만 general 로그 용량이 너무 커져서 select query는 안남도록 하고싶다.

확인해보니 select을 제외한 트랜잭션이 발생한 쿼리만 로깅하는게 바이너리로그다. (알고 있었는데 까먹었었다.)

바이너리로그를 보는법은 mysqlbinlog bin로고ㅡ파일명 > filename.sql 확인 가능하다 허나 bin log에는 ISMS에서 필요로 하는 누가와 어디서가 나오지 않는다. 따라서 isms의 개인정보처리시스템에 대한 로그는 general로그를 보관하는게 맞다.

내가 쓰고도 이글의 요지가 뭔지 모르겠는데... 이글을 처음 쓰게된 이유(목표)는 general로그 용량이 워낙 크니 select 쿼리는 빼자였는데... isms 관점에서는 빼면 안되는거였다. 애초에 생각을 깊이 하지 않아서 이런 똥글이 나왔다.

이글은 마리아디비 공식 홈페이지에 있는 내용만을 참고하여서 오인입된 내용은 없을것같다.
영어에 익숙치 않고 columnstore가 뭔지 & 어떻게 사용하는지에 대해 알아보는 글이고, 알아보면서 한번에 이해되지 않는 용어들은 구글링해서 적어둠

1.mariadb columnstore란 

컬럼지향 스토리지 엔진이고(columnar storage)

대용량 병렬 분산 데이터 아키텍처를 사용(massively parallel distributed data architecture)
페타단위의처리를 위한 빅데이터 확장(big data scaling to process petabytes of data)
선형 확장성과 분석쿼리에 대한 실시간 응답을 통한 탁월한 성능(linear scalability and exceptional performance with real-time response to analytical queries)

한마디로 빅데이터 분석과 같은 MPP(대용량 병렬 분산 처리)용으로 설계된 columner 스토리지엔진이다.

2.architecture 

user모듈(UM), performance모듈(PM), storage로 구성

user module이란

프론트엔드로 작동한다. concurrency scaling(동시성확장? 동시에 실행되는 쿼리를 일관된 속도로 빠르게 처리하기 위해) 에 중점을 두고 있다. 
여기서 프론트엔드와 concurrency scaling 가 중요한듯 하다.
프론트엔드 : 엔드유저의 쿼리를 관리&제어한다. 허나 해당 쿼리를 실제로 처리하는건 퍼포먼스모듈임. 그래서 프론트엔드

concurrency scaling : 컬럼스토어엔진은 빅데이터 처리를 위한 엔진이기 때문에 concurrency scaling가 굉장히 중요하다. 그렇기 때문에 컬럼스토어에서는 여러개의 프로세스를 추가로 실행한다.

마지막으로 유저모듈에서 실행하는 프로세스들이 몇가지 있다. 마찬가지로 퍼포먼스 모듈에서도 몇가지 실행하는 프로세스들이 있는데 퍼포먼스 모듈 설명 말미에 스샷과 함께 설명할 예정

performance module이란

유저 모듈을 통해 받은 쿼리(데이터 저장 검색 관리등)를 처리하여 사용자 모듈로 다시 전달(셀렉쿼리 같은건 전달해야하고)해주거나 혹은 처리(인설트같은건 처리)하는 모듈

위 스크린샷처럼 각종 프로세스가 있다.
mysqld, exemgr, ddlproc,dmlproc는 유저모듈에서 실행하는 프로세스이고 나머지는 퍼포먼스 모듈에서 실행하는 프로세스다. 각각마다 기능이 있다. 예를들어 mysqld는 mariadb쿼리를 처리하기 위해 실행되는 프로세스로 쿼리 구문을 컬럼스토어가 처리할 수 있게 변환해준다. ddl/dml 은 각각 ddl/dml 처리하기 위한 프로세스일꺼고. 프로세스모니터는 procmon 등 자세히 알고 싶으면 공식독스 참고.(근데 굳이 이것까지 알아야 할 필요가 있나 싶다.)

storage란

3.query process는 ?

4.install & start & stop

5.트러블슛팅

local bulk load

각종 명령어

addDbroot MariaDB Columnstore 시스템에 DBRoot 디스크 스토리지 추가
addModule MariaDB Columnstore 시스템 내에 모듈 추가
alterSystem-disableModule 모듈 비활성화 및 MariaDB Columnstore 시스템 변경
alterSystem-enableModule 모듈 활성화 및 MariaDB Columnstore 시스템 변경
assignDbrootPmConfig 할당되지 않은 DBroot를 성능 모듈에 할당
assignElasticIPAddress 모듈에 Amazon Elastic IP 주소 할당
disableLog 프로세스 및 디버그 로깅 수준을 비활성화합니다.
disableMySQLReplication 시스템에서 MySQL 복제 기능 비활성화
enableLog 프로세스 및 디버그 로깅 수준을 활성화합니다.
enableMySQLReplication 시스템에서 MySQL 복제 기능 활성화
exit 콘솔 도구에서 나가기
findObjectFile 객체의 첫 번째 파일을 포함하는 디렉토리의 이름을 가져옵니다.
getActiveAlarms 활성 알람 목록 가져오기
getActiveSQLStatements 시스템 내 활성 SQL 문 목록 가져오기
getAlarmConfig 경보 구성 정보 가져오기
getAlarmHistory 시스템 알람 가져오기
getAlarmSummary 활성 경보의 요약 수 가져오기
getLogConfig 시스템 로그 파일 구성 가져오기
getModuleConfig 모듈 이름 구성 정보 가져오기
getModuleCpu 모듈 CPU 사용량 가져오기
getModuleCpuUsers CPU를 사용하는 모듈 상위 프로세스 가져오기
getModuleDisk 모듈 디스크 사용량 가져오기
getModuleHostNames 모듈 호스트 이름 목록 가져오기(NIC 1만 해당)
getModuleMemory 모듈 메모리 사용량 가져오기
getModuleMemoryUsers 메모리를 활용하는 모듈 상위 프로세스 가져오기
getModuleResourceUsage 모듈 리소스 사용량 가져오기
getModuleTypeConfig 모듈 유형 구성 정보 가져오기
getProcessConfig 프로세스 구성 정보 가져오기
getProcessStatus MariaDB Columnstore 프로세스 상태 가져오기
getSoftwareInfo MariaDB Columnstore 패키지 정보 가져오기
getStorageConfig 시스템 스토리지 구성 정보 가져오기
getStorageStatus 시스템 스토리지 상태 가져오기
getSystemCpu 모든 모듈의 시스템 CPU 사용량 가져오기
getSystemCpuUsers CPU를 사용하는 시스템 최상위 프로세스 가져오기
getSystemDirectories 시스템 설치 및 임시 로깅 디렉토리 가져오기
getSystemDisk 모든 모듈의 시스템 디스크 사용량 가져오기
getSystemInfo 전체 시스템 상태 가져오기
getSystemMemory 모든 모듈에서 시스템 메모리 사용량을 가져옵니다.
getSystemMemoryUsers 메모리를 활용하는 시스템 최상위 프로세스 가져오기
getSystemNetworkConfig 시스템 네트워크 구성 정보 가져오기
getSystemResourceUsage 모든 모듈에서 시스템 리소스 사용량 가져오기
getSystemStatus 시스템 및 모듈 상태 가져오기
help 콘솔 명령에 대한 도움말 보기
monitorAlarms 실시간 모드에서 경보 모니터링
movePmDbrootConfig 한 성능 모듈에서 다른 성능 모듈로 DBroot를 이동합니다.
종료 콘솔 도구에서 종료
redistributeData 디스크 사용량의 균형을 맞추기 위해 모든 dbroot에 걸쳐 테이블 데이터를 재배포합니다.
removeDbroot MariaDB Columnstore 시스템에서 DBRoot 디스크 스토리지 제거
removeModule MariaDB Columnstore 시스템 내에서 모듈 제거
resetAlarm 활성 경보를 재설정합니다.
restartSystem 중지되거나 종료된 MariaDB Columnstore 시스템을 다시 시작합니다.
resumeDatabaseWrites MariaDB Columnstore 데이터베이스에 대한 쓰기 수행 재개
setAlarmConfig 알람 구성 매개변수 설정
setModuleTypeConfig 모듈 유형 구성 매개변수 설정
setProcessConfig 프로세스 구성 매개변수 설정
shutdownSystem MariaDB Columnstore 시스템을 종료합니다.
startSystem 중지되거나 종료된 MariaDB Columnstore 시스템을 시작합니다.
stopSystem MariaDB Columnstore 시스템의 처리를 중지합니다.
suspendDatabaseWrites MariaDB Columnstore 데이터베이스에 대한 쓰기 수행을 일시 중단합니다.
switchParentOAMModule 활성 상위 OAM 모듈을 다른 성능 모듈로 전환합니다.
system 시스템 셸 명령을 실행합니다.
unassignDbrootPmConfig 성능 모듈에서 DBroot 할당 해제
unassignElasticIPAddress Amazon 탄력적 IP 주소 할당 해제

에러 내용
[ 38%] Building C object unittest/mysys/CMakeFiles/my_atomic-t.dir/my_atomic-t.c.o
[ 38%] Built target dynstring-t
Scanning dependencies of target my_getopt-t
[ 38%] Building C object unittest/mysys/CMakeFiles/my_getopt-t.dir/my_getopt-t.c.o
Linking CXX executable lf-t
[ 38%] Building C object mysys_ssl/CMakeFiles/mysys_ssl.dir/openssl.c.o
Linking CXX executable my_atomic-t
../../mysys/libmysys.a(my_cpu.c.o): In function `my_cpu_init':
/root/src/mariadb-10.3.22/mysys/my_cpu.c:86: undefined reference to `__rdtsc'
/root/src/mariadb-10.3.22/mysys/my_cpu.c:88: undefined reference to `__rdtsc'
/root/src/mariadb-10.3.22/mysys/my_cpu.c:90: undefined reference to `__rdtsc'
collect2: ld returned 1 exit status
make[2]: *** [unittest/mysys/lf-t] 오류 1
make[1]: *** [unittest/mysys/CMakeFiles/lf-t.dir/all] 오류 2
make[1]: *** 끝나지 않은 작업을 기다리고 있습니다....
[ 38%] Building CXX object mysys_ssl/CMakeFiles/mysys_ssl.dir/my_crypt.cc.o
Linking CXX executable my_getopt-t
[ 38%] Built target my_atomic-t
Linking CXX executable ma_dyncol-t
Linking CXX static library libmysys_ssl.a
[ 38%] Built target mysys_ssl
[ 38%] Built target my_getopt-t
[ 38%] Built target ma_dyncol-t
/root/src/mariadb-10.3.22/storage/mroonga/vendor/groonga/lib/expr.c: In function ‘grn_expr_exec’:
/root/src/mariadb-10.3.22/storage/mroonga/vendor/groonga/lib/expr.c:2620: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
/root/src/mariadb-10.3.22/storage/mroonga/vendor/groonga/lib/expr.c:2620: note: variable tracking size limit exceeded
Linking CXX static library libgroonga.a
[ 38%] Built target libgroonga
make: *** [all] 오류 2



os : CentOS release 6.10 (Final) / 2.6.32-642.el6.x86_64 / gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC) 

원인
gcc 버전이 낮아서 그런것 같다.
gcc-4.4 does not have support for rdtsc in x86intrin.h. It was added since gcc-4.5.
(https://jira.mariadb.org/browse/MDEV-20233?attachmentOrder=desc)참고

해결 33번 라인에
기존
#  include 
# else
변경
#  include 
# elif GCC_VERSION < 4005

#  include 
# else

마스터1대, 슬레이브 3대로 구성된 디비 서버들인데     

          Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.212
                   Master_User: slave1
                   Master_Port: 3813
                 Connect_Retry: 60
               Master_Log_File: mariadb-bin.602137
           Read_Master_Log_Pos: 163251227
                Relay_Log_File: localhost-relay-bin.013096
                 Relay_Log_Pos: 100492948
         Relay_Master_Log_File: mariadb-bin.602137
              Slave_IO_Running: Yes
             Slave_SQL_Running: No
               Replicate_Do_DB: 
           Replicate_Ignore_DB: 
            Replicate_Do_Table: 
        Replicate_Ignore_Table: 
       Replicate_Wild_Do_Table: 
   Replicate_Wild_Ignore_Table: 
                    Last_Errno: 1032
                    Last_Error: Could not execute Delete_rows_v1 event on table gameworkr.offer_account; Can't find record in 'offer_account', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mariadb-bin.602137, end_log_pos 101337573
                  Skip_Counter: 0
           Exec_Master_Log_Pos: 100492647
               Relay_Log_Space: 700123700
               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: NULL
 Master_SSL_Verify_Server_Cert: No
                 Last_IO_Errno: 0
                 Last_IO_Error: 
                Last_SQL_Errno: 1032
                Last_SQL_Error: Could not execute Delete_rows_v1 event on table gameworkr.offer_account; Can't find record in 'offer_account', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mariadb-bin.602137, end_log_pos 101337573
   Replicate_Ignore_Server_Ids: 
              Master_Server_Id: 1
                Master_SSL_Crl: 
            Master_SSL_Crlpath: 
                    Using_Gtid: No
                   Gtid_IO_Pos: 
       Replicate_Do_Domain_Ids: 
   Replicate_Ignore_Domain_Ids: 
                 Parallel_Mode: conservative
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: 
              Slave_DDL_Groups: 552
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 2545153712

위와같이 1032 에러 발생, 리플리케이션 장애발생

먼저
STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;START SLAVE;
슬레이브 1번서버 에러 스킵후 데이터를 확인해보니 에러 난 슬레이브1번 서버의 데이터가 정상이고 나머지가 비정상임을 확인

즉
마스터, 슬레이브2,3 의 데이터는 비정상이고 슬레이브1의 데이터가 정상이기에 슬레이브 1의 데이터를 마스터, 슬레이브2,3에 옮겨야 한다.

아래와 같이 작업 진행

1.모든 디비서버들 외부에서의 접속 차단(iptables로 디비 서버끼리는 통신되도록 하고 나머지 외부에서 들어오는건 차단) 그리고 한 1~2분정도 기다려서 리플리케이션 확인

2.슬레이브1 서버에서 정상 테이블 덤프 - drop table이나 no create 옵션 사용하여 insert 구문만 들어가도록 덤프

3.마스터 서버에서 문제있는 테이블 트렁케이트 후 기달려서 동기화 까지 확인
4.마스터 서버에 덤프받은 디비 복원 후 동기화 확인

ps.

디비 차단 안한상태에서, 즉 서비스에 최대한 문제 없이 진행하고자 한다면 아래와 같이 했으면 됐을듯싶다.

1.문제있는 테이블 수정권한이 있는 계정의 수정권한을 빼서 해당 테이블 변경되지 않도록 설정
2.나머지는 기존처럼 정상 테이블 백업 후 마스터에서 truncate 한 뒤 복원하기

[root@localhost ~]# /opt/mysql/bin/mysql -uroot -p'123123' -e 'SHOW SLAVE STATUS \G' | egrep "Master_Log_Pos"
           Read_Master_Log_Pos: 478353559
           Exec_Master_Log_Pos: 452076624

         Seconds_Behind_Master: 3971

위와같이 싱크가 잘 안맞는다.

bin 로그 확인시 지연될만한 쿼리가 아니고 개발자에게 문의해봐도 따로 쿼리 업데이트가 된건 없다고 한다.

iostat 
Linux 2.6.32-754.17.1.el6.x86_64 ()       08/05/2019      _x86_64_        (24 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.77    0.00    0.55    3.28    0.00   89.40

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               1.04         7.48        24.84    3539870   11757640
sdb               2.26         0.15      2158.02      70244 1021591088
sdc               0.00         0.01         0.00       6378          8
sdd             694.72      2571.53     18588.32 1217341239 8799565808

(sdd 디스크가 mysql data 디렉토리)

디스크 i/o가 높긴한데... 예전부터 높았다. 디스크 문제도 아닌것으로 보이고..

커널업데이트 한 이후부터 싱크가 안맞고 있음

i/o 스케쥴링이 cfg 로 설정돼있는 상태여서 noop(ssd 디스크임)으로 변경해봤으나 큰 차이가 없음

commitinnodb_flush_log_at_trx_commit = 2 으로 설정(기본 1)
ㄴhttps://santander.co.kr/151 참고

         Seconds_Behind_Master: 0

우선 조치완료.. 했으나 개운치않다. 추가 점검할 예정

190329 19:47:38  InnoDB: ERROR: the age of the last checkpoint is 13637149,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.

참고

https://dba.stackexchange.com/questions/16510/mysql-innodb-innodb-error-the-age-of-the-last-checkpoint-is-innodb-which-exc

iib_logfiib_logfile 0이랑 1 mv로 옮겨두고 

innodb_log_file_size = 52428800  (my.cnf에는 아무 설정 안돼있고 디폴트는 5242880 인데 0 하나 더 줌)

그리고 mysql 재시작

mysql 리플리케이션 운영중 슬레이브 서버에 문제가 발생

mysql 리플리케이션 구동방식이

데이터 업데이트 > master에서 업데이트된 쿼리를 bin로그에 기록 > slave의 io쓰레드에서 bin log를 토대로 relay  로그를 작성 > sql쓰레드에서 relay 로그를 토대로 slave의 DB 업데이트 > relay 로그 쓸모가 없어지면(master의 bin log가 삭제되면) relay 퍼지 옵션 디폴트가 on이기 때문에 자동으로 삭제됨

근데... slave서버에서 상태를 보면 

                Relay_Log_File: localhost-relay-bin.999999

위와같이 릴레이 로그-999999 를 보고 있따. 

[root@localhost data]# ls -lat localhost-relay-bin.11* | more
-rw-rw---- 1 mysql mysql  2891938 May  3 09:35 localhost-relay-bin.1157093

실제로는 위 파일을 바라봐야 한다.

order by limit 1 주고 계속 확인해보면 다행히도 실시간으로 동기화는 잘 되고 있다..
select count(*) from table 같은걸로 레코드 수 새보면 좋겠찌만... 실서비스중인데 부하 생길포인트 만드는건 쫌 아닌것같다.

여튼 상황 정리하면 아래와 같다.
1.디비 동기화는 잘 되고 있음
2.마스터 서버의 bin 로그는 잘 삭제되고 있음
3.슬레이브 서버의 relay bin 로그를 999999를 바라보고 있음
ㄴ실제로는 1157093 을 봐야함

4.relay 로그 삭제가 안되고 있음
5.error log는 없음

inc_group_relay_log_pos() 이 함수에 문제가 있다고 한다.
strcmp() 라는 함수를 통해 전/후 두개의 relay log를 비교하는데 이때 둘다 6자리까지는 정상적으로 비교가 되는데 6자리에서 7자리로 바뀔 때 즉, 999999 => 1000000 이때 문제가 있다고 한다.

추가로 handle_queued_pos_update() 라는 함수에서도 7자리로 변경될 때 parallel replication 이슈가 발생할 수 있다고 한다.

https://jira.mariadb.org/browse/MDEV-8134

패치는 뭐... 재컴파일하기엔 좀 무리가 있으니... 일단 relaylog 전부 reset으로 날리고 다시 맞춰준다음 relay log 용량을 10M(디폴트)에서 512M로 바꿔야겠다. 그럼 그렇게 많이 차진 않겠찌...
그래도 많이 차면 패치하고 재컴파일 해야할듯

----조치 한 사항---

1.우선 데이터 백업 한번 해주고

2.새벽에(접속자 최대한 없을 때)웹페이지 공지 띄우고 디비서버로의 접근 차단(마스터 서버 업데이트 없도록)
ㄴiptables 에서 마스터-슬레이브만 3306 포트 통신하도록 변경하고 나머지는 전체 차단, 웹에서도 차단
ㄴ마스터서버 binlog 파일 넘버랑 로그 포지션 안바뀌는거 확인

3.stop slave

4.reset slave
ㄴreset slave 하니까 삭제되지 않던 relay log 파일도 전부 삭제됨

5.start slave

6.CHANGE MASTER TO MASTER_LOG_FILE='<master-bin.number>', MASTER_LOG_POS=;

7.위와같이 작업하고 bin 로그파일 넘버랑 로그 포지션 넘버 동일한지 확인

위와같이 슬레이브 서버들 전부 진행하니까 잘 해결됐다.

추가로 10MB씩 쌓이던 relay 로그 파일 512MB로 변경함

innodb 의 경우 instert 속도가 myisam에 비해 느리다.

이경우 여러가지 튜닝을 할 수 있는데 대표적인것만 몇개 수정, 비교 해보려고 한다.

1.innodb_flush_log_at_trx_commit 를 0으로 변경하면 속도를 많이 올릴 수 있다고 한다.
innodb_flush_log_at_trx_commit 란...
https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html

요약하자면

innodb_flush_log_at_trx_commit 이란 쿼리 요청이 디스크에 저장되는 방법이 지정된 변수이다. 즉 이 값을 변경하면 트랜잭션 방법을 수정해서 insert 속도를 올릴 수 있따.

##트랜잭션, commit이란

먼저 DB에서의 트랜잭션이란 정상적으로 완료된 일련의 작업들이라고 생각하면된다. 예를들어 insert , update , delete가 순차적으로 일어나고 그후 commit을 하게되면 트랜잭션이 정상적으로 완료됐다할 수 있다. 즉 commit이란 저장되지 않은(메모리에 적혀있는)데이터를 디비에 저장 후 트랜잭션을 종료한다.

innodb_flush_log_at_trx_commit  값이 디폴트일때의 과정(즉 1일 때)은 아래 처럼 진행된다.

쿼리 하나당 [log buffer(메모리 영역)를 거쳐서 >os buffer/cache(메모리 영역)를 거쳐서  > 마지막으로 ib_logfile(디스크영역)에 저장(flush) 된다.] 즉 1회 요청당 1회 commit - 한번의 요청때마다 매번 commit을 진행한다. - (요게 핵심임)

0 또는 2로 바꾼다면 저 과정이 간략해진다.

innodb_flush_log_at_trx_commit  =0
쿼리 하나당 [log buffer(메모리 영역)저장]하고 1초에 한번씩 나머지 commit을 수행(os buffer/cache(메모리 영역)를 거쳐서  > 마지막으로 ib_logfile(디스크영역)에 저장(flush)])

innodb_flush_log_at_trx_commit  = 2

쿼리 하나당 [log buffer(메모리 영역)를 거쳐서 >os buffer/cache(메모리 영역)에 저장] 후 1초에 한번씩 나머지 commit을 수행ib_logfile(디스크영역)에 저장(flush)])

즉 0과 2의 차이는 쿼리하나당 log buffer까지 저장하느냐 os buffer/cache 까지 저장하느냐의 차이임

(혹시 이글을 읽으시는 분들중 틀린 내용이 있다면 제발 코멘트 부탁드립니다. 구글링하면서 다른 내용이 적잖이 보여서 사실 저도 좀 헷갈립니다.)

이론적으로 보면 속도 순서는 0 - 2 -1 순으로 빨라야 한다. 

비교를 해보자.

0이랑 2랑 거의 비슷하고(0이쫌더 빠르긴함) 확실히 1로 줬을때보단 빠르긴 한듯합니다. 용량 작으면 그냥 하고 용량 크면 데이터 유실될 가능성이 좀 더 적은 2로 주고 하는게 좋겠네요. 

2.innodb buffer pool size 

아마 이게 가장 대표적이고 또 확실히 눈에 보이게 성능 향상이 이루어질걸로 판단한다.

극단적으로 보기위해 기존에는 디폴트 값(128MB)과 서버 메모리(32GB)에 맞게끔 변경해서 비교했는데

7GB 짜리 덤프파일 복원 하는데 3시간 쫌 넘게 걸렸고
real    187m17.825s 
user    2m21.802s 
sys     0m6.869s

이번에는 innodb buffer pool size = 20GB로 변경하고 .sql 용량 =8GB 짜리 복원시(키 버퍼랑 등등 추가로 알맞게 진행)

real    40m44.386s
user    2m21.319s
sys     0m8.349s

역시... innodb buffer pool size 는 튜닝 필수다.

내용 요약.

1.innodb buffer pool size 수정은 필수(그에따른 키 버퍼나 솔트 버퍼등도 구글링해서 알맞게 수정)

2.용량이 큰 dump파일 복원시 innodb_flush_log_at_trx_commit 는 2로 변경
ㄴ실제 사용시 상황에 맞게(안전성이냐 속도냐) 1또는 2로 사용

master 서버 1대/ slave 서버 3대 리플리케이션 구성

CPU : E5-2620 v3 @ 2.40GHz, 24core / RAM : 96GB 4대 모두 동일사양 / 디비 용량 1.1TB / 테이블 약 220개, 그중 용량 큰 테이블은 약 40개정도(개당 10~40GB)

사양은 4대 모두 동일

관리 방법 정리
1.mysqldump
장점 : 간편하다.. 가장 기본적인 방법
(디비 용량이 작다면 심플하게 table 단위로 mysqldump 백업이 가장 좋다고 본다.)

단점 : 백업 시간이 오래걸리고 복원하는데도 오래걸린다. 

약 500GB 테이블단위로 백업하는데 약 2시간 30분 걸리고 377GB로 백업됨

1-1.mysqldump후 .sql 파일을 한번더 tar로 압축하여 보관

약 20GB 짜리 덤프파일 하나를 tar -cvzf 로 압축할경우 약 2.6GB로 압축됨, 압축하는데 걸리는 시간은 8분~8분30초

약 40GB 짜리 덤프파일 하나를 tar -cvzf 로 압축할경우 약 5.7GB로 압축됨, 압축하는데 걸리는 시간은 약 25분소요
ㄴ이 파일 압축 푸는데 걸리는 시간은 약 10분인데 400기가 데이터 날리면 약 100분동안 압축 푸는시간 날리는거

장점 : 용량을 많이 줄일 수 있으니까(상황에 따라 다르겠지만 실 데이터에 약 8분의1정도 압축됨) 그만큼 보관 주기도 길게 잡을 수 있다.

단점 : 백업하고 복원하는데 시간 더럽게 오래 걸린다.용량 큰 디비에 이거 하나만 가지고 운영하는건 거의 도라이짓임(누가 디비를 잘못 삭제해서 장애 한번나면... 복원하는데 시간 더럽게 오래걸림)

2.xtrabackup

장점 : 속도가 빠르다. 증분백업도 된다.
단점 : 용량이 크다. 추가로 설치해야한다.(ibdata나 디렉토리등 데이터를 복사하는 방식이라 실제 데이터와 용량이 거의 같다. 즉 1TB짜리 실 데이터 백업하려면 1TB가 필요, 증분 백업이 가능하기에 어느정도 커버 가능하다본다.)

xtrabackup

500GB 백업하는데 약 2시간 40분
덤브백업하는데 
real    165m33.431s
user    77m40.210s
sys     8m34.757s

MariaDB [(none)]> SHOW ENGINE INNODB STATUS\G

latest detected deadlock 항목에서 데드락을 확인할 수 있다.

마지막에 발생한 deadlock만 확인된다. 

내용을 보면

------------------------

LATEST DETECTED DEADLOCK

------------------------

2019-01-24 04:00:03 7f2914242b00 ## 데드락 발생시간

*** (1) TRANSACTION:  ##첫번째 트랜잭션

TRANSACTION 47312201250, ACTIVE 0 sec fetching rows

mysql tables in use 3, locked 3

LOCK WAIT 266 lock struct(s), heap size 30248, 2129 row lock(s)

MySQL thread id 13168615, OS thread handle 0x7f28fac80b00, query id 120397240 192.168.0.213 root updating

UPDATE `TABLE` SET `rsInstall` = '123123', `rsOpen` = '123123'   ##쿼리내용

WHERE `rsToday` = '123123'

AND `rsAdmIdx` = '123123'

AND `rsAffIdx` = '3123123'

AND `rsAdsIdx` = '123123'

AND `rsSubAffIdx` = '1123123'

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 9873 page no 170251 n bits 88 index `PRIMARY` of table `DB`.`TABLE` trx table locks 1 total table locks 2  trx id 47312201250 lock_mode X locks rec but not gap waiting lock hold time 0 wait time before grant 0     ##이부분이 지금 데드락에 빠진거고

*** (2) TRANSACTION:   ##두번째 트랜잭션

TRANSACTION 47312201244, ACTIVE 0 sec fetching rows

mysql tables in use 3, locked 3

241 lock struct(s), heap size 30248, 5827 row lock(s), undo log entries 22

MySQL thread id 13168659, OS thread handle 0x7f2914242b00, query id 120397235 192.168.0.213 root updating

UPDATE `TABLE` SET `rInstall` = '18123123, `rOpen` = '123123'   ##쿼리내용

WHERE `rsToday` = '123123'

AND `rsAdmIdx` = '123123'

AND `rsAffIdx` = '123123'

AND `rsAdsIdx` = '123213'

AND `rsSubAffIdx` = '123123'

*** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 9873 page no 170251 n bits 88 index `PRIMARY` of table `DB`.`TABLE` trx table locks 1 total table locks 2  trx id 47312201244 lock_mode X locks rec but not gap lock hold time 0 wait time before grant 0    ##여기도 데드락에 빠졌꼬 

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 9873 page no 170473 n bits 88 index `PRIMARY` of table `DB`.`TABLE` trx table locks 1 total table locks 2  trx id 47312201244 lock_mode X locks rec but not gap waiting lock hold time 0 wait time before grant 0    ##데드락을 해결하기위해 이부분이 롤백됨

*** WE ROLL BACK TRANSACTION (2)   

위 두개의 트랜잭션이 데드락에 빠졌꼬 이를 해결하기 위해 두번째 트랜잭션이 롤백됐음 을 확인할 수 있다.

음. 난 dba가 아니라서 이걸보고 그다음 뭘 어떠케 해줘야 하는지 모르겠네 그래도 일단 dba한테 알려는 줄 수 있는 se가 되자 

상황

버전 : mysql  Ver 15.1 Distrib 10.1.29-MariaDB, for Linux (x86_64) using readline 5.1

메모리 용량 : ~]# free

             total       used       free     shared    buffers     cached

Mem:      65856248   65592836     263412          4      92876     181636

-/+ buffers/cache:   65318324     537924

Swap:      8389624    6001720    2387904

위와같이 물리 메모리 전부 사용하고 스왑메모리까지 사용하고 있다.

우선 innodb buffer pool size 란 간단하게 innodb용 캐시 사이즈라고 생각하면 될듯하다.

###innodb_buffer_pool_instances 이거는 buffer pool size 를 몇개의 쓰레드로 나눌지. buffer pool size 가 1GB 이상일때만 사용가능

----------------------

BUFFER POOL AND MEMORY

----------------------

Total memory allocated 60728279040; in additional pool allocated 0    ### 약 56GB 정도 할당된걸 확인할 수 있음

Total memory allocated by read views 4192

Internal hash tables (constant factor + variable factor)

    Adaptive hash index 1547957664      (917988664 + 629969000)

    Page hash           7172584 (buffer pool 0 only)

    Dictionary cache    231761997       (229498768 + 2263229)

    File system         1032976         (812272 + 220704)

    Lock system         143445008       (143436728 + 8280)

    Recovery system     0       (0 + 0)

Dictionary memory allocated 2263229    ###딕셔너리에 할당된 메모리

Buffer pool size        3538936

Buffer pool size, bytes 57981927424

Free buffers            8189     
##나는 지금 요부분이 중요하다.
서버의 메모리가 부족하여 스왑메모리가 사용됐고 이걸 방지하기위해 불필요하게 사용되는 메모리는 없는지 찾고있는 상황이였고 디비의 innodb buffer poolsize가 전체 메모리의 약 85~90프로를 차지하고 있다. 따라서 innodb buffer pool size 를 줄여야 하는데.. 줄여도 되는 상황일까 ? 
free buffers 가 8189 이다. 

Database pages          3492297

Old database pages      1288984

Modified db pages       141927

Percent of dirty pages(LRU & free pages): 4.054

Max dirty pages percent: 75.000

Pending reads 0

Pending writes: LRU 0, flush list 117, single page 0

Pages made young 1465646, not young 3638134

6.33 youngs/s, 1.00 non-youngs/s

Pages read 3411009, created 1266390, written 13049586

0.67 reads/s, 19.33 creates/s, 228.46 writes/s

Buffer pool hit rate 999 / 1000, young-making rate 0 / 1000 not 0 / 1000

Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s

LRU len: 3492297, unzip_LRU len: 0

I/O sum[100408]:cur[2856], unzip sum[0]:cur[0]

결론

free buffer가 없으니 그냥 냅뒀따가 메모리 추가해야겠다. 
buffer pool size 의 쓰레드를 8개로 나눠서 사용하고 있는데 이거를 좀 더 잘게 나눠보고싶다. 근데 실 사용 서버이고 내가 갑이 아니라서 괜히 문제생기면 안되니까 걍 메모리 추가해야겠따.

마리아디비 슬로우쿼리를 3초나 5초등으로 적용 했는데도 슬로우쿼리에 모든 쿼리가 전부 쌓이는 증상이 있었다.

제너럴 로그였나 모든 쿼리 쌓는게 슬로우쿼리로 이름이 잘못돼있는건가... 이것저것 찾아보던중

##공식홈페이지 참고##

https://mariadb.com/kb/en/library/server-system-variables/#log_queries_not_using_indexes

log_queries_not_using_indexes

• Description: Queries that don't use an index, or that perform a full index scan where the index doesn't limit the number of rows, will be logged to the slow query log (regardless of time taken). The slow query log needs to be enabled for this to have an effect.
• Commandline: --log-queries-not-using-indexes
• Scope: Global
• Dynamic: Yes
• Data Type: boolean
• Default Value: OFF

위와같은 내용이 있다. 어쩌구 저쩌구 용량 관계없이 쓰여진다 뭐 이런 내용인듯. 기본값은 OFF라는데 왜 이서버들은 ON이냐

MariaDB [(none)]> SHOW VARIABLES LIKE '%log_queries_not_%';    

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

| Variable_name                 | Value |

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

| log_queries_not_using_indexes | ON    |

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

1 row in set (0.00 sec)

확인해보니 켜져있다.

MariaDB [(none)]> set global log_queries_not_using_indexes  = OFF;

Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SHOW VARIABLES LIKE '%log_queries_not_%';       

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

| Variable_name                 | Value |

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

| log_queries_not_using_indexes | OFF   |

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

1 row in set (0.00 sec)

껏다.

해결됐다. ㅋㄷㅋㄷ

WHERE (password = PASSWORD('$password') OR password = OLD_PASSWORD('$password'))

pdate TB_TEST set test_path = REPLACE(test_path,"www.naver.com","www.daum.net");

mysql에 접속하여 방향키를 위로 올리면 그전에 입력했던 명령어를 확인할수 있습니다. 그러나 이렇게 하나하나씩 말고 로그형식으로 저장돼있는 파일을 확인하는 방법을 알아보겠습니다.

쿼리 로그를 파일로 남기는 방법

1.

먼저 mysql에 접속을 합니다.

mysql -u root -p 
"패스워드"

현재 로그 활성화 상태를 확인 하겠습니다.

show variables where Variable_name in ('version', 'log', 'general_log');
off로 돼 있습니다.

on으로 바꿔주고 다시 확인해보겠습니다. 

set global general_log = 1;
show variables where Variable_name in ('version', 'log', 'general_log');
on으로 바꼈습니다.

로그 파일을 확인해보겠습니다.

로그 파일의 위치는 코리아 IDC 기준 /free/mysql_data 입니다.(mysql db 디렉토리)

localhost.log 란 이름으로 저장이 됩니다.

이제 새로운 세션으로 접속하고 테스트 쿼리를 날려 확인해보겠습니다.

위에 있는 세션으로 show processlist; 란 쿼리를 입력하였고 
아래 세션이 새로 접속하여 /free/mysql_data디렉토리에 위치해 있는 localhost.log 란 파일을 확인중입니다.
확인 결과 날짜와 시간과 함께 입력한 쿼리문이 보입니다.

이방법은 mysql server를 재시작하지 않아도 바로 적용이 됩니다. 하지만 mysql server를 재시작 한다면 옵션이 풀리기때문에 이 방법을 사용하려한다면 set global general_log = 1; 옵션으로 다시 로그를 활성화 시켜야 합니다.

2.

첫번째 방법과 동일하게 로그를 활성화 시키는 방법입니다. 첫번째 방법과 다른점은 
my.cnf를 수정하는 방법으로 첫번째 방법과 반대로 mysqlserver를 재시작 해줘야 적용이 되고 재시작을 해줘도 계속 적용 됩니다.

my.cnf를 vi로 열어줍니다.

vi /etc/my.cnf

mysqld를 찾아 밑에 log = /free/mysql_data(mysqldb디렉토리)/logname.log 를 입력합니다.

저장하고 나온뒤 mysql.server를 재시작합니다.

재시작한뒤 로그를 확인해봅니다.

위에 두 방법은 정상적인 쿼리만 쌓이기 때문에 test; sdlfsdkl; 등의 인식되지 않는 명령어는 로그에 남지 않습니다.
또한 일반 웹사이트에서의 모든 쿼리또한 전부저장됩니다. 위에 보시는 것처럼 11시08분 30초에만 약 15~20개의 쿼리가 입력됩니다.
그렇기 때문에 이 방법을 쓴다면 해당 로그파일의 용량이 금방 늘어납니다.
(첫번째 방법을 실행한 서버는 mysql만 설치되어있는 테스트서버이고 두번째 방법을 실행한 서버는 실제 구동중인 서버입니다. 그래서 첫번째 결과에 쿼리가 많이 안찍혀있습니다.)

마지막 세번째 방법 입니다.

이 방법은 일반 리눅스 시스템에서 명령어를 남기는 history와 같습니다. 위치는 홈디렉토리이고 파일명은 .mysql_history입니다.

cd ~
ls -al

일반 history인 .bash_history가 보이고 mysql history 파일인 .mysql_history 파일이 보입니다.
파일명 앞에 . 이 붙게 된다면 그 파일은 숨김파일이 됩니다. ls -al 을 하여 확인 가능 합니다.

.mysql_history 파일을 확인해보겠습니다.

위에 보시면 아시겠지만 맨처음 지정한 루트 패스워드가 나옵니다. 패스워드가 여과없이 전부 출력 됩니다.그렇기 때문에 보안상 매우 취약합니다.
그렇다면 mysql_histroy를 남지 않게끔 하는 방법을 알아보겠습니다.

1.
우선 생성되어있는 .mysql_history 파일을 삭제합니다.
그다음 mysql_history 파일을 /dev/bull으로 심볼릭 링크를 겁니다.

ln -s /dev/null /홈디렉토리(root계정은 root 또는 ~ )/.mysql_history

이방법은 루트 계정만 돌아가는 서버면 상관 없겠지만 일반 계정이 많은 서버에서는 추천하지 않습니다.
이유는 일반계정마다 하나하나씩 해줘야하고 해준다 해도 나중에 일반계정을 추가하면 또 심볼릭 링크를 따로 걸어줘야합니다.

2.
MYSQL_HISTFILE 변수를 /dev/null로 설정

vi /etc/profile
export MYSQL_HISTFILE=/dev/null 추가 한뒤 저장

source /etc/profile

이상입니다.

보안과 편리함은 반비례하기 때문에 잘 판단하여 사용하기 바랍니다.

mysql 5.6 버전 기준입니다.
cmake로 컴파일 하는 버전, 즉 5.5.9 버전부터 최근에 나온 버전(5.7.2) 까지는 거의 동일합니다.

따라서 사용중인 mysql 버전이 5.5버전 이상인 경우는 버전에 크게 신경 안써도 됩니다.

설치시 어떤 옵션을 주어야 할지 몰라서 오신분들은 마지막 부분에 추천 옵션만 보시면 됩니다.

옵션중 "bool"로 표기돼 있는 것은 0(OFF) 또는 1(ON)로 주면 됩니다.
ex)-DENABLED_LOCAL_INFILE=bool 이란 옵션이 있다면
   -DENABLED_LOCAL_INFILE=1(활성화)
   -DENABLED_LOCAL_INFILE=0(비활성화) 입니다. 
   -DENABLED_LOCAL_INFILE 옵션의 기본값은 off 입니다. 따라서 이 옵션을 사용하지 않는다면 안써주면 됩니다. 
    그러나 이 옵션을 활성화 해야 한다면 -DENABLED_LOCAL_INFILE=1 으로 하면 됩니다.

---------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
Installation Layout Options

-DINSTALL_LAYOUT=name   기본값=standalone
사전 정의 된 설치의 레이아웃을 선택.

standalone = 동일한 레이아웃입니다. tar.gz 형식을 위해 사용. ZIP 패키지
rpm:RPM 패키지와 비슷한 레이아웃.
svr4:Solaris 패키지 레이아웃.
deb:DEB 패키지 레이아웃. 실험(미완성버전?이나 테스트용을 뜻하는듯)

ex)solaris 패키지 레이아웃으로 설치를 원한다면   -DINSTALL_LAYOUT=svr4
솔라리스 레이아웃을 선택하지만 추가로 다른 옵션을 지정하여 개별 구성 요소의 설치 위치를 변경 할수 있다.
예를들면 
shell> cmake . -DINSTALL_LAYOUT=SVR4 -DMYSQL_DATADIR=/var/mysql/data
(레이아웃은 솔라리스패키지용으로 설치하되, mysql datadir는 /var/mysql/data로 지정)

-DCMAKE_INSTALL_PREFIX=dir_name   기본값=/usr/local/mysql
mysql 디렉토리 설치 경로 지정

-DINSTALL_BINDIR=dir_name        기본값=PREFIX/bin
bin 파일

-DINSTALL_DOCDIR=dir_name  기본값=PREFIX/docs
documentaion 파일

-DINSTALL_DOCREADMEDIR=dir_name  기본값=PREFIX
readme 파일

-DINSTALL_INCLUDEDIR=dir_name  기본값=PREFIX/include
header 파일 
 
-DINSTALL_INFODIR=dir_name  기본값=PREFIX/docs 
info 파일

-DINSTALL_LIBDIR=dir_name  기본값=PREFIX/lib
library 파일

-DINSTALL_MANDIR=dir_name  기본값=PREFIX/man
manual page

-DINSTALL_MYSQLSHAREDIR=dir_name 기본값=PREFIX/share
shared data 파일

-DINSTALL_MYSQLTESTDIR=dir_name  기본값=PREFIX/mysql-test
 mysql-test 디렉토리

-DINSTALL_PLUGINDIR=dir_name  기본값=PREFIX/lib/plugin
plugin 디렉토리

-DINSTALL_SBINDIR=dir_name  기본값=PREFIX/bin
mysqld server 파일

-DINSTALL_스크립트DIR=dir_name  기본값=PREFIX/스크립트s
mysql_install_db 디렉토리

-DINSTALL_SHAREDIR=dir_name  기본값=PREFIX/share
aclocal/mysql.m4 파일

-DINSTALL_SQLBENCHDIR=dir_name  기본값=PREFIX
sql-bench 디렉토리

-DINSTALL_SUPPORTFILESDIR=dir_name 기본값=PREFIX/support-files
extra support files 파일

-DMYSQL_DATADIR=dir_name
mysql data디렉토리

-DODBC_INCLUDES=dir_name
ODBC includes 디렉토리

-DODBC_LIB_DIR=dir_name
ODBC library 디렉토리

-DSYSCONFDIR=dir_name
기본 my.cnf의 옵션 파일 디렉토리

--------------------------------------------------------------------
CMAKE_INSTALL_PREFIX 와 MYSQL_DATADIR 옵션을 제외한 나머지 옵션들은 따로 설정할 필요가 없다.
이유는 보시다시피 전부 기본값이 CMAKE_INSTALL_PREFIX 옵션으로 지정해준 경로의 하위 디렉토리이기 때문이다.
MYSQL_DATADIR 는 편한대로 지정해주면 된다.

Installation Layout Options 중에서 알아둬야할 옵션은 -DCMAKE_INSTALL_PREFIX 와 MYSQL_DATADIR 이다.
나머지는 기본값으로 해도 무방하다.

---------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
Storage Engine Options

서버에 정적스토리지 엔진 설정

-DWITH_engine_STORAGE_ENGINE=1

ex)
-DWITH_INNOBASE_STORAGE_ENGINE=1
-DWITH_ARCHIVE_STORAGE_ENGINE=1
-DWITH_BLACKHOLE_STORAGE_ENGINE=1
-DWITH_PERFSCHEMA_STORAGE_ENGINE=1

반대로 제외할려면
-DWITHOUT_engine_STORAGE_ENGINE=1

myisam 엔진은 따로 설정할 필요가 없다.

---------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
Feature Options

-DCOMPILATION_COMMENT=string
컴파일 환경에 대한 설명 코멘트

-DDEFAULT_CHARSET=charset_name  기본값:latin1
서버의 기본 케릭터셋 설정

-DDEFAULT_COLLATION=collation_name 기본값:latin1_swedish_ci
서버의 기본 콜레이션 설정

-DENABLE_DEBUG_SYNC=bool
서버에 디버깅 동기화 기능을 컴파일하는것으로 , 테스트 및 디버깅을 위해 사용됨.
이 옵션은 기본적으로 활성화 되어 있지만 mysql 설정에서 디버깅이 구성되어 있지 않으면 효과가 없다.
디버깅을 활성화하고 디버깅 동기화를 비활성화하는 경우는 -DENABLE_DEBUG_SYNC=0 옵션을 사용

-DENABLE_DOWNLOADS=bool   기본값:off
어떤 파일을 다운로드할지 여부

-DENABLE_DTRACE=bool
DTrace 프로브의 지원을 포함할지 여부

-DENABLE_GCOV=bool
gcov의 지원을 포함할지 여부 (리눅스에서 가능)

-DENABLE_GPROF=bool    기본값:off
gprof 사용 여부(최적화된 리눅스에서 가능)

-DENABLED_LOCAL_INFILE=bool  기본값:off
LOAD DATA INFILE에 대한 클라이언트 라이브러리에서 LOCAL 기능을 사용할지 여부

-DENABLED_PROFILING=bool  기본값:on
쿼리 프로파일 링 코드를 사용할지 여부   

-DIGNORE_AIO_CHECK=bool   기본값:off
DBUILD_CONFIG=mysql_release옵션을 줬을때 libaio 라이브러리 검사를 무시

-DMYSQL_MAINTAINER_MODE=bool  기본값:off
MySQL의 메인테이너 특정 개발 환경을 사용할지 여부

-DMYSQL_PROJECT_NAME=name  기본값:3306
Windows or Mac OS X 에서만 사용가능

-DMYSQL_TCP_PORT=port_number  기본값:3306
tcp/ip 포트 넘버 설정

-DMYSQL_UNIX_ADDR=file_name  기본값:/tmp/mysql.sock
서버가 소켓 연결을 수신하는 Unix 소켓 파일의 경로.
절대경로로 써주어야 합니다.

-DOPTIMIZER_TRACE=bool
최적화 프로그램 추적을 지원하는지 여부

-DWITH_DEBUG=bool   기본값:Off
디버깅 지원을 포함할지 여부

-DWITH_DEFAULT_COMPILER_OPTIONS=bool 기본값:ON
기본 컴파일러 옵션을 사용할지 여부
-DWITH_DEFAULT_FEATURE_SET=bool  기본값:ON
기본 freature 옵션을 사용할지 여부
위에 두 옵션의 기본 옵션의 위치는 cmake/build_configurations/'compiler' or feature_set.cmake 파일

-DWITH_EXTRA_CHARSETS=name  기본값:all
추가로 지원할 케릭터셋 설정

-DWITH_INNODB_MEMCACHED=bool  기본값:OFF
memcached의 공유 라이브러리를 생성할지 여부(libmemcached.so and innodb_engine.so)

-DWITH_LIBEVENT=string   기본값:bundled
두 libevent 라이브러리 사용

-DWITH_LIBEDIT=bool   기본값:on
bundled libedit 라이브러리를 사용

-DWITH_LIBWRAP=bool   기본값:off
libwrap의 (TCP wrappers) 지원을 포함할지 여부

-DWITH_READLINE=bool   기본값:off
bundled readline 라이브러리를 사용
readline은 오래된 번들로서 5.6.5 버전부터 삭제된 옵션

-DWITH_SSL={ssl_type|path_name}  기본값:no
ssl 지원 여부

-DWITH_UNIXODBC=1   기본값:off
unixodbc사용가능 여부

-DWITH_ZLIB=zlib_type   기본값:system
zlib지원 여부

-DWITHOUT_SERVER=bool   기본값:off
mysqlserver없이 구축할지 여부

---------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------

추천 옵션
 

-DCMAKE_INSTALL_PREFIX=/usr/local/mysql
-DSYSCONFDIR=/free/mysql_data
-DMYSQL_UNIX_ADDR=/usr/local/mysql/tmp/mysql.sock
-DDEFAULT_CHARSET=utf8
-DDEFAULT_COLLATION=utf8_general_ci
-DWITH_EXTRA_CHARSETS=complex
-DWITH_INNOBASE_STORAGE_ENGINE=1
-DWITH_ARCHIVE_STORAGE_ENGINE=1
-DWITH_BLACKHOLE_STORAGE_ENGINE=1
-DWITH_PERFSCHEMA_STORAGE_ENGINE=1
-DWITH_READLINE=1
-DMYSQL_TCP_PORT=3306
-DENABLED_LOCAL_INFILE=1

-DMYSQL_USER=mysql

설명
-DCMAKE_INSTALL_PREFIX=/usr/local/mysql
mysql 디렉토리 지정.

-DSYSCONFDIR=/free/mysql_data
db디렉토리 지정

-DMYSQL_UNIX_ADDR=/usr/local/mysql/tmp/mysql.sock
mysql.sock 위치 지정.

-DDEFAULT_CHARSET=utf8
디폴트 케릭터셋 지정

-DDEFAULT_COLLATION=utf8_general_ci
디폴트 콜레이션 지정

-DWITH_EXTRA_CHARSETS=complex
추가 지원할 케릭터셋 all,complex,none 이 있다. all 로 줘도 무방하지만 complex로 줘도 충분합니다.

-DWITH_INNOBASE_STORAGE_ENGINE=1
-DWITH_ARCHIVE_STORAGE_ENGINE=1
-DWITH_BLACKHOLE_STORAGE_ENGINE=1
-DWITH_PERFSCHEMA_STORAGE_ENGINE=1
스토리지 엔진 장착 
(mysql5.6부터는 기본 엔진이 innodb이고, 각 엔진마다 장단점이 있다.설치후 변경 가능)

-DWITH_READLINE=1
readline 사용 가능
이 옵션을 사용하면 원격접속후 mysql에서 한글 타이핑시 한글이 보입니다. 사용하지 않으면 한글이 보이지 않고 그냥 빈 공백으로 보입니다.  그러나 테스트 결과 옵션 적용해도 글자가 안 보입니다. 어차피 이제 곧 없어질 옵션이니 써도 그만 안써도 그만, 크게 신경 쓸 필요없는 옵션입니다.
이 옵션은 5.6.6 부터는 사용되지 않습니다. 이유는 너무 오래된 번들이기 때문.

-DMYSQL_TCP_PORT=3306
mysql 기본 포트 3306

-DENABLED_LOCAL_INFILE=1
local_infile 변수 사용 가능하게끔.
텍스트 파일의 데이터를 특정 테이블에 저장하는 변수.

-DMYSQL_USER=mysql

이 옵션은 공식홈페이지에는 나와있지 않은 옵션입니다. 그러나 mysql 설치하시는 분들중 종종 이 옵션을 넣더군요. 테스트결과 서버에 아무 지장 없으니 넣어도 그만 안넣어도 그만입니다.

mysql사용자를 "mysql"이란 사용자로 하는거겠지요 ?

이상 mysql 설치시 옵션에 대해 알아보았습니다.

5.6버전 기준이며 mysql 공식 홈페이지 http://dev.mysql.com/doc/refman/5.6/en/source-configuration-options.html 참조 하였습니다.

몇몇 옵션들은 기본값이 off로 돼 있어도 설치해보면 on으로 돼있는 경우도 있습니다.
ex)-DENABLED_LOCAL_INFILE=1   //디폴트값은 0ff로서 이옵션을 주지 않으면 off로 돼있어야 하지만 on으로 돼있음

그렇기 때문에 옵션값과 디폴트값이 같더라도 중요한 옵션은 다시한번 적어주었습니다.
ex)-DCMAKE_INSTALL_PREFIX=/usr/local/mysql

서버 환경이나 용도에 따라 변경 하셔야 합니다.

select * from db;

디비 나열

--------------------------

select User, Db from db;

db안에 user랑 db열만 나열

-------------------------

select * from db where User = 'root';

db안에 user이름이 root만

-------------------------------

select User from db;

where User like '%ot'

db에 ot로 끝나는(root,bot,soot등)것들 User열만 나열

---------------------------------

character_set_client : 클라이언트로부터 전달되는 명령문 문자셋

character_set_connection : 서버가 명령문을 해석하기 위해 사용하는 문자셋

character_set_database : 현재 데이터 베이스의 기본 문자셋 없으면 서버의 기본 문자셋

character_set_results : 서버가 결과값을 클라이언트에 보내는 문자셋

character_set_server : Mysql 시작시 옵션 default-character-set=utf8 에 의해 결정되는 default 캐릭터셋

에러 로그

log-error=/home/mysql/err.log

쿼리 로그

log=/home/mysql/data/query.log

바이너리 로그

log-bin=mysql-bin

# 슬로우 쿼리 로그

log-slow-queries=/home/mysql/data/mysql-slow.log

long_query_time=3

# UPDATE 쿼리

log-update=update_logs

root 비번 생성

>mysqladmin -u root password 비밀번호

또는

>mysql -u root -p

>엔터(그냥 엔터)

mysql>set password for 'root'@'localhost' = password('tetsets');

-----------------------

mysql을 설치후 root로 로긴이 안된다면

# : killall -9 mysqld

# : mysqld_safe --skip-grant &

# : mysql

mysql>set password for 'root'@'localhost' = password('비밀번호');

mysql>flush privileges; 

----------------------

유저 , 유저 패스워드 신규 생성

mysql>create user '유저'@'localhost' identified by '유저패스워드';

모든 디비에 권한위임(로컬에서만 접속가능)

mysql>grant all privileges on *.* to '유저명'@'localhost' identified by '비밀번호'

모든 디비에 권한위임(원격접속 가능)

mysql>grant all privileges on *.* to '유저명'@'%' identified by '비밀번호' with grant option

특정 디비에 권한위임

mysql>grant all privileges on 디비명.* to '유저명'@'localhost' with grant option

flush privileges

--------------------------

데이터베이스 생성

status

create database 데이터명;

--------------------------

mysql 유저 비밀번호 변경

mysql>use mysql;

mysql>update user set password=password('비밀번호') where user='사용자';

mysql>flush privileges;

insert into user (host,user,password) values('%','kjtnet_test',password('kjttest')); 

insert into db values('%','%','kjtnet_test','y','y','y','y','y','y','y','y','y','y','y','y','y','y','y','y','y'); 

update ABCDE set column1='xyz' where no='3'
'ABCDE' 테이블의
'column1' 컬럼 값을 'xyz' 으로 수정한다.
수정대상은 'no' 컬럼값이 '3' 인 레코드 전부이다.
 
 
update ABCDE set column1='xyz' where no>3
'ABCDE' 테이블의
'column1' 컬럼 값을 'xyz' 으로 수정한다.
수정대상은 'no' 컬럼값이 '3' 보다 큰 레코드 전부이다.
 
 
update ABCDE set point=(point+50) where no<>3
'ABCDE' 테이블의
'point' 컬럼 값을 현재 값보다 50을 더한 값으로 수정한다.
수정대상은 'no' 컬럼값이 '3' 이 '아닌' 레코드 전부이다.
 
 
update ABCDE set column1='xyz',column2='1234' where point>3 and point<100
'ABCDE' 테이블의
'column1' 컬럼 값을 'xyz' 으로,  'column2' 컬럼 값을 '1234' 로 수정한다.
수정대상은 'point' 컬럼값이 '3' 보다 크고 100 보다 작은 레코드 전부이다.
 
 
update ABCDE set column1='xyz' where no>3 order by uid limit 20
'ABCDE' 테이블의
'column1' 컬럼 값을 'xyz' 으로 수정한다.
수정대상은 'no' 컬럼값이 '3' 보다 큰 레코드이고,
전체목록을 uid 컬럼값을 기준으로 정렬해서 상위 20 개를 수정한다.
 
 

update ABCDE set column1=replace(column1,'코리아','한국')
'ABCDE' 테이블의
'column1' 컬럼 값에 '코리아' 라는 단어가 포함되어 있다면 모두 '한국' 으로 수정한다.
 

update ABCDE set column1=replace(column1,'코리아','한국') where wdate>1159454960
'ABCDE' 테이블의
'column1' 컬럼 값에 '코리아' 라는 단어가 포함되어 있는 것은  '한국' 으로 수정한다.
수정대상은 wdate 컬럼의 값이 1159454960 보다 큰 레코드 이다.
 

update ABCDE set column1=concat(column1,'hellow') where no>5
'ABCDE' 테이블의
'column1' 컬럼 값에 'hellow' 라는 단어를 덧붙인다.
수정대상은 no 컬럼의 값이 5 보다 큰 레코드 이다.

출처

https://www.technote.co.kr/php/technote1/board.php?board=faq&command=body&no=14

데이터 원본 이름이 없고 기본 드라이버를 지정하지 않았습니다.

mysql connector/odbc 사용할때 로컬 pc 비트수에 상관없이 접속할 서버에 맞춰서 다운받아야한다.

ex)pc 32bit고 db서버가 64bit면 64비트용 받아야함 반대로 pc가 64비트 db서버가 32비트면 32비트용

root@localhost:/opt/mysql/scripts# ./mysql_install_db --base-dir=/opt/mysql --datadir=/opt/mysql/data

FATAL ERROR: Could not find ./bin/my_print_defaults

If you compiled from source, you need to run 'make install' to

copy the software into the correct location ready for operation.

If you are using a binary release, you must either be at the top

level of the extracted archive, or pass the --basedir option

pointing to that location.

FATAL ERROR: Could not find ./bin/my_print_defaults

위 에러 처럼 경로를 제대로 못찾고있다.

해결은

vi로 ./mysql_install_db 열어서

 21 basedir="/opt/mysql"

 22 builddir=""

 23 ldata="/opt/mysql/data"

위 라인에 직접 basedir ldata 에 직접 경로 넣어주고

./mysql_install_db

위에처럼 basedir 이나 datadir 옵션 주지말고 그냥 실행하면됨

mysql 처음 컴파일할때 아래 옵션 추가

-DWITH_INNODB_MEMCACHED=ON

###위 옵션 안해주면 플러그인에 innodb_memcached 설치 안됨

그다음 설치 다 하고

 # mysql -u root -p < /opt/mysql/share/innodb_memcached_config.sql

 # mysql -u root -p

mysql> install plugin daemon_memcached soname "libmemcached.so";

다하고 mysql 재시작하면 아래와같이 mysql 로 11211 포트 올라온거 확인됨

tcp        0      0 :::11211                    :::*                        LISTEN      7093/mysqld       

mysql> set global log_slow_queries = ON;              

ERROR 1238 (HY000): Variable 'log_slow_queries' is a read only variable

####공식홈페이지 설명#######

One way around this is to setup the machine with the Slow Query Log 

enabled but to use a very large value of --long-query-time to 

essentially ignore every query. Then, when you want to capture slow 

queries, you reset --long-query-time to a reasonable value. 

Unfortunately, this requires a restart to initialize. After that you can 

adjust the --long-query-time to throttle the contents of the log.

mysql5.0 버전까지는 재시작없이는 설정이 안된단다. my.cnf에 등록하고 db 재시작해야한다. 5.1부터는 재시작없이 설정가능