에러 내용
[ 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

 

MySQL :: MySQL 8.0 Reference Manual :: 15.13 InnoDB Startup Options and System Variables

MySQL 8.0 Reference Manual  /  The InnoDB Storage Engine  /  InnoDB Startup Options and System Variables 15.13 InnoDB Startup Options and System Variables System variables that are true or false can be enabled at server startup by naming them, or disabled

dev.mysql.com

요약하자면

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일때 1일때 2일때
12GB 45분 60분 50분
10GB 40분 50분 45분
15GB 65분 80분 65분
18GB 75분 95분 75분
14GB 테스트 안함 75분 60분
19GB 테스트 안함 105분 85분
19GB 테스트 안함 105분 85분

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로 사용

'job > mysql' 카테고리의 다른 글

mysql log file size error  (0) 2019.06.26
mysql replication relay log relay-bin.999999 bug  (0) 2019.05.03
innodb mysql/mariadb insert 속도 높이기  (0) 2019.04.12
mysql 대용량 DB 백업 구성  (0) 2019.04.09
mysql dead lock 확인하기  (0) 2019.01.24
mysql innodb buffer pool size  (0) 2019.01.24

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 이상일때만 사용가능


내용 요약하자면
1.설정 안할경우 기본값은 128MB
2.최대값은 32bit의 경우 4GB(그러나 실제로는 더 낮을 수 있다고 한다.), 64bit의 경우 16엑사?바이트(첨봄, 테라>페타>엑사)
3.DB서버로만 이용할경우 물리 메모리의 80%를 권장한다.
4.할당값보다 10% 추가로 할당됨(디스크 파티션 나눌 때 10%정도 빠지는거랑 같은거)

공식홈페이지에 보면 innodb buffer 에대한 여러가지 기능(더블라이트나 뭐 하이튼 겁내 별게 많음)들을 사용하면 성능향상에 도움이 될 꺼같은데 언제 써야 도움이 되는지를 모르겠네...

하여튼 버퍼가 뭔지 알았으니까 이제 버퍼 사이즈를 조정할껀데.. 조정하는 이유를 먼저 알아야한다.(조정할 필요가 없는데 조정하면 안되니까)

조정하는이유는 메모리가 가득차서 스왑메모리영역까지 사용해버린다. 스왑사용하면 속도가 느려지니까 스왑사용안되도록 조치를 해야한다.(정상적으로 메모리가 사용이 되는거라 메모리부족한거면 메모리를 늘려야한다.) 보니까 버퍼 풀 사이즈가 큰거같다. 54GB로 잡혀있다. 이걸 줄여도 될까 자세히 한번 알아봐야겠따.

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

SHOW ENGINE INNODB STATUS\G 명령어로 엔진의 상태를 좀 봐봐야겠다.
(
innodb의 상태를 저장해주는 innodb 모니터링이라는게 있는데 이걸 불러오는 명령어가 show engine innodb status 이다.즉 innodb 상태 보는 명령어. 내가 지금 봐야하는 buffer pool memory 섹션외에도 디텍티드 데드락섹션, 트랜잭션 세션이나 세마포어 섹션을 확인하여 데드락의 원인을 파악할 수 있다. 이거 다하고 공부해야지)

나는 buffer pool and memory 섹션을 봐야한다.

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

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개로 나눠서 사용하고 있는데 이거를 좀 더 잘게 나눠보고싶다. 근데 실 사용 서버이고 내가 갑이 아니라서 괜히 문제생기면 안되니까 걍 메모리 추가해야겠따.

'job > mysql' 카테고리의 다른 글

mysql 대용량 DB 백업 구성  (0) 2019.04.09
mysql dead lock 확인하기  (0) 2019.01.24
mysql innodb buffer pool size  (0) 2019.01.24
마리아디비 mariadb slow query log 적용 안될 때  (0) 2019.01.21
mysql old패스워드 password 함수 동시 사용  (0) 2018.09.03
mysql update replace  (0) 2018.09.03


마리아디비 슬로우쿼리를 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)


껏다.


해결됐다. ㅋㄷㅋㄷ

'job > mysql' 카테고리의 다른 글

mysql dead lock 확인하기  (0) 2019.01.24
mysql innodb buffer pool size  (0) 2019.01.24
마리아디비 mariadb slow query log 적용 안될 때  (0) 2019.01.21
mysql old패스워드 password 함수 동시 사용  (0) 2018.09.03
mysql update replace  (0) 2018.09.03
mysql history 로그 설정  (0) 2018.09.03

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

'job > mysql' 카테고리의 다른 글

mysql innodb buffer pool size  (0) 2019.01.24
마리아디비 mariadb slow query log 적용 안될 때  (0) 2019.01.21
mysql old패스워드 password 함수 동시 사용  (0) 2018.09.03
mysql update replace  (0) 2018.09.03
mysql history 로그 설정  (0) 2018.09.03
mysql 컴파일시 옵션 설명  (0) 2018.09.03

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

'job > mysql' 카테고리의 다른 글

마리아디비 mariadb slow query log 적용 안될 때  (0) 2019.01.21
mysql old패스워드 password 함수 동시 사용  (0) 2018.09.03
mysql update replace  (0) 2018.09.03
mysql history 로그 설정  (0) 2018.09.03
mysql 컴파일시 옵션 설명  (0) 2018.09.03
mysql select 문  (0) 2018.09.03

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

 

이상입니다.

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

'job > mysql' 카테고리의 다른 글

mysql old패스워드 password 함수 동시 사용  (0) 2018.09.03
mysql update replace  (0) 2018.09.03
mysql history 로그 설정  (0) 2018.09.03
mysql 컴파일시 옵션 설명  (0) 2018.09.03
mysql select 문  (0) 2018.09.03
mysql 케릭터셋  (0) 2018.09.03

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

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

'job > mysql' 카테고리의 다른 글

mysql update replace  (0) 2018.09.03
mysql history 로그 설정  (0) 2018.09.03
mysql 컴파일시 옵션 설명  (0) 2018.09.03
mysql select 문  (0) 2018.09.03
mysql 케릭터셋  (0) 2018.09.03
mysql 로그 설정  (0) 2018.09.03

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열만 나열

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

'job > mysql' 카테고리의 다른 글

mysql history 로그 설정  (0) 2018.09.03
mysql 컴파일시 옵션 설명  (0) 2018.09.03
mysql select 문  (0) 2018.09.03
mysql 케릭터셋  (0) 2018.09.03
mysql 로그 설정  (0) 2018.09.03
mysql 계정생성등  (0) 2018.09.03

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

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

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

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

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

'job > mysql' 카테고리의 다른 글

mysql 컴파일시 옵션 설명  (0) 2018.09.03
mysql select 문  (0) 2018.09.03
mysql 케릭터셋  (0) 2018.09.03
mysql 로그 설정  (0) 2018.09.03
mysql 계정생성등  (0) 2018.09.03
mysql update  (0) 2018.08.31

에러 로그

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

'job > mysql' 카테고리의 다른 글

mysql select 문  (0) 2018.09.03
mysql 케릭터셋  (0) 2018.09.03
mysql 로그 설정  (0) 2018.09.03
mysql 계정생성등  (0) 2018.09.03
mysql update  (0) 2018.08.31
데이터 원본 이름이 없고 기본 드라이버를 지정하지 않았습니다.  (0) 2018.08.31

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'); 


'job > mysql' 카테고리의 다른 글

mysql 케릭터셋  (0) 2018.09.03
mysql 로그 설정  (0) 2018.09.03
mysql 계정생성등  (0) 2018.09.03
mysql update  (0) 2018.08.31
데이터 원본 이름이 없고 기본 드라이버를 지정하지 않았습니다.  (0) 2018.08.31
FATAL ERROR: Could not find ./bin/my_print_defaults  (0) 2018.08.31

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부터는 재시작없이 설정가능

+ Recent posts